Modelo Cascada

1. UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENERÍA
Y CIENCIAS SOCIALES Y ADMINISTRATIVAS
INSTITUTO
POLITÉCNICO NACIONAL

3. Ω En 1970 W. Royce propuso lo que actualmente se conoce como el
modelo de cascada como un concepto inicial.
Ω Posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en
1985.
Ω Winston W. Royce (1929 – 7 de junio de 1995) fue un computólogo
Americano, director en el Centro de Tecnología de Software Lockheed en
Austin, Texas. Fue un pionero en el campo de ingeniería de software,1
conocido por su papel en 1970 el cual el modelo en cascada de ingeniería
de software.

4. El origen de sus ideas:
“Yo voy a describir mi opinión personal sobre la administración de grandes
desarrollos de software. Yo he tenido varias tareas durante los últimos
nueve años, la mayoría preocupado por el desarrollo de paquetes de
software para la planeación de misiones en el espacio, comandando y
análisis post-vuelo. En estas tareas he experimentado diferentes grados
de éxito con respecto a la llegar a un estado funcional, a tiempo y dentro
de los costos. He sido perjudicado por mis experiencias y ahora en esta
presentación les voy a contar algunos de estos prejuicios”.

5. El desarrollo en cascada, también llamado modelo en cascada (denominado así por la
posición de las fases en el desarrollo de esta, que parecen caer en cascada, hacia las
siguientes fases), es el enfoque metodológico que ordena rigurosamente las etapas del
proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe
esperar a la finalización de la etapa anterior.

7. Barry Boehm escribió en 1987:
“El papel de Royce de 1970 es generalmente considerado como el papel en el cual se definen
las etapas del modelo “cascada” del proceso de software. Pero es sorprendente ver que los
papeles de Benington y Hosier tenían una buena aproximación al modelo cascada, y que el
papel de Royce ya tenía incorporado un paso esencial que es la creación de prototipos.”
*La expresión "modelo de cascada" rápidamente llegó a referirse no a la visión final de Royce
del diseño interactivo, sino más bien a su modelo puramente como un orden secuencial.

8. Ciclo de Vida en Cascada
Requisitos
Mantenimiento
Verificación
Diseño
Codificación
Se analizan las necesidades de los
usuarios finales del software para
determinar qué objetivos debe
cubrir.
Es la fase en donde el usuario
final ejecuta el sistema.
En esta etapa se pueden
actualizar las versiones del
software, al igual que alguna de
las herramientas, esto con el fin
de que el programa cumpla con
todos los requisitos que se
Es la fase de programación o
implementación propiamente
dicha.
Es la fase en donde se realizan los algoritmos
necesarios para el cumplimiento de los
requerimientos del usuario así como también
los análisis necesarios para saber que
herramientas usar en la etapa de
Codificación.
Descompone y organiza el sistema en
elementos que puedan elaborarse por
separado, aprovechando las ventajas
del desarrollo en equipo.
Diseño del sistema
Diseño del programa

9. La orientación del modelo de cascada,
es universal ya que puede ser
utilizada en cualquier tipo de
desarrollo de software, ya que la
estructura de la metodología permite
identificar posibles fallas y corregirlas,
por lo regular la implementación y
mantenimiento es lo que absorbe más
tiempo en el ciclo de vida de este
método.

10. Al final el modelo tiene que
ser homologado y cumplir
con la entrega del sistema
con su respectiva
documentación, para que
otros grupos puedan trabajar
fácilmente.

11.  Se tiene todo bien organizado y no se mezclan las fases
 Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo.
 Ayuda a minimizar los gastos de la planificación porque permite realizarla sin planificación porque
permite realizarla sin problemas.
X Gran dependencia en los requerimientos iníciales
X Difícilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que
provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite
movilizarse entre fases.
X El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresión de un
desarrollo lento, existe la incertidumbre de los clientes si sus proyectos serán entregados a tiempo.
X Inicio de la codificación muy tarde en el ciclo de vida del proyecto