2.4.

4 Medición y métricas de software

La medición del software se refiere a derivar un valor numérico para algún atributo de un
producto de software o un proceso del software. Comparando estos valores entre
parámetros que se van a incluir en el modelo y calibrarlos utilizando datos existentes. Un
profesional de la estadística debe involucrarse en el proceso.

2.4.4.1 El proceso de medición

En la figura 24.11 se muestra el proceso de medición del software que es parte de

un proceso de control de calidad. Cada uno de los componentes del sistema se
analiza por separado y los diversos valores de las métricas se comparan entre ellos
y, quizás, con los datos históricos de medición recolectados en los proyectos
previos. Las medidas anómalas se utilizan para centrar el esfuerzo de
aseguramiento de la calidad en los componentes que tienen problemas de calidad.
Los pasos clave en este proceso son:

1. Seleccionar las medidas a realizar Se deben formular las preguntas que la

medición intenta responder y definir las medidas requeridas para resolver estas
preguntas. No se recolectan las mediciones que no son relevantes de forma directa
a estas preguntas. El paradigma GQM (Goal-Question-Metric) de Basili (Basili y
Rombach, 1988), que se discute en el siguiente capítulo, es un buen enfoque a
utilizar cuando se decide qué datos recolectar.

2. Seleccionar los componentes a evaluar No es necesario o deseable estimar los

valores de las métricas de todos los componentes de un sistema de software. En
algunos casos, para la medición se elige un conjunto representativo de
componentes. En otros, se evalúan los componentes particularmente críticos como
los fundamentales que se utilizan de forma constante.

3. Medir las características de los componentes Se miden los componentes

seleccionados y se calculan los valores de las métricas. Normalmente, esto
comprende procesar la representación del componente (diseño, código, etcétera)
utilizando una herramienta de recolección de datos. Esta herramienta se puede
crear de forma especial o puede estar incorporada en las herramientas CASE
utilizadas en una organización.

4. Identificar las mediciones anómalas Una vez que se obtienen las mediciones de
los componentes, se comparan entre ellas y con las mediciones previas registradas
en una base de datos de mediciones. Se deben observar los valores más altos y
más bajos de cada métrica puesto que éstos sugieren que puede haber problemas
con los componentes que exhiben estos valores.

5. Analizar los componentes anómalos Una vez identificados los componentes con
valores anómalos para las métricas particulares, se examinan estos componentes
para decidir silos valores de la métrica indican que la calidad del componente está
en peligro o no. Los valores de la métrica anómalos para la complejidad (por
ejemplo) no necesariamente significan que el componente tenga calidad
deficiente. Puede existir alguna otra razón para el valor alto y no significa que
existan problemas con la calidad del componente.
Los datos recolectados se mantienen como un recurso organizacional, de igual
forma los registros históricos de todos los proyectos deben conservarse aun
cuando los datos no se hayan utilizado durante un proyecto particular. Una vez
que se haya creado una base de datos suficientemente grande de mediciones, se
hace la comparación con los proyectos y las métricas específicas se refinan de
acuerdo con las necesidades organizacionales.

2.4.4.2 Métricas del producto

Las métricas del producto se refieren a las características del software mismo.
Desafortunadamente, las características del software que se miden fácilmente —
como el tamaño y la complejidad ciclomática, los atributos de calidad como la
comprensión y la mantenibilidad— no tienen una relación clara y universal. Las
relaciones varían dependiendo de los procesos y la tecnología de desarrollo y el
tipo de sistemas a desarrollar. Las organizaciones interesadas en la medición
tienen que construir una base de datos histórica. Después, esto se puede utilizar
para descubrir cómo se relacionan los atributos del producto de software con la
calidad en la que está interesada la organización.
Las métricas del producto se dividen en dos clases:

1. Las métricas dinámicas recolectadas por las mediciones hechas en un programa

en ejecución.
2. Las métricas estáticas recolectadas por las mediciones hechas en las
representaciones del sistema como el diseño, el programa o la documentación.

Estas diferentes métricas están relacionadas con diversos atributos de calidad. Las
métricas dinámicas ayudan a valorar la eficiencia y la fiabilidad de un programa
mientras que las métricas estáticas ayudan a valorar la complejidad, la
comprensión y la mantenibilidad de un sistema de software.

Las métricas dinámicas por lo general están relacionadas de forma cercana con los
atributos de calidad del software. Es relativamente fácil medir el tiempo de
ejecución requerido por funciones particulares y estimar el tiempo requerido para
iniciar un sistema. Esto se relaciona directamente con la eficiencia del sistema. De
forma similar, se puede registrar el número y el tipo de caídas del sistema y
relacionarlos directamente la fiabilidad del software, discutida en el capítulo 16.

Métricas de software

Fan-in/Fan-out
Fan-in es una medida del número de funciones que llaman a otra función (por
ejemplo, X). Fan-out es el número de funciones que son llamadas por una función
X. Un valor alto de fan-in significa que X está fuertemente acoplada al resto del
diseño y que los cambios en X tendrán efectos extensivos contundentes. Un valor
alto de fan-out sugiere que la complejidad de X podría ser alta debido a la
complejidad de la lógica de control necesaria para coordinar los componentes
llamados.
Longitud del código
Ésta es una medida del tamaño del programa. Generalmente entre más grande sea
el tamaño del código de un componente del programa, más complejo y susceptible
a errores será el componente.

Complejidad ciclomática
Ésta es una medida de la complejidad del control de un ciclomática programa. Esta
complejidad del control está relacionada con la comprensión del programa. El
cálculo de la complejidad ciclomática se cubre en el capítulo 20.

Longitud de los identificadores

Es una medida de la longitud promedio de los diferentes identificadores en un
programa. Entre más grande sea la longitud de los identificadores, es más probable
que tengan significado y, por lo tanto, el programa será más comprensible.

Profundidad de la condicional anidada

Ésta es una medida de la profundidad de anidamiento de las instrucciones if en un
programa. Instrucciones ji profundamente anidadas son difíciles de comprender y
son potencialmente susceptibles a errores.

Indice de Fog

Ésta es una medida de la longitud promedio de las palabras y declaraciones en los

documentos. Entre más grande sea el valor del indice de Fog, el documento será
más difícil de comprender.

Las métricas estáticas, por otro lado, tienen una relación indirecta con los atributos
de calidad. Se han propuesto varias de estas métricas y se han llevado a cabo
experimentos para tratar de derivar y validar las relaciones entre estas métricas y
la complejidad, la comprensión y la mantenibilidad del sistema. La figura 24.12
describe varias métricas estáticas utilizadas para valorar los atributos de calidad.
De éstas, parece ser que los predictores más confiables de la comprensión, la
complejidad y mantenibilidad del sistema son la longitud del programa o del
componente y la complejidad del control.
Desde principios de los 90, han habido varios estudios sobre métricas orientadas a
objetos. Algunas de éstas se derivaron de métricas anteriores, mostradas en la
figura 24.12, pero otras son específicas de los sistemas orientados a objetos. Varias
de las métricas orientadas a objetos se explican en la figura 24.13. Estas métricas
son menos maduras que las de la figura 24.12, las cuales est&i relacionadas con los
diseños orientados a funciones, por lo que su utilidad como métricas indicadoras
aún está en proceso de establecimiento.

Métricas orientadas a objeto

Profundidad del árbol de herencia

Ésta representa el número de niveles discretos en el árbol del árbol de de herencia
donde las subclases heredan atributos y opera- herencia ciones (métodos) de las
superclases. Entre más profundo sea el árbol de herencia, más complejo será el
diseño puesto que muchas clases de objetos potencialmente distintas tienen que
comprenderse para conocer las clases de objetos en las hojas del árbol.

Método fan-in/fan-out
Está directamente relacionada a fan-in y a fan-out, como se fan-in/fan-out
describió antes, y significa esencialmente lo mismo. Sin embargo, es cónveniente
hacer una distinción entre las llamadas provenientes de otros métodos dentro del
objeto y las llamadas provenientes de los métodos externos.

Métodos pesados por clase

Éste es el número de métodos incluidos en una clase con peso dado por la
complejidad de cada método. Por lo tanto, un método sencillo tiene tina
complejidad de 1 y un método grande y complejo un valor mucho más grande.
Entre más grande sea el valor de esta métrica, la clase será más compleja. Los
objetos complejos tienden a ser más difíciles de comprender. No son lógicamente
cohesivos por lo que no se pueden reutitizar efectivamente como superclases en
un árbol de herenda.

Número de operaciones anuladas

Éste es el número de operaciones en una superclase que operaciones se anulan en
una subclase. Un valor alto para esta métrica anulada indica que la superclase
utilizada no es una madre adecuada para la subclase.

Las métricas específicas relevantes dependen del proyecto, de las metas del
equipo d administración de la calidad y del tipo de software a desarrollar. Todas las
métricas mostradas en las figuras 24.12 y 24.13 son útiles en algunas situaciones.
Sin embargo, existen otras situaciones donde no son apropiadas. Cuando se
introduce una medida de software como parte del proceso de administración de la
calidad, las organizaciones deben hace experimentos para descubrir la métricas
más apropiadas a sus necesidades.

2.4.4.3 Análisis de Las mediciones

Uno de los problemas con la recolección de datos cuantitativos en el software y en

le proyectos de software es comprender lo que significan realmente los datos. Es
fácil malinterpretar los ciatos y hacer inferencias incorrectas. Las mediciones se
deben analizar cuidadosamente para comprender lo que realmente significan.
Para ilustrar la manera en que los datos recolectados se pueden interpretar de
formas diferentes considere el siguiente escenario:

Un administrador decide supervisar el número de peticiones de cambios solicitad

por los clientes basándose en la suposición de que existe una relación entre estas
peticiones de cambio y la utilidad y conveniencia del producto. Entre más grande
es el número de peticiones de cambios, el software cumple menos las necesidades
del usuario.
Procesar las peticiones de cambios y cambiar el software es costoso. Por lo tanto,
la organización decide modificar su proceso para incrementar la satisfacción del
cliente y, al mismo tiempo, reducir los costos del cambio. Se pretende que los
cambios en el proceso conduzcan a mejores productos y menos peticiones de
cambios.

Los cambios en el proceso dan inicio lo que involucra más al cliente en el proceso
de diseño de software. Se introducen las pruebas beta para todos los productos y
las modificaciones solicitadas por los clientes se incorporan en el producto a
entregar. Las nuevas versiones de los productos, desarrolladas con este proceso
modificado, se entregan. En algunos casos, el número de peticiones de cambios se
reduce; en otros, se incrementa. El administrador se queda perplejo y no puede
valorar los efectos de los cambios del proceso en la calidad del producto.

Para comprender por qué pasan esta clase de cosas, se tiene que comprender por
qué se hacen las peticiones de cambio. Una razón es que el software entregado no
haga lo que los clientes quieren que haga. Otra posibilidad es que el software sea
muy bueno y se utilice amplia y frecuentemente, algunas veces para propósitos
para los que no se diseñó originalmente. Puesto que existen muchas personas
utilizándolo, es natural que se generen más peticiones de cambios.

Una tercera posibilidad es que la compañía productora del software sea sensible a
las peticiones de cambio de los clientes. Por lo tanto, los clientes se sienten
satisfechos con el servicio que reciben. Generan muchas peticiones de cambios
debido a que conocen que esas peticiones se considerarán seriamente. Sus
sugerencias probablemente se incorporarán en las versiones posteriores del
software.
El número de peticiones de cambios podría decrecer debido a que los cambios en
el proceso han sido efectivos y lo han hecho más utilizable y conveniente. De
forma alternativa, el número podría haber decrecido debido a que el producto ha
perdido mercado con respecto a su producto rival. En consecuencia, existen menos
usuarios del producto. El número de peticiones de cambios podría incrementarse
debido a que existen más usuarios, debido a que los procesos de pruebas beta han
convencido a los usuarios de que la compañía desea hacer cambios o debido a que
los sitios de pruebas beta no son típicos o no se utilizan mucho en el programa.

Para analizar los datos que requieren cambios, simplemente no se necesita

conocer el número de peticiones de cambios. Es necesario conocer quién hizo la
petición, cómo utiliza el software y por qué hizo la petición. Es necesario saber si
existen factores externos, como las modificaciones al procedimiento de petición de
cambios o cambios en el mercado, que podrían tener algún efecto. Con esta
información, es posible descubrir si los cambios del proceso han sido efectivos
para incrementar la calidad del producto.

Esto ilustra que la interpretación de datos cuantitativos de un producto o proceso

es un proceso incierto. Los procesos y productos a ser medidos no están aislados
de su entorno y los cambios a ese entorno invalidan las comparaciones de los
datos. Los datos cuantitativos de las actividades humanas no siempre pueden
tomarse como valores de entrada. Las razones subyacentes detrás del valor
medido deben investigarse.