Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software

Transcripción

1 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, Ingeniero de Sistemas Universidad del Valle, 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

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

3 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

4 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

5 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. Adaptación continua de equipo al proceso Fuga de conocimiento Incremento de documentación para soportar rotación Incremento del costo en comunicación Fuga de conocimiento Bajo nivel de productividad Alta rotación del equipo No existencia de procesos livianos para adaptar Desmotivación Oportunidades del mercado Jerarquías impuestas Figura 1. Árbol de problemas para la identificación de características propias de un contexto.

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