Rarezas (2), primera vez que se mencionó waterfall (cascada)

Por si no lo leíste, la semana pasada compartía contigo aquel Rarezas, nuestra colección sobre el desarrollo software (1) en el que te hablaba de una colección de post, que iré sacando sin periodicidad fija, sólo cuando me apetezca y me motive lo que quiero enseñarte, en el que compartir esos ficheros, a los que he llamado rarezas, que contienen cosas que muchos desconocen pero que han marcado nuestra profesión y lo que es hoy en día.
jgarzas-rarezas-directorio

Un pequeño subconjunto de los miles de ficheros que hay en “010_Software Enginering Papers”

Ya te dije que en la colección iba a haber de todo, desde buenas ideas, los documentos que originaron grandes buenas prácticas de hoy en día, hasta también documentos que originaron grandes malas prácticas de hoy en día. Y hoy vamos con una de estas…

Rareza 2. Primera mención del ciclo de vida en cascada, Waterfall

Aquello que hoy conocemos como ciclo de vida en cascada, Waterfall, como todo, hubo un primer artículo que lo describió, y un autor que lo escribió, concretamente, te hablo del “Managing the Development of Large Software Systems”, escrito en 1970 por el “popular” y “señalado” como culpable desde entonces… Winston W. Royce. Aquí lo tienes…

Pero la historia de esta rareza, curiosidad e importancia, no termina aquí, porque si te lees el anterior artículo, verás que es en la página 2 donde aparece el famoso diagrama que hoy conocemos como ciclo de vida en cascada, de ahí que aquí esté la que consideramos su primera descripción, hito histórico. Y de ahí que Royce se llevase todas las culpas por haber llevado este ciclo de vida al mundo del software.

Pero realmente (de esto ya te hablé algo hace unos años en El verdadero origen del ciclo en cascada, sobre cazas de brujas y errores históricos) el pobre Royce, no defendía tal modelo, es más, ni siquiera lo llamó “cascada”, palabra que no aparece en el artículo. Fíjate que incluso escribe justo debajo de la figura…

I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. 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 lO0-percent overrun in schedule and/or costs.

El nombre de “cascada” se lo pusieron en el 76, Thomas y Thayer, en el artículo “Software Requirements: Are They Really A Problem?”, que te dejo más abajo (página 2, párrafo 2), que viene del entorno Defensa de los USA, que acabó en unas entonces populares normas llamadas DOD STD que obligaban a usar en cascada para subcontratar.

Aunque Royce que quedó asociado al cascada, y su nombre es popular por ello, y a Thomas y Thayer apenas los recuerda nadie.
Como te decía la última vez, unas páginas que no te pido que leas, pero si que creo que merece la pena que te las guardes.
 
 

Javier Garzás

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba