1 Ingeniería de Software II - Universidad de Buenos Aires
Anuncio
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: 8 Las etapas de un desarrollo de software 8 Su orden relativo 8 Sus 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 ¿Por qué esto es importante? 8Cambiando el modelo de ciclo de vida se hace un “tradeoff” entre: 8 Velocidad del desarrollo 8 Calidad del producto 8 Visibilidad del proyecto 8 Carga de trabajo administrativo 8 Disponibilidad de documentación 8 Exposición al riesgo 8 Relación con el cliente 8 Etc… 3 Empezando por el más simple… Fuente: Steve Mc Connell, Rapid Development, Microsoft Press, 1996 4 2 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 1982 6 3 El “Salmon Waterfall” 7 Fuente: Steve Mc Connell, Rapid Development, Microsoft Press, 1996 Mejoras del modelo en cascada (Royce) Diseñar antes de analizar. Similar idea: prototipos 8 4 Otras mejoras: Sashimi Fuente: Steve Mc Connell, Rapid Development, Microsoft Press, 1996 9 Waterfall con Subproyectos Fuente: Steve Mc Connell, Rapid Development, Microsoft Press, 1996 10 5 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 Instalación El “Prototipo para descartar” nunca se descarta... Problemas de calidad 12 6 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 8 El usuario ve algo rápidamente 8 Se admite que lo que se está construyendo es el sistema, y por lo tanto se piensa en su calidad desde el principio 8 Se pueden atacar los principales riesgos 8 Los ciclos van mejorando con las experiencias de los anteriores 14 7 El Modelo en Espiral (Boehm) Determ ine ob jectiv es alternatives and cons traint s R isk analys is Ev aluate alt ern atives id en tify, resol ve risk s R isk analys is R isk analys is REVIEW Requi rement s pl an Li fe-cycle pl an Develop ment pl an Plan next p has e Integrati on and t est p lan Prot otyp e 3 Prot otyp e 2 Risk analysis Prot oty pe 1 Operati onal prot oyp e Sim ul ati ons, m odels, b en ch marks C oncept o f Operati on S/W requi rement s Requi rement valid ati on Prod uct desi gn Detail ed desi gn C ode Uni t t es t Integr ati on test Accep tance test Develop, v erify Serv ice next -l evel p rod uct Desi gn V& V 15 El modelo en espiral 8En un artículo que tiene tantas interpretaciones como lectores, Boehm propuso su “modelo en espiral” 8Ideas básicas 8 El desarrollo debe ser incremental 8 Un criterio para seleccionar las funciones es: primero las más riesgosas, las que pueden hacer fracasar el proyecto 8 Cuidado, lo más riesgoso puede no ser lo más difícil, debemos hacer un buen análisis de riesgos 16 8 Variaciones de modelos iterativos – UP / RUP 17 Variaciones – SCRUM 24 horas Daily Scrum Meeting Estimation Meeting 30 días Sprint Backlog Product Backlog Incremento del Producto 18 9 En la práctica 8Analizar diferentes factores: 8 Inestabilidad de requerimientos / novedad del producto Æ Mayor peso al enfoque evolutivo 8 Posibilidad concreta de partir el desarrollo Æ Iteraciones más cortas 8 Arquitectura más compleja Æ Enfoque de atacar riesgos desde el inicio 8 Mayor complejidad del negocio Æ No descuidar la especificación 19 10
