Fecha de recepción: 18-12-2010 - Fecha de aceptación: 20-03-2011

Resumen

El objetivo de esta investigación es validar un modelo liviano de gestión de configuración que reconozca el contexto y las particularidades de las pequeñas empresas de desarrollo de software. Para ello se acude a los lineamientos establecidos por CMMI sin alterar las seis prácticas específicas, pero pasando de las treinta y cuatro sub-prácticas a siete actividades. El trabajo empieza a partir de la definición de las entradas, salidas, actividades, controles y plantillas de soporte del modelo, para después presentar el marco experimental sobre el cual se adelanta en forma ordenada y sistemática su respectiva validación. Con el diseño y ejecución del experimento se espera confirmar su viabilidad y su ajuste a las pequeñas empresas de software a través de los resultados que se obtengan de las métricas establecidas. La validación logró gracias a la cooperación de tres pequeñas empresas (dos de ellas a nivel internacional -en Rusia-) que permitieron su aplicación en seis proyectos reales de software con resultados que muestran las mejoras en los índices de eliminación de defectos, productividad y valor ganado. El modelo propuesto abre un camino hacia la transferencia de buenas prácticas de industria a las empresas pequeñas, esperando que estos resultados permitan aplicarlo en otros escenarios, tanto nacionales como internacionales.

Palabras clave: Gestión de configuración, CMMI®, proyectos de desarrollo de software, empresas pequeñas de software.

Abstract

The purpose of this research work is to valídate a light configuration management model that recognizes the setting and the specific characteristics of small companies engaged in software development. To this end, it follows CMMI's guidelines without changing the six specific practices, but it goes from thirty-four sub-practices to seven activities. This work begins with a definition of the inputs, outputs, activities, controls, and supporting templates of the model, and goes on to present the experimental framework that provides the basis for an orderly and systematic validation. It is expected that the design and execution of the experiment will allow confirming viability and adjustment of the model to small software companies based on the results of established metrics. Validation was made possible thanks to the cooperative efforts of three small companies (two of which are international companies based in Russia) that allowed the model to be applied to six real software projects with results that show improvements of defect elimination, productivity, and earned value rates. The model proposed here opens a path for transferring best industry practices to small-sized companies. It is expected that these results will enable future implementation of the model in other settings, both on a national and iternational level.

Keywords: Configuration management, CMMI®, software development projects, small software companies.

Introducción

El propósito de la gestión de configuración (GC) es establecer y mantener la integridad de cada uno de los productos que se van obteniendo del ciclo de desarrollo de software (Merchán, Urrea y Rebollar, 2008, pp 37-50). La GC representa un elemento clave en el proceso de desarrollo de software (Habra, et al., 2008, pp 763-771) ya que proporciona estabilidad a la producción de software, controla el cambio continuo y concurrente que viene con la evolución del producto de software y obliga a implementar estrategias de versionamiento.

Dentro de la industria de software en Colombia hay un sector emergente, cuya característica más importante es la formación de empresas pequeñas desarrolladoras de software que cuentan con reducidos equipos de trabajo (hasta diez personas) (RCCS, 2010). Estas empresas en muchas ocasiones no tienen en cuenta el impacto de los cambios que surgen en el desarrollo de sus productos (Merchán, 2010) y por lo tanto presentan un alto porcentaje de errores en su producción. La causa común de estos errores es la desactualización de las versiones de su software o peor aún, la pérdida de funcionalidades por solapamiento de código entre desarrolladores (Merchán y Hoyos, 2007).

A pesar de sus limitaciones en recursos, las empresas emergentes son conscientes de la necesidad de ejecutar procesos de calidad que les permitan crecer de manera ordenada y eficiente para lograr reconocimiento en la industria y por ende mayor aceptación en el mercado. Igualmente, saben que necesitan acceder a procesos de certificación como los ofrecidos por CMMI® para enfrentar los mercados internacionales, que hoy son más restrictivos y complejos para las pequeñas empresas de tware (Anacleto, Gresse Von Wangenheim, Salviano and Savi, 2004).

Para ello, y como resultado de un trabajo de priorización (Merchán, 2010), el Laboratorio de Investigación para la Ingeniería de Software -LIDIS-, definió un modelo de mejoramiento de procesos para el contexto de las pequeñas empresas de software en el que se contemplaron las siete áreas correspondientes al nivel dos de CMMI®, y se consideró el área de gestión de configuración como una de las más crítica de las empresas. Con esta motivación se inició el proyecto de investigación cuyo propósito fundamental fue la definición y validación de un proceso liviano para la gestión de configuración aplicada al contexto de la industria de software emergente.

El modelo no omite ninguna actividad clave, solo minimiza el número de tareas que han sido definidas en CMMI®, con el objetivo de economizar el uso de los recursos (tiempo y dinero) que se tienen disponibles. Y brinda una guía práctica, así como define y documenta (instructivos, metodologías y tareas) las actividades de administración de la configuración que ayuden a las empresas a establecer y mantener la integridad de sus productos, de manera que se pueda adoptar como una disciplina que proporciona estabilidad a la producción de software, controlando el cambio continuo y concurrente, derivado del ciclo de desarrollo del software.

Este artículo presenta inicialmente una caracterización de las empresas pequeñas (o emergentes), luego propone el modelo a la vez que lo compara con el proceso que CMMI® establece para la gestión de requisitos. Luego muestra el diseño del experimento que abocará la aplicación del modelo liviano y finalmente analiza los resultados del proceso de validación.

1. Características de la gestión de configuración en las pequeñas empresas de software

Por sus particularidades, las pequeñas empresas de software -también se les conoce como very small enterprise (VSE) (Laporte, April and Renault, 2006)- han venido ganando terreno en el reconocimiento de sus limitantes. Para ello, la International Organization for Standardization/International Electrotechnical Commission Joint Technical Committee 1/Sub Committee 7 (ISO/IEC JTC 1/SC7) ha establecido el Work Group 24 (WG24) con el ánimo de propender por modelos de madurez enfocados principalmente a empresas que cuentan con muy poco personal y recursos. En algunos países latinoamericanos se les conoce como empresas emergentes en virtud a que forman parte de procesos de emprendimiento (también conocidos como incubación empresarial).

En mayo de 2006, en Thailandia, el WG24 estableció dos perfiles para empresas: las que tienen de uno a nueve empleados y las de diez a veinticinco trabajadores (Laporte, 2006), enviando así un mensaje a la comunidad internacional sobre la necesidad de trabajar estándares, modelos, técnicas y herramientas que soporten a las empresas pequeñas.

En un estudio de caracterización de la industria local (suroccidente colombiano), adelantado por el LIDIS, se estableció que el 87% de las empresas estaban conformadas por menos de nueve empleados y presentaban características similares respecto a la informalidad en los procesos que aplicaban y a la forma en que dirigían y organizaban sus actividades (Merchán, 2010).

El mismo estudio, en cuanto a la gestión de configuración, presentó el siguiente diagnóstico:

• Sólo un 37% de las empresas realiza el proceso de administración de la configuración, aunque reconocen que lo hacen sin ningún soporte procedimental.
• Son pocas empresas, representadas en un 27%, las que adelantan capacitación en esta área de proceso de actualización técnica permanente. Se destaca el 31%, que representa a aquellas empresas que ni siquiera han considerado aplicar aún este tipo de actividades.
• En cuanto a criterios para la identificación, el 35% de las empresas no saben o no hacen una identificación previa de todos los productos de trabajo que necesitan ser controlados.

En cuanto a los criterios para el control de cambios, que representa el mayor problema, se tiene:

• Sólo el 41% de las empresas hacen siempre o regularmente un seguimiento documentado de los cambios que se aplican a los ítems de configuración.
• Sólo el 53% de las empresas siempre o regularmente identifican y determinan cuáles son las personas o grupos autorizados para realizar los cambios.
• Sólo el 43% de las empresas realizan siempre o regularmente un análisis del impacto que puede generar los cambios.
• Sólo el 43% siempre o regularmente hacen saber los cambios realizados en las líneas base a los grupos o individuos afectados.
• Sólo el 37% de las empresas siempre o regularmente manejan formularios para las solicitudes de cambio.

Con respecto al registro de estado, el 51% de las empresas llevan siempre o regularmente un registro de todas las versiones y entregas de sus productos, y en lo que tiene que ver con la revisión y auditoría, sólo el 37% definen siempre o regularmente por escrito las actividades de administración de configuración antes de ponerlas en ejecución.

En cuanto a la aplicación del CMMI®, las empresas estudiadas manifiestan que es necesario por la estructura y certifcación que ofrece, pero requiere muchos recursos y tiempo someterse a un proyecto de mejora bajo sus lineamientos (Merchán, 2010). En razón a lo anterior, se decidió adelantar una investigación que condujera a un modelo liviano de gestión de la configuración apropiada al contexto de las empresas pequeñas de software pero sin perder de vista los referentes que tarde o temprano tendrán que implementar para procesos de certifcación.

2. Modelo propuesto

2.1. Alcance

El modelo de gestión de configuración tiene como objetivo establecer y mantener la integridad de los productos y/o servicios desarrollados.

2.2. Etapas del modelo

Ha sido estructurado en dos etapas principales (Figura 1):

Definición: Su propósito es obtener un óptimo entendimiento del contexto organizacional en sus aspectos técnicos.

Mantenimiento: El propósito de esta etapa es especificar las actividades que ayudan al mantenimiento del proceso y que garantizan la integridad del sistema y la adopción del proceso por parte de la empresa.

La Tabla 1 muestra una relación de las prácticas y sub-prácticas dadas por el referente CMMI® con las etapas y actividades que se tomaron para el diseño del modelo propuesto (ver Tabla 1).

En resumen, en el modelo propuesto se conservan las seis prácticas específicas (PE) y se pasa de treinta y cuatro sub-prácticas (SubP) a siete actividades (GC).

3. Diseño del experimento de validación

Una vez definido el modelo con sus entradas, salidas, actividades, controles y plantillas de soporte, se seleccionó el marco experimental sobre el cual se adelantaría, en forma ordenada y sistemática, su respectiva validación.

Para aplicar el experimento se tuvieron en cuenta los conceptos de Juristo and Moreno (2001) explicados a continuación:

3.1 Unidad experimental

Objeto o espacio al cual se le aplica el experimento y donde se mide y analizan las métricas que se investigan. Se consideró como unidad el proceso de gestión de configuración.

3.2. Sujetos experimentales

Son aquellas personas u objetos sobre los que se va a llevar a cabo el experimento. Como sujetos se consideraron las tres empresas que participan en el experimento mediante la implementación del modelo.

3.3. Factores

Representan las características de la unidad experimental que se toman para el experimento. Los valores que pueden tomar los factores se conocen como niveles. El experimento tomó dos factores: el tamaño del proyecto de software y la experiencia de los sujetos experimentales en gestión de requisitos.

El tamaño de un proyecto de software es un factor diferenciador para clasificarlo de acuerdo con el esfuerzo estimado. Este tamaño se clasifica en tres niveles:

• Nivel 1 (proyectos pequeños): Emplean un tiempo menor a tres meses durante el ciclo de vida.
• Nivel 2 (proyectos medianos): Emplean entre tres y nueve meses durante el ciclo de vida de su desarrollo.
• Nivel 3 (proyectos grandes): Emplean un tiempo mayor a nueve meses durante el ciclo de vida de su desarrollo.

La experiencia de los sujetos experimentales se entiende como la práctica prolongada que proporciona el conocimiento o habilidad de quienes intervienen en el experimento y de acuerdo con las empresas se clasifica en tres niveles.

• Nivel 1 (baja experiencia): Empresas que no tienen institucionalizado el proceso de gestión de requisitos durante el ciclo de vida de desarrollo.
• Nivel 2 (mediana experiencia): Empresas que definen un proceso formal para gestionar los requisitos o que el producto tiene definido un roadmap y se aplica la medición como mecanismo de control.
• Nivel 3 (Alta experiencia): Empresas que definen un proceso formal para gestionar los requisitos y se aplica la medición como mecanismo de control; o en las que incluyen prácticas maduras para el control de cambios y utilizan los resultados de la medición para identificar tendencias y tomar decisiones respecto a nuevos proyectos y mejora de las prácticas existentes.

La estructura organizacional no se tomó como factor en razón a que el 92% de las empresas no la tienen definida y que el 87% de ellas están compuestas por menos de nueve empleados, de los cuales el 67% son ingenieros de sistemas. Tampoco se consideró la antigüedad y la experiencia comercial en razón a que el 59% de las empresas tenían en promedio tres años de antigüedad y el 82% de los proyectos no superaban en presupuesto los US$50.000 (Merchán, 2010).

3.4. Métricas

Las métricas representan el método que permite medir las variables de un modelo para darle pertinencia y validez. En la investigación, las métricas fueron definidas para ofrecer información cuantificada a las empresas de los resultados de aplicar el modelo versus continuar con sus métodos y metodologías. Igualmente, en cierta forma, debían representar datos que los empresarios consideraran significativos a la hora de evaluar el modelo.

En razón a lo anterior, la investigación estableció que se debía validar si una empresa, al aplicar apropiadamente el modelo, mejoraba en la eliminación de defectos. De la misma manera, interesaba saber si aplicando el modelo se incrementaba la productividad, ya que era una de las mayores expectativas de las empresas al abordar el proyecto. Finalmente, siendo la estimación una de las grandes limitantes en la planificación de proyectos, se requería saber la validez de las estimaciones de esfuerzo.

En razón a lo anterior se consideraron tres métricas: mejora en la eliminación de defectos (ver Tabla 2), mejora en la productividad (ver Tabla 3) y mejora en el valor ganado en desarrollo (ver Tabla 4).

3.5. Aplicación del experimento de Validación

La validación en las empresas reales tuvo los siguientes condicionamientos:

Cada empresa debía seleccionar dos proyectos basados en las características que se muestran en la Tabla 5.

Los proyectos debían ser diferentes pero con características similares (alcance, recursos, tiempos y complejidad). Se brindó a las empresas un acompañamiento metodológico en la aplicación del modelo, que se debía desarrollar en dos fases, a saber:

• La primera, correspondía a un proyecto ya realizado en cada empresa, y se debía estimar los valores de las métricas a partir de su información histórica. Esta primera fase se denominó sin modelo (SM).
• La segunda, correspondía a un nuevo proyecto (diferente al anterior) en cada empresa. A esta segunda fase se le denominó con modelo (CM).

4. Recolección de datos

A partir del diseño experimental se procedió a establecer el tratamiento en cada empresa y el tipo de proyecto al cual se le aplicaba el modelo y por ende las métricas establecidas (ver Tabla 6).

La Tabla 7 presenta el método seguido para la obtención de las métricas en los proyectos históricos para los cuales no se aplicó el modelo.

La Tabla 8 presenta el método seguido para la obtención de las métricas en los proyectos en los que se aplicó el modelo.

5. Resultados y análisis

5.1. Métrica para la mejora en la eliminación de defectos

La Tabla 9 presenta los resultados en la eliminación de defectos para cada una de las empresas que participaron en el proceso de evaluación del modelo.

La Tabla 10 presenta el análisis de los resultados para cada una de las empresas y que fueron producto de reuniones de análisis, verifcación y validación del modelo.

5.2. Métrica para la mejora en la productividad

La Tabla 11 presenta los resultados en la mejora de productividad para cada una de las empresas que participaron en el proceso de evaluación del modelo. Indica el tiempo que puede tardar un grupo de trabajo en empaquetar un producto que ya esté listo para salir a producción, midiendo el esfuerzo empleado desarrollando un producto contra el tiempo empleado empaquetándolo.

La Tabla 12 presenta el análisis de los resultados para cada una de las empresas y que fueron producto de reuniones de análisis, verifcación y validación del modelo.

5.3. Métrica para la mejora en el Valor ganado

La Tabla 13 presenta los resultados en la mejora en el valor ganado para cada una de las empresas que participaron en el proceso de evaluación del modelo. Indica la exactitud de la estimación de esfuerzo comparada con la estimación real del trabajo, buscando tener una estimación para los tiempos de trabajo del proyecto que le permita a futuro establecer estimaciones muy cercanas a las presupuestadas.

La Tabla 14 presenta el análisis de los resultados para cada una de las empresas y que fueron producto de reuniones de análisis, verifcación y validación del modelo.

6. Conclusiones

Las empresas pequeñas de software son conscientes de la necesidad de procesos de mejoramiento pero adaptados a su contexto y particularidades.

Una vez aplicado el modelo y ante la evidencia de los resultados logrados, los empresarios crean las condiciones para que el modelo forme parte de sus estrategias permanentes de mejoramiento. Igualmente, los hechos y evidencias son la mejor forma de presentar propuestas de mejoramiento a las empresas ya que pueden evidenciar realmente los beneficios internos y externos que se logran.

Igualmente, las empresas (a través de una encuesta) manifestaron la satisfacción de los desarrolladores al contar con estándares que les permiten adelantar sus procesos de manera más técnica y organizada. Adicionalmente, se sentían seguros ante la presentación de proyectos de desarrollo a empresas contratantes al presentarles que contaban con modelos adecuados y pertinentes.

El modelo propuesto abre un camino hacia la transferencia de buenas prácticas de industria a las empresas pequeñas, esperando que estos resultados permitan aplicar el modelo en otros escenarios, tanto nacionales como internacionales.

Reconocimientos

Se reconoce a las empresas la participación en la presente investigación. Igualmente a los estudiantes Christian Aparicio, Andrés Collazos y Javier Yela por el trabajo de aplicación de instrumentos del trabajo de campo.

Bibliografía

1. ANACLETO, Alessandra; GRESSE VON WANGENHEIM, Christiane; SALVIANO, Clenio and SAVI, Rafael. A method for process assessment in small software companies. En: International SPICE Conference on process assessment and improvement. (4: 2004: Portugal). Conferences of IV International SPICE Conference on process assessment and improvement. Lisboa, 2004.         [ Links ]

2. HABRA, Naji; ALEXANDRE, Simon; DESHARNAIS, Jean-Marc; LAPORTE, Claude And RENAULT, Alain. Initiating software process improvement in very small enterprises: Experience with a light assessment tool. Information and Software Technology, Volume 50, Issues 7-8. 2008. pp 763-771.         [ Links ]

3. JURISTO, Natalia y MORENO, Ana. Basics of software Engineering Experimentation. Boston: Kluwer Academic Publisher, 2001. 395p. ISBN 0-7923-7990-X.         [ Links ]

4. LAPORTE, Claude; APRIL, Alain and RENAULT, Alain. Applying ISO/IEC software engineering standards in small settings: historical perspectives and initial achievements. En: SPICE Conference on Process Assessment and Improvement. (6:2006: Luxembourg).         [ Links ]

5. LAPORTE, Claude. The Application of International Software Engineering Standards in Very Small Enterprises. En: ENCUENTRO DE CALIDAD DE SOFTWARE. (2006: Cartagena). Ponencias del I Encuentro de Calidad de Software. Cartagena, 2006.         [ Links ]

6. MERCHÁN, Luis; URREA, Alba y REBOLLAR, Rubén. Definición de una metodología ágil de ingeniería de requerimientos para empresas emergentes de desarrollo de software del sur occidente colombiano. En Revista Guillermo de Ockham, Vol. 6, No 1, p. 37-50. Cali: Universidad de San Buenaventura, 2008.         [ Links ]

7. MERCHÁN, Luis. Planificación de proyectos de mejora de procesos: enfoque en pequeñas empresas de desarrollo de software. Cali, Colombia: Editorial Universidad de San Buenaventura, 2010. 176p. ISBN 978-958-8436-39-5.         [ Links ]

8. MERCHAN, Luis y HOYOS, Patricia. Definición de un proceso liviano para administración de configuración para empresas emergentes de la industria del software. En: Congreso Internacional de Ingeniería de Proyectos. (11:2007: España). Lugo, 2007.         [ Links ]

9. RCCS. Red Colombiana de Calidad de Software. [en línea]. http://rccs.cidlisuis.org/index.php?option=com_content&task=view&id =12&Itemid=20. (citado en 20 mayo de 2010).         [ Links ]

Luis Merchán Paredes, Ph.D
Doctorado en Administración de Proyectos, Universidad de Zaragoza, España. Maestria en Administración de Empresas, Universidad Icesi, Colombia. Especialista en Finanzas, Universidad EAFIT. Ingeniero de Sistemas, Universidad Industrial de Santander, Colombia. Coordinador de Investigaciones y docente titular en el Programa de Ingenieria de Sistemas de la Universidad de San Buenaventura Cali - Colombia.

Diego Armando Gómez Mosquera, Msc.
Magister en Ingenieria de software, Universidad Politecnica de Madrid, España. Ingeniero de Sistemas, Universidad de San Buenaventura, Cali - Colombia. Docente titular en el Programa de Ingenieria de Sistemas de la Universidad de San Buenaventura Cali - Colombia.