jueves, 30 de mayo de 2019

Proyecto 1







Bibliografía
Ø Tema 1: Proyectos
Ø Tema 2: Ciclo de la vida del proyecto del software
Ø Tema 3: Identificación de diagramas UML

VÍDEO UML  
https://www.youtube.com/watch?v=UI6lqHOVHic



Ø Tema 1: Proyectos
        1.1 ¿Qué es un proyecto?

Un proyecto es un conjunto de acciones que se planifican a fin de conseguir una meta u objetivo previamente establecido, para lo que se cuenta con una determinada cantidad de recursos y tiempo

        1.2 Tipos de Proyecto

Proyecto comunitario o social: conjunto de actividades orientadas a crear el producto, servicio o resultado que satisfaga las necesidades más urgentes de una comunidad.
Ejemplo: 1.- Proyectos para brindar ayuda a niños de la calle
2.- Proyecto para la construcción de áreas o espacios dentro de una zona a beneficio de la sociedad o comunidad.
Son ejecutados por:
*Algún miembro de la sociedad      *Gobierno       *Grupo social existente
Proyecto de vida: Representa, en su conjunto, “lo que el individuo quiere ser” y “lo que él va a hacer” durante toda su vida.
Son ejecutados por:
*Un solo individuo de la sociedad
Proyecto productivo: Son proyectos que buscan generar estabilidad económica y obtener ganancias en dinero.
Son ejecutados por:
*Empresas                    *negocios                 *inversionistas               *empresarios             *organizaciones           *corporativos
Proyecto de informática: Representa, la elaboración de alguna aplicación, software de base de datos, pagina web, o producto tecnológico Con el fin de mejorar por medio de la tecnología nuestra vida cotidiana.
Son ejecutados por:
*Ingenieros en sistemas         * Diseñadores de sistemas          * Programadores
*Técnicos                                   *Diseñadores gráficos                  *Informáticos.

1.3   Concepto de planeación de proyectos de software

La planificación de proyectos forma parte de la gestión de proyectos, la cual se vale de cronogramas tales como diagramas de Gantt para del progreso dentro del entorno del proyecto. ​ Es el proceso para cuantificar el tiempo y recursos que un proyecto costará.

Ø Tema 2: Ciclo de la vida del proyecto del software

2.1 Concepto de ciclo de vida del software
Es el proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y retiro del sistema. Se definen las distintas fases intermedias que se requieren para validar el desarrollo de un software, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo, se asegura de que los métodos utilizados son apropiados.

2.2 Descripción de tipos de ciclos de vida del desarrollo del software

INGENIERÍA DE SISTEMAS
En esta etapa el analista luego de un minucioso y detallado estudio de los sistemas de una organización, detecta un problema o una necesidad que para su solución y/o satisfacción es necesario realizar un desarrollo de software.
ANÁLISIS
En esta etapa se debe entender y comprender de forma detallada cual es la problemática a resolver, verificando el entorno en el cual se encuentra
Ingeniería, descripción o análisis.
DISEÑO
Una vez que se tiene la suficiente información del problema solucionar, es importante determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa es conocida bajo el CÓMO se va a solucionar.
CODIFICACIÓN E IMPLEMENTACIÓN:
partiendo del análisis y diseño de la solución, en esta etapa se procede a desarrollar el correspondiente programa que solucione el problema mediante el uso de una herramienta computacional determinada (Lenguaje de programación tales como: C++, Java, C#, Cobol, PHP, ASP, JSP entre otros.).
PRUEBAS Y DEPURACION:
 Los errores humanos dentro de la programación de los computadores son muchos y aumentan considerablemente con la complejidad del problema. Cuando se termina de escribir un programa de computador, es necesario realizar las debidas pruebas que garanticen el correcto funcionamiento de dicho programa bajo el mayor número de situaciones posibles alas que se pueda enfrentar.
 DOCUMENTACIÓN
Es la guía o comunicación escrita en sus diferentes formas, ya sea en enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un programa. La importancia de la documentación radica en que a menudo un programa escrito por una persona, es modificado por otra
IMPLANTACIÓN
 en esta etapa se instala el software en los dispositivos computacionales y se pone en marcha la ejecución e utilización del software.
MANTENIMIENTO
una vez instalado un programa y puesto en marcha para realizar la solución del problema previamente planteado o satisfacer una determinada necesidad, es importante mantener una estructura de actualización, verificación y validación que permitan a dicho programa ser útil y mantenerse actualizado según las necesidades o requerimientos planteados durante su vida útil.

2.3 Descripción de las etapas del ciclo de vida del software Cascada
Diseño, desarrollo, implementación, pruebas, mantenimiento.
Este modelo asume que todo se lleva a cabo y tiene lugar tal y como se había planeado en la fase anterior, y no es necesario pensar en asuntos pasados que podrían surgir en la siguiente fase. Este modelo no funcionará correctamente si se dejan asuntos de lado en la fase previa. La naturaleza secuencial del modelo no permite volver atrás y deshacer o volver a hacer acciones. Este modelo es recomendable cuando el desarrollador ya ha diseñado y desarrollado softwares similares con anterioridad, y por eso está al tanto de todos sus dominios.

Modelo repetitivo

Este modelo guía el proceso de desarrollo de software en repeticiones. Proyecta el proceso de desarrollo de forma cíclica repitiendo cada paso después de cada ciclo en el proceso de SDLC. El software primero se desarrolla en menor escala y se siguen y tienen en consideración todos los pasos. Entonces, por cada repetición, más módulos y características son diseñados, codificados, evaluados y añadidos al software. Cada ciclo produce un software completo, con más características y capacidad que los previos. Después de cada repetición, el equipo directivo puede concentrarse en la gestión de riesgos y prepararse para la siguiente repetición. Como el ciclo incluye pequeñas porciones de la totalidad del proceso software, es más fácil gestionar el proceso de desarrollo, pero a la vez se consumen más recursos.

Modelo en espiral

El modelo en espiral es una combinación de ambos modelos, el repetitivo y uno del modelo SDLC. Se puede ver como si se combina un modelo de SDLC combinado con un proceso cíclico (modelo repetitivo). Este modelo considera el riesgo, factor que otros modelos olvidan o no prestan atención en el proceso. El modelo empieza determinando los objetivos y las limitaciones del software al inicio de cada repetición. En la siguiente etapa se crean los modelos de prototipo del software. Esto incluye el análisis de riesgos. Luego un modelo estándar de SDLC se usa para construir el software. En la cuarta etapa es donde se prepara el plan de la siguiente repetición.

Modelo V

El mayor inconveniente del modelo de cascada es que solo se pasa a la siguiente fase cuando se completa la anterior, por tanto, no es posible volver atrás si se encuentra algún error en las etapas posteriores. El Modelo V aporta opciones de evaluación del software en cada etapa de manera inversa. En cada etapa, se crea la planificación de las pruebas y los casos de pruebas para verificar y validar el producto según los requisitos de la etapa. Por ejemplo, en la etapa de recogida de requisitos, el equipo de evaluadores prepara las pruebas de caso correspondientes a los requisitos. Más tarde, cuando el producto se desarrolla y está preparado para ser evaluado, las pruebas de caso en esta etapa verifican el software y su validez según sus requisitos. Esto hace que tanto la verificación como la validación vayan en paralelo. Este modelo también se conoce como modelo de validación y verificación.

Modelo Big Bang

Este modelo es el modelo con la forma más simple. Requiere poca planificación, mucha programación y también muchos fondos. Este modelo se conceptualiza alrededor de la teoría de creación del universo 'Big Bang'. Tal como cuentan los científicos, después del big bang muchas galaxias, planetas y estrellas evolucionaron. De la misma manera, si reunimos muchos fondos y programación, quizá podemos conseguir el mejor producto de software. Para este modelo, se requiere poca planificación. No sigue ningún proceso concreto, y a veces el cliente no está seguro de las futuras necesidades y requisitos. Por tanto, la entrada o input respecto a los requisitos es arbitraria. Este modelo no es recomendable para grandes proyectos de software, pero es bueno para aprender y experimentar.
Ø Tema 3: Identificación de diagramas UML

3.1 Concepto de UML y objetivo

UML es un lenguaje con un alcance muy grande y que cubre diversos conjuntos de dominios arquitectónicos en el diseño de aplicaciones. Por ello, no todas sus capacidades de modelados son necesariamente útiles en todos los dominios o aplicaciones. UML permite seleccionar sólo aquellas partes del lenguaje que sean realmente útiles. El objetivo de UML es “proporcionar a desarrolladores de software, arquitectos de sistemas e ingenieros de software de herramientas para el análisis, diseño e implementación de sistemas basados en software, así como modelar procesos de negocio y similares. El modelado captura las partes esenciales del sistema

3.2 Tipos de diagramas de UML

Diagramas de uso

Los Casos de Uso no forma parte de la llamada Fase de Diseño, sino parte de la fase de Análisis, respondiendo el interrogante ¿Qué?. De forma que al ser parte del análisis ayuda a describir que es lo que el sistema debe hacer.

Estos diagramas muestran operaciones que se esperan de una aplicación o sistema y como se relaciona con su entorno, es por ello que se ve desde el punto de vista del usuario. Describen un uso del sistema y como éste interactúa con el usuario.

Los casos de usos se representan en el diagrama por una elipses la cual denota un requerimiento solucionado por el sistema.
Diagrama de clases
En UML el diagrama de clases es uno de los tipos de diagramas o símbolo estático y tiene como fin describir la estructura de un sistema mostrando sus clases, atributos y relaciones entre ellos.
Estos diagramas son utilizados durante el proceso de análisis y diseño de los sistemas informáticos, en donde se intentan conformar el diagrama conceptual de la información que se manejará en el sistema.
Como ya sabemos UML es un modelado de sistema Orientados a Objetos, por donde los conceptos de este paradigma se incorporan a este lenguaje de modelado.
Los diagramas de clases tienen las siguientes características:
·         Las clases define el ámbito de definición de un conjunto de objetos.
·         Cada objeto pertenece a una clase.
·         Los objetos se crean por instanciación de las clases.
Diagrama de objetos
Forma parte de la vista estática del sistema. En este diagrama se modelan las instancias de las clases del Diagrama de Clases. Este diagrama cabe aclarar que cuenta con objetos y enlaces. En estos diagramas también es posible encontrar las clases para tomar como referencia su instanciación. 
En otras palabras, el Diagrama de Objetos muestra un conjunto de objetos y sus relaciones en un momento concreto. Los Diagramas de Objetos son realmente útiles para modelar estructuras de datos complejas
Diagrama de Estados

Un estado es una condición durante la vida de un objeto, de forma que cuando dicha condición se satisface se lleva a cabo alguna acción o se espera por un evento.

 El estado de un objeto se puede caracterizar por el valor de uno o varios de los atributos de su clase, además, el estado de un objeto también se puede caracterizar por la existencia de un enlace con otro objeto.

El diagrama de estados engloba todos los mensajes que un objeto puede enviar o recibir, en otras palabras es un escenario que representa un camino dentro de un diagrama.

Como característica de estos diagramas siempre cuentan con dos estados especiales, el inicial y el final, con la particularidad que este diagrama puede tener solo un estado inicial pero varios estados finales.
Una transición entre estados representa un cambio de un estado origen a un estado sucesor destino que podría ser el mismo que el estado origen, dicho cambio de estado puede estar aparejado con alguna acción. Además, las acciones se asocian a las transiciones y se consideran que ocurre de forma rápida e interrumpible. 
Los elementos que componen estos diagramas son:
Círculo lleno, apuntando el estado inicial.
·        Círculo hueco que contiene un círculo lleno más pequeño en el interior, indicando el estado final.
·        Rectángulo redondeado dividido por una línea horizontal, indicado los estados, en la parte de arriba se encuentra el nombre del estado y abajo se indica la actividad que realiza.
·         Flecha, la cual denota la transición, el nombre del evento que causa esta transición etiqueta el cuerpo de la flecha.
Diagrama de actividad

Un Diagrama de Actividades representa un flujo de trabajo paso a paso de negocio y operacionales de los componentes en un sistema.

En UML 1, un diagrama de actividades es una variación del Diagrama de Estados UML donde los estados representan operaciones y las transiciones representan las actividades que ocurren cuando la operación es completa.

En la actualidad, el diagrama de actividades en UML 2.0 es similar al aspecto del diagrama en UML 1, solo que ahora la semántica está basada en lo que se conoce como Redes de Petri. En UML 2.0, el diagrama general de interacción está basado en el diagrama de Actividad.

Componentes:
·         Inicio: el inicio de un diagrama de actividades es representado por un círculo de color negro sólido.
·         Actividad: Una actividad representa la acción que será realizada por el sistema la cual representa dentro de un óvalo.

·         Transición: Una transición ocurre cuando se lleva acabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar su dirección.

Diagrama de Secuencia

Un Diagrama de Secuencias muestra una interacción ordenada según la secuencia temporal de eventos y el intercambio de mensajes. Los diagramas diagramas de secuencia ponen especial énfasis en el orden y el momento en el que se envían los mensajes a los objetos.

En los diagramas de Secuencias los elementos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta.

Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamado hasta que el método finalice, o asíncronos donde se devuelve el control directamente al objeto que realiza la llamada.

Los mensajes síncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa.
Diagrama de Colaboración

Un diagrama de colaboración, se puede decir que es una forma alternativa al diagrama de secuencias a la hora de mostrar un escenario.

Este tipo de diagrama muestra las interacciones que ocurren entre los objetos que participan en una situación determinada.

A diferencia del diagrama de secuencia, el diagrama de colaboración se enfoca en la relación entre los objetos y su topología de comunicación.
Diagrama de componentes
Lo que distingue el Diagrama de Componentes de otro tipo de diagramas es sin duda su contenido. Normalmente contiene componentes, interfaces y relaciones entre ellos. Los componentes perteneces a un mundo físico, es decir, representan a un bloque de construcción al modelar aspectos físicos de un sistema.
Cada componente debe tener un nombre que lo distinga de los demás. Al igual que las clases los componentes pueden enriquecerse con compartimientos adicionales que muestran sus detalles.
Diagrama de Despliegue
Básicamente este tipo de diagrama se utiliza para modelar el Hardware utilizado en la implementación del sistema y la relaciones entre sus componentes.
Los elementos usados por este tipo de diagrama son nodos, componentes y asociaciones. En el UML 2.0 los componentes ya no están dentro de nodos, en cambio puede haber artefactos (archivo, un programa, una biblioteca o Base de datos) u otros nodos dentro de nodos.
Además, los Diagramas de Despliegue muestran la configuración en funcionamiento del sistema incluyendo su software y su hardware. Para cada componente de un diagrama es necesario que se deba documentar las características técnicas requeridas, el tráfico de red, el tiempo de respuesta, etc.

3.3 Ejemplifica cada uno
  •  Clases



  •  Objetos

  • Casos de uso

  • De secuencia

  • De colaboración

  • De transición de estado

  • De actividad

  • De componentes

  • De despliegue


  • VÍDEO UML