Analisis comparativo de los ciclos de vida del software - PARTE 1

Ciclo de vida de Software

“Un marco de referencia que contiene los procesos, las actividades
y las tareas involucradas en el desarrollo, la explotación y el
mantenimiento de un producto de software, abarcando la vida del
sistema desde la definición de los requisitos hasta la finalización de
su uso”                                                                  ISO 12207-1

Modelo Cascada

Se define como una secuencia deactividades donde la estrategia principal es seguir el proceso del desarrollo de Software  hacia checkpoints o mediante entregas calendarizadas

    
Características:

•  Cada fase empieza cuando se ha terminado la fase anterior
•  Para pasar de una fase a otra es necesario conseguir todos los objetivos de la etapa previa
• Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados
• Al final de cada fase el personal técnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto

  Críticas:

•  No refleja realmente el proceso de desarrollo del software 
•  Se tarda mucho tiempo en pasar por todo el ciclo 
• Acentúa el fracaso de la industria del software en su comunicación con el usuario final
• Se convierten las especificaciones en implementaciones de manera informal
• Las revisiones de proyectos de gran complejidad son muy difíciles
• Impone una estructura de gestión de proyectos

 

Modelo 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. 

Caracteristicas:

• Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.
  El usuario se involucre más.
• La administración de proyectos es más fácil de lograr en incrementos más pequeños.
• Es más fácil comprender y probar incrementos de funcionalidad más pequeños.
• Hay más probabilidad de satisfacer el cambio en los requisitos de usuario mediante incrementos del Software en el tiempo que si fueran planeados todos a la vez en un mismo periodo

Criticas:

• Dificil de evaluar el costo total.
• Díficil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. 
• Requiere gestores experimentados. 
• Los errores en los requisitos se detectan tarde.

Modelo Espiral

Modelo de proceso de software evolutivo que combina la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial.

 Caracteristicas:

• Trata de mejorar los ciclos de vida clásicos y prototipos.
• Permite acomodar otros modelos
• Incorpora objetivos de calidad y gestión de riesgos
• Elimina errores y alternativas no atractivas al comienzo
• Permite iteraciones, vuelta atrás y finalizaciones rápidas
• Cada ciclo empieza identificando: 

•  Los objetivos de la porción correspondiente 
•  Las alternativas 
•  Restricciones

• Cada ciclo se completa con una revisión que incluye todo el ciclo anterior y el plan para el siguiente.

 Criticas:

• Falta un proceso de guía explícito para determinar objetivos, limitaciones y alternativas.
• Provee más flexibilidad que la conveniente para la mayoría de las aplicaciones.
• La pericia de tasación del riesgo no es una tarea fácil. El autor declara que es necesaria mucha experiencia en proyectos de software para realizar esta tarea exitosa
  mente.

 
Modelo Prototipado

• Paradigma de construcción de prototipos:

• Escuchar al cliente
• Construir/revisar maqueta
• Probar maqueta

• Los prototipos tienen una doble función:

• El cliente ve el producto y refina sus requisitos
• El desarrollador comprende mejor lo que necesita hacer 

Caracteristicas:

• Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios
• Reduce costos y aumenta la probabilidad de éxito
• Exige disponer de las herramientas adecuadas

Criticas:

• No presenta calidad ni robustez 

• Poco útil en el caso de querer realizar sistemas complejos.

• Las maquetas no son software funcionales, solo muestran al usuario una aproximación de lo que seria un producto con las características que solicite. 
  
  
  
  Modelo Prototipado- Evolutivo
  
   Construcción de una implementación parcial que cubre los requisitos conocidos, para ir aprendiendo el resto y, paulatinamente, incorporarlos al sistema
    
  Características:
  • Reduce el riesgo y aumenta la probabilidad de éxito
  • Construir software para que pueda ser modificado
  • fácilmente es un “arte desconocido”
  
  Criticas:
• No se conocen niveles apropiados de calidad y documentación
• Problemas de gestión de configuración
   

   

Modelo Prototipado-Operacional

Es una mezcla entre el prototipado rápido y el evolutivo.En algunos sistemas ni el prototipado rápido ni el evolutivo por sí solos son aceptables porque los requisitos son:

• Críticos al diseño y bien entendidos
• No críticos al diseño y pobremente entendidos
• Desconocidos

El prototipado rápido por sí solo es poco efectivo porque los requisitos pobremente entendidos no son críticos.
El prototipado evolutivo por sí solo es poco efectivo porque no
ayuda a clarificar los requisitos que no se entienden.