Hablando de los eruditos más frustrados en la historia de la ingeniería blanda, si Winston Royce afirma ser el segundo, se estima que pocas personas pueden llamarlo primero. Este tipo resumió su experiencia y resolvió un modelo de desarrollo (el famoso modelo en cascada), que ahora aparece como un ejemplo negativo en la mayoría (se estima que son bastante cerca de 100) documentos que explican la gestión de proyectos de software y se considera inadecuado para el desarrollo de software. Poppendieck incluso afirmó en el libro "Lean Software Development" que el propio Royce tenía una actitud negativa hacia el modelo en cascada, es decir, creía que el modelo no era adecuado para el desarrollo de software (a muchas personas también les gusta negar fundamentalmente la cascada, que puede ser la razón). Obviamente, aquí hay una irracionalidad evidente: es ilógico proponer un modelo para resolver un determinado problema y luego negarlo. ¿Cuál es la verdad? Simplemente lea el texto original de "Gestión del desarrollo de sistemas de software a gran escala". Las ideas básicas son las siguientes:
1. El modelo en cascada no es un modelo lineal y secuencial único, sino una serie de modelos desde el análisis más simple: codificación hasta la integración de múltiples elementos de proceso (práctica);
2. Cuanto más difícil es el proyecto, más elementos de proceso se aplican en el modelo, aunque esto provocará un aumento en el costo; esto también es mejor que
3. la dificultad del proyecto y el uso de un modelo demasiado simplificado.
No solo eso, Royce también señaló que diseñar primero, hacerlo dos veces (prueba y error), presentar a los usuarios, etc. son prácticas típicas que niegan el método ágil más poderoso de cascada, pero no No sé si la comunidad ágil está dispuesta a reconocer a Royce, el creador de las cascadas.
Ingeniería de software del metro, parte 2