SDLC - Modelo de cascada

El modelo Waterfall es un modelo SDLC clásico que es ampliamente conocido, comprendido y de uso común. Fue introducido por Royce en 1970 y todavía se sigue como un enfoque común para el desarrollo de software en varias organizaciones de la industria.

En el modelo Waterfall, cada fase del ciclo de vida puede comenzar solo después de que se complete la fase anterior del ciclo de vida. Por tanto, es un modelo lineal sin bucles de retroalimentación.

Modelo de cascada - Fortalezas

Los puntos fuertes del modelo Waterfall son:

  • Fácil de entender y de usar.
  • Proporciona estructura al equipo de desarrollo sin experiencia.
  • Los hitos se comprenden bien.
  • Establece la estabilidad de los requisitos.
  • Ideal para el control de la gestión (planificación, seguimiento, informes).
  • Funciona bien cuando la calidad es más importante que el costo o el cronograma.

Modelo de cascada - Debilidades

Las debilidades o desventajas del modelo Waterfall son:

  • Idealizado: no encaja bien con la realidad.

  • Poco realista: no se pueden esperar requisitos precisos al principio del proyecto.

  • No refleja la naturaleza iterativa del desarrollo exploratorio que es más común.

  • Es difícil y costoso realizar cambios.

  • El software se entrega solo al final del proyecto. Debido a esto -

    • Retrasa el descubrimiento de defectos graves.

    • Posibilidad de entrega de requisitos obsoletos.

  • Gastos generales de gestión importantes, que pueden resultar costosos para equipos y proyectos pequeños.

  • Requiere recursos experimentados en cada fase: analistas, diseñadores, desarrolladores, probadores.

  • Las pruebas comienzan solo después de que se completa el desarrollo y los evaluadores no participan en ninguna de las fases anteriores.

  • La experiencia de los equipos multifuncionales no se comparte ya que cada fase se ejecuta en silos.

¿Cuándo usar el modelo de cascada?

Puede usar el modelo Waterfall si:

  • Los requisitos son muy conocidos.

  • La definición del producto es estable.

  • La tecnología se comprende bien.

  • Nueva versión de un producto existente.

  • Portar un producto existente a una nueva plataforma.

  • Gran organización con equipos multifuncionales estructurados.

  • Los canales de comunicación están bien establecidos dentro de la organización y también con el cliente.

Modelo evolutivo de prototipos

En el desarrollo de software utilizando el modelo de Prototipos Evolutivos, los desarrolladores construyen un prototipo durante la fase de requisitos. Luego, los usuarios finales evalúan el prototipo y brindan comentarios. Los comentarios pueden ser correcciones al prototipo o funcionalidad adicional. Según los comentarios, los desarrolladores perfeccionan aún más el prototipo.

Por lo tanto, el producto evoluciona a través de Prototipo → Comentarios → Ciclos de prototipos refinados y de ahí el nombre de Prototipos evolutivos. Cuando el usuario está satisfecho con la funcionalidad y el funcionamiento del producto, el código del prototipo se ajusta a los estándares requeridos para la entrega del producto final.

Modelo evolutivo de prototipos: fortalezas

Las fortalezas o las ventajas de un modelo de creación de prototipos evolutivos son:

  • Los clientes / usuarios finales pueden visualizar los requisitos del sistema a medida que se recopilan mirando el prototipo.

  • Los desarrolladores aprenden de los clientes y, por lo tanto, no hay ambigüedades con respecto al dominio o al entorno de producción.

  • Permite un diseño y desarrollo flexible.

  • La interacción con el prototipo estimula la conciencia de la funcionalidad adicional necesaria.

  • Los requisitos inesperados y los cambios de requisitos se adaptan fácilmente.

  • Se producen signos constantes y visibles de progreso.

  • Entrega de un producto final preciso y fácil de mantener.

Modelo evolutivo de prototipos - Debilidades

Las debilidades o desventajas del modelo de creación de prototipos evolutivos son las siguientes:

  • Tendencia a abandonar el desarrollo estructurado en el desarrollo de código y corrección, aunque no es lo que prescribe el modelo.

  • Este modelo recibió mala reputación por los métodos rápidos y sucios.

  • Posiblemente se pueda pasar por alto la mantenibilidad general.

  • Es posible que el cliente pueda solicitar la entrega del prototipo como final, sin dar la oportunidad a los desarrolladores de ejecutar el paso final, es decir, la estandarización del producto final.

  • El proyecto puede continuar para siempre (con un aumento continuo del alcance) y es posible que la administración no lo aprecie.

¿Cuándo utilizar el modelo de creación de prototipos evolutivos?

Puede utilizar el modelo de creación de prototipos evolutivos:

  • Cuando los requisitos son inestables o deben aclararse
  • Como etapa de aclaración de requisitos de un modelo en cascada
  • Desarrollar interfaces de usuario
  • Para demostraciones de corta duración
  • Para desarrollo nuevo u original
  • Para implementar una nueva tecnología