Tema 2. El Ciclo de Vida del Software (ISG1-ITIG)

Transcripción

1 Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Grupo de Ingeniería del Software Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual España 1

2 Objetivos del Tema Qué es el ciclo de vida del software Tipos de ciclos de vida Conocer el ciclo de vida de algunas metodologías ampliamente conocidas Agilización del ciclo de vida 2

3 Índice Definición del ciclo de vida Tipos de ciclos de vida Prototipos y Componentes software Ingeniería inversa y re-ingeniería El ciclo de vida de Métrica 3 El Modelo de Proceso Unificado Agilidad 3

4 Definición de Ciclo de Vida Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto software, abarcando la vida del sistema desde la definición hasta la finalización de su uso (ISO 12207). El ciclo de vida de un proyecto especifica el enfoque general del desarrollo, indicando los procesos, actividades y tareas que se van a realizar y en qué orden, y los productos que se van a generar, los que se van a entregar al cliente y en qué orden se van a entregar. 4

5 Índice Definición del ciclo de vida Tipos de ciclos de vida Prototipos y Componentes software Ingeniería inversa y re-ingeniería El ciclo de vida de Métrica 3 El Modelo de Proceso Unificado Agilidad 5

6 Ciclo de vida clásico (en cascada) Análisis Desarrollo Diseño Codificación Pruebas Mantenimiento 6

7 Ciclo de vida clásico (en cascada) Cada proceso comienza cuando termina el anterior. Los desarrollos reales presentan iteraciones. Es difícil obtener todos los requisitos al comienzo. Se tarda mucho en disponer del software. Es mejor que no seguir ningún ciclo de vida. Es el más fácil de planificar, es el ciclo ideal. 7

8 C.V. Cascada con Subsistemas Análisis del sistema Diseño del sistema Análisis del software Análisis del software Diseño del software Diseño del software Codificación Codificación Pruebas del software Pruebas Subsistema del Software software 1 Subsistema Software 2 Subsistema Hardware 1 Integración de subsistemas Pruebas del sistema 8

9 C.V. Cascada con Subsistemas En el caso del desarrollo de sistemas, el ciclo de vida tiene dos niveles: sistema y hardware/software. El diseño se suele dividir en diseño de la arquitectura y en diseño detallado 9

10 Ciclos de vida evolutivos Requisitos Desarrollo Evaluación Versiones 10

11 Ciclos de vida evolutivos Cuanto mayor es un proyecto, menor es su probabilidad de éxito (Informes CHAOS). Conseguir obtener todos los requisitos al comienzo del proyecto es prácticamente imposible. Las necesidades de clientes y usuarios evolucionan durante el desarrollo y surgen nuevos requisitos. Los ciclos de vida evolutivos afrontan estos problemas mediante ciclos requisitos-desarrolloevaluación. El resultado de la evaluación permite evolucionar hacia la siguiente versión. 11

12 Ciclo de vida incremental Análisis Análisis Análisis Diseño Diseño Diseño Codificación Codificación Codificación Pruebas Pruebas Pruebas Versión 1 Funcionalidad 1 Versión 2 + Funcionalidad 2 Versión 3 + Funcionalidad 3 12

13 Ciclo de vida incremental Es una repetición de varios ciclos de vida en cascada. Al final de cada ciclo se entrega una versión parcial del software incrementada con cierta funcionalidad nueva respecto a las entregas anteriores. Los ciclos se repiten hasta obtener un producto completo. Los usuarios disponen antes del software, aunque no sea completo, por lo que pueden sugerir mejoras. Se suele aplicar a desarrollos de gran tamaño. 13

14 Ciclo de vida iterativo Análisi s Análisi s Análisi s Diseño Diseño Diseño Codificació n Codificació n Codificació n Prueba s Prueba s Prueba s Versión 1 Versión 2 Versión 3 Iteración 1 Iteración 2 Iteración 3 14

15 Ciclo de vida iterativo Es también una repetición de varios ciclos de vida en cascada. Al final de cada ciclo se entrega una versión completa del software mejorada respecto a la anterior. Los ciclos se repiten hasta obtener un producto satisfactorio. Los usuarios deben evaluar el producto en cada iteración y proponer mejoras. Se suele aplicar en desarrollos en los que los requisitos no están claros, las primeras versiones pueden ser prototipos que se desechan posteriormente. 15

16 Índice Definición del ciclo de vida Tipos de ciclos de vida Prototipos y Componentes software Ingeniería inversa y re-ingeniería El ciclo de vida de Métrica 3 El Modelo de Proceso Unificado Agilidad 16

17 Prototipos Ej C.V. Clásico Prototipo Requisitos Desarrollo Análisis Diseño Prototipos Algoritmos Codificación Pruebas Mantenimiento 17

18 Prototipos El uso de prototipos no es exclusivo del ciclo de vida iterativo. Los prototipos se pueden usar como una herramienta para obtener y validar los requisitos de clientes y usuarios en cualquier ciclo de vida. Lo habitual es usar prototipos de interfaz de usuario, que pueden reutilizarse (ejecutables) o desecharse (papel). Siempre se debe evaluar si el esfuerzo de desarrollo del prototipo merece la pena (coste de errores). 18

19 Prototipos Es fundamental la implicación de los usuarios. Otro tipo de prototipos pueden utilizarse para evaluar diferentes algoritmos antes de tomar decisiones de diseño. Siempre se debe tener en cuenta que el prototipo no es el producto final, ya que su calidad no suele ser la necesaria. 19

20 Componentes software Identificar componente necesario Seleccionar proveedor componente existe no existe Comprar componente Desarrollar componente Catalogar componente Integrar componente 20

21 Componentes software Cada vez es más frecuente el ensamblaje de componentes software desarrollados por terceros en la construcción de nuevos sistemas software. El uso de componentes tiene implicaciones en todas las actividades del desarrollo desde los requisitos hasta el mantenimiento. 21

22 Índice Definición del ciclo de vida Tipos de ciclos de vida Prototipos y Componentes software Ingeniería inversa y re-ingeniería El ciclo de vida de Métrica 3 El Modelo de Proceso Unificado Agilidad 22

23 Ingeniería inversa y Reingeniería Ingeniería inversa A veces es necesario mantener sistemas heredados (legacy systems) que fueron desarrollados sin documentación. La ingeniería inversa consiste en analizar el resultado de una etapa de software para obtener el resultado de la anterior; normalmente analizar el código para obtener el diseño. 23

24 Ingeniería inversa y Reingeniería Reingeniería La reingeniería utiliza la información obtenida por la ingeniería inversa para aplicar cualquier tipo de mantenimiento (perfectivo, adaptativo, correctivo o preventivo). El mantenimiento preventivo del efecto 2000 ha sido el mayor esfuerzo de ingeniería inversa, reingeniería y mantenimiento en la historia de la Ingeniería del Software. 24

25 Ingeniería inversa y Reingeniería Aspectos Legales En algunos países la ingeniería inversa sin acceso al fuente es delito Ingeniería Inversa Especificaciones Reingeniería Mantenimiento Sistema Original Sistema Adaptado 25

26 Índice Definición del ciclo de vida Tipos de ciclos de vida Prototipos y Componentes software Ingeniería inversa y re-ingeniería El ciclo de vida de Métrica 3 El Modelo de Proceso Unificado Agilidad 26

27 Ciclo de vida en Métrica 3 Gestión de Proyectos Gestión de Configuración Planificación De Sistemas De Información PSI Desarrollo EVS ASI DSI CSI IAS Mantenimiento De Sistemas De Información MSI Seguridad Aseguramiento De Calidad 27

28 Ciclo de vida en Métrica 3 Permite aplicar Diferentes ciclos de vida Métodos estructurados y Orientados a Objetos Procesos básicos: Plan de Sistemas de Información (PSI) Desarrollo de Sistemas de Información Estudio de Viabilidad del Sistema (EVS) Análisis del Sistema de Información (ASI) Diseño del Sistema de Información (DSI) Construcción del Sistema de Información (CSI) Implantación y Aceptación del Sistema (IAS) Mantenimiento de Sist. de Información (MSI) 28

29 Ciclo de vida en Métrica 3 También incluye interfaces con procesos de apoyo Gestión de proyectos Seguridad Gestión de la Configuración Aseguramiento de la Calidad 29

30 Métrica 3 ASI - OO 30

31 Métrica 3 ASI OO - E/S 31

32 Índice Definición del ciclo de vida Tipos de ciclos de vida Prototipos y Componentes software Ingeniería inversa y re-ingeniería El ciclo de vida de Métrica 3 El Modelo de Proceso Unificado Agilidad 32

33 Ciclo de vida del Proceso Unificado Es un ciclo de vida incremental e iterativo propuesto por los creadores de UML (Unified Modeling Language). El proceso unificado define de manera general una estructura para las actividades y productos de un proyecto organizado por fases, iteraciones y flujos de trabajo (organizados por disciplinas). Las fases se suceden en el tiempo con hitos de validación En cada fase se producen iteraciones con entregables Cada iteración cicla entre disciplinas 33

34 Ciclo de vida del Proceso Unificado Está dirigido por casos de uso: las actividades de desarrollo son planeadas y programadas en función de los casos de uso o servicios que cubren las necesidades de los usuarios. Está centrado en la arquitectura: definición de los aspectos estáticos y dinámicos más significativos del sistema. Es iterativo e incremental: el trabajo es dividido en partes más pequeñas o miniproyectos que corresponden a una iteración, que incrementa el producto 34

35 Contexto *UP Cliente Necesidades Desarrollo de Sistema o Entregables Necesidades Cubiertas Sistema, Producto, Entregable Explotación de Sistema o Uso de Entregables 35

36 *UP Desarrollo Versiones Producción Disciplinas de Desarrollo Disciplinas de Apoyo Unified Process OpenUP Retiro Disciplinas de Empresa Gestión de Cartera de Proyectos Arquitectura de Empresa Reutilización Estratégica Gestión de RR.HH. Administración Empresarial Proceso de Mejora de Software Cuadro de Mando Integral CMMI Líneas de Productos ISO 9001:

37 UP / EUP Versión n+1 Fases Comienzo Elaboración Construcción Transición Producción Retiro Iteraciones It. iniciales E1 E2... En C1 C2... Cn T1 T2... Tn Producción R1 R2... Rn Hitos Objetivos del Ciclo de Vida Arquitectura del Ciclo de Vida Capacidad Operativa Inicial Liberación del Producto Objetivos de Retirada del Producto Retirada del Producto *UP/Agile ITIL 37

38 Versión n+1 Disciplinas de Desarrollo Fases Comienzo Elaboración Construcción Transición Producción Retiro Modelado de Negocio Requisitos Análisis y Diseño Implementación Disciplinas de Apoyo Pruebas Despliegue Gestión de Cambios y Configuración Gestión de Proyecto Entorno Operaciones y Soporte Iteraciones Inicial Elab. 1 Elab. 2 Cnst 1 Cnst 2 Cnst N Trn 1 Trn 2 Producción Ret. 1 Ret. 2 Hitos Objetivos del Ciclo de Vida Arquitectura del Ciclo de Vida Capacidad Operativa Inicial Liberación del Producto Objetivos de Retirada del Producto Retirada del Producto Disciplinas de Empresa Modelado de Negocio de Empresa Gestión de Cartera de Proyectos Arquitectura de Empresa Reutilización Estratégica Gestión de RR.HH. Administración Empresarial Proceso de Mejora de Software 38

39 *UP - Elaboración Elaboración Modelado de Negocio Requisitos Análisis y Diseño Implementación Pruebas Despliegue Gestión de Cambios y Configuración Gestión de Proyecto Entorno Operaciones y Soporte Iteraciones Elab. 1 Elab. 2 Hitos Arquitectura del Ciclo de Vida 39

40 *UP Construcción - Transición Construcción Transición Modelado de Negocio Modelado de Negocio Requisitos Requisitos Análisis y Diseño Análisis y Diseño Implementación Implementación Pruebas Pruebas Despliegue Despliegue Gestión de Cambios y Configuración Gestión de Cambios y Configuración Gestión de Proyecto Gestión de Proyecto Entorno Entorno Operaciones y Soporte Operaciones y Soporte Iteraciones Cnst 1 Cnst 2 Cnst N Iteraciones Trn 1 Trn 2 Hitos Capacidad Operativa Inicial Hitos Liberación del Producto 40

41 Índice Definición del ciclo de vida Tipos de ciclos de vida Prototipos y Componentes software Ingeniería inversa y re-ingeniería El ciclo de vida de Métrica 3 El Modelo de Proceso Unificado Agilidad 41

42 El Manifiesto Ágil (2001) Estamos descubriendo mejores formas de desarrollar software, haciéndolo y ayudando a otros a hacerlo. En este trabajo hemos concluido en valorar: Individuos e interacciones sobre procesos y herramientas Software que funcione sobre documentación detallada Colaboración con el cliente sobre negociación de contratos Respuesta al cambio sobre seguimiento de un plan Es decir, mientras que encontramos valiosos los términos de la derecha, consideramos más valiosos los de la izquierda 42

43 Individuos e Interacciones La gente es el principal factor de éxito de un proyecto software. Es más importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a sus necesidades. 43

44 Software que funcione La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisión importante. Estos documentos deben ser cortos y centrarse en lo fundamental. 44

45 Colaboración con el Cliente Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito. 45

46 Respuesta al Cambio La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también e l éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta. 46

47 Ágil vs Tradicional Basadas en heurísticas provenientes de prácticas de producción de código Especialmente preparados para cambios durante el proyecto Impuesta internamente Proceso menos controlado, con pocos principios El contrato es flexible El cliente es parte del equipo de desarrollo Equipos pequeños y/o en contacto físico Pocos artefactos Pocos roles Menor énfasis en la arquitectura Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo Presenta cierta resistencia al cambio Impuesta externamente Proceso muy controlado, con numerosas políticas y normas Contrato prefijado El cliente interactúa formalmente en reuniones Grupos grandes y/o distribuidos Numerosos artefactos Numerosos roles Arquitectura y modelos fundamentales 47

48 Mejora de Valor Valor Valor añadido Objetivo de valor aportado al negocio Mínimo valor aceptable Versión 1.0 Versión 1.0 Tiempo 48

49 Técnicas de Apoyo Refactorización (refactoring) Cambios en el diseño sobre el sistema implementado Pruebas automáticas Pruebas exhaustivas del sistema cuyos resultados se comparan con resultados esperados Integración continua Automatización de la integración de sistemas de modo de permitir pruebas automáticas muy frecuentes Gestión de configuración Hecha de una forma especial para apoyar la interacción y la integración continua 49

50 XP Iniciado en 1996, primer libro publicado en 1999 Extremo: elimina técnicas/procesos de poco valor y sobre-enfatiza procesos de mucho valor Iteraciones de 1 a 4 semanas Historias de usuarios Cliente en las instalaciones Mucho énfasis en pruebas automáticas Hágalo lo más simple posible You aren't gonna need it (YAGNI) 50

51 XP (Resumen) Se basa en implementar user stories en forma iterativa: Planificación: elegir cuáles US implementar y aclararlos Codificación: implementar el US Pruebas automáticas: al menos una por cada clase/método Prueba de aceptación: si pasa, la funcionalidad nueva se acepta; si no, el US correspondiente se rehace en la próxima iteración Los requisitos son poco detallados El cliente debe estar entre los desarrolladores on-site Si hay problemas se corrigen a muy bajo costo Una US es una oración escrita en una tarjeta 51

52 XP (Coste de los Cambios) El error es usualmente 100 veces más caro de corregir en la fase de mantenimiento que en la fase de requisitos. (Barry Boehm, Software Engineering Economics, 1981, p. 40.) 52

53 XP (Ciclo de Creación de Valor) 53

54 XP 54

55 XP 55

56 XP 56

57 XP (Prácticas) El juego del plan Pequeñas entregas (releases) Metáfora Diseño Simple Probar antes de codificar (Test then Code) Refactorizar (Refactoring) Programación en parejas Responsabilidad compartida del código Integración continua Ritmo sostenible (40 horas a la semana) Cliente disponible onsite Estándares de codificación 57

58 XP (Recomendable si...)... se tienen requisitos vagamente definidos o volátiles... se tienen o pueden desarrollar habilidades y prácticas de ingeniería potentes... los clientes se pueden involucrar todos los días (horas) 58

59 Scrum Método de Gestión de Proyecto que se basa en que el desarrollo de proyectos de software es un proceso empírico en lugar de definido, y por lo tanto se debe poner más hincapié en el control que en la predicción Flexibilidad Adaptabilidad Productividad Ken Schwaber & Jeff Sutherland > 1,500 Scrum Master certificados 59

60 Scrum (Resumen) Sprint: Iteración de 30 días Produce código potencialmente entregable Equipos auto-organizados No hay prácticas de ingeniería específicas recomendadas Muchos usan XP Agile Meeting: reuniones cortas y frecuentes donde cada miembro del equipo expone: Qué ha hecho desde la última reunión Qué problemas ha tenido Qué va a ejecutar hasta la próxima reunión 60

61 Scrum (Resumen) Backlog: Lista priorizada de tareas Reemplaza al Diagrama de Gantt Backlog de producto Backlog de iteración 61

62 Scrum (Perfiles) Equipo de Scrum 5 a 10 personas a dedicación completa Auto-organizados Cambios de miembros sólo al final del sprint Propietario del producto Cliente o usuario del proyecto Toma decisiones de priorización Scrum Master No es exactamente el jefe de proyecto Elimina obstáculos Asegura que se usen los valores del Scrum 62

63 Scrum (Proc.) Scrum Reunión rápida diaria Sprint Iteración 63

64 Scrum (Recomendable si...)... los requisitos son cambiantes o emergentes... se está dispuesto a dejar que los equipos se organicen solos... se necesita un modelo de gestión más que un conjunto de prácticas de ingeniería... se necesita un proceso ágil probado y escalable 64

65 Conclusiones El ciclo de vida guía a la ingeniería del software Procesos Actividades Tareas Productos Se debe seleccionar aquel que: Cumpla las restricciones económicas Cumpla las restricciones legales / normativas Se adapte al contexto del equipo y empresa Se adapte al contexto del producto a desarrollar 65