UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENERÍA

Y CIENCIAS SOCIALES Y ADMINISTRATIVAS

INSTITUTO

POLITÉCNICO NACIONAL

Ω 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.

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”.

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.

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.

Ciclo de Vida en Cascada

Requisitos

Mantenimiento

Verificación

Diseño

Codificación

Se analizan las necesidades de losusuarios finales del software paradeterminar qué objetivos debecubrir.

Es la fase en donde el usuariofinal 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 requieran.

Es la fase de programación oimplementación propiamentedicha.

Es la fase en donde se realizan los algoritmosnecesarios para el cumplimiento de losrequerimientos del usuario así como tambiénlos análisis necesarios para saber queherramientas usar en la etapa deCodificación.

Descompone y organiza el sistema enelementos que puedan elaborarse porseparado, aprovechando las ventajasdel desarrollo en equipo.

Diseño del sistema

Diseño del programa

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.

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.

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