ANALISIS COMPARATIVO DE LOS DIFERENTES CICLOS DE VIDA EN EL SW
Modelos de ciclo de
vida del software
La ingeniería del software se vale de una serie de
modelos que establecen y muestran las distintas etapas y estados por los que
pasa un producto software, desde su concepción inicial, pasando por su
desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del
producto. A estos modelos se les denomina “Modelos de ciclo de vida del
software”. El primer modelo concebido fue el de Royce, más comúnmente conocido
como “Cascada” o “Lineal Secuencial”. Este modelo establece que las diversas
actividades que se van realizando al desarrollar un producto software, se
suceden de forma lineal.
Los
modelos de ciclo de vida del software describen las fases del ciclo de software
y el orden en que se ejecutan las fases. Un modelo de ciclo de vida de software
es una vista de las actividades que ocurren durante el desarrollo de software,
intenta determinar el orden de las etapas involucradas y los criterios de
transición asociados entre estas etapas. Un modelo de ciclo de vida del
software:
•Describe
las fases principales de desarrollo de software.
•Define
las fases primarias esperadas de ser ejecutadas durante esas fases.
•Ayuda
a administrar el progreso del desarrollo.
•Provee
un espacio de trabajo para la definición de un proceso detallado de desarrollo
de software. Las principales diferencias entre distintos modelos de ciclo de
vida están en:
•El
alcance del ciclo dependiendo de hasta dónde llegue el proyecto
correspondiente. Un proyecto puede comprender un simple estudio de viabilidad
del desarrollo de un producto, o su desarrollo completo o en el extremo, toda
la historia del producto con su desarrollo, fabricación y modificaciones
posteriores hasta su retirada del mercado.
•Las
características (contenidos) de las fases en que dividen el ciclo. Esto puede
depender del propio tema al que se refiere el proyecto, o de la organización.
•La
estructura y la sucesión de las etapas, si hay realimentación entre ellas, y si
tenemos libertad de repetirlas (iterar).
Modelo en cascada
Es un enfoque metodológico que ordena rigurosamente las
etapas del ciclo de vida , de forma que el inicio de cada etapa debe esperar a
la finalización de la inmediatamente anterior. El modelo en cascada es un
proceso de desarrollo secuencial, en el que el desarrollo se ve fluyendo hacia
abajo (como una cascada) sobre las fases que componen el ciclo de vida. La
primera descripción formal del modelo en cascada se cree que fue en un artículo
publicado en 1970 por Winston W. Royce, aunque Royce no usó el término cascada
en este artículo. Irónicamente, Royce estaba
presentando este modelo como un ejemplo de modelo que no funcionaba,
defectuoso. En el modelo original de Royce, existían las siguientes fases:
1.
Especificación de requisitos
2. Diseño
3. Construcción
(Implementación o codificación)
4. Integración
5. Pruebas
6. Instalación
7.
Mantenimiento
Para seguir el
modelo en cascada, se avanza de una fase a la siguiente en una forma puramente
secuencial.
Figura 1. Modelo de
ciclo de vida en cascada
Si bien ha sido ampliamente
criticado desde el ámbito académico y la industria, sigue siendo el paradigma
más seguido a día de hoy.
Modelo en V
El modelo en v
se desarrolló para terminar con algunos de los problemas que se vieron
utilizando el enfoque de cascada tradicional. Los defectos estaban siendo
encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se
introducían hasta el final del proyecto. El modelo en v dice que las pruebas
necesitan empezarse lo más pronto posible en el ciclo de vida. También muestra
que las pruebas no son sólo una actividad basada enla ejecución. Hay una
variedad de actividades que se han de realizar antes del fin de la fase de
codificación. Estas actividades deberían ser llevadas a cabo en paralelo con
las actividades de desarrollo, y los técnicos de pruebas necesitan trabajar con
los desarrolladores y analistas de negocio de tal forma que puedan realizar
estas actividades y tareas y producir una serie de entregables de pruebas. El
modelo en v es un proceso que representa la secuencia de pasos en el desarrollo
del ciclo de vida de un proyecto. Describe las actividades y resultados que han
de ser producidos durante el desarrollo del producto. La parte izquierda de la
v representa la descomposición de los requisitos y la creación de las
especificaciones del sistema. El lado derecho de la v representa la integración
de partes y su verificación. V significa “Validación y Verificación”.
INGENIERÍADEREQUISITOSDISEÑO DELSISTEMADISEÑO DELSOFTWARECODIFICACIÓNVERIFICACIÓNDELSOFTWAREVERIFICACIÓN
DEL SISTEMA VALIDACIÓN DEL SISTEMA
Figura 2. Modelo de
ciclo de vida en V
Realmente las etapas individuales
del proceso pueden ser casi las mismas que las del modelo en cascada. Sin
embargo hay una gran diferencia. En vez de ir para abajo de una forma lineal
las fases del proceso vuelven hacia arriba tras la fase de codificación,
formando una v. La razón de esto es que para cada una de las fases de diseño se
ha encontrado que hay un homólogo en las fases de pruebas que se correlacionan.
Modelo iterativo
Es un modelo derivado del ciclo de
vida en cascada. Este modelo busca reducir el riesgo que surge entre las
necesidades del usuario y el producto final por malos entendidos durante la
etapa de recogida de requisitos. Consiste en 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,
después 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 las necesidades
del cliente.
Este modelo se suele utilizar en
proyectos en los que los requisitos no están claros por 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 desarrollo
incremental
El modelo incremental combina
elementos del modelo en cascada con la filosofía interactiva de construcción de
prototipos. Se basa en la filosofía de construir incrementando las funcionalidades
del programa. Este modelo aplica secuencias lineales de forma escalonada mientras
progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento
del software.
Cuando se utiliza un modelo
incremental, el primer incremento es a menudo un producto esencial, sólo con
los requisitos básicos. Este modelo se centra en la entrega de un producto
operativo con cada incremento. Los primeros incrementos son versión es incompletas
del producto final, pero proporcionan al usuario la funcionalidad que precisa y
también una plataforma para la evaluación.
Modelo en espiral
El desarrollo en espiral es un
modelo de ciclo de vida desarrollado por Barry Boehm en1985, utilizado de forma
generalizada en la ingeniería del software. Las actividades de este modelo se
conforman en una espiral, cada bucle representa un conjunto de actividades. Las
actividades no están fijadas a priori, sino que las siguientes se eligen en
función del análisis de riesgos, comenzando por el bucle anterior. Al ser un
modelo de ciclo de vida orientado a la gestión de riesgos se dice que uno de
los aspectos fundamentales de su éxito radica en que el equipo que lo aplique
tenga la necesaria experiencia y habilidad para detectar y catalogar
correctamente riesgos.
Tareas:
Para cada ciclo habrá cuatro
actividades:
1.
Determinar o fijar objetivos:
• Fijar también los productos definidos
a obtener: requerimientos, especificación, manual de usuario.
• Fijar las restricciones.
• Identificar riesgos del proyecto y
estrategias alternativas para evitarlos.
• Hay una cosa que solo se hace una
vez: planificación inicial o previa
2. Análisis del riesgo:
• Estudiar todos los riesgos
potenciales y se seleccionan una o varias alternativas propuestas para reducir
o eliminar los riesgos
3. Desarrollar, verificar y validar (probar):
• Tareas de la actividad propia y de
prueba.
• Análisis de alternativas e
identificación de resolución de riesgos.
• Dependiendo del resultado de la
evaluación de riesgos, se elige un modelo para el desarrollo, que puede ser
cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así,
por ejemplo, si los riesgos de la interfaz de usuario son dominantes, un modelo
de desarrollo apropiado podría ser la construcción de prototipos evolutivos.
4. Planificar:
• Revisar todo lo que se ha llevado a
cabo, evaluándolo y decidiendo si se continua con las fases siguientes y
planificando la próxima actividad. El proceso empieza en la posición central.
Desde allí se mueve en el sentido de las agujas del reloj.
Modelo de prototipos
El paradigma de construcción de
prototipos comienza con la recolección de requisitos. El desarrollador y el
cliente encuentran y definen los objetivos globales para el software,
identifican los requisitos conocidos y las áreas del esquema en donde es
obligatoria más definición. Entonces aparece un diseño rápido. El diseño rápido
se centra en una representación de esos aspectos del software que serán
visibles para el usuario/cliente. El diseño rápido lleva a la construcción de
un prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza para
refinar los requisitos del software a desarrollar. La iteración ocurre cuando
el prototipo se pone a punto para satisfacer las necesidades del cliente,
permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se
necesita hacer.
Comparativa de los
modelos de ciclo de vida
A continuación se van a mostrar las
ventajas e inconvenientes más significativas de cada uno de los modelos de
ciclo de vida:
|
VENTAJAS
|
INCONVENIENTES
|
MODELO
EN
CASCADA
|
• Modelo en el que está todo bien organizado.
•No se mezclan las fases.
•Simple y fácil de llevar a la práctica.
•Fácil de gestionar
|
•Rara
vez los proyectos siguen una secuencia lineal.
•Difícil establecer todos los requisitos al principio.
•Visibilidad del producto cuando está terminado
|
MODELO
EN
V
|
•Simple
y fácil de llevar a la práctica.
•En cada una de las fases hay entregables específicos.
•Desarrollo de planes de prueba en
etapas tempranas del ciclo de vida.
•Suele funcionar bien para proyectos pequeños donde los requisitos son entendidos
fácilmente
|
•Tiene
poca flexibilidad ya justar el alcance es difícil y caro.
•El modelo no proporciona caminos claros para problemas encontrados durante
las fases de pruebas
|
MODELO
INCREMENTAL
|
•Se
genera software operativo de forma rápida y en etapas tempranas del ciclo de vida
del software.
•Modelo más flexible, por lo que se reduce el costeen cambios de alcance y
requisitos.
•Es más fácil probar y depurar en una iteración más pequeña.
•Es más fácil gestionar riesgos.
•Cada iteración es un hito gestionado fácilmente
|
•Se requiere mucha experiencia
para definir los incrementos y distribuir en ellos las tareas de forma proporcionada.
•Cada fase de una iteración es rígida y no se superpone con otras.
•Todos los requisitos han de definirse al inicio.
Modelo iterativo
|
MODELO
ITERATIVO
|
•No hace falta que los requisitos estén totalmente
definidos desde el principio.
•Desarrollo en pequeños ciclos.
•Es más fácil gestionar riesgos.
•Cada iteración es un hito gestionado fácilmente.
|
•Que los requisitos no estén definidos desde
el principio también puede verse como un inconveniente ya que
Curso de Introducción a la Ingeniería del Software 33 pueden surgir problemas
con la arquitectura
|
MODELO
DE
PROTOTIPO
|
•Visibilidad del producto desde el inicio
del ciclo de vida con el primer prototipo
•Permite introducir cambios en las iteraciones siguientes del ciclo.
•Permite la realimentación continua del cliente
|
•Puede
ser un desarrollo lento.
|
MODELO
EN
ESPIRAL
|
•Reduce
riesgos del proyecto.
•Incorpora objetivos de calidad.
•Integra el desarrollo con el mantenimiento.
•No es rígido ni estático.
•Se produce software en etapas tempranas del ciclo de vida
|
•Modelo
que genera mucho trabajo adicional.
•Exige un alto nivel de experiencia y cierta habilidad en los analistas de
riesgos.
•Modelo costoso
|