4. DEFINICIÓN El desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.
6. FASES Las fases del método de desarrollo en cascada son: Análisis de requisitos Diseño del Sistema Diseño del Programa Codificación Pruebas Implantación Mantenimiento
7. FASES Análisis de requerimientos En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.
8. FASES DiseñodelSistema Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.
9. FASES Diseño del ProgramaEs la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación. Codificación Es la fase de programación o implementación propiamente dicha. Aquí se implementa el código fuente, haciendo uso de prototipos así como pruebas y ensayos para corregir errores.
10. FASES PruebasLos elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser puesto. Implantación El software obtenido se pone en producción. Se implantan los niveles software y hardware que componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo de elaboración de un proyecto. Es una de las fases finales del proyecto.
11. FASES Variantes Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de fallos.
12. CARACTERISTICAS Es el más utilizado. Es una visión del proceso de desarrollo de software como una sucesión de etapas que producen productos intermedios. Para que el proyecto tenga éxito deben desarrollarse todas las fases. Las fases continúan hasta que los objetivos se han cumplido. Si se cambia el orden de las fases, el producto final será de inferior calidad.
13. VENTAJAS Se tiene todo bien organizado y no se mezclan las fases. Es perfecto para proyectos que son rígidos, y además donde se especifiquen muy bien los requerimientos y se conozca muy bien la herramienta a utilizar La planificación es sencilla. La calidad del producto resultante es alta. Sus fases son conocidas por los desarrolladores. Los usuarios lo pueden comprender fácilmente.
14. DESVENTAJAS Iteraciones costosas. Los problemas que se presentan son corregidos posteriormente. Puede que el software no cumpla con los requisitos. Es difícil incorporar nuevas cosas si se quiere actualizar. Es normal detenerse en su desarrollo y seguir con otras fases. Se tarda mucho tiempo en pasar por todo el ciclo Las revisiones de proyectos de gran complejidad son muy difíciles
16. DEFINICIÓN Es un modelo de proceso de software evolutivo, desarrolladopor primera vez por Barry Boehm en 1988. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.
17. CARACTERISTICAS En cada giro se construye un nuevo modelo del sistema completo. Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada, evolutivo) Mejor modelo para el desarrollo de grandes sistemas. El análisis de riesgo requiere la participación de personal con alta calificación. No hay un número definido de iteraciones. Las iteraciones debe decidirlas el equipo de gestión de proyecto. Mas realista que el ciclo de vida clásico. Este es el enfoque más realista actualmente.
18. VARIANTES Modelo espiral de cuatro regiones o modelo original de Boehm. Modelo espiral de seis regiones. Modelo espiral WINWIN
21. ACTIVIDADES El modelo en espiral se divide en un numero de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas. Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Son todos los requerimientos. Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y otras informaciones relacionadas con el proyecto. Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación. Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario. Evaluación el cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementación durante la etapa de instalación.
22. MODELO ESPIRAL WINWIN El modelo espiral WINWIN (Victoria-Victoria) sugiere una actividad del marco de trabajo que aborda la comunicación con el cliente. El objetivo de esta actividad es mostrar los requisitos del cliente. En un contexto ideal, el desarrollador simplemente pregunta al cliente lo que se necesita y el cliente proporciona detalles suficientes para continuar.
23. ACTIVIDADES MODELO ESPIRAL WINWIN El modelo en espiral WINWIN de Boehm define un las siguientes actividades: Identificación del sistema o subsistemas clave de los directivos. Determinación de las condiciones de victoria de los directivos. Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones (victoria-victoria) para todos los afectados.
25. HITOS MODELO WIN-WIN El modelo en espiral WINWIN introduce tres hito son los procesos llamados puntos de fijación, que ayudan a establecer la completitud de un ciclo alrededor de la espiral y proporcionan hitos de decisión antes de continuar el proyecto de software. En esencia, los puntos de fijación representan tres visiones diferentes del progreso mientras que el proyecto recorre la espiral.
26. HITOS MODELO WIN-WIN Objetivos del Ciclo de Vida (OCV), define un conjunto de objetivos para cada actividad principal de ingeniería del software. Arquitectura del Ciclo de Vida (ACV), establece los objetivos que se deben conocer mientras que se define la arquitectura del software y el sistema. La capacidad operativa inicial (COI), representa un conjunto de objetivos asociados a la preparación del software para la instalación/distribución, preparación del lugar previamente a la instalación, y la asistencia precisada de todas las partes que utilizará o mantendrá el software.
27. VENTAJAS El modelo en espiral es un enfoque realista del desarrollo de sistemas. Modelo de proceso adaptable. El modelo en espiral puede aplicarse a lo largo de la vida del software. El desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
28. VENTAJAS Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se conviertan en problemas. Modelos evolutivos como el espiral, son apropiados, particularmente para el desarrollo de Sistemas OO. Trata de mejorar los ciclos de vida clásicos y prototipos. Permite acomodar otros modelos Incorpora objetivos de calidad y gestión de riesgos. Elimina errores y alternativas no atractivas al comienzo.
29. DESVENTAJAS Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable. Es nuevo y no se ha utilizado tanto como otros modelos de ciclo de vida. Requiere una considerable habilidad para la evaluación del riesgo, y cuenta con esta habilidad para el éxito. Si un riesgo importante no es detectado y gestionado a tiempo, indudablemente surgirán problemas.