El documento describe diferentes modelos de ciclo de vida de desarrollo de software, incluyendo modelos de proceso, cascada, prototipado rápido, programación extrema y procesos ágiles. También discute los procesos livianos versus pesados y factores a considerar al seleccionar un proceso.

1. Metodologías de Análisis Clase 4 – 29/8/2007 Christian Sifaqui

2. Modelos de ciclos de vida Modelo de ciclo de vida (o modelo del proceso) El desarrollo de software, las actividades operativas y su ordenamiento temporal - requerimientos - especificación - diseño - implementación - integración - mantención - retiro

3. Proceso Un proceso define QUIÉN hace QUÉ, CUÁNDO y CÓMO en el desarrollo de un sistema de software - roles y workflows - productos - hitos - guías - etc. Requerimientos nuevos o cambiados Sistema nuevo o cambiado Proceso de ingeniería de software

4. Proceso vs. Producto Participantes Resultado Herramientas Modelo del proceso Proyecto Personas Producto Automatización Template

5. Proceso Herramientas y equipamiento Personas con habilidades, entrenamiento y motivación Proceso Procedimientos y métodos que definen las relaciones de las tareas

6. Proceso efectivo - Provee guías para desarrollo eficiente de software de calidad - Reduce riesgo e incrementa predictibilidad - Captura y presenta “best practices” - Promueve una visión común y cultura - Provee un mapa para usar herramientas - Entrega información en línea

7. Procesos livianos vs. pesados Pesados (por ejemplo, Proceso-V) Ágiles , livianos (por ejemplo, programación extrema XP) Framework customizable (por ejemplo, RUP) Orientado al documento Elabora definiciones de workflow Muchos roles diferentes Muchos chequeos Sobrecarga alta de administración Altamente burocrático Enfocado al código en vez que a la documentación Enfocado en comunicación directa (entre desarrolladores y desarrolladores y los clientes) Baja sobrecarga de administración

8. Elección de proceso - El proceso usado debería depender del tipo de producto que se desarrollará para sistemas grandes, la administración es usualmente el principal problema, por lo que se necesita un proceso administrado estrictamente. Para sistemas pequeños, se permite mayor informalidad - Se podría incurrir en costos altos si se fuerza un proceso inapropiado a un equipo de desarrollo

9. Otros ciclos de vida Codificar-y-arreglar Cascada Prototipo rápido Programación extrema y procesos ágiles Sincronizar-y-estabilizar Espiral Híbrido

10. Codificar-y-arreglar - sin diseño - sin especificaciones  ¿mantención? Implementar la primera versión Modificar hasta que el cliente quede satisfecho Mantención post-entrega Retiro Desarrollo Mantención

11. Codificar-y-arreglar la manera más fácil de desarrollar software de la forma más cara

12. Cascada Requerimientos Análisis Diseño Implementación Mantención post-entrega Requerimientos cambiados Retiro Desarrollo Mantención

13. Cascada Caracterizada por: ciclos de retroalimentación guiado por documentación Ventajas documentación mantención es más fácil Desventajas documento de especificación

14. Prototipo rápido - modelo lineal - “rápido” Prototipo rápido Análisis Diseño Implementación Mantención post-entrega Requerimientos cambiados Retiro Desarrollo Mantención

15. Open-source Dos fases informales Primera fase : una persona construye una versión inicial que publica vía Internet (por ejemplo, SourceForge.net) Si hay suficiente interés en el proyecto: - se baja masivamente la versión inicial - usuarios se convierten en co-desarrolladores - el producto se extiende OBS: los individuos trabajan por lo general en forma voluntaria en sus tiempos libres

16. Open-source Segunda fase : Se reportan y corrigen defectos (mantención correctiva) Se agrega funcionalidad adicional (mantención perfectiva) Se porta el programa a nuevos ambientes (mantención adaptativa) La segunda fase informal consiste solamente de mantención post-entrega

17. Open-source Modelo de mantención post-entrega Implementar la primera versión Mantención post-entrega correctiva, perfectiva y adaptativa Retiro Desarrollo Mantención

18. Open-source Software cerrado se mantiene y testea por empleados de la organización Open-source generalmente es mantenido por voluntarios OBS: Linus’s Law complejidad ciclomática de McCabe

19. Open-source Grupo core: - pequeño número de mantenedores dedicados responsables de administrar el proyecto - tienen la autoridad de instalar parches Grupo periférico: usuarios que deciden enviar reportes de errores de vez en cuando

20. Open-source Nuevas versiones de software propietario se entregan, por lo general, una vez al año, después de una revisión del grupo SQA El grupo core libera una nueva versión del producto open-source tan pronto como esté lista: - quizás un mes o días después de la versión anterior - el grupo core hace test mínimos - el testing extenso lo realiza el grupo periférico usando el software - “release early and often”

21. Open-source Una versión inicial se produce al usar: - el modelo de “prototipo rápido” - el modelo “codificar-y-arreglar” - el modelo “Open-source” Y después: - modelo de “prototipo rápido” la versión inicial se descarta -modelo “codificar-y-arreglar” y “Open-source” la versión inicial se convierte en el producto

22. Open-source Por lo tanto en un proyecto open-source, por lo general no hay especificación ni diseño ¿Cómo estos proyectos open-source han sido tan exitosos al no tener especificación ni diseño?

23. Open-source La producción de software open-source ha atraído a algunos de los mejores expertos de software en el mundo (ellos pueden funcionar efectivamente sin especificación ni diseño) Sin embargo, se podría llegar a un punto en que el proyecto open-source no sea mantenible

24. Open-source el modelo open-source tiene sus restricciones pero ha sido extremadamente exitoso para proyectos de infraestructura: - sistemas operativos (GNU/Linux, OpenBSD, Mach, Darwin) - navegadores (Firefox, Netscape) - compiladores (gcc) - servidores web (apache, zope) - administradores de bases de datos (MySQL, PostgreSQL)

25. Open-source no puede haber desarrollo open-source de un producto de software para ser usado en una sola organización (los miembros del grupo core y periférico son los usuarios del software que se desarrolla) el modelo open-source es inaplicable a menos que el producto sea visto por un gran número de usuarios como útil

26. Open-source al menos la mitad de los proyectos open-source disponibles no han atraído a un equipo para trabajar en éste incluso si el trabajo se inicia, puede que no se complete el trabajo pero donde el modelo open-source ha funcionado, ha mostrado ser extremadamente exitoso (los proyectos mencionados anteriormente son usados por millones de usuarios)

27. Procesos ágiles una nueva aproximación controversial historias (muestra lo que quiere el cliente) - estimar duración y costo de cada historia - elegir historia para la siguiente construcción - cada construcción se divide en tareas - casos de test para una tarea se diseñan primero Programar de a par Integración continua de tareas

28. Procesos ágiles “ Programación extrema (XP)” los computadores se ponen al centro de una oficina larga alineada con cubículos un representante del cliente está siempre presente profesionales del software no pueden hacer horas extras más de dos semanas consecutivas no hay especialización refactoring (modificación al diseño)

29. Procesos ágiles “ Programación extrema (XP)” YAGNI (you aren’t gonne need it) DTSTTCPW (do the simplest thing that could possibly work) un principio de XP es minimizar el número de características (no hay necesidad de construir un producto que hace más que lo que el cliente necesita)

30. Procesos ágiles “ Programación extrema (XP)” XP es sólo una de un nuevo conjunto de paradigmas llamados procesos ágiles en febrero de 2001 se redactó el manifesto for Agile Software Development la Agile Alliance no receta un modelo de ciclo de vida específico (sólo expone un grupo de principios subyacentes)

31. Procesos ágiles Los procesos ágiles son una colección de nuevos paradigmas caracterizados por: - menor énfasis en análisis y diseño - implementaciones tempranas (el software funcionando es considerado más importante que la documentación) - proactivo al cambio - colaboración cercana con el cliente

32. Procesos ágiles un principio del Manifesto es - entregue software frecuentemente - idealmente cada 2 ó 3 semanas una manera de lograr esto es usar timeboxing (usado por muchos años como una técnica de administración del tiempo) se asigna una cantidad específica de tiempo a una tarea: - típicamente 3 semanas para cada iteración - los miembros del equipo hacen su mejor trabajo durante ese tiempo

33. Procesos ágiles entrega al cliente la confianza de saber que una nueva versión con funcionalidad llegará cada 3 semanas los desarrolladores saben que tendrán 3 semanas (y no más) para entregar una nueva iteración (sin interferencia del cliente) si es imposible entregar la tarea completa en el tiempo, el trabajo podría ser reducido (descoped) (procesos ágiles demandan tiempo fijo, no características fijas)

34. Procesos ágiles otro rasgo común de los procesos son las reuniones de pie - reuniones cortas que se efectúan a una hora cada día - se requiere asistencia los participantes están en un círculo - no se sientan en una mesa - para asegurar que la reunión no dure más de 15 minutos

35. Procesos ágiles En una reunión de pie, cada miembro del equipo se turna para responder 5 preguntas ¿Qué hice desde la reunión de ayer? ¿En qué estoy trabajando hoy? ¿Qué problemas tengo para alcanzar esto? ¿Qué hemos olvidado? ¿Qué aprendí que podría compartir con el equipo?

36. Procesos ágiles el objetivo de una reunión de pie es: - detectar problemas - no de resolverlos las soluciones se encuentra en reuniones de continuación, que se efectúan directamente después de la reunión de pie

37. Procesos ágiles procesos ágiles han tenido algún éxito en desarrollo de software a pequeña escala: (sin embargo, desarrollo de software mediano y grande es muy diferente) la clave: el impacto de los procesos ágiles en mantención post-entrega: - refactoring es una componente esencial en procesos ágiles - refactoring continúa durante la mantención - ¿incrementa el refactoring el costo de post-mantención, como lo indica la investigación preliminar?

38. Procesos ágiles procesos ágiles son buenos cuando los requerimientos son vagos o cambiantes es muy pronto para evaluar procesos ágiles: (no hay suficientes datos) incluso si los procesos ágiles fueran decepcionantes (algunas características –como la programación de a pares- podría ser adoptada por prácticas comunes de ingeniería de software)

39. Procesos ágiles Redactar tests Planificación Test Programación de a par + Refactoring Integración Mínimo diariamente cada 2-3 semanas Release

40. Sincronizar-y-estabilizar modelo de ciclo de vida de Microsoft análisis de requerimientos – entrevistar clientes potenciales redactar especificaciones dividir el proyecto en 3 ó 4 construcciones cada construcción se lleva a cabo por pequeños equipos trabajando en paralelo

41. Sincronizar-y-estabilizar al final del día – sincronizar (test y debug) al final de la construcción – estabilizar (congelar la construcción) componentes siempre trabajan juntos (se obtienen vistas tempranas de la operación de producto)

42. Espiral

43. Espiral si no se pueden mitigar todos los riesgos, el proyecto se termina inmediatamente

44. Espiral preceder cada fase con: - alternativas - análisis de riesgo continuar cada fase con: - evaluación - planificación de la siguiente fase dimensión radial: costo acumulado a la fecha dimensión angular: progreso a través de la espiral

45. Espiral Fortalezas: - es fácil decidir cuánto testear - no hay distinción entre desarrollo y mantención Debilidades: - sólo para software de gran escala - sólo para software interno (in-house)

46. Modelos de ciclos de vida Criterios para decidir por un modelo: - la organización - su administración - las habilidades de los empleados - la naturaleza del producto

47. Híbrido Probar mezclar modelos - Sistemas grandes están hechos de algunos sub-sistemas - El mismo modelo no necesita ser aplicado en todos los sub-sistemas - Prototipado para especificaciones altamente riesgosas - Modelo cascada para desarrollos claros - Adaptar el proceso al problema

48. Otros - RUP - V-Modell XT - … Adicionalmente - PSP (Personal Software Process) - TSP (Team Software Process) Finalmente - CMMI - Model IDEAL

49. Modelos de ciclos de vida Guiada por documentos Producto entregado podrían no satisfacer las necesidades del cliente Aproximación disciplinada Cascada Insatisfactorio para programas no triviales Bueno para pequeños programas que no requieren mantención Codificar-y-arreglar Subyacente al proceso unificado Modela cercanamente la producción de software del mundo real Iterativo-e-incremental Equivalente al modelo iterativo-e-incremental Modela cercanamente la producción de software del mundo real Árbol de evolución Debilidades Fortalezas Modelo de ciclo de vida

50. Modelos de ciclos de vida No ha sido probado fielmente Asegura que el producto entregado concuerda con las necesidades del cliente Prototipo rápido Desarrolladores deben ser competentes en análisis de riegos y evolución del riesgo Puede ser usado sólo en producto internos de gran escala Orientada al riesgo Espiral Asegura que las componentes se puedan integrar exitosamente No ha usado en otra parte distinta a Microsoft Necesidades futuras de los usuarios se satisfacen Sincronizar-y-estabilizar Parece funcionar sólo en proyectos de pequeña escala Funciona bien si los requerimientos del cliente son vagos Procesos ágiles Usualmente no funciona Aplicación limitada Ha funcionado muy bien en un pequeño número de instancias Open-source Debilidades Fortalezas Modelo de ciclo de vida