5 ciclos de vida del software(fixed)

5,529 views

Published on

1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total views
5,529
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
132
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

5 ciclos de vida del software(fixed)

  1. 1. <ul><li>Procesos de desarrollo </li></ul><ul><li>Modelo Construir y corregir (Build-and-fix) </li></ul><ul><li>Cascada </li></ul><ul><li>Prototipo rápido </li></ul><ul><li>Incremental </li></ul><ul><li>Programación Extrema (XP) </li></ul><ul><li>Espiral </li></ul><ul><li>Orientados a objetos </li></ul><ul><li>Comparación entre los ciclos de vida </li></ul><ul><li>Conclusiones </li></ul>Procesos de desarrollo del Software (Ciclos de vida del software)
  2. 2. Modelos del Ciclo de Vida del Software <ul><li>Modelo del ciclo de vida, antes conocido como modelo del proceso de desarrollo del software </li></ul><ul><li>Los pasos por los cuales progresa el producto </li></ul><ul><ul><li>Fase de requerimientos </li></ul></ul><ul><ul><li>Fase de especificaciones </li></ul></ul><ul><ul><li>Fase de diseño </li></ul></ul><ul><ul><li>Fase de implementación </li></ul></ul><ul><ul><li>Fase de integración </li></ul></ul><ul><ul><li>Fase de mantenimiento </li></ul></ul><ul><ul><li>Retiro </li></ul></ul>
  3. 3. Modelo Build and Fix <ul><li>Problemas </li></ul><ul><ul><li>No especificaciones </li></ul></ul><ul><ul><li>No diseño </li></ul></ul><ul><li>Totalmente insatisfactorio </li></ul><ul><li>Requiere de un modelo del ciclo de vida </li></ul><ul><ul><li>Planificación </li></ul></ul><ul><ul><li>Fases </li></ul></ul><ul><ul><li>Metas </li></ul></ul>
  4. 4. Cascada <ul><li>Caracterizada por </li></ul><ul><ul><li>Retroalimentación </li></ul></ul><ul><ul><li>Dirigida por documentación </li></ul></ul><ul><li>Ventajas </li></ul><ul><ul><li>Documentación </li></ul></ul><ul><ul><li>Más fácil mantenimiento </li></ul></ul><ul><li>Desventajas </li></ul><ul><ul><li>Especificaciones </li></ul></ul><ul><ul><ul><li>Documentos pueden ser ambiguos </li></ul></ul></ul><ul><ul><ul><li>Retroalimentación tardía </li></ul></ul></ul><ul><ul><ul><li>Requerimientos mal entendidos </li></ul></ul></ul>
  5. 5. Prototipo Rápido <ul><li>Modelo lineal </li></ul><ul><li>“ Rápido” </li></ul><ul><li>Garantizar entendimiento de requerimientos desde el inicio </li></ul><ul><li>Desventajas: </li></ul><ul><ul><li>Puede crear la impresión de que el producto final puede generarse tan rápido como el prototipo </li></ul></ul><ul><ul><li>El equipo puede tener la tentación de reusar el prototipo (código y diseño de baja calidad) </li></ul></ul>
  6. 6. Tres puntos clave <ul><li>No se convierte en el producto final. El prototipo por hacerse rápido NO SE REUTILIZA, se genera un producto nuevo desde cero en las siguientes fases </li></ul><ul><li>El prototipo rápido podría reemplazar la fase de especificaciones pero NUNCA la de diseño. </li></ul><ul><li>Comparación: </li></ul><ul><ul><li>Cascada – intenta tener el producto correcto en una primera vez </li></ul></ul><ul><ul><li>Prototipo rápido – cambios frecuentes, después desecharlo </li></ul></ul>
  7. 7. Modelos de Cascada y de Prototipo rápido <ul><li>Cascada </li></ul><ul><ul><li>Muchós éxitos </li></ul></ul><ul><ul><li>Problemas con las necesidades del cliente </li></ul></ul><ul><li>Prototipo rápido </li></ul><ul><ul><li>No muy probado </li></ul></ul><ul><ul><li>Tiene sus propios problemas </li></ul></ul><ul><li>Solución </li></ul><ul><ul><li>Prototipo rápido para la fase de requerimientos </li></ul></ul><ul><ul><li>Cascada para el resto del ciclo de vida </li></ul></ul>
  8. 8. Modelo incremental <ul><li>Dividir el proyecto en builds </li></ul>
  9. 9. Modelo Incremental (cont) <ul><li>Modelos de Cascada, prototipo rápido </li></ul><ul><ul><li>Producto completo operacional sólo hasta el final </li></ul></ul><ul><li>Modelo incremental </li></ul><ul><ul><li>Se tiene una porción del producto de calidad operando en semanas </li></ul></ul><ul><li>Menos traumático </li></ul><ul><li>Rápido retorno de la inversión </li></ul><ul><li>Requiere de una arquitectura abierta, se puedan integrar las porciones que se van generando a pesar de requerimientos no estáticos. </li></ul><ul><li>Se usan variaciones de este ciclo de vida en los ciclos orientados a objetos. </li></ul>
  10. 10. Modelo Incremental (cont) <ul><li>Problemas </li></ul><ul><ul><li>Peligro de caer en construir y corregir (Build-and-fix) </li></ul></ul><ul><ul><li>Si no se tiene una arquitectura definida desde un inicio problemas para integrar y de mantenimiento </li></ul></ul>
  11. 11. Modelo Incremental (cont) <ul><li>Una versión más riesgosa no considera se entiendan los requerimientos más importantes y se tenga una visión entera del proyecto, sino ir avanzando en los requerimientos en cada build— las piezas podrían no coincidir! </li></ul><ul><ul><li>Peligro de codificar un poco, probar un poco CABTAB (code a bit test a bit) </li></ul></ul>
  12. 12. Programación Extrema (Xtreme Programming) <ul><li>Nueva metodología algo controversial </li></ul><ul><li>Dirigida por historias (stories) o requerimientos que el cliente desea. </li></ul><ul><li>Estima la duración y costo de cada historia </li></ul><ul><li>Selecciona historias para el siguiente build </li></ul><ul><li>Cada build está dividido en tareas. </li></ul><ul><li>Los casos de prueba para cada tarea se establecen primero. </li></ul><ul><li>Programación en parejas. </li></ul><ul><li>Continua integración de las tareas. </li></ul>
  13. 13. Características novedosas de XP <ul><li>Las computadores se ponen en el centro de un gran cuarto divididas por cubículos. </li></ul><ul><li>Representantes del cliente siempre están presentes. </li></ul><ul><li>No pueden trabajar tiempos extras dos semanas consecutivas. </li></ul><ul><li>Refactorización </li></ul>
  14. 14. Evaluación de XP <ul><li>XP ha tenido algunos éxitos </li></ul><ul><li>Bueno cuando los requerimientos son vagos o cambiantes. </li></ul><ul><li>Muy pronto para evaluarse </li></ul>
  15. 15. Modelo de espiral <ul><li>Forma simplificada </li></ul><ul><ul><li>Modelo de cascada más análisis de riesgo </li></ul></ul><ul><li>A cada fase le precede </li></ul><ul><ul><li>Búsqueda de alternativas </li></ul></ul><ul><ul><li>Análisis dse riesgo </li></ul></ul><ul><li>Después de cada fase: </li></ul><ul><ul><li>Evaluación </li></ul></ul><ul><ul><li>Planeación de la siguiente fase </li></ul></ul>
  16. 16. Simplified Spiral Model <ul><li>Si los riesgos no pueden resolverse el proyecto termina inmediatamente </li></ul>
  17. 17. Análisis del Modelo de Espiral <ul><li>Fuerzas </li></ul><ul><ul><li>Fácil juzgar cuánto probar </li></ul></ul><ul><ul><li>No hay distinción entre desarrollo y mantenimiento. </li></ul></ul><ul><li>Debilidades </li></ul><ul><ul><li>Sólo para software de gran escala </li></ul></ul><ul><ul><li>Sólo para uso interno (in-house), es decir el equipo desarrollador es del mismo cliente. </li></ul></ul>
  18. 18. Modelos de ciclos de vida Orientados a Objetos <ul><li>Necesidad de iteración dentro y entre las fases </li></ul><ul><ul><li>Modelo de fuente </li></ul></ul><ul><ul><li>Round-trip gestalt </li></ul></ul><ul><ul><li>Proceso Unificado (Unified software development process -UP-) </li></ul></ul><ul><li>Todos incorporan alguna forma de </li></ul><ul><ul><li>Iteración </li></ul></ul><ul><ul><li>Paralelistmo </li></ul></ul><ul><ul><li>Desarrollo incremental </li></ul></ul><ul><li>Peligro </li></ul><ul><ul><li>CABTAB (code a bit test a bit) </li></ul></ul>
  19. 19. Fountain Model <ul><li>Características: </li></ul><ul><ul><li>Paralelisto (parte de una fase ocurre al mismo tiempo que otra) </li></ul></ul><ul><li>Permite iteracioens </li></ul><ul><li>Ciclo de mantenimiento más corto </li></ul>
  20. 20. Requirements Design Implementation Test Analysis *Nota: esta diapositiva fue agregada a la presentación original. P r e l i m i n a r y I t e r a t i o n ( s ) i t e r . # 1 i t e r . # 2 i t e r . # n i t e r . # n + 1 i t e r . # n + 2 i t e r . # m i t e r . # m + 1 I n c e p t i o n E l a b o r a t i o n C o n s t r u c t i o n T r a n s i t i o n P h a s e s C o r e W o r k f l o w s A n i t e r a t i o n i n t h e e l a b o r a t i o n p h a s e
  21. 21. Conclusiones <ul><li>Diferentes modelos de ciclos de vida </li></ul><ul><li>Cada uno sus fuerzas </li></ul><ul><li>Cada uno con sus debilidades </li></ul><ul><li>Criterio para decidir cuál modelo incluye: </li></ul><ul><ul><li>La organización </li></ul></ul><ul><ul><li>Sus directivos </li></ul></ul><ul><ul><li>Habilidades de los empleados </li></ul></ul><ul><ul><li>Naturaleza del producto </li></ul></ul><ul><ul><li>Tamaño del proyecto </li></ul></ul><ul><ul><li>Variabilidad de los requerimientos </li></ul></ul><ul><li>Mejor sugerencia: </li></ul><ul><ul><li>Mezclar y ajustar el modelo de ciclo de vida </li></ul></ul>
  22. 22. Bibliografía <ul><li>Schach, Stephen. “Classical and Object-Oriented Software Engineering, with UML”. McGraw Hill, 2002, 5a edición. </li></ul>
  23. 23. Fin de la presentación Continúe en la siguiente actividad Procesos de desarrollo del Software (Ciclos de vida del software)

×