¿Cuáles son los problemas del modelo de cascada?

El modelo de cascada es un enfoque de diseño secuencial relativamente lineal para ciertas áreas del diseño de ingeniería.

En el desarrollo de software, tiende a estar entre los enfoques menos iterativos y flexibles, ya que el progreso fluye principalmente en una dirección hacia abajo, como una cascada, a través de las fases de concepción, iniciación, análisis, diseño, construcción, prueba, implementación y mantenimiento. Usadas en proyectos de desarrollo de software, las fases típicamente se ven así:

1. Requisitos

Si está involucrado en el desarrollo de software o en cualquier tipo de equipo de creación de proyectos, le gustaría conocer el contexto comercial de lo que está tratando de crear: desea definir qué tipo de problemas está tratando de resolver y cómo reaccionaría la gente a su producto terminado. Después de definir todos estos «requisitos», tiene la entrada que necesita para pasar al siguiente paso.

2. Diseño

Este paso se compone de todos los pasos que necesita para satisfacer todos los requisitos que ha determinado anteriormente. En el desarrollo de software, esta es la parte en la que define toda la arquitectura de software y hardware, el lenguaje de programación, el almacenamiento de datos, etc. Esta es también la parte en la que determina cómo el proyecto sería útil para su usuario final.

3. Implementación

En este paso, comienza a construir lo que ha diseñado en su plan. Esta parte del método Waterfall está dedicada a cumplir con los estándares que ha establecido en los pasos anteriores. Esta es la parte donde la gente del equipo de desarrollo entra y hace que sucedan todas las cosas discutidas en los pasos anteriores.

4. Verificación

Esta es la parte del método donde la gente de control de calidad ingresa para asegurarse de que el equipo de desarrollo no cometió ningún error. Esta también es probablemente la parte en la que las personas se dan cuenta de lo que está funcionando o no en su plan.

Tenga en cuenta que

Cuando los desarrolladores del proyecto satisfacen todo, el cliente o el usuario final entra y toma la decisión final si el proyecto está listo para ser lanzado.

El método Waterfall destaca que cuando algo sale mal en una etapa en particular, las personas pueden volver a la etapa anterior para ver qué salió mal. Por ejemplo, si hay un problema en la implementación del plan y las personas saben que simplemente siguieron el plan que se les entregó, los gerentes revisan su plan y hacen sus revisiones a partir de ahí.

¿Cuál es el problema de la cascada?

Es posible que los clientes no sepan exactamente cuáles son sus requisitos antes de ver el software en funcionamiento y, por lo tanto, cambien sus requisitos, lo que lleva al rediseño, nuevo desarrollo y nuevas pruebas, y mayores costos.

Es posible que los desarrolladores no sean conscientes de las dificultades futuras al diseñar un nuevo producto o característica de software, en cuyo caso es mejor revisar el diseño que persistir en un diseño que no tiene en cuenta las restricciones, los requisitos o los problemas recién descubiertos.

Por lo tanto, no hay garantía de que los requisitos que la organización ha pensado realmente funcionen. A partir de aquí, te darás cuenta de que el modelo Waterfall tiene los siguientes problemas:

1.  La gente sigue ciegamente los planes.

En el método tradicional, las personas prestan más atención a cómo sucederán las cosas en el momento adecuado sin tener en cuenta si las cosas realmente están encajando. Si bien la planificación es importante, también es importante que los desarrolladores y los verificadores de calidad entiendan cómo deben suceder las cosas, especialmente con el cliente o el usuario final. También es importante que todas las personas involucradas en el proyecto puedan decir de inmediato cómo un paso en particular en el cumplimiento del proyecto puede fallar sin tener que esperar a la etapa de prueba.

2.  El proceso secuencial y los cambios se vuelven costosos

Este enfoque no tiene en cuenta el cambio de los requisitos definidos a medida que avanza el proyecto. Por lo tanto, existe un gran potencial de que el software no satisfaga completamente los requisitos del usuario, sea ineficiente y tenga una funcionalidad deficiente.

Es inadecuado ya que los desarrolladores no pueden simplemente regresar y cambiar algo en una fase anterior a medida que cambian los requisitos de los consumidores, sino que el desarrollador tiene que volver a donde el requisito debe cambiar y comenzar esa fase de nuevo. Hasta que no se completa esa fase, no puede pasar a la siguiente fase.

3.  Los usuarios finales no saben lo que quieren.

La mayoría de las veces, la mente de los usuarios finales cambia constantemente y la mayoría de las personas tienen una idea vaga de los requisitos de su software y es a medida que se desarrolla el software que especifican sus requisitos.

Cuando llega el momento de entregar el producto terminado a un cliente, es probable que no le guste cómo quedó, a pesar de haber dicho deliberadamente lo contrario durante las etapas iniciales. Es fácil para los clientes y usuarios finales cambiar lo que quieren con el tiempo. El sistema Waterfall aún no tiene una forma de resolver eso, sin tener que revisar los planes y rehacer todo el proyecto por completo.

4.  Las pruebas de calidad pueden sufrir.

Es imposible predecir con precisión los resultados de un proyecto, y cuando todo el equipo tiene poco tiempo, es posible acortar la etapa de prueba para cumplir con la fecha límite.

5.  Nunca sabrás en qué escenario estás realmente.

Dado que el producto que está tratando de crear no se producirá hasta el final, no está realmente seguro de si todavía está en la etapa de planificación o si ya está en desarrollo. Eso significa que también es probable que pase más tiempo en un escenario de lo que esperaba debido a esta poca visibilidad.

Al final, el método Waterfall puede ser demasiado arriesgado ya que es demasiado rígido. Para que pueda producir un producto que funcione y que sea lo suficientemente flexible como para ayudarlo a descubrir qué funciona o no.

Recursos Relacionados

• Agile & Scrum: artículos de desarrollo de software ( inglés ) ( chino ) ( japonés )