METODO CASCADA

El modelo en cascada también conocido como ciclo de vida clásico es el modelo mas
conocido y ofrece una velocidad de desarrollo aceptable en algunas circunstancias. Este
es el predecesor de todos los modelos de ciclo de vida es el modelo en cascada. La visión
del modelo cascada del desarrollo de software es muy simple

Este modelo en cascada se utiliza correctamente para los ciclos de productos en los que
se conoce muy bien el producto, y también cuando se esta trabajando con metodologías
técnicas conocidas. En estos casos el modelo en cascada ayuda a localizar errores en las
primeras etapas de la realización del proyecto a un bajo coste.

El modelo cascada pura ayuda a minimizar los gastos de la planificación del proyecto
porque permite realizarla sin problemas. No da resultados tangibles en forma de software
hasta el final del ciclo del modelo, pero los que ya trabajan con el modelo cascada la
documentación que este genera entrega indicaciones significativas de progreso a lo largo
del ciclo de vida del proyecto.

Como es un modelo lineal secuencial este no puede ser corregido con gran facilidad pues
no puede dar retrocesos así que esa es su gran desventaja además que no se puede dar
una vista de los avances del proceso. Su ventaja es que es fácil de explicarlo.
Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue
siendo el paradigma más seguido al día de hoy

Definido por Winston Royce a fines de los 70 desde entonces muchos usuarios utilizan
este modelo como base para los modelos actuales de desarrollo de software. Y se trata
principalmente de que se debe completar un paso correctamente sin ningún error para
pasar al siguiente.

Este modelo desde 10 a 15 años atrás, ha sido sujeto de numerosas criticas debido a que
es restrictivo y rígido, lo cual dificulta el desarrollo de proyectos de software moderno. En
su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo
modelos que pretenden desarrollar software más rápidamente, o más incrementalmente o
de una forma más evolutiva, o precediendo el desarrollo a escala total con algún conjunto
de prototipos rápidos.

El modelo cascada mantiene que uno debe moverse a una fase solamente en que se
termina y se perfecciona su fase precedente. Sin embargo, hoy en día hay varios modelos
modificados de la cascada que puede incluir leves variaciones o importantes sobre este
proceso.

El modelo de cascada significa que primero haces una especificación de requisitos del
sistema, luego haces un análisis de los requisitos para especificar la metodología de
desarrollo que usarás, luego realizas el diseño de lo analizado anteriormente, luego la
compilación, la prueba y el mantenimiento. Esa metodología tiene el problema de que solo
le enseñas el producto al cliente cuando ya has terminado todo, y es difícil de modificar
las cosas
EL MODELO ORIGINAL DE LA CASCADA DE WINSTON ROYCE

Especificación de requisitos

 Diseño
 Construcción (AKA puesta en práctica o codificación)
 Integración
 Prueba y el eliminar errores (Verificación de AKA)
 Instalación
 Mantenimiento

Los que utilizan tales métodos no distinguen siempre formalmente entre el modelo puro
de la cascada y los varios modelos modificados de la cascada, así que pueden ser difícil
discernir exactamente que los modelos se están utilizando y en qué medida

EL MODELO CASCADA, TIENE ALGUNOS PRINCIPIOS BÁSICOS LOS CUALES SE

LOS NOMBRA A CONTINUACIÓN:

 Planear un proyecto antes de comenzar con él.

 Definir el comportamiento externo deseado del sistema antes de diseñar su
arquitectura interna.
 Documentar los resultados de cada actividad.
 Diseñar un sistema antes de codificarlo.
 Testear un sistema después de construirlo.

VENTAJAS

El modelo cascada por su sencillez solo utiliza los pasos intuitivos necesarios a la hora de
desarrollar el software, además es muy entendible para cliente.

 La planificación es sencilla.
 La calidad del producto resultante es alta.
 Permite trabajar con personal poco cualificado

DESVENTAJAS

 Los proyectos raramente siguen el flujo secuencial que propone el modelo

cascada, hay iteraciones
 El cliente no puede establecer al principio todos los requisitos.
 El cliente deber tener paciencia pues la versión operativa del producto solo estará
disponible en las últimas etapas del proyecto.
 No refleja realmente el proceso de desarrollo del software
 Se tarda mucho tiempo en pasar por todo el ciclo
 Perpetúa el fracaso de la industria del software en su comunicación con el usuario
final
  El mantenimiento se realiza en el código fuente
 Las revisiones de proyectos de gran complejidad son muy difíciles
 Impone una estructura de gestión de proyectos
 Un error importante no detectado hasta que el programa este funcionando puede
ser desastroso
 El proceso de creación del software tarda mucho tiempo ya que debe pasar por el
proceso de prueba y hasta que el software no esté completo no se opera. Esto es
la base para que funcione bien.
 Cualquier error de diseño detectado en la etapa de prueba conduce
necesariamente al rediseño y nueva programación del código afectado,
aumentando los costos del desarrollo.

En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada,

es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del
software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la
inmediatamente anterior.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce

necesariamente al rediseño y nueva programación del código afectado, aumentando los
costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la
gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de
un proyecto.

El modelo de cascada significa que primero haces una especificación de requisitos del
sistema, luego haces un análisis de los requisitos para especificar la metodología de
desarrollo que usarás, luego realizas el diseño de lo analizado anteriormente, luego la
compilación, la prueba y el mantenimiento. Esa metodología tiene el problema de que solo
le enseñas el producto al cliente cuando ya has terminado todo, y es difícil de modificar
las cosas

MODELO DE CICLO DE VIDA CASCADA

Análisis de requerimientos
En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qué objetivos debe cubrir.
Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del
sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir
nuevos resultados a mitad del proceso de elaboración del software.

Diseño del Sistema

Se descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo.
Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El
primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la
fase de análisis ha descrito el problema) identificando grandes módulos (conjuntos de
funciones que van a estar asociadas) y sus relaciones.
Con ello se define la arquitectura de la solución elegida. El segundo define los algoritmos
empleados y la organización del código para comenzar la implementación.

Diseño del Programa

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 siguiente etapa.

Codificación
Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así como
de pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y
componentes reutilizables dentro del mismo proyecto para hacer que la programación sea
un proceso mucho más rápido.

Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente y que cumple con los requisitos, antes de ser
entregado al usuario final.

Implantación
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya
realizaron exhaustivas pruebas para comprobar que el sistema no falle.

Mantenimiento
Una de las etapas que creo considerables porque se destina un 75% de los recursos, es
la mantención del Software ya que al utilizarlo como usuario final puede ser que no
cumpla con todas nuestras expectativas.

Variantes
Existen variantes de este modelo; especialmente destacamos la que hace uso de
prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento,
verificando que el sistema final este libre de fallos.
Mientras que todos los modelos del desarrollo del software llevarán una cierta semejanza
al modelo de la cascada, pues todos los modelos del desarrollo del software incorporarán
por lo menos algunas fases similares a ésas usadas dentro del modelo de la cascada.

CONCLUSIONES
Los diseñadores pueden no estar enterados de las dificultades futuras de la puesta en
práctica al escribir un diseño para un producto de software unimplemented.
Es decir, puede llegar a estar claro en la fase de la puesta en práctica que un área
particular de la funcionalidad del programa es extraordinario difícil de poner en ejecución.
Si éste es el caso, es mejor revisar el diseño que persistir al usar un diseño que fueron
hechos basado en predicciones culpables y que no explique las áreas problemáticas
nuevamente descubiertas.
A menos que los que especifican los requisitos y los que diseñan el sistema de software
en la pregunta sean altamente competentes, es difícil saber exactamente qué se necesita
en cada fase del proceso del software antes de que una cierta hora esté pasada en la
fase que lo sigue. Es decir, la regeneración a partir de fases siguientes es necesaria
terminar fases precedentes satisfactoriamente. Por ejemplo, la fase de diseño puede
necesitar la regeneración a partir de la fase de la puesta en práctica identificar áreas del
diseño del problema.

El counter-argument para el modelo de la cascada es que los diseñadores

experimentados pudieron haber trabajado en sistemas similares antes, y así que puede
poder predecir exactamente áreas problemáticas sin prototyping y poner en ejecución
pasados tiempo.

La prueba constante a partir de las fases del diseño, de la puesta en práctica y de la

verificación se requiere validar las fases que las preceden.
El trabajo de diseño constante del prototipo es necesario asegurarse de que los requisitos
son no-contradictorios y posibles satisfacer; la puesta en práctica constante es necesaria
encontrar áreas problemáticas e informar al proceso del diseño; la integración y la
verificación constantes del código puesto en ejecución es necesarias asegurarse de que
queda orientada la puesta en práctica pista.

El counter-argument para el modelo de la cascada aquí es que la puesta en práctica

constante y la prueba para validar el diseño y los requisitos es solamente necesarias si la
introducción de insectos es probable ser un problema. Los usuarios del modelo de la
cascada pueden discutir que si los diseñadores siguen un proceso disciplinado y no
incurren en equivocaciones que no hay necesidad del trabajo constante en fases
subsecuentes de validar las fases precedentes.

Es difícil estimar hora y el coste para cada fase del proceso del desarrollo sin hacer un
cierto trabajo “renovado” en esa fase, a menos que ésos que estiman tiempo y coste se
experimenten altamente con el tipo de producto de software en la pregunta.

El modelo de la cascada no trae ningún medio formal de ejercitar control de la gerencia

sobre un proyecto y no cubren a la gerencia del control que planea y de riesgo dentro del
modelo sí mismo.

Los sistemas muy específicos de la habilidad se requieren para cada fase, así hay un
requisito para los proyectos múltiples para funcionar en orden para optimizar uso del
recurso si todos los miembros permanecen con el curso de un proyecto dado, o para sufrir
niveles de habilidad

La idea detrás del modelo de la cascada puede ser “medida dos veces; corte una vez ", y
ésos opuestos al modelo de la cascada discuten que esta idea tienda para bajar aparte
cuando el problema que es medido es constantemente el cambiar debido a las
modificaciones y a las nuevas realizaciones sobre el problema sí mismo del requisito.
ESTRUCTURA DEL MODELO DE LA CASCADA

Ingeniería y Análisis
del Sistema

Análisis de los
Requisitos

Diseño

Codificación

Prueba

Mantenimiento
Bibliografía

http://es.wikipedia.org/wiki/Desarrollo_en_cascada

http://html.rincondelvago.com/el-ciclo-de-vida-del-software.html

http://carolina.terna.net/ingsw2/Datos/Cascada-ModeloV.doc

http://www.scribd.com/doc/20724441/modelo-cascada

http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema03.pdf

http://www.calameo.com/books/0000339419515702c3574

http://www.rcgcalume.phpnet.us/Doc/ciclo%20de%20vida%20de%20unsistema.pdf

http://jjegonzalezf.wordpress.com/2010/06/03/%C2%BFporque-no-funciona-el-modelo-en-
cascada/

http://delta.cs.cinvestav.mx/~pmejia/softeng/nuevo1.ppt

http://caraujo334.blogspot.es/1192584300/

http://www.rcgcalume.phpnet.us/Doc/ciclo%20de%20vida%20de%20unsistema.pdf

Formulación y Evaluación de Proyectos Informáticos Gabriel Baca Urbina

Desarrollo y Gestión de Proyectos Informáticos Steve McConnell