KEMIS: Un Entorno para la Medición de la Calidad del
Producto Software


Moisés Rodríguez, Javier Garzás y Mario Piattini

1. Introducción

Hoy en día las organizaciones, en la búsqueda de mayores ventajas competitivas, están invirtiendo cada vez más en automatizar sus procesos de negocio y en desarrollar nuevos servicios basados en tecnología software, lo que requiere una confianza creciente en los productos de desarrollo software, considerando el rol estratégico que estos tienen en las organizaciones. Por todo ello, el incremento y el control de la calidad del producto software se ha convertido en una necesidad vital.

A la vez los productos software son cada vez de mayor tamaño, más sofisticados y complejos (Wong, Boehm et al. 2004)(Wong, Verner et al. 2005), creando el reto de desarrollar dichos productos dentro de las restricciones de tiempo sin sacrificar la calidad. Para poder asegurar que un proceso o sus productos resultantes son de calidad es necesario asignar valores, descriptores, indicadores o algún otro mecanismo mediante el cual se pueda llevar a cabo dicha evaluación. Para ello es necesario implantar un proceso de medición del software, que en general, persigue tres objetivos fundamentales: ayudarnos a entender qué ocurre durante el desarrollo y el mantenimiento, permitirnos controlar qué es lo que ocurre en los proyectos y poder mejorar los procesos y productos (Fenton and Pfleeger 1997).

Las métricas son un buen medio para entender, monitorizar, controlar, predecir y probar el desarrollo de software y los proyectos de mantenimiento (Briand, Morasca et al. 1999) y pueden ser utilizadas por profesionales e investigadores para tomar mejores decisiones (Kitchenham, Pfleeger et al. 2002). La construcción de un entorno que permita llevar a cabo la medición, requiere tanto de un soporte metodológico como de un soporte tecnológico (Lavazza 2000). Por tanto, para que las métricas puedan ser utilizadas para evaluar los productos software de un modo práctico, eficiente y exacto, es necesario contar con herramientas que permitan automatizar la adquisición, la presentación y el análisis de los valores obtenidos para dichas métricas (Giles and Daich 1995).

2. Proyecto KEMIS

KEMIS “Kybele Environment Mesaurement Information System” es un entorno desarrollado por Kybele Consulting que proporciona, por un lado, un conjunto predefinido de aplicaciones de software libre, junto con su configuración e instalación, que permiten implantar un sistema de medición de la calidad software a nivel operativo, táctico y estratégico , y por otro, un soporte metodológico basado en PSM para la evaluación de la calidad del producto software.

Si bien métricas, revisiones, inspecciones o controles de calidad son áreas clásicas y con años de madurez, en la actualidad lo que hace que estas se conviertan en práctica de uso, útiles y de la que se obtienen amplios beneficios es que se consideren los siguientes objetivos:

  • Definir unos objetivos claros y medibles.
  • Realizar las mediciones de manera periódica y frecuente.
  • Automatizar el proceso de medición.
  • Definir diferentes niveles de abstracción.

Para cumplir con el primer objetivo (definir unos objetivos claros de medición), KEMIS está basada en PSM “Practical Software and System Measurement”. PSM es un proceso de medición que permite dirigir los objetivos técnicos y de negocio de una organización, y recoge las mejores prácticas utilizadas por los profesionales de la medición dentro de las comunidades del software, la adquisición de sistemas y la ingeniería.

Para alcanzar el segundo y tercer objetivo (realizar las mediciones de una manera automatizada, periódica y frecuente), la infraestructura del entorno KEMIS se basa en Maven 2, una herramienta software para la gestión y comprensión de proyectos Java que mediante sus plugins de medición permite obtener un conjunto de métricas de manera automática. Además, Maven 2 se basa en el concepto de integración continua (Fowler 1999; Pérez 2005), y mediante la herramienta Continuum, permite realizar una planificación de los procesos de medición.

Para cumplir el cuarto objetivo (obtener distintos niveles de abstracción en la presentación de resultados), y permitir realizar un análisis intuitivo de la calidad del producto software, KEMIS propone un conjunto de informes en los que recoge los principales indicadores de calidad. Para ello utiliza una base de datos MySQL donde almacena los resultados más representativos obtenidos por los plugins de medición y un servidor en el que se registran los informes, permitiendo después consultar y presentar automáticamente la información sobre la calidad del producto software.

3. Arquitectura del Proyecto KEMIS

En la Figura 1 se observa la arquitectura del entorno KEMIS. Destaca la división de la imagen en dos mitades separadas por una línea discontinua. Esta separación corresponde a las dos fases en las que se realiza la implantación del entorno:

  • Infraestructura de medición básica (nivel operativo): La primera fase corresponde a la instalación y configuración de Maven 2, así como de los plugins de medición. Al terminar esta primera fase, el usuario dispone de un entorno que le permite obtener métricas de calidad de manera periódica y automática.
  • Infraestructura de medición avanzada (niveles táctico y estratégico): La segunda fase corresponde a la instalación y configuración del entorno para la generación de informes. Al terminar esta segunda fase, el usuario dispone del entorno de medición KEMIS completo, lo que le permite, además de realizar las actividades de la primera fase, obtener informes personalizados con los principales indicadores de calidad del producto software.

 Figura 1. Arquitectura proyecto KEMIS

4. Indicadores

Debido a la gran cantidad de información generada mediante los plugins de medición y la dificultad de manejar dichos resultados en la manera que son generados, KEMIS propone y proporciona una serie de informes que recogen los principales indicadores de calidad del producto software. Estos indicadores se encuentran clasificados en las siguientes categorías:

4.1 COMPONENTES

Los indicadores pertenecientes a esta categoría sirven para dar un punto de vista global acerca del tamaño del proyecto bajo estudio en cuanto a número de elementos se refiere.

4.2 LÍNEAS DE CÓDIGO

Los indicadores pertenecientes a esta categoría sirven para dar un punto de vista global acerca del tamaño del proyecto bajo estudio en cuanto a número de líneas de código (NCSS) se refiere.

4.3 DEFECTOS

Los indicadores pertenecientes a esta categoría sirven para dar un punto de vista global acerca de la calidad del código del proyecto bajo estudio en cuanto a número de defectos se refiere.

4.4 COMPLEJIDAD CICLOMÁTICA

Los indicadores pertenecientes a esta categoría sirven para dar un punto de vista global acerca de la calidad del código del proyecto bajo estudio respecto a la complejidad ciclomática que presenta.

4.5 CÓDIGO DUPLICADO

Los indicadores pertenecientes a esta categoría sirven para dar un punto de vista global acerca de la calidad del código del proyecto bajo estudio respecto a la cantidad de código duplicado que presenta.

4.6 RESUMEN SOBRE CALIDAD DE SOFTWARE

Indicador global cuya función es resumir el resultado de los indicadores anteriores, mostrando mediante un único informe aquella información considerada más importante para determinar la calidad de los proyectos estudiados.

5. Buenas Prácticas

A continuación presentamos un conjunto de buenas prácticas o recomendaciones que por nuestras experiencias nos parecen importantes, destacando:

  • La evaluación cuantitativa del producto:
  • Es un método necesario no solo en el desarrollo, también si éste se externaliza, más aún si somos responsables de la puesta en producción.
  • Permite identificar síntomas para poder aplicar soluciones correctas.
  • Aporta argumentos sólidos para defender y concienciar sobre la necesidad de mejora del proceso.
  • La periodicidad del muestreo la dicta la complejidad del método/infraestructura de medición. Cuanto mas costoso resulta el proceso de medición, se llevarán a cabo menos mediciones y de menor calidad.
  • Una gran cantidad de pasos a producción, o un importante proceso de mejora en, por ejemplo, una fábrica software, necesitará de una alta periodicidad en la medición, así podremos controlar los efectos de las mejoras (“que arreglar algo no rompa otra cosa”), etc.
  • Hoy en día es fácil recopilar un gran volumen de datos sobre la calidad de los productos software, sin embargo, la dificultad está en saber que hacer con ellos.
  • Es necesario decidir qué mostrar, cuándo y a quién. Niveles de abstracción e información.
  • El proceso de definición de métricas es incremental y ha de ser mejorado continuamente, según las necesidades concretas del usuario y el producto.
  • También existe la opción de externalizar la propia actividad de evaluar la calidad del producto software.
  • Nunca se debe perder de vista el objetivo final, que será alinear los objetivos de negocio con planes de mejora, incrementar la productividad y rentabilidad del desarrollo, aumentar la calidad del software y la satisfacción del usuario, etc.

6. Conclusiones

En el desarrollo software actual, la medición es una pieza básica a la hora de controlar la calidad del producto, más aún si el desarrollo es realizado por equipos externos, donde el receptor del software debe establecer sus propios sistemas de control de la calidad. Es en este punto donde surge nuestro proyecto KEMIS, como una solución para aquellas empresas que desean realizar una medición de la calidad de sus productos software, especialmente aquellas que han externalizado el desarrollo de dichos productos y necesitan un análisis de calidad automatizado, planificable e intuitivo.

Referencias

  • Briand, L., S. Morasca, et al. (1999). “Defining and Validating Measures for Object-Based high-level design.” IEEE Transactions on Software Engineering25(5): 722-743.
  • Chrissis, M. B., M. Konrad, et al. (2003). CMMI: Guidelines for Process Integration and Product Improvement, Addison Wesley Professional.
  • Fenton, N. and S. Pfleeger (1997). Software Metrics: A Rigorous Approach. Londres, Chapman & Hall.
  • Fowler, M. (1999). Refactoring. Improving the Design of Existing Code, Addison-Wesley.
  • Giles, A. E. and G. T. Daich (1995). “Universal MetricsTools.” CrossTalk(February).
  • ISO/IEC (2002). “ISO/IEC 15939 International Standard Software engineering – Software measurement process.”
  • Kitchenham, B. A., S. L. Pfleeger, et al. (2002). “Preliminary Guidelines for Empirical Research in Software Engineering.” IEEE Transactions on Software Engineering28(8): 721-734.
  • Lavazza, L. (2000). “Providing Automated Support for the GQM Measurement Process.” IEEE Software17(3).
  • Pérez, J. (2005). “Integración Continua utilizando herramientas OpenSource.” Agile-spain, from http://javahispano.net/frs/download.php/126/PonenciaIntegracionContinua_AgileSpain.pdf.
  • Wong, B., B. Boehm, et al. (2004). Second Workshop on Software Quality. 26th international conference on Software engineering, St. Louis, MO, USA, ACM Press
  • Wong, B., J. Verner, et al. (2005). Third Workshop on Software Quality. 27th international conference on Software engineering, St. Louis, MO, USA, ACM Press