8/6/2019 CDVDS

1/9

1.2 Ciclo de vida del software

Al igual que en otros sistemas de ingeniera, los sistemas de software requieren un tiempo yesfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho

mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de

construir un sistema de software hasta que este es retirado, se identifican varias etapas queen conjunto se denominan el ciclo de vida del software y en cada caso, en funcin de cualessean las caractersticas del proyecto, se configurar el ciclo de vida de forma diferente.

Usualmente se consideran las etapas: especificacin y anlisis de requisitos, diseo delsistema, implementacin del software, aplicacin ypruebas, entrega y mantenimiento. Un

aspecto esencial dentro de las tareas del desarrollo del software es la documentacin detodos los elementos y especificaciones en cada fase. Dado que esta tarea siempre estar

influida por la fase del desarrollo en curso, se explicar de forma distribuida a lo largo delas diferentes fases como un apartado especial para recalcar su importancia en el conjunto

del desarrollo del software.

Tal como ya hemos mencionado, las etapas principales a realizar en cualquier ciclo de vidason:

1. Anlisis: Construye un modelo de los requisitos2. Diseo: A partir del modelo de anlisis se deducen las estructuras de datos, la

estructura en la que descompone el sistema y la interfaz de usuario.3. Codificacin: Construye el sistema. La salida de esta fase es cdigo ejecutable.4. Pruebas: Se comprueba que se cumplen criterios de correccin y calidad.5. Mantenimiento: En esta fase, que tiene lugar despus de la entrega se asegura que

el sistema siga funcionando y adaptndose a nuevos requisitos.

Las etapas constan de tareas. La documen

tacin

es una tarea importante que se realiza entodas las etapas. Cada etapa tiene como entrada uno o varios documentos procedentes de

las etapas anteriores y produce otros documentos de salida segn se muestra en la figura1.1.

Figure: Etapa genrica

Algunos autores dividen la fase del diseo en dos partes: Diseo globalo arquitectnico y

diseo detallado. En el primero se transforman los requisitos en una arquitectura de altonivel, se definen las pruebas que debe satisfacer el sistema en su conjunto, se esboza la

8/6/2019 CDVDS

2/9

documentacin y se planifica la integracin. En el detallado para cada mdulo se refina el

diseo, se definen los requisitos del mdulo y su documentacin.

Las formas de organizar y estructurar la secuencia de ejecucin de las tareas en lasdiferentes fases de cada uno de los mtodos puede dar lugar a un tipo de ciclo de vida

diferente. Los principales ciclos de vida que se van a presentar a continuacin realizan estastareas. Cada uno de ellos tiene sus ventajas e inconvenientes.

1.2.1 Ciclos de vida en cascada

El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software apartir de ciclos de vida de otras ramas de la ingeniera. Es el primero de los propuestos y el

ms ampliamente seguido por las organizaciones (se estima que el 90% de los sistemas hansido desarrollados as). La estructura se muestra en la figura 1.2.

Figure 1.2: Ciclo de vida en cascada

1.2.1.1 Descripcin

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 enel diseo, lo cual significa que se harn los cambios necesarios en la codificacin y se

tendrn que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapasanteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas.

Despus de cada etapa se realiza una revisin para comprobar si se puede pasar a lasiguiente.

8/6/2019 CDVDS

3/9

Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de

documento especfico. Idealmente, cada fase podra hacerla un equipo diferente gracias a ladocumentacin generada entre las fases. Los documentos son:

y Anlisis: Toma como entrada una descripcin en lenguaje natural de lo que quiereel cliente. Produce el S.R.D. (Software Requirements Document).

y Diseo: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)y Codificacin: A partir del S.D.D. produce mdulos. En esta fase se hacen tambin

pruebas de unidad.

y Pruebas: A partir de los mdulos probados se realiza la integracin y pruebas detodo el sistema. El resultado de las pruebas es el producto final listo para entregar.

1.2.1.2 Ventajas

y La planificacin es sencilla.y La calidad del producto resultante es alta.y

Permite trabajar con personal poco cualificado.

1.2.1.3 Inconvenientes

y Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es queel cliente no tenga perfectamente definidas las especificaciones del sistema, o puedeser que surjan necesidades imprevistas.

y Si se han cometido errores en una fase es difcil volver atrs.y No se tiene el producto hasta el final, esto quiere decir que:

o Si se comete un error en la fase de anlisis no lo descubrimos hasta laentrega, con el consiguiente gasto intil de recursos.

o El cliente no ver resultados hasta el final, con lo que puede impacientarse .y No se tienen indicadores fiables del progreso del trabajo (sndrome del 90%).1.1y Es comparativamente ms lento que los dems y el coste es mayor tambin.

1.2.1.4 Tipos de proyectos para los que es adecuado

y Aquellos para los que se dispone de todas las especificaciones desde el principio,por ejemplo, los de reingeniera.

y Se est desarrollando un tipo de producto que no es novedoso.y Proyectos complejos que se entienden bien desde el principio.

Como el modelo en cascada ha sido muy popular ha generado algunas variantes. Ahoraveremos algunas.

1.2.1.5 Ciclo de vida en V

Propuesto por Alan Davis, tiene las mismas fases que el anterior pero se considera el nivel

de abstraccin de cada una. Una fase adems de utilizarse como entrada para la siguiente,

8/6/2019 CDVDS

4/9

sirve para validar o verificar otras fases posteriores. Su estructura est representada en la

figura 1.3.

Figure 1.3: Ciclo de vida en V

1.2.1.6 Ciclo de vida tipo sashimi

Segn el modelo en cascada puro una fase solo puede empezar cuando ha terminado laanterior. En este caso sin embargo, se permite un solapamiento entre fases. Por ejemplo, sin

tener terminado del todo el diseo se comienza a implementar. El nombre ``sashimi'' derivadel modo del estilo de presentacin de rodajas de pescado crudo en Japn. Una ventaja de

este modelo es que no necesita generar tanta documentacin como el ciclo de vida encascada puro debido a la continuidad del mismo personal entre fases. Los problemas

planteados son:

y Es an ms difcil controlar el progreso del proyecto debido a que los finales de faseya no son un punto de referencia claro.

y Al hacer cosas en paralelo si hay problemas de comunicacin pueden surgirinconsistencias.

La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios, tipo detecnologa y el tipo de ciclo de vida. El diseo arquitectnico es el de alto nivel, el

detallado el de bajo nivel. En la figura 1.4 se ha representado la estructura del ciclo de vidasashimi.

8/6/2019 CDVDS

5/9

Figure 1.4: Ciclo de vida sashimi

1.2.1.7 Ciclo de vida en cascada con subproyectos

Si una vez que se ha llegado al diseo arquitectnico, se comprueba que el sistema se

divide en varios subsistemas independientes entre s, sera razonable suponer que a partir deese punto cada uno se puede desarrollar por separado y en consecuencia en paralelo con los

dems. Cada uno tendr seguramente fechas de terminacin distintas. Una vez que hanterminado todos se integran y se prueba el sistema en su conjunto. La ventaja es que se

puede tener a ms gente trabajando en paralelo de forma eficiente. El riesgo es que existaninterdependencias entre los subproyectos.

1.2.1.8 Ciclo de vida en cascada incremental

En este caso se va creando el sistema aadiendo pequeas funcionalidades. Cada uno de lospequeos incrementos es parecido a lo que ocurre dentro de la fase de mantenimiento. La

ventaja de este mtodo es que no es necesario tener todos los requisitos en un principio. Elinconveniente es que los errores en la deteccin de requisitos se encuentran tarde.

Hay dos partes en el ciclo de vida, similares al anterior. Por un lado est el anlisis y el

diseo global. Por otra parte estn los pequeos incrementos, con las fases de diseodetallado, codificacin y mantenimiento. En la figura 1.5 se puede ver su estructura.

8/6/2019 CDVDS

6/9

Figure 1.5: Cascada incremental

1.2.1.9 Ciclo de vida en cascada con reduccin de riesgos

Como se ha comentado anteriormente, uno de los problemas del ciclo de vida en cascada es

que si se entienden mal los requisitos esto slo se descubrir cuando se entregue elproducto. Para evitar este problema se puede hacer un desarrollo iterativo durante las fases

de anlisis y diseo global. Esto consistira en:

1. Preguntar al usuario.2. Hacer el diseo global que se desprende del punto 1.3. Hacer un prototipo de interfaz de usuario, entrevistas con los usuarios, etc y volver

con ello al punto 1 para identificar ms requisitos o corregir malentendidos.

El resto es igual al ciclo de vida en cascada.

8/6/2019 CDVDS

7/9

1.2.2Modelo 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 alciclo 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: requisitosno comprendidos, mal diseo, errores en la implementacin, etc. Un representacin tpica

de esta estructura se muestra en la figura 1.6.

Figure 1.6: Ciclo de vida en espiral

En cada iteracin Boehm recomienda recopilar la siguiente lista de informaciones:

y Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc.

y Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Seconsideran desde dos puntos de vista

o Caractersticas del producto.o Formas de gestionar el proyecto.

y Restricciones:o Desde el punto de vista del producto: Interfaces de tal o cual manera,

rendimiento, etc.

8/6/2019 CDVDS

8/9

o Desde el punto de vista organizativo: Coste, tiempo, personal, etc.y Riesgos: Lista de riesgos identificados.y Resolucin de riesgos: La tcnica ms usada es la construccin de prototipos.y Resultados: Son lo que realmente ha ocurrido despus de la resolucin de riesgos.y Planes: Lo que se va a hacer en la siguiente fase.y

Compromiso: Decisiones de gestin sobre como continuar.

Al terminar una iteracin se comprueba que lo que se ha hecho efectivamente cumple conlos requisitos establecidos, tambin se verifica que funciona correctamente. El propio

cliente evala el producto. No existe una diferencia muy clara entre cuando termina elproyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio,este puede consistir en un nuevo ciclo.

1.2.2.1 Ventajas

y No necesita una definicin completa de los requisitos para empezar a funcionar.y

Al entregar productos desde el final de la primera iteracin es ms fcil validar losrequisitos.

y El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido eltiempo y recursos invertidos en una iteracin (las anteriores iteraciones estn bien).

y El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapastempranas hay tiempo de subsanarlos.

1.2.2.2 Inconvenientes

y Es difcil evaluar los riesgos.y Necesita de la participacin continua por parte del cliente.y Cuando se subcontrata hay que producir previamente una especificacin completa

de lo que se necesita, y esto lleva tiempo.

1.2.2.3 Dnde es adecuado

y Sistemas de gran tamao.y Proyectos donde sea importante el factor riesgo.y Cuando no sea posible definir al principio todos los requisitos.

1.2.3 Ciclos de vida orientados a objetos

Los tipos de ciclos de vida que se han visto hasta ahora son relativos al anlisis y diseoestructurados, pero los objetos tienen una particularidad, y es que estn basados en

componentes que se relacionan entre ellos a travs de interfaces, o lo que es lo mismo, sonmas modulares y por lo tanto el trabajo se puede dividir en un conjunto de miniproyectos.

Adems, hoy en da la tendencia es a reducir los riesgos, y en este sentido, el ciclo de vidaen cascada no proporciona muchas facilidades. Debido a todo esto, el ciclo de vida tpico

en una metodologa de diseo orientado a objetos es iterativo e incremental.

8/6/2019 CDVDS

9/9

En este texto slo veremos un tipo de ciclo de vida orientado a objetos, que es adems el

ms representativo, el modelo fuente.

Modelo fuente

F

ue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensadopara la orientacin a objetos y posiblemente el ms seguido. Un proyecto se divide en lasfases:

1. Planificacin del negocio2. Construccin: Es la ms importante y se divide a su vez en otras cinco actividades

o Planificacino Investigacino Especificacino Implementacino Revisin

3.

Entrega

La primera y la tercera fase son independientes de la metodologa de desarrollo orientado a

objetos. Adems de las tres fases, existen dos periodos:

1. Crecimiento: Es el tiempo durante el cual se construye el sistema2. Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica

igual que el periodo anterior, es decir, con las fases de Planificacin del negocio,Construccin y Entrega.

Cada clase puede tener un ciclo de vida slo para ella debido a que cada una puede estar en

una fase diferente en un momento cualquiera. La ventaja es que permite un desarrollosolapado e iterativo. En la figura 1.7 se muestra un esquema de este tipo de ciclo de vida.

Figure 1.7: Ciclo de vida fuente