¿Sigue siendo viable la metodología de desarrollo de software Waterfall?

En mi experiencia, parece que el modelo Waterfall ha demostrado ser demasiado inflexible y no responde a los cambios de requisitos para ser considerado un método viable en el mundo moderno del desarrollo de software. El crecimiento y el historial comprobado de métodos más ágiles e iterativos parecen indicar que no hay ninguna razón por la cual alguien deba seguir un proceso de bloques rígidos que supone pocos o ningún cambio desde el inicio del proyecto hasta la entrega del producto.

¿Sigue siendo viable la metodología de desarrollo en cascada para entregar sistemas de software, con respecto al tiempo, el costo y la calidad?

El modelo de cascada al que se refiere nunca tuvo la intención de ser un modelo de proceso utilizado en un proyecto real. En cambio, es un hombre de paja. Identifica las fases y actividades clave que existen en los proyectos de software y el flujo más básico entre ellos. Esta simplificación excesiva de cómo desarrollar software es defectuosa, e incluso se presentó de esa manera.

Del artículo de Wikipedia:

La primera descripción formal del modelo de cascada a menudo es citada como un artículo de 1970 por Winston W. Royce, aunque Royce no usó el término "cascada" en este artículo. Royce presentó este modelo como un ejemplo de un modelo defectuoso y que no funciona.

El documento discutido se titula Gestión del desarrollo de grandes sistemas de software . En él, Royce presenta ese modelo en la segunda página. Sin embargo, el texto inmediatamente debajo de la representación pictoral continúa leyendo:

Creo en este concepto, pero la implementación descrita anteriormente es arriesgada e invita al fracaso.

Él sigue esto con una discusión de los problemas con las pruebas después de la "finalización" de la fase de desarrollo, y cómo las fallas aquí pueden conducir a importantes rediseños y cambios de código, y cómo estos pueden conducir a grandes excesos en el costo y el cronograma. A lo largo del documento, refina el modelo original a uno que sea realmente viable en un proyecto. Al final, termina con un modelo que introduce prototipos, interacción con el cliente y refinamiento de artefactos, ideas que eventualmente terminarían siendo críticas para el movimiento ágil que comenzó a fines de la década de 1990 y principios de la década de 2000.

Para responder a su pregunta: La Cascada por la que está preguntando no es, y nunca fue, un método viable para entregar proyectos de software con una cantidad razonable de calidad a tiempo y presupuesto. Sin embargo, hay otras metodologías basadas en planes que son opuestas a las ágiles que pueden y funcionan en proyectos.

La gente no usa el modelo de cascada de libros de texto y probablemente nunca lo haya hecho.

Es una construcción teórica idealizada cuyo propósito es hacerle pensar sobre los pasos en el desarrollo de sistemas. Su punto principal es que desea que los cambios más grandes sucedan lo antes posible, porque nunca tendrá el tiempo o el dinero para hacer un gran cambio una vez que se haya construido mucho código.

A pesar de que es más una forma de pensar que un proceso, sigue siendo la forma en que muchas, probablemente la mayoría de las organizaciones se dedican a construir software (o casas, o submarinos, o cualquier otra cosa ...).

En el mundo real, no tiene límites totalmente estrictos entre fases, y a veces regresa a fases anteriores para pequeños subproyectos. Lo que la metodología te dice no es que "estas cosas no están permitidas". Lo que le dice es "estas cosas le cuestan dinero y / o tiempo", así que trate de evitar eso en el futuro.

Está muy bien que Agile Snobs (TM) mire de reojo a los desarrolladores "anticuados" y su metodología de cascada pintoresca e inviable, pero el hecho es que Agile tampoco es una panacea. Algunos proyectos no se pueden construir usando Agile y muchos equipos que piensan que son Agile son realmente descuidados y desorganizados.

La metodología no es el punto. El punto es pensar en lo que está haciendo y por qué lo está haciendo de esa manera , y obtener el mayor valor para el cliente en el menor tiempo razonable.

El mítico proceso de cascada que se compara con mayor frecuencia contra ágil nunca existió y, por lo tanto, no puede considerarse muerto. Los procesos reales en cascada todavía están vivos y bien, y se destacan por entregar a tiempo un software de presupuesto que cumple con las expectativas del usuario.

Quizás una mejor manera de preguntar a qué se refiere es "¿cuándo es menos iterativo y más formal mejor?"

Hay situaciones en las que este es el caso:

• Cuando los requisitos no cambien.

• Cuando se cumplen nuevos requisitos es menos importante que alcanzar el 100% de los originales.

• Cuando todos los componentes tecnológicos son maduros y bien entendidos.

En cierto sentido, puedes tomar lo contrario de lo que te puede llevar a ser ágil.

Muy pocas técnicas son aplicables en todas partes. Muy pocos no tienen uso.

Sí, está muy vivo, aunque hoy en día se usa el " modelo V " más común .

En cualquier caso, el problema que tiene Agile es que la solución casi nunca termina, el cliente puede continuar solicitando cambios y el desarrollo continuará resolviéndolos iterativamente. Para un proyecto que se basa en el costo del tiempo y los materiales, esto funciona muy bien. Para un proyecto que tiene un costo fijo, no lo tiene.

Para estos proyectos de costo fijo, el cliente casi siempre espera que los hitos predefinidos demuestren progreso, sin embargo, estos son más de la variedad escrita formal en lugar de un código de trabajo. Para clientes como este, las especificaciones escritas se convierten en el proyecto, uno donde el desarrollo de software es una consideración secundaria (como suponen, si tiene un proyecto bien definido, el software debería ser fácil de desarrollar). Estas empresas también son las que hacen un uso intensivo de recursos de desarrollo baratos y subcontratados.

Por lo tanto, si tiene una cantidad fija de dinero o tiempo, no espere que los requisitos cambien o no se les permite cambiar ningún requisito, y se espera que proporcionen un sólido conjunto de documentación escrita, entonces los modelos en cascada son los únicos que tener sentido.

Agile se puede introducir en el medio de estos proyectos para realizar el desarrollo, pero aún tiene una fase de aceleración en la que las especificaciones se crean a partir de los requisitos, y una fase de desaceleración en la que el software se instala y prueba in situ. Ágil no responde bien a estos casos.

¿A quién? La mayoría de los gerentes con los que he tratado todavía usan el Proceso de desarrollo de software de Waterfall para la programación, y parece que a los niveles superiores les gusta para facilitar la programación.

Prácticamente, muy pocos desarrolladores que conozco creen que funciona o incluso es válido.