2

Ciclo de vida
del software

Objetivos del captulo

Comprender el concepto
de Ciclo de Vida y su
importancia para el
Software.

Conocer el Modelo en
Cascada.

Conocer el Modelo
Incremental.

Conocer el Modelo en
Espiral.

Conocer las caractersticas

de los ciclos de vida de
los sistemas orientados a
objetos.

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

RA-MA

2.1 INTRODUCCIN

Tradicionalmente el desarrollo de aplicaciones informticas se llevaba a cabo de

forma individualizada, a base de codificar (generar lneas de cdigo) y probar lo realizado cuanto antes. La misma persona escriba el cdigo, lo ejecutaba y, si fallaba, lo
depuraba. El proceso se realizaba sin ninguna planificacin previa y sin que soliese
existir documentacin alguna. Debido a que la movilidad en el trabajo era baja, los
ejecutivos estaban seguros de que esa persona estara all cuando se produjese algn
fallo. En principio, el hecho de que desde un primer momento se vaya generando
cdigo, podra considerarse como un sntoma de enorme progreso, pero puede
suponer posteriormente un gran retroceso e incluso la necesidad de desechar una
gran parte de lo realizado en el caso de que existan errores y no se puedan llevar a
cabo las modificaciones necesarias para subsanarlos (por ejemplo, si al 90% del cdigo se descubre que el diseo de la base de datos es incorrecto, puede suponer desechar el trabajo y tener que comenzar de nuevo). Con este enfoque, cualquier cosa que
no sea codificacin pura y dura no se realiza (como, por ejemplo, actividades de planificacin, de documentacin, de aseguramiento de la calidad).
Esta forma de desarrollar aplicaciones es muy comn en muchas organizaciones y,
generalmente, se utiliza cuando no se elige o sigue un enfoque de desarrollo (ciclo de
vida) concreto y/o apenas se realiza la actividad de planificacin. Adems, otro factor
que juega a favor de este enfoque de codificar y probar es que requiere poca experiencia y cualquier persona podr fcilmente familiarizarse con l [MCCONNELL,
1997].
Esta forma de desarrollar software puede ser eficaz en programas pequeos.
Para otro tipo de proyectos, puede resultar peligrosa su utilizacin, ya que no se
puede conocer el progreso del proyecto, ni tampoco su calidad, simplemente se
est codificando y probando hasta que finaliza el proyecto. Otras maneras de realizar el desarrollo software, como se vern en los siguientes apartados, permitirn,
por ejemplo, conocer el progreso, detectar un error lo antes posible, etc.
Por lo tanto, es probable que las aplicaciones realizadas segn este enfoque de
codificar y probar:

46

Sean poco flexibles, y ante posibles modificaciones (por cambios en los

requerimientos del cliente, cambios en el hardware, etc.) se incremente el
coste de los proyectos e, incluso, en ocasiones, resulten virtualmente irrealizables debido a la naturaleza personalizada de los programas y a la falta de
documentacin (lo que provocar problemas de mantenimiento).

Sean incompletas o no reflejen bien las necesidades del cliente, es decir, que
no realicen todas las funciones requeridas y, adems, lo hagan con una escasa fiabilidad.

Provoquen el descontento de los clientes, pues se producen retrasos en la entrega (no se conoce el momento exacto en el que se entregarn), aparecen errores

 RA-MA

2 CICLO DE VIDA DEL SOFTWARE

una vez que la aplicacin ha sido entregada (lgico al no haberse realizado de forma
sistemtica actividades de verificacin y validacin en el proyecto).
Por tanto, es necesario que todo esfuerzo en el desarrollo del software conlleve
un enfoque lgico para su realizacin. Dicho enfoque debe abarcar toda la vida del
sistema, comenzando con su concepcin y finalizando cuando ya no se utiliza o se
retira [SIGWART, 1990].
El ciclo de vida software es la descripcin de las distintas formas de desarrollo
de un proyecto o aplicacin informtica, es decir, la orientacin que debe seguirse
para obtener, a partir de los requerimientos del cliente, sistemas que puedan ser utilizados por dicho cliente. Tambin puede definirse como el conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar,
explotar y mantener un producto software.
Las funciones principales de un ciclo de vida software son:

Determinar el orden de las fases y procesos involucrados en el desarrollo del

software y su evolucin (teniendo en cuenta el modelo de procesos que se
utilice como referencia).

Establecer los criterios de transicin para pasar de una fase a la siguiente (productos intermedios). Todo ello, incluye los criterios para la terminacin de la
fase actual y los criterios para seleccionar e iniciar la fase siguiente.

El ciclo de vida software da respuesta a las siguientes preguntas de la gestin de

un proyecto de software:

Qu har a continuacin?

Cunto tiempo continuar hacindolo?

El ciclo de vida que se seleccione en un proyecto [DAVIS, 1988] influir en el

xito del proyecto, y puede ayudar a asegurar que cada paso que se d acorte ms
la consecucin del objetivo. Dependiendo del ciclo de vida que se seleccione, se
puede aumentar la velocidad de desarrollo, mejorar la calidad, el control y el seguimiento del proyecto, minimizar gastos y riesgos, o mejorar las relaciones con los
clientes. Una seleccin ineficaz puede ser una fuente constante de ralentizacin
del trabajo, trabajo repetitivo, innecesario y frustrante.

Algunas de las ventajas que aporta el enfoque de ciclo de vida residen en lo

siguiente:

En las primeras fases, aunque no haya lneas de cdigo, pensar el diseo es

avanzar en la construccin del sistema, pues posteriormente resulta ms fcil
la codificacin.

Asegura un desarrollo progresivo, con controles sistemticos, que permite

detectar precozmente los defectos.

Se controla el sobrepasar los plazos de entrega y los costes excesivos,

mediante un adecuado seguimiento del progreso.

47

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

RA-MA

La documentacin se realiza de manera formal y estandarizada simultneamente al desarrollo, lo que facilita la comunicacin interna entre el equipo
de desarrollo y la de ste con los usuarios. Tambin aumenta la visibilidad y
la posibilidad de control para la gestin del proyecto.

Supone una gua para el personal de desarrollo, marcando las tareas a realizar en cada momento.

Minimiza la necesidad de rehacer trabajo y los problemas de puesta a punto.

A continuacin, se presentan algunos de los modelos de ciclo de vida ms

comunes.

2.2 MODELO EN CASCADA (WATERFALL)

La versin original del modelo de ciclo de vida en cascada fue propuesta por
Royce [ROYCE, 1970] y, desde entonces, han aparecido numerosos refinamientos
y variaciones de dicho modelo: por ejemplo, [BOEHM, 1981], [SOMMERVILLE,
1985], [SIGWART, 1990]. El nmero de fases o etapas que se proponen en este
ciclo suele variar, aunque suelen ser: anlisis de requisitos del sistema, anlisis de
requisitos del software, diseo preliminar, diseo detallado, codificacin, pruebas,
explotacin y mantenimiento (vase la figura 2.1).
Algunas caractersticas de este ciclo son:

Cada fase empieza cuando se ha terminado la fase anterior [HAWRYSZKIEWYCZ, 1990].

Para pasar de una fase a otra es necesario conseguir todos los objetivos de la
etapa previa [BOEHM, 1981]. Para ello, se realiza una revisin al final de la fase.

Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados.

Figura 2.1. Ciclo de Vida en Cascada.

48

 RA-MA

2 CICLO DE VIDA DEL SOFTWARE

Al final de cada fase el personal tcnico y los usuarios tienen la oportunidad

de revisar el progreso del proyecto.

Aunque es el ciclo de vida ms antiguo y el ms ampliamente utilizado, debido

a las facilidades que da a los gestores para controlar el progreso de los sistemas, ha
recibido numerosas crticas (vase, por ejemplo, [McCRACKEN y JACKSON,
1982]).
Algunas de las crticas del modelo en cascada son:

No refleja el proceso real de desarrollo de software. Los proyectos reales

raramente siguen este flujo secuencial, puesto que siempre hay iteraciones.
Aunque en este modelo la iteracin est permitida en etapas contiguas
[MACRO, 1990], en la vida real normalmente la iteracin abarca ms de una
etapa. Un caso tpico es la redefinicin de los requisitos cuando se est codificando la aplicacin.

Se tarda mucho tiempo en pasar por todo el ciclo, dado que hasta que no se
finalice una fase no se pasa a la siguiente. As, se podra dar el caso de no salir
nunca de la fase de anlisis de requisitos software.

Acenta el fracaso de la industria del software con el usuario final. En este

caso, el usuario debe tener paciencia [PRESSMAN, 2002], ya que el sistema
en funcionamiento no estar disponible hasta las fases finales del proyecto.

2.3 MODELO INCREMENTAL

El modelo incremental [LEHMAN, 1984] corrige la necesidad de una secuencia no lineal de pasos de desarrollo. En el modelo incremental (vase la figura 2.2)
se va creando el sistema software aadiendo componentes funcionales al sistema
(llamados incrementos). En cada paso sucesivo, se actualiza el sistema con nuevas
funcionalidades o requisitos, es decir, cada versin o refinamiento parte de una
versin previa y le aade nuevas funciones [AMESCUA et al, 1995]. El sistema
software ya no se ve como una nica entidad monoltica con una fecha fija de
entrega, sino como una integracin de resultados sucesivos obtenidos despus de
cada iteracin.
El modelo incremental se ajusta a entornos de alta incertidumbre, por no tener
la necesidad de poseer un conjunto exhaustivo de requisitos, especificaciones,
diseos, etc., al comenzar el sistema, ya que cada refinamiento ampla los requisitos y las especificaciones derivadas de la fase anterior.
El modelo incremental constituy un avance sobre el modelo en cascada, pero
tambin presenta problemas. Aunque permite el cambio continuo de requisitos,

49

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

RA-MA

Figura 2.2. Modelo en cascada utilizando el desarrollo incremental.

an existe el problema de determinar si los requisitos propuestos son vlidos. Los

errores en los requisitos se detectan tarde y su correccin resulta tan costosa como
en el modelo en cascada.

2.4 MODELO EN ESPIRAL

Con el fin de paliar los inconvenientes del modelo en cascada, [BOEHM, 1988]
propuso el modelo en espiral (vase la figura 2.3), que consta de una serie de ciclos.
Cada uno empieza identificando los objetivos, las alternativas y las restricciones del
ciclo. Una vez evaluadas las alternativas respecto a los objetivos y teniendo en
cuenta las restricciones, se lleva a cabo el ciclo correspondiente para, una vez finalizado, empezar a plantear el prximo.
Para ver de forma ms clara el modelo en espiral, lo explicaremos con un ejemplo. Cada ciclo de la espiral comienza con la identificacin de:

50

Los objetivos de la parte del producto que est siendo elaborada (rendimientos, funcionalidad, adaptacin al cambio, etc.). Por ejemplo, una empresa
que desea aumentar su productividad de software.

Las alternativas principales de la implementacin de esta porcin del producto (usar el diseo A, usar el diseo B, reutilizar el mdulo X de la aplicacin Z, comprar a un proveedor externo, etc.). Para el ejemplo anterior, existen diferentes alternativas: en el rea de tecnologa se podra reutilizar software o utilizar ciertas herramientas, determinados mtodos que condujeran
al desarrollo de mejores productos. Pero tambin existen alternativas no
software que marcan la posibilidad de realizar actividades no software, por
ejemplo en las reas de gestin (la organizacin de los proyectos, la poltica
de la empresa, la planificacin y el control de los proyectos, etc.), de perso-

 RA-MA

2 CICLO DE VIDA DEL SOFTWARE

nal (la incorporacin de plantilla, la promocin de incentivos, la formacin, etc.) y

de soporte (comunicaciones entre el personal, lugares de trabajo, etc.).

Las restricciones impuestas para cada alternativa (costes, planificaciones,

interfaces, etc.). Para el ejemplo, las restricciones podran ser que el aumento de productividad fuera a un coste razonable, que no se cambiase la cultura de la empresa, etc.

El segundo paso es evaluar las diferentes alternativas que se plantean teniendo

en cuenta los objetivos a conseguir y las restricciones impuestas. Frecuentemente,
este paso identifica las reas de incertidumbre del proyecto con sus correspondientes riesgos. Para el ejemplo anterior, los riesgos encontrados podran ser que las
ganancias en productividad no fueran significativas y que adems dichas mejoras
no fueran compatibles con la cultura de la empresa.
Si existen riesgos, el siguiente paso conlleva la formulacin de una estrategia
efectiva en coste (utilizando prototipos, simulacin, bancos de prueba, cuestionarios para los usuarios, modelizacin analtica o combinaciones de stas y otras tcnicas de resolucin de riesgos) para resolver dichos riesgos. Para el ejemplo, podra
recurrirse a la realizacin de informes y anlisis.
El tercer paso consiste en revisar los resultados del anlisis de riesgos. As, para
el ejemplo que estamos tratando, los resultados podran indicar la posibilidad de
conseguir ganancias significativas de productividad a un coste razonable persiguiendo un conjunto integrado de iniciativas en las reas de tecnologa, gestin,
personal y soporte.

Figura 2.3. Modelo en espiral de Boehm.

51

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

RA-MA

El cuarto paso consiste en planificar la fase posterior. En el ejemplo prctico, se

incluira la necesidad de realizar informes y anlisis ms profundos y, por lo tanto,
de contar con ms personal.
Una vez realizado el primer ciclo se volvera a empezar. As, por ejemplo, los
objetivos de este segundo ciclo podran ser doblar la productividad en tres aos,
con la restriccin de que el coste de investigacin fuese de 6000 euros por persona y que la cultura de la compaa no cambiase.
El modelo en espiral puede aplicarse en la mayora de las ocasiones. Sin embargo, en algunos casos hay que resolver ciertas dificultades [BOEHM, 1988]:

Trabajo con software contratado. El modelo en espiral trabaja bien en los desarrollos internos, pero necesita un ajuste posterior para adaptarlo a la subcontratacin de software. En el desarrollo interno existe una gran flexibilidad
y libertad para ajustarse a los acuerdos etapa por etapa, para aplazar acuerdos
de opciones especficas, para establecer miniespirales con objeto de resolver
caminos crticos, para ajustar niveles de esfuerzo, o para acomodar prcticas
como prototipado, desarrollo evolutivo, o uso de mtodos de diseo ajustado
al coste. En el desarrollo de software bajo contrato no existe esta flexibilidad y
libertad, por lo que es necesario mucho tiempo para definir los contratos, ya
que los entregables no estarn previamente definidos de forma clara.

Necesidad de expertos en evaluacin de riesgos para identificar y manejar las

fuentes de riesgos de un proyecto. Normalmente, un equipo sin experiencia
puede producir una especificacin con una gran elaboracin de los elementos de bajo riesgo bien comprendidos, y una pequea y pobre elaboracin de
los elementos de alto riesgo. A no ser que se realice una inspeccin por
expertos, en este tipo de proyecto se tendr la ilusin de progresar durante un
perodo, y, sin embargo, se encuentra dirigido directamente hacia el desastre.
Otro aspecto a tener en cuenta es que una especificacin dirigida por riesgos
es tambin dependiente del personal. Por ejemplo, un diseo producido por
un experto puede ser implantado por inexpertos. Sin embargo, lo contrario es
muy difcil llevarlo a cabo.

2.5 MODELO GENRICO PARA DESARROLLO

DE SISTEMAS ORIENTADOS A OBJETOS

Sin entrar en detalles, podemos decir, [PARETS et al., 1991], que los modelos
orientados a objetos caracterizan el desarrollo orientado al objeto por:

52

La eliminacin de fronteras entre fases, ya que debido a la naturaleza iterativa del desarrollo orientado al objeto, estas fronteras se difuminan cada vez
ms.

 RA-MA

2 CICLO DE VIDA DEL SOFTWARE

Una nueva forma de concebir los lenguajes de programacin y su uso, ya que

se incorporan bibliotecas de clases y otros componentes reutilizables.

Un alto grado de iteracin y solapamiento, lo que lleva a una forma de trabajo muy dinmica.

En general, todos los expertos en tecnologa de objetos proponen seguir un

desarrollo iterativo e incremental. Es iterativo porque las tareas de cada fase se llevan a cabo de forma iterativa, a la vez que existe un ciclo de desarrollo anlisisdiseo-implementacin-anlisis que permite hacer evolucionar al sistema.
Por lo que respecta al desarrollo incremental, el sistema se divide en un conjunto de particiones, cada una de las cuales se desarrolla de manera completa, hasta que
se finaliza el sistema. Esta idea est aumentando su importancia a medida que existe
ms experiencia sobre el desarrollo orientado al objeto. Goldberg afirma que la idea
de la integracin incremental es la diferencia clave de cmo debe ser gestionado un
proyecto que utiliza tecnologa orientada al objeto [GOLDBERG, 1993].
De esta forma las actividades de validacin, verificacin y aseguramiento de la
calidad se pueden realizar, para cada iteracin de cada fase de cada incremento en
el desarrollo del sistema, es decir, de forma continuada.
Por otro lado cabe destacar, como seala Booch, que en realidad se pueden
combinar los modelos tradicionales de ciclo de vida con los ms modernos,
reconciliando as la necesidad de creatividad e innovacin con el requisito de
prcticas de gestin ms controladas [BOOCH, 1994]. Booch propone distinguir
el microproceso del macroproceso. El microproceso puede seguir cualquiera
de los ciclos de vida ms modernos, ya que sirve de marco para el desarrollo inte-

RESUMEN DEL CAPTULO

El ciclo de vida software describe las diferentes fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener una aplicacin informtica.
Existen diferentes modelos de ciclo de vida como son: el modelo en
cascada (el ms antiguo, y en el que cada fase empieza cuando se ha
terminado la fase anterior), el modelo incremental (en el que se va
creando el sistema software aadiendo componentes funcionales al
sistema), el modelo en espiral (que consta de una serie de ciclos) y
modelos especficos para sistemas orientados a objetos en los que se
difuminan las fronteras entre fases y se utiliza un enfoque iterativo e
incremental, y se diferencia el macroproceso del microproceso.

53

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

EJERCICIOS PROPUESTOS

ractivo y es ms informal. Mientras que el

macroproceso est ms cercano a un
modelo en cascada con el fin de controlar el microproceso de una manera formal.
La ventaja principal de estos modelos
es que permiten fijar hitos ms frecuentemente, realizando entregas de sistemas
que son operativos cada dos o tres meses,
para recibir retroalimentacin del cliente

54

RA-MA

lo antes posible e ir adaptando la aplicacin segn cambian las necesidades y se

refinan los requisitos. El inconveniente
que presentan es la dificultad de gestionar de manera formal los proyectos que
siguen estos ciclos de vida aunque, como
se ha sealado, este problema se puede
paliar diferenciando el micro del
macroproceso.

TEST DE CONOCIMIENTOS

1. Qu factores influyen a la hora de

elegir un ciclo de vida para resolver un
problema dado? Qu ciclo de vida
elegira para resolver un problema que
se comprende bien desde el principio
y est muy estructurado? Una vez elegido el ciclo de vida, qu procesos
escogera para dicho ciclo de vida,
teniendo en cuenta que el desarrollo
informtico para resolver el problema
anterior lo realiza una nica persona?
2. Se supone que se va desarrollar una
aplicacin relativa a la gestin de pedidos de una empresa. En este caso el
cliente no tiene todava muy claro qu
es lo que quiere. Adems el personal
informtico va a utilizar una tecnologa que le es completamente nueva.
Disctase qu tipo de ciclo de vida es
ms apropiado y qu procesos se

deberan utilizar para desarrollar esta

aplicacin.

Sealar la respuesta incorrecta. Entre

las funciones principales de un ciclo
de vida software se encuentran:
a) Determinar el orden de las fases
involucradas en el desarrollo del
software.
b) No realizar documentacin simultneamente al desarrollo.
c) Establecer los criterios para iniciar
una fase.
d) Establecer los criterios para finalizar una fase.

Sealar la respuesta correcta. El

enfoque de codificar y probar:
a) Consiste en realizar actividades de
anlisis, diseo, codificacin y pruebas.

 RA-MA

b) Realiza actividades dedicadas a la

planificacin.
c) Avanza muchas veces en sentido
equivocado.
d) Obtiene aplicaciones muy flexibles, ya que la introduccin de
modificaciones no supone un gran
problema.

2 CICLO DE VIDA DEL SOFTWARE

d) El sistema estar disponible en las

fases finales del proyecto.

Sealar la respuesta incorrecta. En el

modelo en cascada:
a) Se tarda mucho tiempo en pasar
por todo el ciclo.
b) El coste de subir la cascada (retroceder en las fases) es muy grande,
sobre todo cuando son ms de dos
las fases a retroceder.
c) Para pasar de una fase a la
siguiente es necesario realizar una
revisin final.
d) Se permite que el cliente vaya
viendo prototipos segn se avanza
en el desarrollo.

Sealar la respuesta incorrecta. En el

ciclo de vida:
a) Se comienza con la idea o necesidad del cliente y finaliza con la
entrega de la aplicacin.
b) Se comienza con la idea o necesidad del cliente y finaliza cuando se
retira la aplicacin.
c) Existe un seguimiento del progreso del proyecto.
d) Se produce documentacin simultneamente al desarrollo.

Sealar la respuesta incorrecta. En el

ciclo de desarrollo:
a) Se comienza con la idea o necesidad del cliente y finaliza con la
entrega de la aplicacin.
b) Se comienza con la idea o necesidad del cliente y finaliza cuando se
retira la aplicacin.
c) Existe un seguimiento del progreso del proyecto.
d) Se produce documentacin simultneamente al desarrollo.

Sealar la respuesta correcta. En el

modelo en cascada:
a) Se crean los sistemas software
aadiendo componentes funcionales mediante incrementos.
b) Se pueden realizar dos fases en
paralelo.
c) Se hace un hincapi especial en la
gestin de los riesgos.

Sealar la respuesta incorrecta. En el

modelo incremental:
a) Se crean los sistemas software
aadiendo componentes funcionales mediante incrementos.
b) No se pueden realizar dos incrementos en paralelo.
c) Es necesario definir todos los
requisitos al principio del proyecto.
d) Existe un sistema en funcionamiento al finalizar el primer incremento.

Sealar la respuesta incorrecta. El

modelo en espiral:
a) Necesita de expertos en gestin
de riesgos.
b) Se basa en el desarrollo de aplicaciones mediante ciclos, donde en
cada ciclo se definen requisitos,
diseo, cdigo y pruebas.
c) Se basa en el desarrollo de aplicaciones mediante ciclos, donde un
ciclo corresponde a los requisitos,
otro al diseo, otro al cdigo y a las
pruebas.

55

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

RA-MA

BIBLIOGRAFA

d) La segunda fase consiste en la evaluacin de alternativas e identificacin y

resolucin de riesgos.

Sealar cul no es un modelo de ciclo de vida:

a) Cascada.
b) Codificar y probar.
c) Incremental.
d) Espiral.

10

Sealar la respuesta correcta. En el modelo genrico para OO:

a) Se recomienda seguir un enfoque en cascada.

b) Se recomienza seguir un enfoque en espiral.
c) Se recomienda seguir un enfoque incremental.
d) Se recomienda seguir un enfoque iterativo e incremental.

BIBLIOGRAFA
Amescua Seco, A., Garca Snchez, L., Martnez Fernndez, P. y Daz Prez, P.,
Ingeniera del Software de Gestin: anlisis y diseo de aplicaciones, Paraninfo,
Madrid, 1995.
Boehm, B. W., A Spiral Model of Software Development and Enhancement,
Computer, pp. 61-72, mayo 1988.
Davis, A., Bersoff, E. y Comer, E., A Strategy for Comparing Alternative software development Life Cycle Models, IEEE Transactions on Software Engineering, vol. 14,
n 10, pp. 1453-1461, octubre 1988.
International Standards Organization / Internacional Electrotechnical Commission,
ISO/IEC 12207-1 - Information Technology Software Parte 1: Software life-cycle
process (ISO/IEC 12207-1 - Tecnologa de la Informacin Software Parte 1:
Proceso del ciclo de vida software), 1994.

56

 RA-MA

2 CICLO DE VIDA DEL SOFTWARE

TEST DE CONOCIMIENTOS

57