Los modelos de ciclo de vida del software describen las fases por las que pasa un proyecto de desarrollo, desde su concepción hasta su retiro. Elegir el modelo adecuado es crucial para la gestión y el éxito del proyecto.

Ciclo de Vida Lineal

Este modelo es sencillo y descompone la actividad global en etapas que se realizan de manera lineal. Cada etapa se ejecuta una sola vez.

Características:

• Fácil dividir las tareas y estimar tiempos (sumando linealmente los de cada etapa).
• Etapas independientes entre sí.
• No hay retroalimentación (solo correctiva).
• Requiere conocer todo desde el primer momento.
• Minimiza la posibilidad de errores en la codificación.
• Reduce la necesidad de requerir información constante del cliente.

Etapas:

1. Análisis
2. Diseño
3. Implementación
4. Debugging (Depuración)
5. Instalación
6. Aceptación

Ventajas:

• Sencillez de su gestión y administración.
• Económico para programas pequeños (ABM – Altas, Bajas, Modificaciones).

Desventajas:

• No apto para desarrollos con retroalimentación.
• Costoso para retomar una etapa anterior.

Aplicabilidad Típica:

• Plazo: Corto
• Tamaño del equipo: Pequeño
• Criticidad del proyecto: Baja
• Retroalimentación: Nula
• Complejidad de planificación: Sencilla
• Requerimientos iniciales: Sí, todos
• Tecnología a utilizar: Tradicional
• Participación del cliente al inicio: Baja

Modelo Cascada o Puro (Waterfall)

Propuesto por Winston Royce en 1970. Admite iteraciones, realizando una o varias revisiones después de cada etapa para comprobar y pasar a la siguiente.

Características:

• Rígido y poco flexible, con muchas restricciones.
• Requiere conocer todos los requerimientos al principio.

Ventajas:

• Planificación sencilla.
• Producto de gran calidad (sin considerar el personal calificado).

Desventajas:

• Necesidad de contar con todos los requerimientos al inicio.
• Si se cometen errores y no se detectan en la etapa siguiente, es muy costoso volver atrás.
• El resultado solo se ve al final.
• Los errores traen retrasos, aumentando el costo y el tiempo.

Aplicabilidad Típica:

Ideal para desarrollos con requerimientos conocidos al comienzo o para proyectos con funcionalidades bien definidas. Es un modelo teórico; pocas veces se mantienen los requerimientos iniciales sin necesidad de retomar alguna etapa anterior. Utilizado inicialmente en proyectos medianos y grandes en la década de 1990, aunque luego recibió críticas.

• Plazo: Mediano
• Tamaño del equipo: Pequeño
• Criticidad del proyecto: Baja
• Retroalimentación: Nula
• Complejidad de planificación: Sencilla
• Requerimientos iniciales: Sí, todos
• Tecnología a utilizar: Tradicional
• Participación del cliente al inicio: Baja

Ciclo de Vida V (V-Model)

Propuesto por Alan Davis. Ofrece una mayor garantía de corrección al terminar el proyecto al enfatizar la verificación y validación en cada etapa.

Ventajas:

• Planificación sencilla.
• Producto de gran calidad (sin considerar el personal calificado).
• Controles cruzados para lograr una mayor corrección.

Desventajas:

• El resultado solo se ve al final.
• Los errores traen retrasos, aumentando el costo y el tiempo.

Aplicabilidad Típica:

Se puede utilizar en aplicaciones simples que necesitan alta confiabilidad. Ejemplo: Una aplicación de facturación. Los procedimientos individuales pueden ser de codificación sencilla, pero la aplicación en conjunto puede tener matices complicados. Mayor garantía de corrección al terminar.

• Plazo: Mediano a largo
• Tamaño del equipo: Grande
• Criticidad del proyecto: Alta
• Retroalimentación: Alta
• Complejidad de planificación: Alta
• Requerimientos iniciales: Sí, todos
• Tecnología a utilizar: Versátil
• Participación del cliente al inicio: Mediana

Ciclo de Vida Sashimi

En este modelo, las etapas se pueden solapar, lo que aumenta su eficiencia ya que la retroalimentación se encuentra implícitamente en el modelo.

Ventajas:

• Ganancia de calidad en el producto final.
• No necesita documentación detallada (ahorro por el solapamiento de etapas).

Desventajas:

• Difícil gestionar el comienzo y fin de cada etapa.
• Los problemas de comunicación, si aparecen, generan inconsistencia en el proyecto.

Aplicabilidad Típica:

Ejemplo: Una aplicación que comparte recursos con otras aplicaciones. El solapamiento permite, en la práctica, jugar un poco con modelos como el de 3 capas, ahorrando recursos. Desarrollo que se divide en 3 partes: base de datos, código, interfaz.

• Plazo: Corto
• Tamaño del equipo: Pequeño
• Criticidad del proyecto: Baja
• Retroalimentación: Nula
• Complejidad de planificación: Alta
• Requerimientos iniciales: Sí, todos
• Tecnología a utilizar: Tradicional
• Participación del cliente al inicio: Baja

Cascada con Subproyectos

Cada una de las cascadas se divide en subetapas independientes que se pueden desarrollar en paralelo.

Ventaja:

• Permite que más personas trabajen simultáneamente.

Desventaja:

• Pueden surgir dependencias entre las distintas subetapas que detengan el proyecto temporalmente si no se gestiona de manera correcta.

Aplicabilidad Típica:

Este modelo puede administrar cualquier proyecto mencionado, siempre que se gestionen bien los tiempos y las dependencias.

Modelo Iterativo

Deriva del modelo Cascada puro. Busca reducir el riesgo entre las necesidades del usuario y el producto final (causado por malos entendidos en la etapa de solicitud de requerimientos). Es la iteración de varios ciclos en cascada.

Características:

• Al final de cada iteración, se entrega al cliente una versión mejorada o con mayores funcionalidades.
• El cliente evalúa el producto después de cada iteración y corrige o propone mejoras.
• Estas iteraciones se repiten hasta que el producto satisfaga al cliente.

Aplicabilidad Típica:

Ideal cuando el usuario necesita entregas rápidas, aunque el producto no esté terminado.

Modelo por Prototipos

Se utiliza si no se sabe cómo desarrollar un producto o sus especificaciones de forma precisa. Se definen solo especificaciones iniciales para crear un prototipo (producto parcial).

Características:

• El objetivo es lograr un producto intermedio antes del final.
• Permite conocer, mediante el prototipo, cómo responderán las funcionalidades previstas para el producto final.

Aplicabilidad Típica:

Desarrollo de productos con innovaciones importantes, tecnologías nuevas o poco probadas. Ejemplo: Migración de aplicaciones de una tecnología a otra para adoptar nuevas funciones (ej. Java, .NET).

Ventaja:

• Único apto para desarrollos donde no se conocen previamente sus especificaciones o la tecnología a utilizar.

Desventaja:

• Muy costoso.
• Difícil administración temporal.

Modelo Evolutivo

Los requerimientos del usuario pueden cambiar en cualquier momento. Obtener los requerimientos al comienzo es muy difícil debido a la dificultad del usuario para transmitir su idea. Los requerimientos evolucionan durante el desarrollo y la evolución del proyecto.

Aplicabilidad Típica:

Muy útil cuando se desconocen la mayoría de los requerimientos iniciales o no están completos. Ejemplo: Sistemas de stock, ventas, facturación. Varios sectores utilizan el programa y pueden pedir modificaciones o nuevas solicitudes que influyan en otro sector. Es necesario que la aplicación evolucione para satisfacer a todos los involucrados.

Modelo Incremental

Consiste en construir el sistema incrementando las funcionalidades del programa. Se construye por módulos que cumplen las diferentes funciones del sistema, aumentando gradualmente las capacidades del software.

Características:

• Facilita el desarrollo, asignando a cada parte del equipo un módulo particular.
• Repite el modelo Cascada para cada funcionalidad a construir.
• Al final de cada ciclo, se entrega una versión con una nueva función (reduce riesgos).

Ventajas:

• Construir un sistema pequeño es menos riesgoso que uno grande.
• Como las funciones se desarrollan de forma independiente, es más fácil obtener los requerimientos del usuario.
• Si se detecta un error grave, solo se desecha la última iteración.

Aplicabilidad Típica:

Orientado al usuario o cliente, para cualquier proyecto que requiera entregas rápidas o parciales.

Modelo Espiral

Propuesto por Barry Boehm en 1988. Es una variación del modelo por prototipos. Consiste en una serie de ciclos repetitivos para ir ganando madurez en el producto final. Se basa en los modelos incremental y por prototipos, incorporando el concepto de riesgo debido a la incertidumbre de los requerimientos iniciales.

Características:

• A medida que avanza, se obtienen prototipos sucesivos que aumentan la satisfacción del cliente.
• La incertidumbre la genera el usuario si no conoce bien las funciones de su producto.

Etapas (por ciclo):

1. Planificación: Definición de requerimientos iniciales o revisión tras una iteración.
2. Análisis de Riesgo: Evaluación de riesgos según los requerimientos para decidir si continuar.
3. Implementación: Desarrollo de un prototipo basado en los requerimientos.
4. Evaluación: El cliente evalúa si está conforme (termina) o si se incluyen nuevos requerimientos solicitados.

El ciclo se repite las veces que sea necesario.

Ventajas:

• Se puede iniciar con pocos requerimientos.
• Bajo riesgo de retraso gracias a la detección temprana de errores.

Desventajas:

• Costoso.
• Difícil evaluar los riesgos.
• Necesidad constante de comunicación con el cliente.

Desarrollo Orientado a Objetos

Surgió en la década de 1990 como una metodología destacada para crear software. Aunque no es un modelo de ciclo de vida en sí mismo, influye en cómo se estructuran las fases. Considera cada funcionalidad o requerimiento solicitado por el usuario como un objeto.

Características:

• Permite abstraer los requerimientos del usuario, siendo mucho más flexible.
• Herramientas como CRC (Class-Responsibility-Collaboration) ayudan a obtener abstracciones y crear casos de uso.
• Se puede utilizar con cualquier lenguaje de programación.
• Ha aprendido mucho de los modelos anteriores.

Definición de Metodología

Una metodología es un modo sistemático de realizar, gestionar y administrar un proyecto.

Etiquetas: cascada, ciclo de vida software, espiral, incremental, iterativo, modelos desarrollo software, Prototipos, SDLC