Modelos de Ciclo de Vida
Las
formas de organizar y estructurar la secuencia de ejecución de las tareas en
las diferentes fases de cada uno de los métodos puede dar lugar a un tipo de ciclo
de vida diferente; Las principales diferencias entre distintos modelos de ciclo
de vida están divididas en 3 grandes visiones:
1.-El alcance de ciclo de vida:
depende de hasta donde deseamos llegar con el proyecto.
2.-La cualidad y cantidad de las
etapas: que ciclo de vida se escogerá y el proyecto al cual se adaptara.
3.-La estructura y la sucesión
de las etapas: si hay realimentación entre las etapas y hay libertad para
repetirlas.
Ciclo de Vida en Cascada
El
ciclo de vida inicialmente propuesto por Winston Royce en 1970, es el más seguido
por las organizaciones. Es un ciclo de vida que admite interacciones, es decir,
durante las modificaciones que se hacen en el mantenimiento se puede ver por
ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se
harán los cambios necesarios en la codificación y se tendrán que realizar de
nuevo las pruebas, es decir, si se tiene que volver a una de las etapas
anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas. Después de cada etapa se realiza una o varias
revisiones para comprobar si se puede pasar a la siguiente. Este sirvió de base
para el resto de los ciclos de vida.
Trabaja
en 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. Algunas de sus
ventajas son las siguientes:
·
La planificación es sencilla.
·
La calidad del producto
resultante es alta.
·
Permite trabajar con
personal poco calificado.
·
Generalmente no se
cuenta con todos los requisitos y las especificaciones al principio y surgen necesidades
imprevistas.
·
Si se cómete algún
error ya avanzada una etapa es difícil regresar a corregir.
·
El cliente no verá
resultados hasta el final. No se tiene el producto hasta el final.
·
No se tienen
indicadores fiables del progreso del trabajo.
·
Es comparativamente más
lento que los demás y el coste es mayor también.
La necesidad de
conocer los requerimientos al principio del proyecto es primordial al elegir
este modelo a pesar de permitir iteraciones.
Ciclo de Vida en V
Propuesto
por Alan Davis, tiene las mismas etapas del ciclo de vida de cascada solo que a
este se le agregaron dos sub-etapas de retroalimentación entre la etapa de
análisis y mantenimiento y entre las de diseño y depuración.
Las ventajas y
desventajas de este ciclo son las mismas que las de cascada, con el agregado de
los controles entre etapas para lograr una mayor corrección. Este modelo lo
podemos utilizar en aplicaciones simples pero de alta confiabilidad como por
ejemplo en facturación. Este modelo nos ofrece mayor garantía de corrección al
terminar el proyecto.
Ciclo de Vida Tipo Sashimi
Según
el modelo en cascada, 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 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.
Cuando necesitemos realizar una
aplicación que comparta los recursos CPU, memoria y espacio de almacenamiento,
con otras aplicaciones tratando de mantener un ambiente productivo, este modelo
de ciclo de vida es una opción muy válida. El solapamiento de sus etapas nos
permite jugar con el modelo de tres capas ahorrando recursos.
El modelo de tres capas es un modelo de
programación para aplicaciones de acceso a datos que busca separar la
arquitectura del programa en tres capas. En la capa de datos solo nos
preocupamos por el almacenamiento de estos, en la capa de negocios situamos
todas las transacciones y
validaciones y en la capa de
presentación solo encontramos las rutinas de visualización e interacción con el
usuario.
Ciclo de Vida en Cascada con Subproyectos
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.
Es ideal cuando se cuenta con un
plantel numeroso de programadores, es una ventaja tener más gente trabajando al
mismo tiempo. Pero la desventaja es que pueden surgir ciertas dependencias
entre las distintas subetapas que detengan el proyecto temporalmente si no es
gestionado de manera correcta, es un modelo donde hay que administrar y poner
demasiada atención a los tiempos.
Ciclo de Vida en Cascada Incremental
En
este caso se va creando el sistema añadiendo pequeñas funcionalidades. Se
realiza construyendo por módulos que cumplen las diferentes funciones del
sistema; esto permite ir aumentando gradualmente las capacidades del software.
Este ciclo de vida facilita la tarea del
desarrollo permitiendo a cada del equipo desarrollar un modulo del proyecto. Es
una repetición del ciclo de vida en cascada, aplicando se este ciclo en cada
funcionalidad del programa a construir.
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, 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.
Ciclo de Vida en Espiral
Propuesto
inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten.
Cada uno tiene las mismas fases y cuando termina da un producto ampliado con
respecto al ciclo anterior. En este sentido es parecido al modelo incremental,
la diferencia importante es que tiene en cuenta el concepto de riesgo. Un
riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseño, errores
en la implementación, etc.
Hay cuatro
actividades que envuelven a las etapas:
Determinar
los objetivos a través de una entrevista hecha directamente con el cliente
incluyendo todo tipo de requerimientos. La planificación que es el relevamiento
de los requerimientos iníciales o luego de una interacción el análisis de
riesgo que va de acuerdo con la planificación para ver si es factible continuar
con el desarrollo y después se procede a las pruebas y evaluación.
Al
terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple
con los requisitos establecidos, también se verifica que funciona correctamente.
El propio cliente evalúa el producto. No existe una diferencia muy clara entre
cuando termina y cuando empieza una fase. Cuando hay que hacer un cambio, este
puede consistir en un nuevo ciclo.
Ventajas
de este tipo de ciclo: No necesita una definición completa de los requisitos
para empezar a funcionar. Al entregar productos desde el final de la primera
iteración es más fácil validar los requisitos. El riesgo en general es menor,
porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos
en una iteración (las anteriores iteraciones están bien). El riesgo de sufrir
retrasos es menor, ya que al identificar los problemas en etapas tempranas hay
tiempo de subsanarlos.
Algunas desventajas serian: Es
difícil evaluar los riesgos. Necesita de la participación continua por parte
del cliente. Cuando se subcontrata hay que producir previamente una
especificación completa de lo que se necesita, y esto lleva tiempo.
Ciclo de Vida Orientado a Objetos
considerarse como un modelo
pleno a seguir, técnica presentada en los 90´s, tal vez como una de las mejores
metodologías para la creación de productos software. Cada funcionalidad o requerimiento
solicitado por el usuario, es considerado un objeto. Los objetos están
representados por un conjunto de propiedades llamadas atributos, por otra parte
el comportamiento que tendrán estos objetos se denominaran métodos.
