Lo que hoy todos conocemos como ciclo de vida en cascada, la primera vez que alguien lo describió fue en un artículo llamado «Managing the Development of Large Software Systems», escrito en 1970 por el “popular” y “señalado” Winston W. Royce (1929 – 1995) (comprenderás ahora la cara esa que se me queda cuando escucho decir que el ciclo de vida en cascada lo inventó CMMI o UML).
Más concretamente, si te descargas el artículo, hazlo que está en abierto y son 2 segundos, es en la página 2 donde aparece el famoso diagrama del ciclo de vida en cascada, he ahí su primera descripción, hito histórico.
Desde aquel momento, Royce se llevó todas las culpas por haber llevado este ciclo de vida, al “maligno”, al mundo del software.
Pero realmente el pobre Royce, que se llevó todas las culpas, no defendía tal modelo, es más, ni siquiera lo llamó “cascada”. El nombre de “cascada” se lo pusieron en el 76, Thomas y Thayer, en el artículo “Software Requirements: Are They Really A Problem?”. También lo puedes descargar en abierto y ver en la página 2, párrafo 2, otro hito de nuestra historia, un hito de la gestión de proyectos software… la primera aparición de la palabra “cascada”.
Al contrario, Royce, en la línea justo debajo de su dibujo del ciclo de vida “en cascada” escribe «but the implementation described above is risky and invites failure” (pero la implementación de este concepto es riesgosa e invita al error).
Posteriormente, dice… Los cambios de diseño son propensos a ser tan disruptivos que los requisitos software sobre los que el diseño se basa y que son la justificación de todo serán violados. O bien los requisitos deben ser modificados, o se requiere un cambio sustancial en el diseño. En efecto, el proceso de desarrollo ha vuelto al origen y se puede esperar hasta sobrecostes del 100% en el horario y/o costos.
(“The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.”)
Royce, en el mismo artículo (lo que pasa es que hay que leer un poco más), recomienda un proceso diferente: «hacerlo dos veces» mediante la construcción de un «modelo experimental».
El hijo de Royce escribió que su padre sentía mucho que todo le mundo pensase que promovió él el uso del ciclo de vida en cascada. Y decía que su padre siempre había sido un defensor del desarrollo iterativo e incremental.
Quién realmente lo hizo popular….
El gran paso hacia la popularidad del ciclo de vida en cascada vino del DoD STD 2167, que también te puedes descargar en abierto, otro hito histórico más para hoy. Alguno seguro os suena eso de STD, son normas y estándares del Departamento de Defensa de los USA.
En el DoD STD 2167 puedes leer párrafos como… El proveedor deberá establecer el diseño de alto nivel para cada CSIC (elemento de Configuración de software) asignando requisitos de la SRS (Especificación de Requisitos software) y, en su caso, del IRS (De los Requisitos de Interfaz) a los TLCSCS (componente de software de nivel superior ) de cada CSIC)
(“The contractor shall establish the top-level design of each CSCI (Computer Software Configuration Item) by allocating requirements from the SRS (Software Requirements Specifications) and, if applicable, IRS (Interface Requirements Specifications) to the TLCSCS (Top-level computer software component) of each CSCI.”)
El DoD STD 2167 fue posteriormente inspirador de otras metodologías, en otros países, de modelos, normas, estándares, etc.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Pura Justicia! Me recuerda a un «intercambio de opiniones», algo agrio, en un cliente, en el que alguien pretendía que Métrica V.3 (sí, hace años de esto, je je) era un modelo siempre en cascada…es lo que tiene no saber leer, o no saber leer entre líneas o, simplemente, no molestarse en leer las cosas hasta el final…
Interesante artículo, muchas gracias por compartirlo.