Las principales diferencias entre distintos modelos de ciclo de vida
están divididas en tres grandes visiones:
• El alcance del ciclo de vida, que depende de hasta dónde
deseamos llegar con el proyecto: sólo saber si es viable el desarrollo de un
producto, el desarrollo completo o el desarrollo completo más las
actualizaciones y el mantenimiento.
• La calidad y cantidad de las etapas en que dividiremos
el ciclo de vida: según el ciclo de vida que adoptemos, y el
proyecto para el cual lo adoptemos.
• La estructura y la sucesión de las etapas, si hay
realimentación entre ellas, y si tenemos libertad de repetirlas (iterar).
En los distintos modelos de ciclo de vida mencionaremos el riesgo
que suponemos aceptar al elegirlo. Cuando hablamos de riesgo, nos referimos a
la probabilidad que tendremos de volver a retomar una de las etapas anteriores,
perdiendo tiempo, dinero y esfuerzo.
Ciclo de
vida Lineal
Es el más sencillo de todos los modelos. Consiste en descomponer la
actividad global del proyecto en etapas separadas que son realizadas de manera
lineal, es decir, cada etapa se realiza una sola vez, a continuación de la
etapa anterior y antes de la etapa siguiente. Con un ciclo de vida lineal es
muy fácil dividir las tareas, y prever los tiempos (sumando linealmente los de
cada etapa).
Las actividades de cada una de las etapas mencionadas deben ser
independientes entre sí, es decir, que es condición primordial que no haya
retroalimentación entre ellas, aunque sí pueden admitirse ciertos supuestos de
realimentación correctiva. Desde el punto de vista de la gestión, requiere
también que se conozca desde el primer momento, con excesiva rigidez, lo que va
a ocurrir en cada una de las distintas etapas antes de comenzarla. Esto último
minimiza, también, las posibilidades de errores durante la codificación y
reduce al mínimo la necesidad de requerir información del cliente o del
usuario.
Se destaca como ventaja la sencillez de su gestión y administración
tanto económica como temporal, ya que se acomoda perfectamente a proyectos
internos de una empresa para programas muy pequeños de ABM (sistemas que
realizan Altas, Bajas y Modificaciones sobre un conjunto de datos). Tiene como
desventaja que no es apto para Desarrollos que superen mínimamente
requerimientos de retroalimentación entre etapas, es decir, es muy costoso
retomar una etapa anterior al detectar alguna falla.
Es válido tomar este ciclo de vida cuando algún sector pequeño de una
empresa necesita llevar un registro de datos acumulativos, sin necesidad de
realizar procesos sobre ellos más que una consulta simple. Es decir, una
aplicación que se dedique exclusivamente a almacenar datos, sea una base de datos
o un archivo plano. Debido a que la realización de las etapas es muy simple y
el código muy sencillo.
Ciclo de
vida en cascada puro
Este modelo de ciclo de vida fue propuesto por Winston Royce en el año
1970. Es un ciclo de vida que admite iteraciones, contrariamente a la creencia
de que es un ciclo de vida secuencial como el lineal. Después de cada etapa se
realiza una o varias revisiones para comprobar si se puede pasar a la
siguiente. Es un modelo rígido, poco flexible, y con muchas restricciones.
Aunque fue uno de los primeros, y sirvió de base para el resto de los modelos
de ciclo de vida.
Una de sus ventajas, además de su planificación sencilla, es la de
proveer un producto con un elevado grado de calidad sin necesidad de un
personal altamente calificado. Se pueden considerar como inconvenientes: la
necesidad de contar con todos los requerimientos (o la mayoría) al comienzo del
proyecto, y, si se han cometido errores y no se detectan en la etapa inmediata
siguiente, es costoso y difícil volver atrás para realizar la corrección
posterior.
Además, los resultados no los veremos hasta que no estemos en las etapas
finales del ciclo, por lo que, cualquier error detectado nos trae retraso y
aumenta el costo del desarrollo en función del tiempo que insume la corrección
de éstos.
Es un ciclo adecuado para los proyectos en los que se dispone de todos
los requerimientos al comienzo, para el desarrollo de un producto con
funcionalidades conocidas o para proyectos, que, aun siendo muy complejos, se
entienden perfectamente desde el principio.
Se evidencia que es un modelo puramente teórico, ya que el usuario rara
vez mantiene los requerimientos iniciales y existen muchas posibilidades de que
debamos retomar alguna etapa anterior.
Pero es mejor que no seguir ningún ciclo de vida.
Fue utilizado en medianos y grandes proyectos hasta principios de la
década de 1990, y a finales de esta década las críticas a este modelo
aumentaron notablemente. Por lo que hoy en día sólo se lo cita como mero
ejemplo bibliográfico. No podemos evitar decir que hay aspectos a cuestionar.
Se le criticó, principalmente, el retardo en entregar partes del producto, su
metodología para la corrección de errores, su obstinación por exigir
requerimientos previos completos, y su alta rigidez. A pesar de todo no es
erróneo adaptarlo para alguna aplicación en la que el modelo de ciclo lineal no
sea del todo adecuado, y el uso de un modelo de gestión más elaborado no lo
justifique.
Ciclo de
vida en V
Este ciclo fue diseñado por Alan Davis, y contiene las mismas etapas que
el ciclo de vida en cascada puro. A diferencia de aquél, a éste se le agregaron
dos subetapas de retroalimentación entre las etapas de análisis y
mantenimiento, y entre las de diseño y debugging.
Las ventajas y desventajas de este modelo son las mismas del ciclo
anterior, con el agregado de los controles cruzados entre etapas para lograr
una mayor corrección.
Podemos utilizar este modelo de ciclo de vida en aplicaciones, que si
bien son simples (pequeñas transacciones sobre bases de datos, por ejemplo),
necesitan una confiabilidad muy alta. Un ejemplo claro en el que no nos podemos
permitir el lujo de cometer errores es una aplicación de facturación, en la que
si bien los procedimientos vistos individualmente son de codificación e interpretación
sencilla, la aplicación en su conjunto puede tener matices complicados.
Ciclo de
vida tipo Sashimi
Este ciclo de vida es parecido al ciclo de vida en cascada puro, con la
diferencia de que en el ciclo de vida en cascada no se pueden solapar las
etapas, y en éste sí. Esto suele, en muchos casos, aumentar su eficiencia ya
que la retroalimentación entre etapas se encuentra implícitamente en el modelo.
Se hace notar como ventajas la ganancia de calidad en lo que respecta al
producto final, la falta de necesidad de una documentación detallada (el ahorro
proviene por el solapado de las etapas). Sus desventajas también se refieren al
solapamiento de las etapas: es muy difícil gestionar el comienzo y fin de cada
etapa y los problemas de comunicación, si aparecen, generan inconsistencias en
el proyecto.
Cuando necesitemos realizar una aplicación que compartirá los recursos (CPU,
memoria o espacio de almacenamiento) con otras aplicaciones en un ambiente productivo,
este modelo de ciclo de vida es una opción muy válida. El solapamiento de sus
etapas nos permite en la práctica jugar un poco con el modelo de tres capas
ahorrando recursos.
Ciclo de
vida en cascada con subproyectos
Sigue el modelo de ciclo de vida en cascada. Cada una de las cascadas se
dividen en subetapas independientes que se pueden desarrollar en paralelo.
La ventaja es que se puede tener más gente trabajando al mismo tiempo,
pero la desventaja es que pueden surgir dependencias entre las distintas
subetapas que detengan el proyecto temporalmente si no es gestionado de manera
correcta.
Podemos utilizar este modelo para administrar cualquier proyecto
mencionado en los modelos anteriores. Pero cuidando de administrar muy bien los
tiempos.
Ciclo de
vida iterativo
También derivado del ciclo de vida en cascada puro, este modelo busca
reducir el riesgo que surge entre las necesidades del usuario y el producto
final por malos entendidos durante la etapa de solicitud de requerimientos.
Es la iteración de varios ciclos de vida en cascada. Al final de cada
iteración se le entrega al cliente una versión mejorada o con mayores
funcionalidades del producto. El cliente es quien luego de cada iteración,
evalúa el producto y lo corrige o propone mejoras. Estas iteraciones se
repetirán hasta obtener un producto que satisfaga al cliente.
Se suele utilizar en proyectos en los que los requerimientos no están
claros de parte del usuario, por lo que se hace necesaria la creación de
distintos prototipos para presentarlos y conseguir la conformidad del cliente.
Podemos adoptar el modelo mencionado en aplicaciones medianas a grandes,
en las que el usuario o cliente final no necesita todas las funcionalidades desde
el principio del proyecto. Quizás una empresa que debe migrar sus aplicaciones hacia
otra arquitectura, y desea hacerlo paulatinamente, es un candidato ideal para
este tipo de modelo de ciclo de vida.
Ciclo de
vida con prototipos
El uso de programas prototipo no es exclusivo del ciclo de vida
iterativo. En la práctica los prototipos se utilizan para validar los requerimientos
de los usuarios en cualquier ciclo de vida.
Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles
son las especificaciones de forma precisa, suele recurrirse a definir
especificaciones iniciales para hacer un prototipo, o sea, un producto parcial
y provisional. En este modelo, el objetivo es lograr un producto intermedio,
antes de realizar el producto final, para conocer mediante el prototipo cómo responderán
las funcionalidades previstas para el producto final.
Antes de adoptar este modelo de ciclo debemos evaluar si el esfuerzo por
crear un prototipo vale realmente la pena adoptarlo.
Se utiliza mayoritariamente en desarrollos de productos con innovaciones
importantes, o en el uso de tecnologías nuevas o poco probadas, en las que la
incertidumbre sobre los resultados a obtener, o la ignorancia sobre el
comportamiento, impiden iniciar un proyecto secuencial.
La ventaja de este ciclo se basa en que es el único apto para
desarrollos en los que no se conoce a priori sus especificaciones o la tecnología
a utilizar. Como contrapartida, por este desconocimiento, tiene la desventaja
de ser altamente costoso y difícil para la administración temporal.
Si deseamos migrar aplicaciones de tecnología para adoptar sus nuevas
funcionalidades o simplemente para estar en la cresta de la ola, este modelo es
ideal. Un claro ejemplo son las llegadas de Java y la tecnología .NET que, si
bien contaban con respaldo y material de ayuda, implantaron nuevas tendencias.
Ciclo de
vida evolutivo
Este modelo acepta que los requerimientos del usuario pueden cambiar en cualquier
momento.
La práctica nos demuestra que obtener todos los requerimientos al comienzo
del proyecto es extremadamente difícil, no sólo por la dificultad del usuario
de transmitir su idea, sino porque estos requerimientos evolucionan durante el
desarrollo y de esta manera, surgen nuevos requerimientos a cumplir. El modelo
de ciclo de vida evolutivo afronta este problema mediante una iteración de
ciclos requerimientos–desarrollo–evaluación.
Resulta ser un modelo muy útil cuando desconocemos la mayoría de los requerimientos
iniciales, o estos requerimientos no están completos.
Tomemos como ejemplo un sistema centralizado de stock–ventas–facturación,
en el cual hay muchas áreas que utilizarán la aplicación. Tenemos dos
complicaciones: la primera, los usuarios no conocen de informática, la segunda,
no es uno, sino varios los sectores que nos pueden pedir modificaciones o hacer
nuevas solicitudes. Además, el pedido de un sector puede influir en los requerimientos
del otro. Se hace necesario, entonces, lograr que la aplicación evolucione
hasta lograr las satisfacciones de los todos los sectores involucrados.
Ciclo de
vida incremental
Este modelo de ciclo de vida se basa en la filosofía de construir
incrementando las funcionalidades del programa.
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 miembro
del equipo desarrollar un modulo particular en el caso de que el proyecto sea
realizado por un equipo de programadores.
Es una repetición del ciclo de vida en cascada, aplicándose este ciclo
en cada funcionalidad del programa a construir. Al final de cada ciclo le
entregamos una versión al cliente que contiene una nueva funcionalidad. Este
ciclo de vida nos permite realizar una entrega al cliente antes de terminar el
proyecto.
El modelo de ciclo de vida incremental nos genera algunos beneficios
tales como los que se describen a continuación:
- Construir un sistema pequeño siempre es menos riesgoso que construir un sistema grande.
- Como desarrollamos independientemente las funcionalidades, es más fácil relevar los requerimientos del usuario.
- Si se detecta un error grave, sólo desechamos la última iteración.
- No es necesario disponer de los requerimientos de todas las funcionalidades en el comienzo del proyecto y además facilita la labor del desarrollo con la conocida filosofía de divide & conqueror.
Este modelo de ciclo de vida no está pensado para cierto tipo de
aplicaciones, sino que está orientado a cierto tipo de usuario o cliente.
Podremos utilizar este modelo de ciclo de vida para casi cualquier proyecto,
pero será verdaderamente útil cuando el usuario necesite entregas rápidas,
aunque sean parciales.
Ciclo de
vida espiral
Este ciclo puede considerarse una variación del modelo con prototipo,
fue diseñado por Boehm en el año 1988. El modelo se basa en una serie de ciclos
repetitivos para ir ganando madurez en el producto final. Toma los beneficios
de los ciclos de vida incremental y por prototipos, pero se tiene más en cuenta
el concepto de riesgo que aparece debido a las incertidumbres e ignorancias de
los requerimientos proporcionados al principio del proyecto o que surgirán
durante el desarrollo. A medida que el ciclo se cumple (el avance del espiral),
se van obteniendo prototipos sucesivos que van ganando la satisfacción del
cliente o usuario.
A menudo, la fuente de incertidumbres es el propio cliente o usuario,
que en la mayoría de las oportunidades no sabe con perfección todas las funcionalidades
que debe tener el producto.
En este modelo hay cuatro actividades que envuelven a las etapas.
- Planificación: Relevamiento de requerimientos iniciales o luego de una iteración.
- Análisis de riesgo: De acuerdo con el relevamiento de requerimientos decidimos si continuamos con el desarrollo.
- Implementación: desarrollamos un prototipo basado en los requerimientos.
- Evaluación: El cliente evalúa el prototipo, si da su conformidad, termina el proyecto. En caso contrario, incluimos los nuevos requerimientos solicitados por el cliente en la siguiente iteración.
La ventaja más notoria de este modelo de desarrollo de software es que
puede comenzarse el proyecto con un alto grado de incertidumbre, se entiende
también como ventaja el bajo riesgo de retraso en caso de detección de errores,
ya que se puede solucionar en la próxima rama del espiral.
Algunas de las desventajas son: el costo temporal que suma cada vuelta
del espiral, la dificultad para evaluar los riesgos y la necesidad de la
presencia o la comunicación continua con el cliente o usuario.
Se observa que es un modelo adecuado para grandes proyectos internos de
una empresa, en donde no es posible contar con todos los requerimientos desde
el comienzo y el usuario está en nuestro mismo ambiente laboral.
Podemos citar una aplicación que administre reclamos, pedidos e
incidentes, como ejemplo para utilizar este modelo de ciclo de vida, en el que
los sectores que utilizarán el sistema son demasiados y con intereses muy
diversos como para lograr un relevamiento exhaustivo y completo de los
requerimientos.
Ciclo de
vida orientado a objetos
Esta técnica fue presentada en la década del 90, tal vez como una de las
mejores metodologías a seguir para la creación de productos software.
Puede considerarse como un modelo pleno a seguir, como así también una
alternativa dentro de los modelos anteriores.
Al igual que la filosofía del paradigma de la programación orientada a
objetos, en esta metodología cada funcionalidad, o requerimiento solicitado por
el usuario, es considerado un objeto. Los objetos están representados por un
conjunto de propiedades, a los cuales denominamos atributos, por otra parte, al
comportamiento que tendrán estos objetos los denominamos métodos.
Vemos que tanto la filosofía de esta metodología, los términos
utilizados en ella y sus fines, coinciden con la idea de obtener un concepto de
objeto sobre casos de la vida real.
La característica principal de este modelo es la abstracción de los
requerimientos de usuario, por lo que este modelo es mucho más flexible que los
restantes, que son rígidos en requerimientos y definición, soportando mejor la
incertidumbre que los anteriores, aunque sin garantizar la ausencia de riesgos.
La abstracción es lo que nos permite analizar y desarrollar las características
esenciales de un objeto (requerimiento), despreocupándonos de las menos
relevantes.
Favorece la reducción de la complejidad del problema que deseamos
abordar y permite el perfeccionamiento del producto.
En este modelo se utilizan las llamadas fichas CRC (clase–responsabilidades-colaboración)
como herramienta para obtener las abstracciones y mecanismos clave de un
sistema analizando los requerimientos del usuario. En la ficha CRC se escribe
el nombre de la clase u objeto, sus responsabilidades (los métodos) y sus
colaboradores (otras clases u objetos de los cuales necesita). Estas fichas,
además, nos ayudan a confeccionar los denominados casos de uso.
No es correcto suponer que este modelo sólo es útil cuando se escoge
para la implementación un lenguaje con orientación a objetos. Se puede utilizar
independientemente del lenguaje elegido. Es un modelo a seguir, una técnica, y
no nos obliga a utilizar ningún lenguaje en particular.
Como mencionamos, es un modelo muy versátil, y por ser uno de los
últimos en aparecer, aprendió mucho de los anteriores. Las aplicaciones que
podemos incluir como ejemplo para su uso van desde programas de monitoreo de
procesos, grandes sistemas de transacciones sobre base de datos, hasta
procesamiento por lotes.
Conclusión
Luego de ver algunos de los modelos de ciclo de vida más utilizados
surge la pregunta con la respuesta más codiciada: ¿qué modelo de ciclo de vida
elegir? Sabemos que ninguno predomina sobre los otros. Por ello, debemos elegir
el modelo que mejor se adapte al proyecto que desarrollaremos. Podemos analizar,
para guiarnos en nuestra elección, la complejidad del problema, el tiempo que
disponemos para hacer la entrega final, o si el usuario o cliente desea entregas
parciales, la comunicación que existe entre el equipo de desarrollo y el
usuario y, por último, qué certeza (o incertidumbre) tenemos de que los requerimientos
dados por el usuario son correctos y completos.
