Roger Humberto Uñoja Chungara
1.
Resumen.-
Otra de las cuestiones a la hora de desarrollar
software además de la elección de los procesos de desarrollo es la elección del ciclo de vida, muy
importante ya que no es posible desarrollar software con cualquier ciclo de
vida, la mala elección significaría cuantiosas pérdidas de tiempo y dinero a la
vez.
A continuación vamos a realizar un análisis de los
diferentes ciclos de vida existentes, aquellos que hoy por hoy son considerados
obsoletos y aquellos que recientemente están siendo utilizados de acuerdo a los
cambios en la forma de crear software y las necesidades del cliente.
Palabras Claves
¾ Ciclo de vida, OO, S.R.D., S.D.D.
2.
Ciclos
de vida en cascada
El ciclo de vida inicialmente
propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos
de vida de otras ramas de la ingeniería. Es el primero de los propuestos y el
más ampliamente seguido por las organizaciones (se estima que el 90% de los
sistemas han sido desarrollados así).
Este modelo admite la posibilidad de
hacer iteraciones, es decir, durante las modificaciones que se hacen en el
mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el
diseño, lo cual significa que se harán los cambios necesarios en la
codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se
tiene que volver a una de las etapas anteriores al mantenimiento hay que
recorrer de nuevo el resto de las etapas.
Después de cada etapa se realiza una
revisión para comprobar si se puede pasar a la siguiente.
Trabaja en base a documentos, es decir,
la entrada y la salida de cada fase es un tipo de documento específico.
Idealmente, cada fase podría hacerla un equipo diferente gracias a la
documentación generada entre las fases. Los documentos son:
- Análisis:
Toma como entrada una descripción en lenguaje natural de lo que quiere el
cliente. Produce el S.R.D. (Software Requirements Document).
- Diseño:
Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)
- Codificación:
A partir del S.D.D. produce módulos. En esta fase se hacen también pruebas
de unidad.
- Pruebas:
A partir de los módulos probados se realiza la integración y pruebas de
todo el sistema. El resultado de las pruebas es el producto final listo
para entregar.
Ventajas
- La
planificación es sencilla.
- La calidad
del producto resultante es alta.
- Permite
trabajar con personal poco cualificado.
Desventajas
- Lo peor es
la necesidad de tener todos los requisitos al principio. Lo normal es que
el cliente no tenga perfectamente definidas las especificaciones del
sistema, o puede ser que surjan necesidades imprevistas.
- Si se han
cometido errores en una fase es difícil volver atrás.
- No se tiene
el producto hasta el final, esto quiere decir que:
- Si se
comete un error en la fase de análisis no lo descubrimos hasta la
entrega, con el consiguiente gasto inútil de recursos.
- El cliente
no verá resultados hasta el final, con lo que puede impacientarse.
- No se
tienen indicadores fiables del progreso del trabajo (síndrome del 90%).1.1
- Es
comparativamente más lento que los demás y el coste es mayor también.
Tipos de
proyectos para los que es adecuado
- Aquellos
para los que se dispone de todas las especificaciones desde el principio,
por ejemplo, los de reingeniería.
- Se está
desarrollando un tipo de producto que no es novedoso.
- Proyectos
complejos que se entienden bien desde el principio.
3.
Ciclo
de vida en V
Este
ciclo fue diseñado por Alan Davis, y contiene las mimas etapas que el ciclo
cascada puro, A diferencia de aquel, a este se le agregaron dos subetapas de
retroalimentación entre las etapas de análisis y mantenimiento, y entre las de
diseño y debubgging.
La
ventajas y las desventajas de este modelo son las mismas del ciclo anterior,
con el agregado de los controles cruzados entre etapas para lograr una mayor
corrección.
Podemos
utilizar este modelo de ciclo de vida en aplicaciones, que si bien son simples
(pequeñas transacciones sobre base de datos por ejemplo), necesitan una
confiabilidad muy alta. Un ejemplo claro en el que no nos podemos permitir el
lujo de cometer errores es una aplicación de facturación, en la que si bien los
procedimientos vistos individualmente son de codificación e interpretación
sencilla, la aplicación en su conjunto puede tener matices complicados.
4.
Modelo
de ciclo de vida en espiral
Propuesto
inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten.
Cada uno tiene las mismas fases y cuando termina da un producto ampliado con
respecto al ciclo anterior. En este sentido es parecido al modelo incremental,
la diferencia importante es que tiene en cuenta el concepto de riesgo. Un
riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseño, errores
en la implementación, etc. 
- Objetivos: Se hacen entrevistas
a los clientes, se les hace rellenar cuestionarios, etc.
- Alternativas: Son las
diferentes formas posibles de conseguir los objetivos. Se consideran desde
dos puntos de vista
- Características
del producto.
- Formas
de gestionar el proyecto.
- Restricciones:
- Desde
el punto de vista del producto: Interfaces de tal o cual manera,
rendimiento, etc.
- Desde
el punto de vista organizativo: Coste, tiempo, personal, etc.
- Riesgos: Lista de
riesgos identificados.
- Resolución
de riesgos:
La técnica más usada es la construcción de prototipos.
- Resultados: Son lo
que realmente ha ocurrido después de la resolución de riesgos.
- Planes: Lo que se
va a hacer en la siguiente fase.
- Compromiso:
Decisiones de gestión sobre como continuar.
Al terminar una iteración se comprueba que lo que se ha hecho
efectivamente cumple con los requisitos establecidos, también se verifica que
funciona correctamente. El propio cliente evalúa el producto. No existe una
diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de
mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo
ciclo.
Ventajas
- No
necesita una definición completa de los requisitos para empezar a
funcionar.
- Al
entregar productos desde el final de la primera iteración es más fácil validar
los requisitos.
- El
riesgo en general es menor, porque si todo se hace mal, solo se ha perdido
el tiempo y recursos invertidos en una iteración (las anteriores
iteraciones están bien).
- El
riesgo de sufrir retrasos es menor, ya que al identificar los problemas en
etapas tempranas hay tiempo de subsanarlos.
Desventajas
- Es
difícil evaluar los riesgos.
- Necesita
de la participación continua por parte del cliente.
- Cuando
se subcontrata hay que producir previamente una especificación completa de
lo que se necesita, y esto lleva tiempo.
Dónde es adecuado
- Sistemas
de gran tamaño.
- Proyectos
donde sea importante el factor riesgo.
- Cuando
no sea posible definir al principio todos los requisitos.
5.
Ciclos
de vida orientados a objetos.
Modelo fuente
Fue creado por Henderson-Sellers
y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientación a
objetos y posiblemente el más seguido. Un proyecto se divide en las fases:
Ø
Planificación del negocio
Ø
Construcción: Es la más importante y se divide a su vez en otras cinco
actividades
o
Planificación
o
Investigación
o
Especificación
o
Implementación
o
Revisión
Ø
Entrega
La primera y la tercera fase son independientes de la metodología
de desarrollo orientado a objetos. Además de las tres fases, existen dos
periodos:
- Crecimiento:
Es el tiempo durante el cual se construye el sistema
- Madurez: Es
el periodo de mantenimiento del producto. Cada mejora se planifica igual
que el periodo anterior, es decir, con las fases de Planificación del
negocio, Construcción y Entrega.
Cada
clase puede tener un ciclo de vida sólo para ella debido a que cada una puede
estar en una fase diferente en un momento cualquiera. La ventaja es que permite un desarrollo
solapado e iterativo.
Ciclos de vida Tradicionales
|
Ciclos de vida orientados a objetos
|
Todos estos ciclos como el cascada y el modelo en V y
el incremental están basados en el análisis y diseño estructurado.
|
Los ciclos basados en objetos tienen la particularidad
de crear componentes que se relacionan entre ellos a través de interfaces.
|
Al ser de tipo estructurado es muy difícil dividirlos
en subsistemas que puedan implementarse independientemente.
|
Al ser modulares se los puede dividir en mini proyectos
de tal forma que no es muy restrictivo a la hora de escoger que proyecto
realizar primero o incluso es posible realizarlo simultáneamente.
|
Los ciclos de vida tradicionales no aseguran un control
de riesgos estable y con pocas facilidades de cambios
|
Reduce la cantidad de riesgos al ser un modelo que
siempre ofrece prototipos de forma temprana debido a la facilidad de
manipularlo en módulos.
|
Se hace mucho más difícil la detección y corrección
temprana de errores debido a que para realizar una corrección se tiene que
evaluar primero el impacto que el mismo tendrá sobre el sistema por su compleja
estructura. .
|
Es mucho más fácil realizar cambios o correcciones
debido a su modularidad.
|
Naturalmente la mayoría de los lenguajes de programación
esta orientados a objetos.
|
Una buena forma de aprender nuevos lenguajes de programación
debido a sus librerías de clases y la reutilización de componentes.
|
Los ciclos tradicionales difícilmente reutilizarían parte
de algún proyecto anterior
|
La ventaja de usar componentes hace posible la reutilización
de código para ahorrar tiempo y esfuerzo.
|
6.
Conclusion.-
Si bien en un principio
el desarrollo de software era orientado a las estructuras se debe a que los
clientes estaban educados de forma que se pensaba que el producto se utilizaría por
mucho tiempo y por tal motivo se invertiría más dinero y tiempo para realizar
todas las tareas del ciclo de vida.
Sin embargo en estos,
el mercado para el software es competitivo ya no es suficiente demostrar calidad
en el producto, es importante además poder satisfacer las necesidades del
cliente con la mayor calidad posible y en el menor tiempo gracias a las nuevas tecnologías.
Referencias.-
Ø Ciclo
de vida del software – Jose Alvarez y Manuel Ariaz - http://www.ia.uned.es/ia/asignaturas/adms/GuiaDidADMS/node10.html#tex2html394.
No hay comentarios:
Publicar un comentario