El diagrama de secuencia de uml muestran la forma en que los objetos se comunican entre si al transcurrir el tiempo.
Los diagramas de secuencia, formalmente diagramas de traza de eventos o de interacción de objetos, se utilizan con frecuencia para validar los casos de uso.
El diagrama muestra:
Los objetos participando de la interacción
La secuencia de mensajes intercambiados
Un diagrama de secuencia contiene:
Objetos con su línea de vida
Mensajes intercambiados entre objetos de una secuencia ordenada
Línea de vida activa
Objetivo
Descubrir las interfaces requeridas para cada objeto y validar que cada interface se usa realmente.
El diagrama de Secuencias modela interacciones entre objetos. Ya que estas interacciones pueden ser muy complejas, se modelan un pequeño juego de interacciones como un solo escenario.
Vídeo
El siguiente vídeo es una explicación de lo que es un diagrama de secuencia, nos menciona cual es su utilidad y cuales son sus componentes.
A diferencia del vídeo anterior, este vídeo menciona de forma más detallada los elementos del diagrama de secuencia, con la ventaja de que muestra una aplicación en la vida diaria y explica como se resuelven.
UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de Modelado”.
UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory.
Principales Beneficios
Mejores tiempos totales de desarrollo (de 50 % o más).
Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
Mejor soporte a la planeación y al control de proyectos.
Alta reutilización y minimización de costos.
Conceptos
Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.
Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.
Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.
FASES DEL DESARROLLO DE UN SISTEMA
Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas.
Análisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de software.
Análisis
La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.
Diseño
En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación.
Programación
En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.
Vídeo
Este vídeo describe de forma concreta que es UML, menciona el uso que tiene así como también cuales son los diferentes tipos de diagramas que lo componen.
Es servir como medio de comunicación entre clientes, usuarios, ingenieros de requisitos y des arrolladores. En la especificación de requerimientos del sistema deben recogerse tanto las necesidades de clientes y usuarios (necesidades del negocio, también conocidas como requisitos de usuario, requisitos de cliente, necesidades de usuario, etc.) como los requisitos que debe cumplir el sistema software a desarrollar para satisfacer dichas necesidades (requisitos del producto, también conocidos como requisitos de sistema o requisitos software).
¿Qué es?
Un documento consensuado* entre todas las partes y tener un carácter contractual, de forma que cualquier cambio que se desee realizar en él una vez acordada la primera línea base deba aplicarse siguiendo el Procedimiento de Control de Cambios establecido en el proyecto.
Requerimientos funcionales
Expresan la naturaleza del funcionamiento del sistema
(cómo interacciona el sistema con su entorno y cuáles
van a ser su estado y funcionamiento).
NOTA: A veces, también es conveniente
indicar lo que no hará el sistema.
Requerimientos no funcionales
Restricciones sobre el espacio de posibles soluciones.
Rendimiento del sistema:
Fiabilidad, tiempo de respuesta, disponibilidad
Interfaces:
Dispositivos de E/S, usabilidad, interoperabilidad*
Proceso de desarrollo:
Estándares, herramientas, plazo de entrega
Vídeo
Este vídeo explica minuciosamente los requisitos funcionales y no funcionales de un sistema.
*Adoptar una decisión de común acuerdo entre dos o más partes: la decisión fue consensuada por todos los partidos.
*El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) define interoperabilidad como la habilidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada.
El estudio de factibilidad es el análisis que lleva a cabo una empresa para determinar si el negocio que se propone será bueno o malo, y cuales serán las estrategias que se deben desarrollar para que sea exitoso.
Objetivos
Reducción de errores y mayor precisión en los procesos.
Reducción de costos mediante la optimización o eliminación de los recursos no necesarios.
Integración de todas las áreas y subsistemas
Actualización y mejoramiento de los servicios a clientes o usuarios.
Hacer un plan de producción y comercialización.
Aceleración en la recopilación de los datos.
Reducción en el tiempo de procesamiento y ejecución de las tareas.
Automatización óptima de procedimientos manuales.
Disponibilidad de los recursos necesarios para llevar a cabo los objetivos señalados.
Saber si es posible producir con ganancias.
Conocer si la gente comprará el producto.
Factibilidad Operacional
Comprende una determinación de posibilidad que un nuevo sistema se use como se supone. Se deben considerar cuatro aspectos:
La utilización de un nuevo sistema puede ser demasiado complejo para los usuarios de la organización o los operadores del sistema.
Este nuevo sistema puede hacer que los usuarios se resistan a él como consecuencia de una técnica de trabajo, miedo a ser desplazado u otras razones.
Un sistema nuevo puede introducir cambios demasiado rápidos que no permita al personal adaptarse a él y aceptarlo.
La probabilidad de obsolescencia en el sistema. Cambios anticipados en la práctica o políticas administrativas pueden hacerse que un nuevo sistema sea obsoleto muy pronto.
Factibilidad Técnica
Permite evaluar si el equipo y software están disponibles y tienen las capacidades técnicas requeridas por cada alternativa del diseño que se esté planificando, también se consideran las interfaces entre los sistemas actuales y los nuevos.
Así mismo, estos estudios consideran si las organizaciones tienen el personal que posee la experiencia técnica requerida para diseñar, implementar, operar y mantener el sistema propuesto.
Factibilidad Económica
Dentro de estos estudios se pueden incluir el análisis de costo y beneficios asociados con cada alternativa del proyecto.
Con análisis de costo/beneficios, todos los costos y beneficios de adquirir y operar cada sistema alternativo se identifican y se establece una comparación entre ellos. Esto permite seleccionar el más conveniente para la empresa.
Dentro de esta comparación se debe tomar en cuenta lo siguiente:
Se comparan los costos esperados de cada alternativa con los beneficios esperados para asegurarse que los beneficios excedan los costos.
La proporción costo/beneficio de cada alternativa se comparan con las que proporcionan los costos/beneficios de las otras alternativas para escoger la mejor.
Se determinan las formas en que la organización podría gastar su dinero.
Factibilidad de Sistemas
Vídeos
En el vídeo anterior se explica cual es la diferencia entre factibilidad y viabilidad ya que son dos términos diferentes.
Este vídeo relata de forma más detallada el concepto de factibilidad junto con sus derivados como son factibilidad técnica, operativa y económica. Brinda objetivos de la factibilidad y detalla los participantes en el proceso junto con descripción de su trabajo.
Las metodologías Crystal son una familia de metodologías ágiles, donde cada una de ellas está adecuada para un tipo de proyecto. Su creador es el popular Cockburn uno de los firmantes del manifiesto ágil.
El nombre de metodologías Crystal viene de que cada proyecto software puede caracterizarse según dos dimensiones, tamaño y criticidad, al igual que los minerales se caracterizan por dos dimensiones, color y dureza. Y esta es una de las bases de las metodologías Crystal: hay una metodología para cada proyecto, o la escala de Cockburn.
Las metodologías Crystal están caracterizadas por estar centradas en las personas que componen el equipo (de ellas depende el éxito del proyecto) y la reducción al máximo del número de artefactos producidos. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo.
Crystal Clear
Crystal Clear es para equipos de hasta 8 personas o menos y da vital importancia a las personas que componen el equipo de un proyecto, y por tanto sus puntos de estudio son:
Aspecto humano del equipo.
Tamaño de un equipo (número de componentes).
Comunicación entre los componentes.
Distintas políticas a seguir.
Espacio físico de trabajo.
Crystal Clear establece un conjunto de prioridades y principios que sirven de guía para la toma de decisiones así como técnicas.
Prioridades
Eficiencia en el desarrollo: para hacer que los proyectos sean económicamente rentables.
Seguridad en lo que se entrega.
Habitabilidad: hacer que todos los miembros del equipo adopten y sigan las convenciones de trabajo establecidas por el equipo mismo.
Frecuencia en las entregas: entregar al usuario funcionalidad “usable” con una frecuencia de entre 2 semanas y no más de un mes.
Comunicación: Crystal Clear toma como uno de sus pilares a la comunicación. Promueve prácticas como el uso de pizarrones, pizarras y espacios destinados a que todos (miembros del equipo y visitas) puedan ver claramente el progreso del trabajo.
Crecimiento reflexivo : es necesario que el equipo lleve a cabo reuniones periódicas de reflexión que permitan crecer y hacernos más eficientes.
Principios
El grado de detalle necesario en documentar requerimientos, diseño, planeamiento, etc. y varía según el proyecto.
Es imposible eliminar toda documentación pero puede ser reducida logrando un modo de comunicación más accesible, informal y preciso que pueda ser accedido por todos los miembros del equipo.
El equipo ajusta constantemente su forma de trabajo para lograr que cada personalidad encaje con los otros miembros, con el entorno y las particularidades de cada asignación.
Técnicas
Las reuniones diarias (introducidas por la metodología Scrum) acompañan el seguimiento y mantienen el foco en el próximo paso a seguir, y también permiten la discusión productiva de líneas a seguir.
Las reuniones de reflexión periódicas son fundamentales para que los miembros del equipo se expresen abiertamente, para revisar el trabajo hecho y evaluar qué cosas dan resultado y cuáles no o de empezar a trabajar. Todo esto permite ir armando una metodología de trabajo que se adecue al equipo, el proyecto y los tiempos que se manejen.
La guía de trabajo que presenta Crystal Clear es altamente recomendable para equipos pequeños. Da flexibilidad y prioriza la parte humana (como todas las Metodologías Agiles), apuntando a lograr eficiencia, habitabilidad y confianza en los miembros del equipo. Presta especial importancia a la ubicación física del grupo, donde la comunicación cumple el principal rol. La entrega frecuente de código confiable y “funcionando” mantiene el foco y evita distracciones. El equipo es el que elige qué técnicas aplicar según lo que consideren apropiado en cada proyecto.
Ventajas y Desventajas Crystal Clear
Ventajas
Es apropiada para entornos ligeros
Al estar diseñada para el cambio experimenta reducción de costo.
Presenta una planificación más transparente para los clientes.
Se definen en cada iteración cuales son los objetivos de la siguiente.
Permite tener una muy útil realimentación de los usuarios.
Desventajas
Delimita el alcance del proyecto con el cliente.
Roles
Patrocinador. Produce la Declaración de Misión con Prioridades de Compromiso
Usuario Experto. Junto con el Experto en Negocios produce la Lista de Actores Objetivos y el Archivo de Casos de Uso y Requerimientos.
Diseñador Principal. Produce la Descripción Arquitectónica. Se supone que debe ser al me nos un profesional de Nivel 3
Diseñador Programador. Produce, junto con el Diseñador Principal, los Borradores de Pantallas
Experto en Negocios. Junto con el Usuario Experto produce la Lista de Actores Objetivos.
Coordinador. Con la ayuda del equipo, produce el Mapa de Proyecto, el Plan de Entr ega, el Estado del Proyecto.
¿Qué es metodología para el Desarrollo de Software?
Son procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software.
Desde un punto de vista general puede considerarse que el ciclo de vida de un software tiene tres etapas claramente diferenciadas, las cuales se detallan a continuación:
Planificación: idearemos un planeamiento detallado que guíe la gestión del proyecto, temporal y económicamente.
Implementación: acordaremos el conjunto de actividades que componen la realización del producto.
Puesta en producción: nuestro proyecto entra en la etapa de definición, allí donde se lo presentamos al cliente o usuario final, sabiendo que funciona correctamente y responde a los requerimientos solicitados en su momento. Esta etapa es muy importante no sólo por representar la aceptación o no del proyecto por parte del cliente o usuario final sino por las múltiples dificultades que suele presentar en la práctica, alargándose excesivamente y provocando costos no previstos.
Finalidad de una metodología
Lo que buscamos guiándonos con una metodología es prolijidad, corrección y control en cada etapa del desarrollo de un programa. Lo que nos permitirá una forma sistemática para poder obtener un producto correcto y libre de errores.
Clasificación de las metodologías
Existen dos metodologías que tienen analogía en la práctica con los paradigmas de programación. Metodología estructurada y metodología orientada a objetos.
Metodología estructurada: la orientación de esta metodología se dirige hacia los procesos que intervienen en el sistema a desarrollar, es decir, cada función a realizar por el sistema se descompone en pequeños módulos individuales. Es más fácil resolver problemas pequeños, y luego unir cada una de las soluciones, que abordar un problema grande.
Metodología orientada a objetos: a diferencia de la metodología mencionada anteriormente, ésta no comprende los procesos como funciones sino que arma módulos basados en componentes, es decir, cada componente es independiente del otro. Esto nos permite que el código sea reutilizable. Es más fácil de mantener porque los cambios están localizados en cada uno de estos componentes.
Metodologías ágiles y tradicionales
Las metodologías ágiles proporcionan una serie de pautas y principios junto a técnicas pragmáticas* que puede que no curen todos los males pero harán la entrega del proyecto menos complicada y más satisfactoria tanto para los clientes como para los equipos de entrega.
Entre las metodologías ágiles más destacadas hasta el momento se pueden nombrar:
• XP (Extreme Programming)
• Scrum
• Crystal Clear
• DSDM (Dynamic Systems Developmemt Method)
• FDD (Feature Driven Development)
• ASD (Adaptive Software Development)
• XBreed
• Extreme Modeling
Aquellas con mayor importancia en la planificación y control del proyecto, en donde se especifican todos los requisitos y modelado, reciben el apelativo de Metodologías Tradicionales o Pesadas.
Entre las metodologías tradicionales o pesadas podemos citar:
• RUP (Rational Unified Procces)
• MSF (Microsoft Solution Framework)
• Win-Win Spiral Model
• Iconix
En el video se pueden mostrar algunos ejempolos de metodología ya explicados más a fondo.
