Ciclo de vida software, Metodologías ágiles, Uml

CICLO DE VIDA DE 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.

PROCESOS DEL CICLO DE VIDA DEL SOFTWARE

PROCESOS PRINCIPALES:

• Adquisición
• Suministro
• Explotación
• Mantenimiento

PROCESOS DE SOPORTE:

• Documentación
• Gestión de configuración
• Aseguramiento de calidad
• Verificación
• Validación
• Revisiñon conjunta
• Auditoria
• Resolución de problemas

PROCESOS DE ORGANIZACIÓN:

• Gestión
• Mejora
• Infraestructura
• Formación

PROCESO DE ADQUISICIÓN:

• Análisis de requisitos del sistema
• Diseño de la arquitectura del sistema
• Análisis de los requisitos del software
• Diseño de la arquitectura del software
• Diseño detallado del software
• Codificación y prueba del software

PROCESO DE SUMINSITRO:

• Integración del software
• Prueba del software
• Integración del sistema
• Prueba del sistema
• Instalación del software
• Soporte del proceso de aceptación del software

PROCEDIMIENTOS

• Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.

• Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.

• Diseño general: requisitos generales de la arquitectura de la aplicación.

• Diseño en detalle: definición precisa de cada subconjunto de la aplicación.

• Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.

• Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.

• Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.

• Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.

• Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.

• Implementación

• Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

REUTILIZACIÓN EN EL CICLO DE VIDA

PRINCIPIOS DE REUTILIZACIÓN:

• Existen similitudes entre distintos sistemas de un mismo dominio de aplicación
• El software puede representarse como una combinación de módulos
• Diseñar aplicaciones = especificar módulos + interrelaciones
• Los sistemas nuevos se pueden caracterizar por diferencias respecto a los antiguos

VENTAJAS Y DESVENTAJAS:

• Reduce tiempos y costes de desarrollo
• Aumenta la fiabilidad
• Dificultad para reconocer los componentes potencialmente reutilizables
• Dificultad de catalogación y recuperación
• Problemas de motivación
• Problemas de gestión de configuración

MODELOS DEL CICLO DE VIDA DE SOFTWARE

Modelo de Cascada:

Siguiendo el modelo de cascada de forma estricta, sólo cuando se finaliza una fase, comienza la otra. En ocasiones se realiza una revisión antes de iniciar la siguiente fase, lo que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de cambio). Las revisiones también se utilizan para asegurar que la fase anterior ha sido totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con el término inglés "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente de crítica de los defensores de modelos más flexibles.

Modelo de Espiral:

La principal característica del modelo en espiral es la gestión de riesgos de forma periódica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm, combinando algunos aspectos clave de las metodologías del modelo de cascada y del desarrollo rápido de aplicaciones, pero dando énfasis en un área que para muchos no jugó el papel que requiere en otros modelos: un análisis iterativo y concienzudo de los riesgos, especialmente en el caso de sistema complejos de gran escala.

La espiral se visualiza como un proceso que pasa a través de algunas interacciones con el diagrama de los cuatro cuadrantes representativos de las siguientes actividades:

1. crear planes con el propósito de identificar los objetivos del software, seleccionados para implementar el programa y clarificar las restricciones en el desarrollo del software;
2. Análisis de riesgos: una evaluación analítica de programas seleccionados, para evaluar como identificar y eliminar el riesgo;
3. la implementación del proyecto: implementación del desarrollo del software y su pertinente verificación;

La primera fase es la búsqueda de un plan para conseguir los objetivos con las limitaciones del proyecto para así buscar y eliminar todos los riesgos potenciales por medio de un cuidadoso análisis, y si fuera necesario incluyendo la fabricación de un prototipo. Si es imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el proyecto o seguir adelante ignorando los riesgos. Por último, se evalúan los resultados y se inicia el diseño de la siguiente fase.

Desarrollo Iterativo e Incremental:

El desarrollo iterativo recomienda la construcción de secciones reducidas de software que irán ganando en tamaño para facilitar así la detección de problemas de importancia antes de que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del diseño en el caso de clientes que no saben cómo definir lo que quieren

Desarrollo ágil:

El desarrollo ágil de software utiliza un desarrollo iterativo como base para abogar por un punto de vista más ligero y más centrado en las personas que en el caso de las soluciones tradicionales. Los procesos ágiles utilizan retroalimentación en lugar de planificación, como principal mecanismo de control. La retroalimentación se canaliza por medio de pruebas periódicas y frecuentes versiones del software.

METODOLOGÍAS ÁGILES

SCRUM:

Scrum es una metodología ágil fantástica para desarrolladores. Consiste en un modelo de asignación de tareas diarias basado en reuniones rápidas y control de la evolución de los procesos. Es muy bueno para llevar un seguimiento de las tareas que se están llevando a cabo y saber en que puntos se ha atascado el equipo. Además la profundidad de las tareas que se asignan en SCRUM tiende a ser incremental, y esto coincide exactamente con el devenir normal de un desarrollo.

Los Eventos Scrum:

Los eventos de Scrum se utilizan para minimizar la necesidad de reuniones no definidas en Scrum y establecer una cadencia que permita al equipo fomentar la comunicación y colaboración reduciendo el tiempo en reuniones extensas además de reducir los procesos restrictivos y predictivos. Todos los eventos tienen una caja de tiempo o “TimeBox”. Una vez que se inicia un Sprint este tiene una duración fija y no se puede acortar o alargar. Los siguientes eventos pueden terminar siempre que se logre el propósito del evento, pero dentro de la caja de tiempo y asegurando el fomento de la transparencia. 

Los eventos de Scrum son:

• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Artefactos Scrum:

Los artefactos de Scrum formas para proveer transparencia y oportunidades de inspección y adaptación. Los artefactos definidos por Scrum están específicamente definidos para fomentar la transparencia de la información de tal manera que todos tengan el mismo entendimiento de lo que se está llevando a cabo a través de los artefactos.

Los artefactos Scrum son:

• Product Backlog
• Sprint Backlog
• Increment

XP o XTREAM PROGRAMMING:

Programación Extrema es un método ágil que se suele utilizar en equipos con muy pocos programadres que tienen muy pocos procesos abiertos al mismo tiempo. Consiste principalmente en diseñar, implementar, programar e implantar lo más rápido posible en equipos de programadores muy pequeños, principalmente parejas, saltandose la documentación y los procedimientos tradicionales. Se fundamente el la capacidad del equipo para comunicarse entre si y las ganas de aprender de los errores propios inherentes en un programador. Las gran ventaja que tiene este sistema es la increíble capacidad de respuesta del equipo ante imprevistos, aunque es una metodología para la que es difícil documentar.

Características:

• Se considera al equipo de proyecto como el principal factor de éxito del proyecto
• Software que funciona por encima de una buena documentación.
• Interacción constante entre el cliente y el equipo de desarrollo.
• Planificación flexible y abierta.
• Rápida respuesta a cambios.

Roles:

• Cliente: responsable de definir y conducir el proyecto así como sus objetivos.
• Programadores: estiman tiempos de desarrollo de cada actividad y programan el proyecto.
• Tester: Encargado de Pruebas.
• Tracker: Encargado de Seguimiento.
• Coach: Entrenador. Su papel es guiar y orientar al equipo.
• Big Boss: Gestor del proyecto, gerente del proyecto, debe tener una idea general del proyecto y estar familiarizado con su estado.

XP es un método estupendo para equipos extremadamente pequeños que se centran en un solo cliente.

DESARROLLO LEAN:

Lean Software Development, también conocido como Lean Programming es un conjunto de técnicas que engloban una metodología de desarrollo ágil de software orientado a conseguir exactamente lo que necesita el cliente. Es una evolución del Método Toyota de Producción aplicado al desarrollo y que está muy de moda entre los equipos de desarrollo en startups. Principalmente consiste en ciclos de evolución de software incrementales en los que se postponen las decisiones lo más posible hasta haber obtenido un feedback del cliente y así reaccionar lo más rápido y eficazmente posible a sus necesidades. Se fundamenta en tener un equipo potente y comprometido y el principio de aprendizaje continuo sobre el producto.

El Desarrollo Lean una metodología fantastica para startups que están desarrollando un software orientado a tener éxito en el mercado, como desarrolladores de videojuegos o apps para móviles.

LENGUAJE UNIFICADO DE MODELADO UML

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de modelado visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas de software complejos, tanto en estructura como en comportamiento. UML tiene aplicaciones más allá del desarrollo de software, p. ej., en el flujo de procesos en la fabricación.

Es comparable a los planos usados en otros campos y consiste en diferentes tipos de diagramas. En general, los diagramas UML describen los límites, la estructura y el comportamiento del sistema y los objetos que contiene.

UML no es un lenguaje de programación, pero existen herramientas que se pueden usar para generar código en diversos lenguajes usando los diagramas UML. UML guarda una relación directa con el análisis y el diseño orientados a objetos.

UML ORIENTADO A OBJETOS:

Los lenguajes orientados a objetos dominan el mundo de la programación porque modelan los objetos del mundo real. UML es una combinación de varias notaciones orientadas a objetos: diseño orientado a objetos, técnica de modelado de objetos e ingeniería de software orientada a objetos.

Conceptos:

Los objetos en UML son entidades del mundo real que existen a nuestro alrededor. En el desarrollo de software, los objetos se pueden usar para describir, o modelar, el sistema que se está creando en términos que sean pertinentes para el dominio. Los objetos también permiten la descomposición de sistemas complejos en componentes comprensibles que permiten que se construya una pieza a la vez.

Estos son algunos conceptos fundamentales de un mundo orientado a objetos:

Objetos Representan una entidad y el componente básico.

Clase Plano de un objeto.

Abstracción Comportamiento de una entidad del mundo real.

Encapsulación Mecanismo para enlazar los datos y ocultarlos del mundo exterior.

Herencia Mecanismo para crear nuevas clases a partir de una existente.

Polimorfismo Define el mecanismo para salidas en diferentes formas.

CONCEPTOS DE MODELADO ESPECIFICADO POR UML:

El desarrollo de sistemas se centra en tres modelos generales de sistemas diferentes:

Funcionales: Se trata de diagramas de casos de uso que describen la funcionalidad del sistema desde el punto de vista del usuario.

De objetos: Se trata de diagramas de clases que describen la estructura del sistema en términos de objetos, atributos, asociaciones y operaciones.

Dinámicos: Los diagramas de interacción, los diagramas de máquina de estados y los diagramas de actividades se usan para describir el comportamiento interno del sistema.

TIPOS DE DIAGRAMAS:

Estructurales:

Diagrama de clases

 El diagrama UML más comúnmente usado, y la base principal de toda solución orientada a objetos. Las clases dentro de un sistema, atributos y operaciones, y la relación entre cada clase. Las clases se agrupan para crear diagramas de clases al crear diagramas de sistemas grandes.

Diagrama de componentes 

Muestra la relación estructural de los elementos del sistema de software, muy frecuentemente empleados al trabajar con sistemas complejos con componentes múltiples. Los componentes se comunican por medio de interfaces.

Diagrama de estructura compuesta 

Los diagramas de estructura compuesta se usan para mostrar la estructura interna de una clase.

Diagrama de implementación 

Ilustra el hardware del sistema y su software. Útil cuando se implementa una solución de software en múltiples máquinas con configuraciones únicas.

Diagrama de objetos

 Muestra la relación entre objetos por medio de ejemplos del mundo real e ilustra cómo se verá un sistema en un momento dado. Dado que los datos están disponibles dentro de los objetos, estos pueden usarse para clarificar relaciones entre objetos.

Diagrama de paquetes

 Hay dos tipos especiales de dependencias que se definen entre paquetes: la importación de paquetes y la fusión de paquetes. Los paquetes pueden representar los diferentes niveles de un sistema para revelar la arquitectura. Se pueden marcar las dependencias de paquetes para mostrar el mecanismo de comunicación entre niveles.

De Comportamiento:

Diagramas de actividades 

Flujos de trabajo de negocios u operativos representados gráficamente para mostrar la actividad de alguna parte o componente del sistema. Los diagramas de actividades se usan como una alternativa a los diagramas de máquina de estados.

Diagrama de comunicación 

Similar a los diagramas de secuencia, pero el enfoque está en los mensajes que se pasan entre objetos. La misma información se puede representar usando un diagrama de secuencia y objetos diferentes.

Diagrama de panorama de interacciones 

Hay siete tipos de diagramas de interacciones. Este diagrama muestra la secuencia en la cual actúan.

Diagrama de secuencia 

Muestra cómo los objetos interactúan entre sí y el orden de la ocurrencia. Representan interacciones para un escenario concreto.

Diagrama de máquina de estados 

Similar a los diagramas de actividades, describen el comportamiento de objetos que se comportan de diversas formas en su estado actual.

Diagrama de temporización 

Al igual que en los diagramas de secuencia, se representa el comportamiento de los objetos en un período de tiempo dado. Si hay un solo objeto, el diagrama es simple. Si hay más de un objeto, las interacciones de los objetos se muestran durante ese período de tiempo particular.

Diagrama de caso de uso

 Representa una funcionalidad particular de un sistema. Se crea para ilustrar cómo se relacionan las funcionalidades con sus controladores (actores) internos/externos