desarollo de software

El modelo de cascada
Gustavo Donoso:
El modelo de cascada es también conocido como Modelo en cascada o Modelo lineal secuencial o Ciclo de
vida básico o Ciclo de vida clásico.
Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Existe, para este modelo, un
reconocimiento de los ciclos de retroalimentación entre etapas, y una guía para confinar las
retroalimentaciones a las etapas sucesivas con el objetivo de minimizar el costo del retrabajo involucrado en
retroalimentaciones a través de muchas etapas.
Las ventajas que presentan tanto el modelo de etapas y de cascada tiene relación con la idea de postular un
marco de trabajo claro, que reconoce y define las actividades involucradas en el desarrollo de software,
permitiendo establecer relaciones de cooperación entre ellas. Corresponden, también, a los métodos más
usados en desarrollo de software y que han sido exitosos durante décadas tanto en el desarrollo de grandes
sistemas como en el de pequeños.



Tanto el modelo de etapas como el de cascada, presentan algunas dificultades comunes. Por ejemplo, la
especificación de los problemas. Ambos métodos asumen que el diseñador puede distinguir entre lo que el
sistema debe hacer y como el sistema lo hará; pero algunos problemas no pueden ser divididos tan fácilmente
para ser atacados desde este prisma.


Tanto el modelo de etapas como el de cascada, presentan algunas dificultades comunes. Por ejemplo, la
especificación de los problemas. Ambos métodos asumen que el diseñador puede distinguir entre lo que el
sistema debe hacer y como el sistema lo hará; pero algunos problemas no pueden ser divididos tan fácilmente
para ser atacados desde este prisma.
Por otro lado, generalmente los requerimientos son especificados al inicio del proyecto y, paradojalmente,
cuando se tiene la claridad suficiente para definir precisamente lo que se quiere es cuando se está en las
últimas etapas del proyecto. Esto es consecuencia, en general, de que los clientes no están familiarizados con
la tecnología, con lo cual producen requerimientos muy vagos, que son interpretados arbitrariamente por los
desarrolladores.
Otro factor importante es que estos métodos asumen que una vez que los requerimientos han sido definidos
entonces ellos no cambiarán más. Pero, dependiendo de la complejidad del proyecto, la implementación final
puede ocurrir meses o, eventualmente, años después de que los requerimientos han sido especificados; así, en
las últimas etapas del proyecto, los requerimientos pueden haber cambiado.
Existiría un énfasis en la elaboración de documentos. El sistema completo es descrito y registrado en papel,
cada etapa produce cierta cantidad de documentos. Esto lleva a que, por ejemplo, para sistemas complejos las
especificaciones de requerimientos pueden ser de cientos de páginas, explicando todos u cada uno de los
detalles del sistema. Y es difícil poder visualizar a priori, desde éste volumen de papel, las características del
sistema.
Por último, se ha detectado que el enfoque lineal de estos métodos no sería el adecuado para reflejar el
proceso de desarrollo de software. Esto explica que se diga que para algunos proyectos el modelo clásico los
lleva a seguir las etapas en orden incorrecto. Más aún, es posible que todas las etapas del proyecto, estén
comprimidas dentro de cada una.
Como se ha podido observar, la especificación de métodos más acabados para el desarrollo de software no
logra superar el problema de la distancia entre la visión del usuario y la del desarrollador, ya que no se ha
buscado resolver ese problema, sino que las soluciones se centraron principalmente en la división de las tareas
con miras al control de las mismas, lo que si bien soluciona el problema de especificar y luego programar,
crea otros, como el presentado en el párrafo anterior, en que no todos los problemas podrían ser abordados
desde una misma perspectiva de orden en las etapas.

Traducir el diseño para que lo entienda la máquina.
· Prueba.
Cuando ya se ha generado el código.
· Mantenimiento.
El software sufrirá cambios después de que se entregue al cliente.
Problemas:
1. No siempre se sigue el flujo secuencial.
2. Es difícil tener un 100% de los requisitos al inicio.
3. El cliente debe tener paciencia. Los primeros resultados serán hasta que ya este operando el sistema.