Modelos de Ciclo de Vida de Desarrollo de Software en el
Contexto de la Industria Colombiana de Software
Hugo F. Arboleda Jiménez. MSc. Docente-Investigador, Facultad de Ingenierías, Universidad de
San Buenaventura Cali.
Magíster Ingeniería de Sistemas y Computación, Universidad de los Andes, 2002.
Ingeniero de Sistemas Universidad del Valle, 1999.
1 INTRODUCCIÓN
La evolución de la disciplina de ingeniería
de software ha traído consigo propuestas
diferentes para mejorar los resultados del
proceso de construcción. Las metodologías
tradicionales haciendo énfasis en la
planeación, y las metodologías ágiles
haciendo énfasis en la adaptabilidad del
proceso, delinean las principales propuestas
presentes en la literatura. De manera
paralela, el tema de modelos para el
mejoramiento de los procesos de desarrollo
ocupa un lugar importante en la búsqueda de
la metodología adecuada para producir
software de calidad en cualquier contexto de
desarrollo. De una u otra forma, las
características de los proyectos de software
hacen necesario seguir prácticas específicas
para optimizar los resultados de los
desarrollos. Este artículo presenta en
contexto las generalidades del estado actual
de evolución de los modelos de ciclo de vida
de desarrollo de software. Luego, se hace
una reflexión de la importancia de las
características de cada proyecto al momento
de escoger el modelo de desarrollo a seguir.
La clasificación de los proyectos de software
de acuerdo a sus características específicas,
es útil para enmarcar contextos de desarrollo
para los cuales prácticas particulares de
proceso resulten en mayor probabilidad de
éxito. De igual forma, la adaptabilidad de los
modelos propuestos de acuerdo al contexto
enmarcado, y a las métricas mantenidas,
ayudan a mejorar la calidad de los productos
de software desarrollados.
2 MODELOS DE DESARROLLO DE
SOFTWARE
2.1 Metodologías tradicionales
Las metodologías tradicionales se
caracterizan por exponer procesos basados
en planeación exhaustiva. Esta planeación se
realiza esperando que el resultado de cada
proceso sea determinístico y predecible. La
experiencia ha mostrado que, como
consecuencia de las características del
software, los resultados de los procesos no
son siempre predecibles y sobre todo, es
difícil predecir desde el comienzo del
proyecto cada
Modelos de Ciclo de Vida de Desarrollo de
Software en el Contexto de la Industria
Colombiana de Software
Hugo F. Arboleda Jiménez. MSc. Docente-
Investigador, Facultad de Ingenierías,
Universidad de San Buenaventura Cali.
Magíster Ingeniería de Sistemas y
Computación, Universidad de los Andes,
2002.
Ingeniero de Sistemas Universidad del
Valle, 1999.
resultado. Sin embargo, es posible por
medio de la recolección y estudio de
métricas de desarrollo lograr realizar
estimaciones acertadas en contextos de
desarrollo repetibles. Remontándose a la
historia, el modelo de cascada fue uno de los
primeros modelos de ciclo de vida (MCV)
que formalizó un conjunto de procesos de
desarrollo de software. Este MCV describe
un orden secuencial en la ejecución de los
procesos asociados. El modelo espiral se
postuló como una alternativa al modelo de
cascada. La ventaja de este modelo radica en
el perfeccionamiento de las soluciones
encontradas con cada ciclo de desarrollo, en
términos de dar respuesta a los
requerimientos inicialmente analizados. El
modelo de cascada y el modelo espiral
suponen, de manera general, que los
requerimientos del cliente no cambian
radicalmente en el transcurso del desarrollo
del sistema. Por otro lado, la realización de
prototipos es una herramienta en la que se
apoyan diferentes MCV. Un prototipo debe
tener el objetivo de mostrar al cliente o a la
gerencia del proyecto el resultado que se
obtendrá de la implementación de cada uno
de los requerimientos del cliente una vez
terminado el desarrollo. Con los prototipos
se tiene la posibilidad de obtener
retroalimentación de manera temprana. La
solución a algunos de los problemas
presentados por las metodologías
tradicionales se logra con una gran
evolución del modelo espiral. El proceso
unificado propone la elaboración de varios
ciclos de desarrollo, donde cada uno finaliza
con la entrega al cliente de un producto
terminado. Este se enmarca entre los
conocidos modelos iterativo-incremental.
2.2 Metodologías ágiles
Grupos de desarrollo han experimentado
soluciones que basan su fundamento en la
adaptabilidad de los procesos de desarrollo,
en lugar de seguir esperando lograr
resultados predecibles de un proceso que no
evoluciona. Esta comunidad de
desarrolladores e investigadores han
nombrado su trabajo bajo lo que conocemos
como metodologías ágiles. Las metodologías
ágiles como puede entenderse mal, no están
en contra de administrar procesos de
desarrollo. Por el contrario promueve la
formalización de procesos adaptables. La
compilación de los principios y valores que
resaltan las metodologías ágiles fue
formalizada en el manifiesto para el
desarrollo de software ágil. Este documento
desarrollado por los representantes de cada
una de las metodologías que en el momento
se presentaban como ágiles, logra resumir en
un conjunto de ideas las prácticas que una
metodología de este estilo debe llevar a
cabo. Como característica fundamental, la
habilidad de responder al cambio es la
principal característica de las metodologías
ágiles. XP, una de las más difundidas, es
una metodología de desarrollo de software
ágil que define pocas reglas y pocas
prácticas. XP promueve la adaptabilidad de
los procesos de desarrollo basándose en los
principios y prácticas que presenta. Quienes
trabajan usando XP deben seguir procesos
disciplinados, pero más que eso, deben
combinar la disciplina con la adaptabilidad
necesaria del proceso.
Las metodologías de Cristal se basan en el
principio de que tipos diferentes de
proyectos requieren tipos diferentes de
metodologías. La metodología escogida
debe depender de dos factores: el número de
personas en el proyecto, y las consecuencias
de los errores. Conforme al principio de las
metodologías ágiles, Scrum recalca la
imposibilidad de encontrar procesos
definidos y repetibles cuando no existen
problemas, personas, ni ambientes definidos
y repetibles.
2.3 ¿Metodologías ágiles o metodologías
tradicionales?
En las metodologías tradicionales el
principal problema es que nunca se logra
planear bien el esfuerzo requerido para
seguir la metodología. Pero entonces, si
logramos definir métricas que apoyen la
estimación de las actividades de desarrollo,
muchas prácticas de metodologías
tradicionales podrían ser apropiadas. El no
poder predecir siempre los resultados de
cada proceso no significa que estamos frente
a una disciplina de azar. Lo que significa es
que estamos frente a la necesidad de
adaptación de los procesos de desarrollo que
son llevados por parte de los equipos que
desarrollan software. Tener metodologías
diferentes para aplicar de acuerdo con el
proyecto que se desarrolle resulta una idea
interesante. Estas metodologías pueden
involucrar prácticas tanto de metodologías
ágiles como de metodologías tradicionales.
De esta manera podríamos tener una
metodología por cada proyecto, la
problemática sería definir cada una de las
prácticas, y en el momento preciso definir
parámetros para saber cual usar. Es
importante tener en cuenta que el uso de un
método ágil no es para todos. Sin embargo,
una de las principales ventajas de los
métodos ágiles es su peso inicialmente
ligero y por eso las personas que no estén
acostumbradas a seguir procesos encuentran
estas metodologías bastante agradables.
3 MODELOS DE DESARROLLO EN LA
INDUSTRIA DEL SOFTWARE
COLOMBIANO
Los primeros desarrollos de software en
Colombia iniciaron de manera artesanal.
Incrementalmente, y con la llegada de
nuevas tecnología, plataformas de
desarrollo, y programas de formación
superior bien estructurados, se inició un
proceso de mejoramiento de procesos entre
los que se incluye el tema de la planeación y
seguimiento de los proyectos de software.
El modelo de cascada fue en ese entonces, y
tal vez lo sigue siendo, el modelo más usado
por los desarrolladores de software que
recién constituyen sus empresas de
desarrollo. Modelos de desarrollo sin alto
nivel de complejidad como el espiral, o el
orientado a prototipos, siguen siendo los
más usados. Sin embargo, estos modelos
siguen siendo interpretados en algunos casos
de manera errónea. Es el caso de equipos de
desarrollo que por tener ciclos de desarrollo
iterativo y/o incremental, aseguran seguir un
modelo espiral, sin realizar un análisis de
riesgo bien soportado. Igual pasa con el uso
de los prototipos. Estos se usan como
herramienta de avance, sin hacer entender al
cliente el objetivo de validación de
requerimientos, y/o especificación de
borradores de interfaz. Un problema paralelo
radica en que muchos de los ingenieros de
desarrollo de software no tienen claro qué
modelo de desarrollo siguen al interior de
sus equipos. Así, problemas “normales”
adjuntos a un modelo de ciclo de vida de
desarrollo los toman por sorpresa, pudiendo
ser evitados haciendo un análisis del modelo
adecuado para el proyecto particular Uno de
los temas más abordados en la industria del
software Colombiano es el tema de
planeación y seguimiento de proyectos. Con
este tema viene adjunto el tema de la
definición de modelos de ciclo de vida de
desarrollo. Sin embargo, normalmente el
tema se ha abordado desde una perspectiva
tradicional de planeación de proyectos, sin
hacer énfasis en las características propias
de los proyectos de software. Es por esta
razón que los modelos de desarrollo siguen
esquemas tradicionales, con poco o ningún
énfasis en la adaptación al cambio y la
estimación basada en datos históricos de
desarrollo. Gran parte de las empresas de
software que tienen esquemas de oficinas de
proyectos, o usan metodologías de
planeación guiadas por el Instituto de
Gerencia de Proyectos de Estados Unidos
(PMI) siguen esquemas tradicionales donde
los procesos de soporte de desarrollo de
software son poco tomados en cuenta,
generalmente por lo poco entendidos. Es el
caso de la Administración de
Requerimientos. De igual forma, aunque los
planes del proyecto sean administrados, en
muchas ocasiones no son impactados frente
a los cambios que surgen en el desarrollo del
día a día. Así, parte de la solución no está en
la búsqueda de realizar planes perfectos de
desarrollo, sino en la búsqueda de estrategias
que permitan realizar ajustes a los planes
definidos desde el inicio. En eso hacen
énfasis las metodologías ágiles.
4 CÚAL ES EL CAMINO A SEGUIR?
Antes de definir el modelo de ciclo de vida
de desarrollo a seguir en una iteración de un
proyecto dentro de una empresa en el
contexto colombiano, se debe entender los
fundamentos básicos, con pros y contras, de
seguir un modelo determinado. Esto incluye
como primera medida, realizar un estudio de
las prácticas que se van a poner en ejecución
dentro de un proyecto. Los modelos híbridos
(tradicionales y ágiles) deben ser
estructurados teniendo en cuenta las
características propias del proyecto. Esto
incluye las propias características del
contexto colombiano. Un modelo de ciclo de
vida exitoso en un contexto, no
necesariamente lo es en otro contexto. Por
ejemplo, ante el surgimiento de los Parques
Tecnológicos que incluyen empresas de
desarrollo de software, se debe tomar en
cuenta las características propias del
contexto de un grupo de jóvenes
emprendedores sin altos recursos para
realizar inversión, con necesidad de poner en
el mercado en relativo poco tiempo un
software altamente funcional de excelente
calidad. Un conjunto de preguntas que
surgen ante la necesidad de redefinir el
modelo de desarrollo que un equipo sigue en
un momento determinado, con el fin de
mejorar los resultados en términos de un
conjunto de
atributos como pueden ser la calidad del
software y la precisión de los planes
realizados, podrían ser las siguientes: 1.
Cómo evaluar mis proceso de desarrollo? 2.
Cómo identificar el conjunto de
características que rodean mis desarrollos, e
impactan de manera significativa los
resultados de mi equipo? 3. Cómo identificar
el conjunto de prácticas adecuadas para
incluir en un nuevo modelo de ciclo de vida
de desarrollo? La respuesta a estas preguntas
se enmarca en el tema de Mejoramiento de
Procesos de Software (SPI). En este tema se
encuentra por ejemplo la propuesta realizada
por el Instituto de Ingeniería de Software
con su trabajo sobre IDEAL y CMMI. Sin
embargo, al igual que para los procesos de
desarrollo, las prácticas requeridas para
mejorar un proceso de software dependen
altamente del contexto donde se mejoran los
procesos. Por ejemplo, no es igual mejorar
los procesos al interior de equipos con alta
rotación, y gran número de participantes,
que mejorarlos en un equipo pequeño y
estable. Para el caso del contexto
colombiano, tomando como objetivo las
pequeñas y medianas empresas, una buena
estrategia es evaluar los procesos frente a un
marco de referencia como puede ser CMMI
en cada una de sus áreas de proceso. Luego
de tener una evaluación inicial del estado
actual de los procesos, y definir lo que se
puede llamar una línea base de procesos, se
debe realizar un plan de mejoramiento
basado en las características del equipo de
desarrollo. Un buen ejercicio para identificar
estas características es realizar un árbol de
problemas como el presentado en la figura 1.
Por medio de este tipo de esquemas, se
pueden identificar características que de
alguna manera no se tomaban en cuenta.
modelo de desarrollo, se debe tener en
cuenta el marco de referencia con el cual se
evaluó el proceso actual, y las características
identificadas. Así, de manera incremental, se
incorporan prácticas en un orden que se
defina como prioritario al interior del equipo
para minimizar los impactos negativos de
características del equipo identificadas, en
los proyectos de desarrollo. Algo que
siempre se debe tener en cuenta es la
definición de métricas desde el inicio de
mejoramiento, que permitan medir la mejora
una vez impactados los procesos. A estas
métricas se les conoce como indicadores de
gestión del mejoramiento de procesos.

Figura 1. Árbol de problemas para la

identificación de características propias de
un contexto.
Alta rotación del equipo
Jerarquías impuestas
Desmotivación Oportunidades del mercado
Bajo nivel de productividad
No existencia de procesos livianos para
adaptar
Fuga de conocimiento
Incremento del costo en comunicación
Adaptación continua de equipo al proceso
Incremento de documentación para soportar
rotación
Fuga de conocimiento

Finalmente, para identificar las prácticas

precisas que se deben incluir en el nuevo