Modelo en cascada

o
clásico
 Modelo en cascada o clásico
 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)

 Más concretamente, si te descargas el artículo, 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.
 Modelo en cascada o clásico
 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?”. 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).
 Modelo en cascada o clásico
 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
sobrecostos del 100% en el horario y/o costos.

 El gran paso hacia la popularidad del ciclo de vida en cascada vino del DoD
STD 2167, otro hito histórico más para hoy. Algo seguro suena eso de STD,
son normas y estándares del Departamento de Defensa de los USA.
 Modelo en cascada o clásico
 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.
 Modelo en cascada o clásico
 Es el enfoque metodológico que ordena rigurosamente las etapas del
proceso para el desarrollo de software, de tal forma que al inicio de cada
etapa debe esperar a la finalización de la etapa anterior.
 Este es el más básico de todos los modelos, y sirve como bloque de
construcción para los demás modelos de ciclo de vida.
 La visión del modelo es muy simple; dice que el desarrollo de software
puede ser a través de una secuencia simple de fases.
 Cada fase tiene un conjunto de metas bien definidas, y las actividades
dentro de una fase contribuyen a la satisfacción de metas de esa fase o
quizás a una sub-secuencia de metas de la fase.
 Modelo en cascada o clásico

 Al final de cada etapa, el modelo está diseñado para llevar a cabo una
revisión final que se encarga de determinar si el proyecto está listo para
avanzar a la siguiente fase.
 Si se cambia el orden de las fases, el producto final será de inferior calidad.
 Las flechas muestran el flujo de información entre las fases, la flecha de
avance muestra el flujo normal, las flechas hacia atrás representan la
retroalimentación.
 Modelo en cascada o clásico
A favor…
 Excelente cuando se tiene un producto estable y se conoce la tecnología.
 Es un método muy estructurado que funciona bien con gente de poca
experiencia.
 Provee estabilidad en los requerimientos.
 La planeación se puede hacer anticipadamente.
 Modelo en cascada o clásico
En contra…
 Tiene poca flexibilidad.
 Los proyectos en la práctica raramente siguen un flujo secuencial.
 Siempre es difícil para el cliente mostrar todos los requerimientos
explícitamente y con mucha anticipación.
 El cliente debe tener paciencia.
 Es inflexible y no motiva al cambio.
 Poco apropiado para aplicaciones para la toma de decisiones.
 Los usuarios tienen una participación limitada.
Modelo en cascada o clásico
Modelo en cascada o clásico
 Modelo en cascada o clásico
ANÁLISIS: Determinar qué debe hacer el software ->
especificación.
DISEÑO: Descomponer y organizar el sistema para que
los módulos puedan ser desarrollados por separado.
CODIFICACIÓN: Escribir el código fuente de cada
módulo y realizar sobre ellos las pruebas necesarias.
INTEGRACIÓN: Combinar todos los módulos y
probar el sistema completo antes de pasar a su
explotación.
MANTENIMIENTO: Durante la explotación es
necesario realizar cambios ocasionales bien para
corregir errores o para introducir mejoras.

Se trata de aislar cada fase de las otras, lo que facilita la especialización de los desarrolladores. Al final de cada
fase se requiere un proceso de revisión para evitar que los errores se propaguen a fases posteriores provocando la
vuelta atrás.
Modelo en cascada ampliado
Cada fase debe generar una información de salida precisa y
suficiente:

DOCUMENTOS DE REQUISITOS DEL SOFTWARE

(SRD): es una especificación precisa y completa a partir de
los requisitos establecidos por el cliente.

DOCUMENTO DE DISEÑO DEL SOFTWARE (SDD):

descripción de la estructura global del sistema, especificación
de qué debe hacer cada uno de los módulos y de cómo se
combinan.
CÓDIGO FUENTE: el programa debidamente comentado
(documentación interna).

SISTEMA SOFTWARE: el ejecutable producto dela fase de

integración y la documentación de las pruebas realizadas.

DOCUMENTOS DE CAMBIOS: después de cada

modificación realizada en la fase de mantenimiento: problema
detectado y solución adoptada
Modelo en cascada o clásico