LOS
CICLOS DE VIDA DEL SOFTWARE
Es el proceso que se sigue
para construir, entregar y hacer evolucionar el software, desde la concepción
de una idea hasta la entrega y retiro del sistema. Se definen las distintas
fases intermedias que se requieren para validar el desarrollo de un software,
es decir, para garantizar que el software cumpla los requisitos para la
aplicación y verificación de los procedimientos de desarrollo, se asegura de
que los métodos utilizados son apropiados.
Desde un punto de vista
general se puede considerar que el ciclo de vida de un software tiene tres
etapas claramente definidas, las cuales son:
· PLANIFICACION: donde se idea un planteamiento
detallado que guie la gestión del proyecto temporal y económicamente.
· IMPLEMENTACION: se concretan el conjunto de
actividades que componen la realización del proyecto.
· PUESTA EN PRODUCCION: en esta etapa es donde
se le presenta al usuario final, sabiendo que funciona correctamente y responde
a los requerimientos solicitados en su momento.
Las principales diferencias
entre distintos tipos de modelo de ciclo de vida se dividen en tres grandes
visiones:
·
El alcance del ciclo de vida
·
La cualidad y cantidad de las etapas
·
La estructura y la sucesión de las etapas
Diferentes tipos de ciclos
de vida:
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.
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.
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.
Modelo
Espiral
El modelo espiral de los
procesos software es un modelo del ciclo de meta-vida. En este modelo, el
esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo
de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes
seguir estos cuatros pasos:
Determinar qué quieres
lograr.
Determinar las rutas
alternativas que puedes tomar para lograr estas metas. Por cada una, analizar
los riesgos y resultados finales, y seleccionar la mejor.
Seguir la alternativa
seleccionada en el paso 2.
Establecer qué tienes
terminado.
La dimensión radial en la
figura refleja costos acumulativos incurridos en el proyecto.
Observemos un escenario
particular. Digamos que en este proyecto, nosotros viajaremos a resolver un
conjunto particular de problemas del cliente. Durante el primer viaje alrededor
de la espiral, analizamos la situación y determinamos que los mayores riesgos
son la interfaz del usuario. Después de un cuidadoso análisis de las formas
alternativas de direccionar esto (por ejemplo, construir un sistema y esperar
lo mejor, escribir una especificación de requerimientos y esperar que el
cliente lo entienda, y construir un prototipo), determinamos que el mejor curso
de acción es construir un prototipo.
Lo realizamos. Luego
proveemos el prototipo al cliente quien nos provee con retroalimentación útil.
Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo
decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos
comiencen a aparecer sólo después de que el sistema sea desplegado. Analicemos
las rutas alternativas, y decidimos que la mejor aproximación es construir un
incremento del sistema que satisfaga sólo los requerimientos mejor entendidos.
Hagámoslo ya. Después del despliegue, el cliente nos provee de
retroalimentación que dirá si estamos correctos con esos requerimientos, pero
50 nuevos requerimientos ahora se originarán en las cabezas de los clientes. Y
el tercer viaje alrededor de la espiral comienza.
El modelo espiral captura
algunos principios básicos:
Decidir qué problema se
quiere resolver antes de viajar a resolverlo.
Examinar tus múltiples
alternativas de acción y elegir una de las más convenientes.
Evaluar qué tienes hecho y
qué tienes que haber aprendido después de hacer algo.
No ser tan ingenuo para
pensar que el sistema que estás construyendo será "EL" sistema que el
cliente necesita, y conocer (comprender) los niveles de riesgo, que tendrás que
tolerar.
El modelo espiral no es una
alternativa del modelo cascada, ellos son completamente compatibles.
Modelo
Concurrente
Como el modelo espiral, el
modelo concurrente provee una meta-descripción del proceso software. Mientras
que la contribución primaria del modelo espiral es en realidad que esas
actividades del software ocurran repetidamente, la contribución del modelo
concurrente es su capacidad de describir las múltiples actividades del software
ocurriendo simultáneamente.
Esto no sorprende a nadie
que ha estado involucrado con las diversas actividades que ocurren en algún
tiempo del proceso de desarrollo de software. Discutamos un poco tales casos:
Los requerimientos son
usualmente "líneas de base", cuando una mayoría de los requerimientos
comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo
considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a
los requerimientos son comunes y frecuentes (después de todo, los problemas
reales cambian, y nuestro entendimiento de los problemas desarrollados
también). Es desaconsejado detener el diseño en este camino cuando los
requerimientos cambian; en su lugar, existe una necesidad de modificar y
rehacer líneas de base de los requerimientos mientras progresa el diseño. Por
supuesto, dependiendo del impacto de los cambios de los requerimientos el
diseño puede no ser afectado, medianamente afectado o se requerirá comenzar
todo de nuevo.
Durante el diseño de
arquitectura, es posible que algunos componentes comiencen a ser bien definidos
antes que la arquitectura completa sea estabilizada. En tales casos, puede ser
posible comenzar el diseño detallado en esos componentes estables.
Similarmente, durante el diseño detallado, puede ser posible proceder con la
codificación y quizás regular testeando en forma unitaria o realizando testeo
de integración previo a llevar a cabo el diseño detallado de todos los
componentes.
En algunos proyectos,
múltiples etapas de un producto se han desarrollado concurrentemente. Por
ejemplo, no es inusual estar haciendo mantención de la etapa 1 de un producto,
y al mismo tiempo estar haciendo mantención sobre un componente 2, mientras que
se está haciendo codificación sobre un componente 3, mientras se realiza diseño
sobre una etapa 4, y especificación de requisitos sobre un componente 5.
En todos estos casos,
diversas actividades están ocurriendo simultáneamente. Eligiendo seguir un
proyecto usando técnicas de modelación concurrente, se posibilita el
conocimiento del estado verdadero en el que se encuentra el proyecto.
