1. Cascada
    1. Clasica
    2. Comprender de forma clara el producto que van a desarrollar.
    3. No hay un líder especifico.
    4. Proyectos pequeños. Se trata de un modelo estructurado: en el que la rigidez puede llegar a suponer una limitación en la práctica. Aborda el proyecto como un todo: en vez de dinamizar su gestión dividiéndolo en unidades más sencillas de gestionar y controlar.
    5. Requisitos del software Diseño Implementación Verificación Instalación y mantenimiento
  2. Incremental
    1. Cada requisito se debe completar en una única iteración: el equipo debe realizar todas las tareas necesarias para completarlo (incluuyendo pruebas y documentación) y que esté preparado para ser entregado al cliente con el mínimo esfuerzo necesario.
    2. Clásica
    3. Se evitan proyectos a largo plazo Los incrementos son pequeños. Permite una fácil administración de las tareas en cada iteración. La inversión se materializa a corto plazo. Es un modelo propicio a cambios o modificaciones. Se adapta a las necesidades que surjan.
    4. Comunicación Planeación Modelado Construcción Despliegue
    5. Subtopic 5
    6. Entrega el software en partes pequeños, pero utilizables, llamadas (incrementos).
  3. Proceso Evolutivo
    1. Clásica
    2. Puede ser modificado y adaptado de acuerdo a las necesidades del software en desarrollo
    3. Ayuda al ingeniero de sistemas y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos
    4. Se recomiendan para proyectos largos de mas de un año Estos modelos se aplican cuando se reconoce la naturaleza evolutiva del proyecto de ingeniería de software. Están diseñados para ajustarse al cambio durante el desarrollo del proyecto. En este tipo de modelos se tiene el modelo de construcción de prototipos, el modelo en espiral y el modelo de desarrollo concurrente.
    5. Subtopic 5
    6. Fase 1: Entrevistar a los usuarios para entender lo que necesitan Fase 2: Construir un prototipo de forma rápida basado en lo que los usuarios necesitan Fase 3: Los usuarios experimentan con el prototipo y estos proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado.
  4. Componentes
    1. El modelo de desarrollo basado en componentes conduce ala reutilización del software, y la reutilización proporciona beneficios a los ingenieros de software.
    2. Clásica
    3. Reutilización del software. Simplifica las pruebas. Simplifica el mantenimiento del sistema. Mayor calidad.
    4. Recomendada igualmente para proyectos Grandes Ciclos de desarrollo más cortos. Mejor ROI. Funcionalidad mejorada.
    5. El lenguaje de modelado unificado define los componentes. Utilizando una combinación del desarrollo incremental e interactivo, el proceso unificado define la función del sistema aplicando un enfoque basado en escenarios.
  5. XP
    1. Ágil
    2. Guia la implementación, vínculo entre clientes y programadores. Su labor esencial es la coordinación
    3. Codificar. Hacer pruebas Escuchar Diseñar
    4. El equipo de desarrolladores debe tener el mismo nivel de conocimiento. Escribe las pruebas unitarias y produce el código del sistema
    5. Se recomienda para proyectos cortos, Desarrollo iterativo e incrementa. Pruebas unitarias continuas. Refactorización del código. Simplicidad en el código
  6. Scrum
    1. Ágil
    2. El equipo tiene la responsabilidad de entregar el producto. Es recomendable un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc).
    3. Son los responsables de establecer el entorno para el desarrollo del proyecto. Eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga
    4. Se recomienda para proyectos cortos. Gestión regular de las expectativas del cliente. Se hace uso de equipos autodirigidos y autoorganizados. Se realiza a diario una reunión de Scrum, que es una reunión de avance diaria que no dura más de 15 minutos con el objetivo de obtener realimentación sobre las tareas del equipo y los obstáculos que se presentan.
    5. Retrospectiva del sprint. Revisión de sprint. Scrum diario. Planificación de sprint. Sprint.
    6. Subtopic 6