Un mtodo para la definicin de mtricas de

software
Manuel Serrano, Mario Piattini, Coral Calero, Marcela Genero, David Miranda
Grupo ALARCOS
Universidad de Castilla La Mancha
{manuel.serrano, marcela.genero, mario.piattini, coral.calero, david.miranda}@uclm.es
Resumen
Existe un gran nmero de medidas para capturar atributos de los procesos y
productos software. Tradicionalmente estas medidas se han realizado
confiando en la sabidura de los expertos, y si bien esta experiencia es
importante, puede no ser suficiente. En la actualidad muchas de las mtricas
propuestas han fracasado, debido generalmente a que carecan de atributos
necesarios para ser vlidas y tiles para el propsito para el que fueron
creadas. La creacin de una mtrica debe seguir un proceso metodolgico
que permita obtener mtricas adecuadas a nuestros propsitos. En el presente
trabajo se presenta un mtodo de creacin de mtricas de software compuesto
por cinco etapas principales y que intenta integrar todos los aspectos que
deben tenerse en cuenta en el proceso y que pretende evitar los problemas
asociados a la creacin de las mtricas.
Palabras Clave: Mtodos de Creacin de Mtricas Software, Mtricas
Software.

1 Introduccin
Existe un gran nmero de medidas para capturar atributos de los procesos y
productos software. Tradicionalmente estas medidas se han realizado confiando en
la sabidura de los expertos, y si bien esta experiencia es importante, puede no ser
suficiente. Esta situacin ha conducido frecuentemente a cierto grado de
imprecisin en las definiciones, propiedades y suposiciones de las medidas,
haciendo que el uso de las mtricas sea difcil, la interpretacin peligrosa y los
resultados de varios estudios de validacin contradictorios.
En la actualidad muchas de las mtricas propuestas han fracasado, debido
generalmente a que carecan de atributos necesarios para ser vlidas y tiles para el
propsito para el que fueron creadas. La creacin de una mtrica debe seguir un
proceso metodolgico que permita obtener mtricas adecuadas a nuestros
propsitos.
Desde los aos setenta han aparecido un gran nmero de medidas para capturar
atributos del software de una forma cuantitativa. Sin embargo, muy pocas han
sobrevivido con xito la fase de definicin y han resultado tiles. Esto se debe a
mltiples problemas relativos a la validez terica y emprica de muchas medidas,
algunos los cuales se detallan a continuacin [5]:

Las medidas no se definen siempre en un contexto en el que sea explcito y

est bien definido su objetivo de inters. Por ejemplo: la reduccin del
esfuerzo de desarrollo o la reduccin de los fallos presentes en los
productos software.

Incluso si el objetivo es explcito, las hiptesis experimentales, a menudo

no se hacen explcitas, por ejemplo. qu se pretende deducir del anlisis?
Es creble el resultado?

Las definiciones de medidas no siempre tienen en cuenta el entorno o

contexto en el que sern aplicadas, por ejemplo Se puede utilizar una
medida definida para un entorno no orientado a objetos en un contexto
orientado a objetos?

No siempre es posible realizar una validacin terica adecuada de la

medida porque el atributo que queremos medir no siempre est bien
definido, por ejemplo, la nocin de complejidad.

Un gran nmero de medidas nunca se han validado empricamente, por

ejemplo, cmo saber que medida de tamao predice mejor el esfuerzo en
un entorno de desarrollo?

En [6] se afirma que las mtricas son un buen medio para entender, monitorizar,
controlar, predecir y probar el desarrollo software y los proyectos de
mantenimiento. Adems tal y como seal Pfleeger [12] las mtricas pueden ser
utilizadas por que los profesionales e investigadores para tomar las mejores
decisiones. Es evidente que si queremos alcanzar todos estos objetivos debemos
evitar, en la medida de lo posible, todos los problemas sealados.
Este artculo presenta un mtodo de trabajo para definir mtricas software de una
manera estructurada, y vlidas tericamente y tiles en la prctica. En la siguiente
seccin se introduce el mtodo de trabajo a nivel general, mientras que una
descripcin detallada de cada una de las etapas se expone en la seccin 3. En el
ltimo apartado se exponen las conclusiones.

2 Mtodo de trabajo
La definicin de las mtricas debe basarse en objetivos de medida claros y
siguiendo las necesidades de la organizacin. Aunque en la literatura relativa a las
mtricas software se comenta la necesidad de la validacin, no existen propuestas
que integren todos los aspectos que es necesario tener en cuenta en dicha
validacin. Teniendo en cuenta todas las consideraciones expuestas, en la figura 1
se propone un proceso de definicin de mtricas, de manera que se puedan
conseguir mtricas vlidas y tiles para productos software. Este proceso est
basado en el mtodo utilizado por Calero et al. [7] y el mtodo MMLC (Measure
Model Life Cycle) [8].

En la figura 1 se puede observar que el mtodo propuesto, consta de diversas fases

que van desde la identificacin de los objetivos y las hiptesis de trabajo hasta la
aplicacin y posterior retirada de una mtrica. En dicha figura, las flechas
continuas representan el flujo de las mtricas y las discontinuas representan el flujo
de informacin a lo largo de todo el proceso. Este proceso consta de cinco etapas
principales:

Identificacin: Se definen los objetivos que se persiguen a la hora de crear

la mtrica y se plantean las hiptesis de cmo se llevar a cabo la
medicin. Sobre los elementos de esta etapa (objetivos e hiptesis) se
basarn todas las etapas siguientes. Como resultado de esta etapa se
generan los requisitos que debe cumplir la mtrica.

Creacin: Se realiza la definicin de la mtrica y su validacin terica y

emprica. Esta etapa es una de las ms importantes y larga pues como
abarca un proceso iterativo del que debe salir una mtrica vlida tanto
formal como empricamente.

Aceptacin: Una vez obtenida una mtrica vlida, suele ser necesario
pasar por una etapa de aceptacin de la mtrica en la que se harn pruebas
en entornos reales, de manera que podamos comprobar si la mtrica
cumple los objetivos deseados dentro del campo de aplicacin real.

Aplicacin: Una vez que tengamos una mtrica aceptada, la utilizaremos

dentro del campo de la aplicacin para la que fue diseada.

Acreditacin: Es la ltima etapa del proceso, que discurre en paralelo con

la fase de aplicacin y tiene como objetivo el mantenimiento de la mtrica,
de manera que se pueda adaptarla al entorno cambiante de aplicacin.
Como consecuencia de esta etapa, puede que una mtrica sea retirada,
porque ya no sea til en el entorno en el que se aplica o que se reutilizada
para iniciar el proceso de nuevo.

3 Etapas del mtodo

A continuacin se detallan las etapas que componen el mtodo propuesto.

3.1 Identificacin
En esta etapa se pretende identificar los objetivos de la medida y las hiptesis en
las que nos basamos para crear las mtricas. Los objetivos indican lo que se
pretende conseguir con la utilizacin del proceso de medida y representan la razn
por la que se llevar el proceso de medida (el porqu). Las hiptesis son la forma
en la que se pretende llevar a cabo la medida (el cmo), identificando la
informacin que se debe manejar para conseguir alcanzar los objetivos deseados.
Este proceso suele estar basado en la experiencia y el conocimiento de los expertos
y puede utilizar mecanismos basados en GQM (Goal-Question-Metric) [2][3][17].

Mtrica Retirada
Reutilizacin

IDENTIFICACIN
OBJETIVOS

HIPTESIS

ACREDITACIN
Objetivos

Requisitos

Realimentacin

CREACIN
Objetivos

DEFINICIN DE MTRICAS

APLICACIN

Mtricas Aceptadas
Mtricas No
Aceptadas

ACEPTACIN

VALIDACIN EMPRICA
VALIDACIN
TERICA

EXPERIMENTOS

CASOS DE
ESTUDIO

ENCUESTAS

EXPLICACIN PSICOLGICA

Mtricas Vlidas

Figura 1.- Mtodo de Investigacin

Como resultado de esta fase se deben obtener los requisitos que debe cumplir la
mtrica, los cuales sern utilizados en la etapa de creacin. Adems, como se
observa en la figura, los objetivos sern utilizados en las etapas de aceptacin,
aplicacin y acreditacin.

3.2 Creacin
El proceso de creacin es aquel en el que a partir de los requisitos obtenidos en la
etapa de identificacin se crear una mtrica vlida, lista para ser aplicada en
entornos reales. Como se puede observar en la figura 1, el proceso de creacin de
las mtricas es evolutivo e iterativo y se subdivide en varias etapas intermedias.
Como resultado de la retroalimentacin, las mtricas deben ser redefinidas de
acuerdo a las validaciones, tericas o empricas, fallidas.
Al final de la etapa de creacin, las mtricas se considerarn vlidas y aquellas que
no sean vlidas, sern descartadas.
3.2.1. Definicin

Es el primer paso de esta fase que debe realizarse considerando las caractersticas
del producto que vamos a medir y la experiencia de los profesionales. Es

recomendable conseguir esta definicin de una forma metodolgica, aplicando, por

ejemplo, la aproximacin GQM [3][15] en el que se puede definir el propsito de
la mtrica que se define, el punto de vista del usuario y el contexto de uso. En la
definicin se deben considerar objetivos claros, es decir, realizar una definicin de
la mtrica orientada al objetivo para evitar obtener una definicin de la mtrica que
no cumple con el objetivo deseado. Es deseable que la definicin de las mtricas se
realice de manera formal para evitar ambigedades.
3.2.2. Validacin terica

El objetivo principal de la validacin terica es comprobar si la idea intuitiva

acerca del atributo que est siendo medido se refleja en la medida. Esto se hace
analizando los requisitos que deben ser satisfechos cuando estamos midiendo.
Adems la validacin terica proporciona informacin relacionada con las
operaciones matemticas y estadsticas que pueden ser realizadas con la mtrica, lo
cual es esencial cuando tengamos que trabajar con ella.
Lamentablemente no existe un estndar para la validacin formal a travs del cual
obtener la informacin matemtica de las mtricas definidas, sin embargo, hay dos
tendencias principales en la validacin: los marcos basados en aproximaciones
axiomticas (que definen formalmente propiedades deseables de las medidas para
un atributo software concreto) [18][6] y los que se basan en la teora de la medida
[19][22][14], cuyo objetivo es obtener la escala matemtica a la que pertenece una
mtrica, y por tanto sus transformaciones admisibles, estadsticos y tests aplicables
y especifican un marco general en el que las medidas deben ser definidas.
3.2.3. Validacin emprica

El objetivo de esta etapa es probar la utilidad prctica de las mtricas propuestas.

El saber general, la intuicin o la especulacin, no son fuentes fiables de
conocimiento [4] por lo que es necesario realizar validaciones empricas con las
mtricas.
La validacin emprica se utiliza para obtener informacin objetiva sobre la
utilidad de las mtricas propuestas ya que puede que una mtrica sea correcta desde
un punto de vista formal, pero no tener relevancia prctica para un problema
determinado.
As pues, el estudio emprico resulta necesario para comprobar y entender las
implicaciones de las medidas de nuestros productos. Esto se consigue a travs de
hiptesis en el mundo real, mas all de la pura teora, que habr que comprobar con
datos empricos.
Kish [10] divide las investigaciones empricas en tres clases principales:
experimentos, encuestas y simples investigaciones. Experimentos son las

investigaciones en las que las posibles variables perturbadoras han sido

aleatorizadas. Encuestas son investigaciones en las que los sujetos del estudio son
una muestra representativa de la poblacin a la que pertenecen. Investigaciones
simples son aquellas en las que no hay aleatoriedad de variables perturbadoras ni
representatividad de los sujetos que componen la muestra de estudio. El primer tipo
corresponde con el mtodo experimental (experimentos en nuestro mtodo)
mientras que los otros dos se enmarcan dentro del mtodo correlacional (casos de
estudio en nuestro mtodo).
As pues, la forma de saber si debemos desarrollar un caso de estudio o un
experimento, depender del grado de control que tengamos sobre las variables. Si
tenemos un alto grado de control sobre las variables que pueden afectar a las
hiptesis, estaremos en condiciones de realizar un experimento mientras que si, por
el contrario, no va a ser posible controlar muchas de las variables afectadas, ser
mejor realizar un caso de estudio. Otro de los factores que nos permitirn elegir
entre ambas alternativas ser el grado en el que la experimentacin podr ser
realizada. Si la rplica es fcil de llevar a cabo tendremos un experimento mientras
que si esta es bastante difcil de conseguir tendremos un caso de estudio. En la
tabla 1 se presentan estos conceptos [11].
Tabla 1. Factores para seleccionar la tcnica de experimentacin
Factor

Experimentos

Casos de estudio

Nivel de control

Alto

Bajo

Dificultad de controlar

Baja

Alta

Nivel de rplica

Alto

Bajo

Coste de replicar

Bajo

Alto

Experimentos

Los experimentos se utilizan cuando tenemos el control de la situacin y queremos

controlar su comportamiento directa, precisa y sistemticamente. Un experimento
puede ser llevado a cabo, por ejemplo, en un laboratorio bajo condiciones
controladas, donde los eventos estn organizados para simular su aparicin en el
mundo real. El objetivo es manipular una o ms variables y mantener las otras
variables a niveles fijos. Un experimento es un examen formal, riguroso y
controlado, en el que se identifican y manipulan los factores claves.
Las ventaja de un experimento es que puede determinar en que situaciones ciertas
afirmaciones son ciertas y puede proporcionar el contexto en el que ciertos
estndares, mtodos y herramientas son recomendables. Slo si el experimento se
realiza adecuadamente, seremos capaces de sacar conclusiones acerca de las
relaciones entre la causa y el efecto para la cual formulamos la hiptesis [20]. Los

experimentos necesitan ser planeados cuidadosamente y realizar una buena

planificacin si queremos que nos proporcionen resultados tiles y significativos
[9].
Es importante, adems, realizar rplicas de los experimentos porque con los
resultados de un nico experimento es difcil apreciar si los resultados son
generalizables y poder as concluir que sus resultados son vlidos.
Casos de estudio

Los casos de estudio se utilizan para monitorizar proyectos, actividades o

asignaciones. Los datos son recogidos para un propsito especfico del estudio. El
caso de estudio est orientado normalmente a analizar un determinado atributo o
establecer relaciones entre diferentes atributos. El nivel de control de un caso de
estudio es ms bajo que en un experimento. Los casos de estudios son estudios
observacionales (es decir, se llevan a cabo mediante la observacin de un proyecto
o actividad que est en marcha) mientras que los experimentos son estudios
controlados [21].
Encuestas

Una encuesta es, a menudo, un mtodo de investigacin que se realiza de forma

retrospectiva, cuando por ejemplo, una herramienta o tcnica ha estado usndose
durante un periodo de tiempo [11]. Las principales formas de recolectar los datos
cualitativos o cuantitativos con las entrevistas y los cuestionarios. Estos se
completan tomando muestras que sean representativas de la poblacin que se
quiere estudiar. Los resultados de una encuesta son despus analizados de manera
que podamos derivar conclusiones descriptivas o explicativas. Las encuestas son
muy comunes en las ciencias sociales. No proporcionan control sobre la ejecucin
de la medida y aunque es posible compararlas a otras parecidas no es posible
manipular las variables.
Las encuestas tienen la habilidad de proporcionar una gran cantidad de variables a
evaluar, pero es necesario que nuestro objetivo est en obtener la mayor
informacin posible de la menor cantidad de variables, ya que la reduccin
simplifica la tarea del anlisis.
La definicin de una encuesta debe hacerse de una forma metodolgica y
controlando una serie de parmetros para conseguir obtener informacin fiable de
la encuesta [13].
3.2.4. Explicacin psicolgica

Idealmente deberamos ser capaces de explicar la influencia de los valores de las

mtricas des de un punto de vista psicolgico. Algunos autores, como Siau [16],
proponen el uso de la psicologa cognitiva como una disciplina de referencia. De

esta manera, las teoras como ACT (Adaptative Control of Thought) [1] pueden
justificar la influencia de ciertas mtricas en la comprensin de los sistemas.

3.3 Aceptacin
Suele ser necesaria la existencia de una fase de pruebas en laboratorio en la que se
realice una experimentacin sistemtica en entornos reales y con usuarios reales
para verificar si cumple los objetivos buscados dentro de un entorno de trabajo real
(Esta etapa se diferencia de los casos de estudio en que en stos ltimos no se suele
trabajar en el entorno final de aplicacin). En definitiva intenta encontrar si las
mtricas vlidas que se consiguieron al final de la fase de creacin son
aceptables en entornos de aplicacin reales, teniendo en cuenta los objetivos
obtenidos en la etapa de identificacin.
Esta etapa debe ser realizada con proyectos no crticos y con riesgos controlados.
Idealmente debera usarse en proyectos piloto de manera que el fracaso de
aceptacin de la mtrica no suponga un fracaso en un proyecto importante.
Si conseguimos demostrar que la mtrica sigue cumpliendo los objetivos,
estaremos en disposicin de pasar a la etapa de aplicacin, si no es as, deberemos
volver a la etapa de creacin.

3.4 Aplicacin
En esta etapa utilizaremos la mtrica ya aceptada en el entorno real. Esta fase
discurrir en paralelo con la fase de acreditacin.

3.5 Acreditacin
Esta ltima fase del proceso es una etapa dinmica que persigue el aseguramiento
de la mtrica y la mejora continua de la misma, en funcin de cmo evoluciona el
entorno de aplicacin, de manera que podamos seguir cumpliendo los objetivos que
se perseguan al principio del mtodo.
En ocasiones el entorno puede variar tanto (por ejemplo, pasar de un entorno
estructurado a uno orientado a objeto) que la mtrica no sea aplicable, en este caso,
la mtrica debera ser descartada y el conocimiento adquirido durante su tiempo de
vida debera realimentarse a la etapa de identificacin de manera que podamos
crear una mtrica adecuada para el nuevo entorno cumpliendo los objetivos
perseguidos. Adems al utilizar la experiencia de la utilizacin de la mtrica
descartada, tendremos ms probabilidades de formular hiptesis correctas en la
etapa de identificacin.

4 Conclusiones
La medida en la ingeniera del software es un elemento crucial que ayuda de gran
manera en la mayora de las etapas del ciclo de vida de un producto software.
ltimamente estn apareciendo una gran cantidad de mtricas, pero no suelen tener
el xito esperado. Esta falta de xito suele deberse a que slo se basan en el
conocimiento de los expertos en el tema, pero no suelen seguir un mtodo de
creacin adecuado y sistemtico.
En este artculo se ha propuesto un mtodo para la definicin de mtricas vlidas,
que abarca desde la etapa de identificacin de objetivos de medida hasta la etapa de
retirada de la mtrica. En este mtodo se incluyen diversas tcnicas de validacin
tanto terica como emprica, as como casos de prueba en entornos reales, que
pretenden que la mtrica definida sea til y adecuada.
El mtodo propuesto est siendo utilizado en diversos entornos, el ms avanzado
de los cuales se encuentra en la etapa de aceptacin.

Agradecimientos
Esta investigacin es parte del proyecto CALDEA (TIC 2000-0024-P4-02)
financiado por la Subdireccin General de Proyectos de Investigacin, Ministerio
de Ciencia y Tecnologa.

Bibliografa
[1] Anderson, J.R. (1983). The Architecture of Cognition. Cambridge. MA: Harvard
Universitiy Press.
[2] Basili V. y Rombach H. (1988). The TAME project: towards improvement-oriented
software environments. IEEE Transactions on Software Engineering, 14(6), 728-738
[3] Basili V. y Weiss D. (1984). A Methodology for Collecting Valid Software
Engineering Data, IEEE Transactions on Software Engineering, 10, 728-738.
[4] Basili, V.R., Shull, F. y Lanubille, F. (1999). Building Knowledge through families of
experiments. IEEE Transactions on Software Engineering. July/August. No. 4. pp. 456473
[5] Briand L., Arisholm S., Counsell F., Houdek F. and Thvenod-Fosse P. (1999).
Empirical Studies of Object-Oriented Artifacts, Methods, and Processes: State of the
Art and Future Directions. Empirical Software Engineering, 4(4), 387-404.
[6] Briand, L.C., Morasca, S. y Basili, V. (1996). Property-based software engineering
measurement. IEEE Transactions on Software Engineering. 22(1). pp.68-85.
[7] Calero, C., Piattini, M. y Genero, M. (2001). Method for obtaining correct metrics.
Proc. of the 3rd International Conference on Enterprise and Information Systems
(ICEIS`2001), 779-784

[8] Cantone G., y Donzelli P. (2000), Production and maintenance of software

measurement models, Journal of Software Engineering and Knowledge Engineering,
5, pp. 605-626.
[9] Juristo N. y Moreno A. (2001). Basics of Software Engineering Experimentation,
Kluwer Academic Publishers.
[10] Kish, L. (1959). Some statisticals problems in research design. American Sociological
Review. 24. pp.328-338.
[11] Pfleeger, S. (1994-1995). Experimental design and analysis in software engineering
part 1-5, ACM Sigsoft, Software Engineering Notes. 19(4), 16-20; 20(1), 22-26; 20(2),
14-16; 20(3), 13-15; 20(4), 14-17.
[12] Pfleeger, S. L. (1997). Assessing Software Measurement. IEEE Software.
March/April. pp. 25-26.
[13] Pfleeger, S. y Kitchenham, B. (2001). Principles of Survey Research. Part 1: Turning
Lemons into Lemonade. ACM Sigsoft, Software Engineering Notes. 26(6), 16-18
[14] Poels G. y Dedene G. (2000). Distance-based software measurement: necessary and
sufficient properties for software measures. Information and Software Technology,
42(1), 35-46.
[15] Rombach, H.D. (1990) Design measurement: some lessonslerned. IEEE Software. 7(3).
pp. 17-25
[16] Siau, K. (1999). Information Modeling and Method Engineering: A Psychological
Perspective. Journal of Database Management 10 (4). pp. 44-50.
[17] Van Solingen R. and Berghout E. (1999). The Goal/Question/Metric Method: A
practical guide for quality improvement of software development. McGraw-Hill.
[18] Weyuker E. (1988). Evaluating software complexity measures. IEEE Transactions
Software Engineering, 14(9), 1357-1365.
[19] Whitmire S. (1997). Object Oriented Design Measurement. John Wiley & Sons, Inc.
[20] Wohlin C., Runeson P., Hst M., Ohlson M., Regnell B. and Wessln A. (2000)
Experimentation in Software Engineering: An Introduction. Kluwer Academic
Publishers.
[21] Zelkowitz M. and Wallace D. (1998). Experimental models for validating technology.
IEEE Computer, 31(5), 23-31.
[22] Zuse, H. (1998). A Framework of Software Measurement. Berlin. Walter de Gruyter.