Pages Menu
Categories Menu

Posted by on May 19, 2014 in General | 1 comment

El verdadero origen del ciclo en cascada, sobre cazas de brujas y errores históricos

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.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

1 Comment

  1. 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…

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This