Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto

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
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.
Fuga
de
conocimiento
Incremento de
documentación
para soportar
rotación
Adaptación
continua
de
equipo
al Incremento del costo en
comunicación
proceso
Fuga
de
conocimiento
Bajo nivel de
productividad
No existencia de
livianos
Alta rotación procesos
para
adaptar
del equipo
Desmotivación
Oportunidades del
mercado
Jerarquías impuestas
Figura 1. Árbol de problemas para la identificación de características propias de un contexto.
Finalmente, para identificar las prácticas precisas que se deben incluir en el nuevo 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.