MODELO EN CASCADA O LINEAL SECUENCIAL

MODELO LINEAL SECUENCIAL (CASCADA)

También llamado "Ciclo de vida básico" o "Modelo de cascada" tiene su
origen en el "Modelo de cascada" ingeniado por Winston Royce, aunque
omite los muchos bucles de este último. El Modelo Lineal Secuencial
sugiere un enfoque sistemático o más bien secuencial del desarrollo de
software que comienza en un nivel de sistemas y progresa con el análisis,
diseño, codificación, pruebas y mantenimiento.
Este es el más básico de todos los modelos y ha servido como bloque de
construcción para los demás paradigmas de ciclo de vida. Está basado en
el ciclo convencional de una ingeniería y su visión es muy simple: el
desarrollo de software se debe realizar siguiendo una secuencia de fases.
Cada etapa tiene un conjunto de metas bien definidas y las actividades
dentro de cada una contribuyen a la satisfacción de metas de esa fase o
quizás a una subsecuencia de metas de la misma.

El modelo en cascada puro difícilmente se utiliza tal cual, pues esto

implicaría un previo y absoluto conocimiento de los requisitos, la no
volatilidad de los mismos (o rigidez) y etapas subsiguientes libres de
errores; ello sólo podría ser aplicable a escasos y pequeños sistemas a
desarrollar. En estas circunstancias, el paso de una etapa a otra de las
mencionadas sería sin retorno, por ejemplo pasar del diseño a la
codificación implicaría un diseño exacto y sin errores ni probable
modificación o evolución: «codifique lo diseñado sin errores, no habrá en
absoluto variantes futuras». Esto es utópico; ya que intrínsecamente el
software es de carácter evolutivo,9cambiante y difícilmente libre de
errores, tanto durante su desarrollo como durante su vida operativa.
El Modelo Lineal Secuencial acompaña las siguientes actividades:

GRÁFICO DEL MODELO LINEAL SECUENCIA "CASCADA"

Análisis de los requerimientos del software:
El proceso de recopilación de los requisitos se centra e intensifica
especialmente en el software. El ingeniero de software debe comprender
el ámbito de la información del software así como la función, el
rendimiento y las interfaces requeridas.

Diseño:
El diseño del software se enfoca en cuatro atributos distintos del
programa; la estructura de los datos, la arquitectura del software, el
detalle procedimental y la caracterización de la interfaz. El proceso de
diseño traduce los requisitos en una representación del software con la
calidad requerida antes de que comience la codificación.

Generación del código: El diseño debe traducirse en una forma legible

para la maquina. Si el diseño se realiza de una manera detallada, la
codificación puede realizarse mecánicamente.
Pruebas:
Una vez que se ha generado el código comienza la prueba del programa.
La prueba se centra en la lógica interna del software y en las funciones
externas, realizando pruebas que aseguren que la entrada definida
produce los resultados que realmente se requieren.

Mantenimiento:
Debido a que el programa puede tener errores, puede no ser del completo
agrado del cliente o puede necesitar, eventualmente acoplarse a los
cambios en su entorno. Esto quiere decir que no se rehace el programa,
sino que sobre la base de uno ya existente se realizan algunos cambios. 

En el modelo vemos una ventaja evidente y radica en su sencillez, ya que

sigue los pasos intuitivos necesarios a la hora de desarrollar el software.
Pero el modelo se aplica en un contexto, así que debemos atender
también a él y saber que:

 Los proyectos reales raramente siguen el flujo secuencial que

propone el modelo. Siempre hay iteraciones y se crean problemas en
la aplicación del paradigma.

 Normalmente, al principio, es difícil para el cliente establecer todos

los requisitos explícitamente. El ciclo de vida clásico lo requiere y
tiene dificultades en acomodar posibles incertidumbres que pueden
existir al comienzo de muchos productos.

 El cliente debe tener paciencia. Hasta llegar a las etapas finales del
proyecto no estará disponible una versión operativa del programa. Un
error importante que no pueda ser detectado hasta que el programa
esté funcionando, puede ser desastroso.

Los responsables del desarrollo de software siempre se retrasan

innecesariamente. Todo lo anteriormente expuesto es cierto pero este
paradigma tiene un lugar bien definido e importante en el trabajo de la
Ingeniería de Software aparte de proporcionar una plantilla en la que se
encuentran métodos para análisis, diseño, codificación, pruebas y
mantenimiento. Con todo y sus errores, sigue siendo el paradigma más
utilizado en el desarrollo del software, siendo mucho mejor que un
enfoque al azar.

1. Ingeniería y Análisis del Sistema: Debido a que el software es siempre

parte de un sistema mayor, el trabajo comienza estableciendo los
requisitos de todos los elementos del sistema y luego asignando algún
subconjunto de estos requisitos al software.

2. Análisis de los requisitos del software:

Características del modelo

 Primer modelo empleado (Royce, 1970), también denominado ciclo
de vida clásico y modelo lineal secuencial.
 Consiste en la ejecución secuencial de una serie de fases que se
suceden, lo que da nombre al modelo.
 Cada fase genera documentación para la siguiente. Esta
documentación debe ser aprobada.
 Una fase no comienza hasta que la anterior ha terminado.
 Requiere disponer de unos requisitos completos y precisos al
principio del desarrollo.
 Se disponga de unos requisitos completos y consistentes al
principio del desarrollo.
 Sea un proyecto pequeño, en el que el período de congelación de los
requisitos es corto, o un proyecto con unos requisitos bastante
estables.
Ventajas:
  Se debe tener en cuenta que fue el primer modelo empleado, y por
lo tanto es mejor que ninguno.
 Facilita la gestión del desarrollo.
Desventajas:
 En general, establecer todos los requisitos al principio del proceso
de desarrollo es un mito inalcanzable, Los usuarios no pueden
imaginarse lo que quieren hasta que no ven un sistema
funcionando.
 Los requisitos no se pueden congelar mientras dura el desarrollo. El
mercado cambia, todo cambia.
 El usuario debe esperar mucho tiempo hasta ver los resultados
 Los errores de análisis y diseño son costosos de eliminar, y se
propagan a las fases siguientes con un efecto conocido como bola de
nieve.
 Se genera mucho mantenimiento inicial debido al período de
congelación de requisitos y éste recae, en su mayor parte.

 Los cambios introducidos durante el desarrollo pueden confundir al

equipo profesional en las etapas tempranas del proyecto. Si los
cambios se producen en etapa madura (codificación o prueba)
pueden ser catastróficos para un proyecto grande.

 No es frecuente que el cliente o usuario final explicite clara y

completamente los requisitos (etapa de inicio); y el modelo lineal lo
requiere. La incertidumbre natural en los comienzos es luego difícil
de acomodar.

 El cliente debe tener paciencia ya que el software no estará

disponible hasta muy avanzado el proyecto. Un error detectado por
el cliente (en fase de operación) puede ser desastroso, implicando
reinicio del proyecto, con altos costos.
Ejemplos
 Este modelo es ampliamente utilizado en los sistemas
gubernamentales de gran tamaño, en especial en el Departamento
de Defensa de los Estados Unidos (DOD).
 Es utilizado en la NASA.
¿Por qué a veces falla el modelo Lineal?
 Los proyectos reales raras veces siguen el modelo secuencial que
propone el modelo.
 A menudo es difícil que el cliente exponga explícitamente todos los
requerimientos.
 El cliente debe tener paciencia. Un grave error puede ser desastroso
 Cada uno de estos errores es real. Sin embargo, el paradigma del
ciclo de vida clásico tiene lugar definido e importante trabajo de la
ingeniería del software. 

Modelos evolutivos
El software evoluciona con el tiempo. Los requisitos del usuario y del
producto suelen cambiar conforme se desarrolla el mismo. Las fechas de
mercado y la competencia hacen que no sea posible esperar a poner en el
mercado un producto absolutamente completo, por lo que se aconsejable
introducir una versión funcional limitada de alguna forma para aliviar las
presiones competitivas.

En esas u otras situaciones similares los desarrolladores necesitan

modelos de progreso que estén diseñados para acomodarse a una
evolución temporal o progresiva, donde los requisitos centrales son
conocidos de antemano, aunque no estén bien definidos a nivel detalle.
En el modelo cascada y cascada realimentado no se tiene demasiado en
cuenta la naturaleza evolutiva del software, se plantea como estático, con
requisitos bien conocidos y definidos desde el inicio.

Los evolutivos son modelos iterativos, permiten desarrollar versiones

cada vez más completas y complejas, hasta llegar al objetivo final
deseado; incluso evolucionar más allá, durante la fase de operación.

Los modelos «iterativo incremental» y «espiral» (entre otros) son dos de

los más conocidos y utilizados del tipo evolutivo.

Conclusión

La metodología de cascada ordena rigurosamente las etapas del ciclo del

software, es decir en este modelo se tienen que terminar las fases en un
orden, Lo que puedo mencionar es que la modelo cascada es un
modelo que al llevarse a cabo se debe de llevar fase por fase para poder
pasar a la siguiente etapa.
El modelo de cascada es exitoso cuando se tienen bien especificados los
requerimientos del software y se conozcan las herramientas a utilizar,
este modelo también nos permite realizar una organización más fácil de
comprender tratando de no mezclar las diferentes fases del modelo y así
nos permite organizar el tipo de proyecto que pretende solucionar es
decir donde se conozcan todos los requisitos especificados durante su
ejecución