Ciclos de vida del software

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 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 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.

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 y
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.
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.

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.
-

Es un modelo que funciona en un escenario donde las

exigencias de tiempo y costo no existen. Al ser secuencial, el
ciclo lleva mucho tiempo de desarrollo y por ende el costo es
altisimo. Ademas todas las etapas descansan en la definicin
sin ambigedades de los requerimientos. En sistemas
administrativos, donde los procedimientos suelen estar bien
documentados no presenta problemas, pero en sistemas
donde las definiciones no son claras o el entorno de desarrollo
es cambiante, es modelo es muy rigido.

MODELO EN CASCADA SOLAPADA (sashimi)

El modelo fue desarrollado por Xerox-Fuji como alternativa a la
presin de tiempo en la ejecucin de proyectos que empezaba a
sentirse en el ambiente de desarrollo de sistemas. En el modelo en
cascada es necesario haber finalizado por completo una etapa para
iniciar la otra. Pero en algunas circunstancias, ya se cuenta con
suficientes definiciones de una etapa como para empezar a trabajar en
la siguiente reduciendo el factor tiempo.
Los inconvenientes que presentan en este modelo se relacionan con
la ambigedad en la definicin de hitos que dificulta establecer con
claridad el avance del proyecto. En proyectos de pequea
envergadura, donde los integrantes del equipo de desarrollo suelen
ocuparse de
varios roles, en diferentes etapas, y donde la
comunicacin suele ser informal, este modelo funciona bien. En forma
similar, en reas de desarrollo de sistemas en empresas cuya
actividad no es el desarrollo de software, y donde la finalizacin de
cada etapa no es determinante de otras acciones (por ejemplo, pago
de anticipos por hito alcanzado) tambin suele ser utilizado con
buenos resultados. En proyectos mas grandes y donde cuestiones
econmicas estn atadas al cumplimiento de hitos este modelo
ocasiona muchos problemas.

MODELO EN SUBPROYECTOS POR COMPLEJIDAD

Se plante como una alternativa a al presin no solo de tiempo sino de
costos que la globalizacin impona a los proyectos informticos.
Generalmente, un proyecto de desarrollo de sistemas informticos
suele presentar mdulos que son de fcil implementacin y otros de
mediana o gran complejidad, con lo que el modelo en cascada
provocara la espera de la finalizacin de los ltimos para continuar
con la etapa siguiente.
Si la estructura del sistema permite su subdivisin en mdulos
independientes de diferente complejidad, este modelo es el ms
conveniente. Sobre todo porque es posible la reasignacin de
recursos ociosos de los mdulos terminados a los que tienen mayor
complejidad. Debe tener se en cuenta que esta reasignacin debe
seguir determinadas pautas. Los recursos de los mdulos ms
complejos suelen ser de tipo senior, expertos y calificados para la
complejidad a resolver, mientras que los recursos de los mdulos ms
sencillos suelen ser juniors. La inclusin de estos recursos entre los
profesionales experimentados, como soporte para sus tareas suele
ocasionar mas inconvenientes (conflictos, demora por capacitacin o

al menos ponerlos al tanto de lo desarrollado) que ventajas.

Pero hay actividades, como por ejemplo las administrativas o de
documentacin que suelen disgustar al nivel mas capacitado, cuyo
valor/hora es adems muy alto para estar dedicndolo a estas
actividades, que pueden ser asignadas a los recursos junior ociosos.
De esta manera, se reduce el tiempo de finalizacin de los mdulos
complejos a la vez que se reduce el costo de los mismos. Este
esquema puede ser aplicado una vez que se ha terminado el Diseo
global, ya que todas las actividades de los subproyectos deben ser
consistentes con ese modelo, y hasta las pruebas o testing, ya que
estas exigen la integracin de los diferentes mdulos. Otro
inconveniente es la aparicin de dependencias no previstas por
errores en el diseo global.

PROTOTIPADO
En realidad, este modelo se aplica solo a las etapas iniciales y puede
ser utilizado en cualquiera de los otros modelos. Se busca eliminar
ambigedades y cuestiones de mala interpretacin con la
consecuencia de posteriores cambios en etapas muy avanzadas del
desarrollo, definiendo iterativamente los requerimientos en forma
conjunta con el usuario en etapas tempranas del ciclo. A partir de una
definicin preliminar de requerimientos por parte del usuario se genera
un prototipo preliminar que es iterativamente revisado, modificado y
aprobado por el usuario.
La etapa de definicin de requerimientos o relevamiento queda
fuertemente integrada a la etapa de anlisis. Este modelo es la salida
de la etapa de anlisis y la entrada a la etapa de diseo global. Al estar
aceptado formalmente por el usuario, los diseadores tienen en claro
sus necesidades, y cualquier modificacin que proponga el usuario en
las etapas finales (prueba e implementacin) ser objeto de nuevas
negociaciones (tiempo, funcionalidad o costo). Pareciera que el ciclo
iterativo consumiera ms tiempo en el proyecto, pero en realidad se
ahora tiempo de modificaciones en etapas mas tardas del ciclo, que
son mucho mas costosas cuanto ms cerca del final del proyecto se
encuentren.

USUARIO

Prototipo preliminar
DISEO
GLOBAL
Prototipo definitivo

DEFINICION DE
REQUERIMIENTOS Y
ANALISIS

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.
Es de aplicacin en implementaciones de sistemas cuyos mdulos
son implementables en forma independiente y sucesiva (los ERPs por
ejemplo). Tiene varias ventajas:
-

Como el sistema se va implementando por mdulos, la

colaboracin requerida a los usuarios es menor que en el caso
de una implementacin integral a nivel organizacional.

El xito en las implementaciones iniciales son un motivante

para la colaboracin de los nuevos usuarios en las siguientes,
ya que informalmente se habla de las bondades del nuevo
sistema, en forma preactiva.

Para los integrantes del equipo, se supone un aprendizaje de

los errores cometidos en la primera implementacin que no
debiera cometerse en las siguientes. El costo de estos errores,
al involucrar solo un modulo y no todo el proyecto es menor.

El equipo afectado a la implementacin de un modulo puede

encargarse de la implementacin de los siguientes (con el
bagaje de conocimientos que trae del proyecto) y la consultora
puede disponer de varios equipos implementadotes afectados
a varios proyectos en lugar de tener todos sus recursos
afectados a una implementacin de un nico proyecto con
todos los mdulos desarrollndose en forma paralela, con lo
cual el riesgo de proyectos que se caigan y afecten su

estabilidad financiera se reparte

-

Del lado del cliente, este tiene una percepcin mas concreta
del avance del proyecto, al ver funcionando mdulos en forma
sucesiva en vez de tener que esperar ver toda la implantacin
al final.

MODELO EN ESPIRAL
Con el fin de paliar los inconvenientes del modelo en cascada,
[BOEHM, 1988] propuso el modelo en espiral, 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 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

10

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
personal (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.
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.

11

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 sub-contratacin 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

12

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.

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., AStrategy for Comparing
Alternative software deve-lopment 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.

13