t-family:Wingdings'>ü Desarrollo Incremental
ü Desarrollo en Espiral
ü Desarrollo por Prototipos
Figura 8: Modelo de desarrollo en cascada.
En
la práctica, este modelo no es lineal, e involucra varias iteraciones e
interacción entre las distintas fases de desarrollo. Algunos problemas que se
observan en el modelo de cascada son:
1)
Las iteraciones
son costosas e implican rehacer trabajo debido a la producción y aprobación de
documentos.
2)
Aunque son pocas
iteraciones, es normal congelar parte del desarrollo y continuar con las
siguientes fases.
3)
Los problemas se
dejan para su posterior resolución, lo que lleva a que estos sean ignorados o
corregidos de una forma poco elegante.
4)
Existe una alta
probabilidad de que el software no cumpla con los requisitos del usuario por el
largo tiempo de entrega del producto.
5)
Es inflexible a
la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder
a cambios en los requisitos.
Este modelo sólo debe usarse si se entienden
a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.
Trabaja con base a documentos, es decir, la entrada y la
salida de cada fase es un tipo de documento específico. Idealmente, cada fase
podría hacerla un equipo diferente gracias a la documentación generada entre
las fases. Los documentos son:
·Análisis: Toma como
entrada una descripción en lenguaje natural de lo que quiere el cliente.
Produce el S.R.D. (Software Requirements Document).
·Diseño: Su entrada es
el S.R.D. Produce el S.D.D. (Software Design Document)
·Codificación: A
partir del S.D.D. produce módulos. En esta fase se hacen también pruebas de
unidad.
·Pruebas: A partir de
los módulos probados se realiza la integración y pruebas de todo el sistema. El
resultado de las pruebas es el producto final listo para entregar.
La planificación es
sencilla.
La calidad del
producto resultante es alta.
Permite trabajar con
personal poco cualificado.
Lo peor es la
necesidad de tener todos los requisitos al principio. Lo normal es que el
cliente no tenga perfectamente definidas las especificaciones del sistema, o
puede ser que surjan necesidades imprevistas.
ü
Si
se han cometido errores en una fase es difícil volver atrás.
ü
No
se tiene el producto hasta el final, esto quiere decir que:
§ Si se comete un error
en la fase de análisis no lo descubrimos
hasta la entrega, con el consiguiente gasto inútil de recursos.
§ El cliente no verá
resultados hasta el final, con lo que puede impacientarse.
ü
No
se tienen indicadores fiables del progreso del trabajo (síndrome del 90%).
ü
Es
comparativamente más lento que los demás y el coste es mayor también.
ü
Aquellos
para los que se dispone de todas las especificaciones desde el principio, por
ejemplo, los de reingeniería.
üSe está desarrollando
un tipo de producto que no es novedoso.
üProyectos complejos
que se entienden bien desde el principio.
Como el modelo en cascada ha sido muy
popular ha generado algunas variantes. Ahora veremos algunas:
Ciclo de vida en V
Propuesto por Alan Davis, tiene las mismas
fases que el anterior pero se considera el nivel de abstracción de cada una.
Una fase además de utilizarse como entrada para la siguiente, sirve para
validar o verificar otras fases posteriores. Su estructura está representada en
la siguiente figura.
Figura 9:
Ciclo de vida en V
Ciclo de vida tipo sashimi
Según el modelo en cascada puro una fase solo
puede empezar cuando ha terminado la anterior. En este caso sin embargo, se
permite un solapamiento entre fases. Por ejemplo, sin tener terminado del todo
el diseño se comienza a implementar. El nombre ``sashimi'' deriva del modo del
estilo de presentación de rodajas de pescado crudo en Japón. Una ventaja de
este modelo es que no necesita generar tanta documentación como el ciclo de
vida en cascada puro debido a la continuidad del mismo personal entre fases.
Los problemas planteados son:
·
Es
aún más difícil controlar el progreso del proyecto debido a que los finales de
fase ya no son un punto de referencia claro.
·
Al
hacer cosas en paralelo si hay problemas de comunicación pueden surgir
inconsistencias.
La fase de ``concepto'' consiste en definir
los objetivos del proyecto, beneficios, tipo de tecnología y el tipo de ciclo
de vida. El diseño arquitectónico es el de alto nivel, el detallado el de bajo
nivel. En la siguiente figura se ha representado la estructura del ciclo de
vida sashimi.
Figura 10:
Ciclo de vida sashimi
Ciclo de vida en cascada con subproyectos
Si una vez que se ha llegado al diseño
arquitectónico, se comprueba que el sistema se divide en varios subsistemas
independientes entre sí, sería razonable suponer que a partir de ese punto cada
uno se puede desarrollar por separado y en consecuencia en paralelo con los
demás. Cada uno tendrá seguramente fechas de terminación distintas. Una vez que
han terminado todos se integran y se prueba el sistema en su conjunto. La
ventaja es que se puede tener a gente trabajando en paralelo de forma
eficiente. El riesgo es que existan interdependencias entre los subproyectos.
En este caso se va creando el sistema
añadiendo pequeñas funcionalidades. Cada uno de los pequeños incrementos es
parecido a lo que ocurre dentro de la fase de mantenimiento. La ventaja de este método es que no es
necesario tener todos los requisitos en un principio. El inconveniente es que los errores en la
detección de requisitos se encuentran tarde.
Hay dos
partes en el ciclo de vida, similares al anterior. Por un lado está el análisis y el diseño global. Por
otra parte están los pequeños
incrementos, con las fases de diseño detallado, codificación y mantenimiento.
En la figura siguiente se puede ver su estructura.
Como se ha comentado anteriormente, uno de los problemas del ciclo de vida en
cascada es que si se entienden mal los requisitos esto sólo se descubrirá cuando
se entregue el producto. Para evitar
este problema se puede hacer un desarrollo
iterativo durante las fases de análisis y diseño global. Esto consistiría
en:
1.
Preguntar
al usuario.
2.
Hacer
el diseño global que se desprende del punto 1.
3.
Hacer
un prototipo de interfaz de usuario, entrevistas con los usuarios, etc. y
volver con ello al punto 1 para identificar más requisitos o corregir
malentendidos.
El resto es igual al ciclo de vida en
cascada.
No hay comentarios:
Publicar un comentario