Ingeniería de Software II

Transcripción

1 Ingeniería de Software II Segundo Cuatrimestre 2007 Clase 1b: Modelos de Ciclo de Vida Buenos Aires, 23 de Agosto de 2007 Qué es un modelo del ciclo de vida de un sistema? 8Una representación estandarizada de: 8Las etapas de un desarrollo de software 8Su orden relativo 8Sus criterios de transición 8Esto sirve para planificar, organizar y ejecutar un proyecto 8Un tema largamente discutido 8Una decisión crítica 8Existen cientos de modelos, la mayoría son variaciones de unos pocos 8La clave: la visibilidad 8Project Plan = Lifecycle Model + Project Parameters 2 1

2 Por qué esto es importante? 8Cambiando el modelo de ciclo de vida se hace un tradeoff entre: 8Velocidad del desarrollo 8Calidad del producto 8Visibilidad del proyecto 8Carga de trabajo administrativo 8Disponibilidad de documentación 8Exposición al riesgo 8Relación con el cliente 8Etc 3 Empezando por el más simple Fuente: Steve Mc Connell, Rapid Development, Microsoft Press,

3 El Modelo en Cascada Fuente: Winston W. Royce, Managing the development of large, complex systems. Proceedings of the 1970 WESCON Conference. Ojo, este excelente paper NO propone usar este modelo 5 Problemas con el modelo en cascada 8Se retrasa la detección de problemas críticos 8Idealista pensar en identificar correctamente todos los requerimientos al principio 8No permite implementaciones parciales 8Usuario sólo involucrado al principio y al final We have an increasing awareness that system requirements cannot ever be stated fully in advance, not even in principle, because the user doesn t know them in advance not even in principle. To assert otherwise is to ignore the fact that the development process itself changes the user s perceptions of what is possible, increases his or her insights into the applications environment, and indeed often changes the environment itself. We suggest an analogy with the Heisenberg Uncertainty Principle: any system development activity inevitably changes the environment out of which the need for the system arose. System development methodology must take into account that the user, and his or her need and environment, change during the process. Life cycle concept considered harmful. Michael A. Jackson and Daniel D. Mc Cracken. ACM Software Engineering Notes. Abril de

4 El Salmon Waterfall Fuente: Steve Mc Connell, Rapid Development, Microsoft Press, Mejoras del modelo en cascada (Royce) Diseñar antes de analizar. Similar idea: prototipos 8 4

5 Otras mejoras: Sashimi Fuente: Steve Mc Connell, Rapid Development, Microsoft Press, Waterfall con Subproyectos Fuente: Steve Mc Connell, Rapid Development, Microsoft Press,

6 Waterfall con Prototipo (o risk reduction ) Requerimientos Inciales Diseño Prototipo Construcción Prueba Prototipo para descartar: se utiliza para validar requerimientos y resolver aspectos críticos del diseño Instalación 11 Prototipos (en la realidad) Requerimientos Inciales Más código Prototipo Más código aún Prototipo Mejorado Prueba El Prototipo para descartar nunca se descarta... Instalación Problemas de calidad 12 6

7 Modelos iterativos e incrementales Iterativo: hacemos varias veces lo mismo Incrementales: El producto se incrementa a medida que avanzamos También llamados evolutivos 13 Modelos iterativos e incrementales 8Principales ventajas 8El usuario ve algo rápidamente 8Se admite que lo que se está construyendo es el sistema, y por lo tanto se piensa en su calidad desde el principio 8Se pueden atacar los principales riesgos 8Los ciclos van mejorando con las experiencias de los anteriores 14 7

8 El Modelo en Espiral (Boehm) Determine objectives alternatives and constraints Plan next p hase REVIEW Requirements plan Life-cycle plan Development plan Integration and test plan Risk analysis Risk analysis Risk analysis Prototype 2 Risk analysis Prototy pe 1 Concept of Operation S/W requirements Requirement valid ati on Design V&V Service Acceptance test Evaluate alternatives id en tify, resolve risk s Prototype 3 Operati onal protoyp e Simulations, models, b en ch marks Product design Code Unit test Integr ation test Detailed design Develop, verify next-level product 15 El modelo en espiral 8En un artículo que tiene tantas interpretaciones como lectores, Boehm propuso su modelo en espiral 8Ideas básicas 8El desarrollo debe ser incremental 8Un criterio para seleccionar las funciones es: primero las más riesgosas, las que pueden hacer fracasar el proyecto 8Cuidado, lo más riesgoso puede no ser lo más difícil, debemos hacer un buen análisis de riesgos 16 8

9 Variaciones de modelos iterativos UP / RUP 17 Variaciones SCRUM Daily Scrum Meeting 24 horas Estimation Meeting 30 días Sprint Backlog Product Backlog Incremento del Producto 18 9

10 En la práctica 8Analizar diferentes factores: 8Inestabilidad de requerimientos / novedad del producto Mayor peso al enfoque evolutivo 8Posibilidad concreta de partir el desarrollo Iteraciones más cortas 8Arquitectura más compleja Enfoque de atacar riesgos desde el inicio 8Mayor complejidad del negocio No descuidar la especificación 19 10