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.
Modelo de 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.
Es un modelo de programación para aplicaciones de acceso a datos en que se busca separar la arquitectura del programa en tres capas. En la capa de datos solo nos preocupamos del almacenamiento de éstos, en la capa de negocios situamos todas las transacciones y validaciones y en la capa de presentación sólo encontraremos las rutinas de visualización e interacción con el usuario.
Modelo de 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.
Modelo de ciclo de vida por 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.
La ventaja de este ciclo se basa en que es el único apto para desarrollos en los que no se conoce a prioridad 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.
Modelo de 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.
Modelo de 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 continuacion:
• 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 & vencerás.
Modelo de ciclo de vida en espiral
Este ciclo puede considerarse una variación del modelo con prototipado, 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 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.
Modelo de 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.
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.
Conclusiones
- El ciclo de vida del software no es mas que las etapas por la cual
pasa la concepción, desarrollo y puesta en marcha un sistema
o una implementación de un software.
- el ciclo de vida del software debe cumplir con ciertas
características y especificaciones para el cual fue construido, para
esto se basa en medidas de rendimientos , pruebas y otras técnicas para
la evaluación de la aplicación.
- un ciclo de vida del software esta constituido por técnicas,
actividades y herramientas que ayudan a la construcción de un proyecto
especifico.
