INGENIERÍA DEL SOFTWARE
MODELO DE CICLO DE VIDA
Modelo en cascada:
Es el enfoque metodológico que ordena rigurosamente las etapas del ciclo
de vida del software, de forma que el
inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. El
modelo en cascada es un proceso de desarrollo secuencial, en el que el
desarrollo se ve fluyendo hacia abajo
(como una cascada) sobre las fases que componen el ciclo de vida.
Se cree que el modelo en cascada fue el primer modelo de proceso introducido
y seguido ampliamente en la ingeniería
el software. La innovación estuvo en la primera vez que la ingeniería del
software fue dividida en fases separadas.
La primera descripción formal del modelo en cascada se cree que fue en un
artículo publicado en 1970 por Winston
W. Royce, aunque Royce no usó el término cascada en este artículo.
Irónicamente, Royce estaba presentando este modelo como un ejemplo de modelo
que no funcionaba, defectuoso.
En el modelo original de Royce, existían las siguientes fases:
1.
Especificación de requisitos
2. Diseño
3. Construcción
(Implementación o codificación)
4. Integración
5. Pruebas
6. Instalación
7. Mantenimiento
Para seguir el modelo en cascada, se avanza de una fase a la siguiente en
una forma puramente secuencial.
Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido a día de hoy.
Ventajas
El modelo en cascada puede ser
apropiado, en general, para proyectos estables
(Especialmente los proyectos con requisitos no cambiantes) y donde es
posible y probable que los diseñadores predigan totalmente áreas de problema
del sistema y produzcan un diseño correcto antes de que empiece la
implementación. Funciona bien para proyectos pequeños donde los requisitos
están bien entendidos.
Es un modelo en el que
todo está bien organizado y no se mezclan las fases. Es simple y fácil de usar.
Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tiene
entregables específicos y un proceso de revisión. Las fases son procesadas y
completadas de una vez.
Inconvenientes
En la vida real, un
proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación
del modelo, lo cual hace que lo lleve al fracaso. Difícilmente un cliente va a
establecer al principio todos los requisitos necesarios, por lo que provoca un
gran atraso trabajando en este modelo, ya que este es muy restrictivo y no
permite movilizarse entre fases. Los resultados y/o mejoras no son visibles
progresivamente, el producto se ve cuando ya está finalizado, lo cual provoca
una gran inseguridad por parte del cliente que quiere ir viendo los avances en
el producto. Esto también implica el tener que tratar con requisitos que no se
habían tomado en cuenta desde el principio, y que surgieron al momento de la implementación,
lo cual provocará que haya que volver de nuevo a la fase de requisitos. Hay
muchas personas que argumentan que es una mala idea en la práctica,
principalmente a causa de su creencia de que es imposible, para un proyecto no
trivial, conseguir tener una fase del ciclo de vida del producto software
perfecta antes de moverse a las siguientes fases. Por ejemplo, los clientes
pueden no ser conscientes exactamente de los requisitos que quieren antes de
ver un prototipo del trabajo; pueden cambiar los requisitos constantemente, y
los diseñadores e implementadores pueden tener poco control sobre esto. Si los
clientes cambian sus requisitos después de que el diseño está terminado, este diseño
deberá ser modificado para acomodarse a los nuevos requisitos, invalidando una buena
parte del esfuerzo.
Muchas veces se considera un modelo
pobre para proyectos complejos, largos, orientados a objetos y por supuesto en
aquellos en los que los requisitos tengan un riesgo de moderado a alto de cambiar.
Genera altas cantidades de riesgos e incertidumbres.
Variantes
Existen muchas variantes
de este modelo. En respuesta a los problemas percibidos con el modelo en
cascada puro, se introdujeron muchos modelos de cascada modificados. Estos modelos
pueden solventar algunas o todas las críticas del modelo en cascada puro. De
hecho muchos de los modelos utilizados tienen su base en el modelo en cascada.
Uno de estos modelos
modificados es el modelo Sashimi.
El modelo Sashimi
(llamado así porque tiene fases solapadas, como el pescado japonés Sashimi) fue
creado originalmente por Peter DeGrace. A veces se hace referencia a él como el
modelo en cascada con fases superpuestas o el modelo en cascada con
retroalimentación. Ya que las fases en el modelo Sashimi se superponen, lo que
implica que se puede actuar durante las etapas anteriores. Por ejemplo, ya que
las fases de diseño e implementación se superpondrán en el modelo Sashimi, los
problemas de implementación se pueden descubrir durante las fases de diseño e
implementación del proceso de desarrollo. Esto ayuda a aliviar muchos de los
problemas asociadas con la filosofía del modelo en cascada.
Aplicación de Este Modelo a Nuestro Proyecto Socio Tecnológico II.
Se aplica este modelo de
ciclo de vida en el proyecto ya que los pasos a seguir son mas directos, específicos y fáciles de desarrollar para así detectar cualquier imprevisto a tiempo. Aplicando cada face de la siguiente manera:
No hay comentarios.:
Publicar un comentario