Las métricas de software serán útiles solo si se caracterizan efectivamente y si se validan de

manera adecuada. Los siguientes principios son representativos de muchos que pueden

proponerse para la caracterización y validación de métricas:

• Una métrica debe tener propiedades matemáticas deseables, es decir, el valor de la métrica

debe estar en un rango significativo (por ejemplo, 0 a 1, donde 0 realmente significa ausencia, 1

indica el valor máximo y 0.5 representa el “punto medio”). Además, una métrica que intente

estar en una escala racional no debe constituirse con componentes que solo se miden en una

escala ordinal.

• Cuando una métrica representa una característica de software que aumenta cuando ocurren

rasgos positivos o que disminuye cuando se encuentran rasgos indeseables, el valor de la métrica

debe aumentar o disminuir en la misma forma.

• Cada métrica debe validarse de manera empírica en una gran variedad de contextos antes de

publicarse o utilizarse para tomar decisiones. Una métrica debe medir el factor de interés,

independientemente de otros factores. Debe “escalar” a sistemas más grandes y funcionar en

varios lenguajes de programación y dominios de sistema.

Aunque la formulación, caracterización y validación son cruciales, la recolección y el análisis

son las actividades que impulsan el proceso de medición. Roche sugiere los siguientes principios

para dichas actividades: 1) siempre que sea posible, la recolección y el análisis de datos deben

automatizarse; 2) deben aplicarse técnicas estadísticas válidas para establecer relaciones entre

atributos de producto internos y características de calidad externas (por ejemplo, si el nivel de

complejidad arquitectónica se correlaciona con el número de defectos reportados en el uso de

producción), y 3) para cada métrica deben establecerse lineamientos y recomendaciones

interpretativos.

Estas métricas atienden varios aspectos del modelo de análisis e incluyen:

Funcionalidad entregada

Tamaño del sistema

Calidad de la especificación

Estas métricas cuantifican los atributos del modelo de diseño de manera que le permite
al ingeniero de software evaluar la calidad del diseño, la cual incluye:

Métricas arquitectónicas

Métricas al nivel de componente

Métricas de diseño de la interfaz

Métricas especializadas en diseño orientada a objetos

 Estas métricas miden el código fuente y se utiliza para evaluar su complejidad,
además de la facilidad con que se mantiene y entre otras características:

Métricas de Halstead

Métricas de complejidad

Métricas de longitud

Tipos de Métricas y su aplicación

MÉTRICAS PARA EL MODELO DE ANÁLISIS

En esta etapa se derivan los requerimientos y se establece un cimiento para el diseno. Por

tanto, son deseables metricas de producto que proporcionen comprension acerca de la calidad del

modelo de analisis. Aunque en la literatura han aparecido relativamente pocas metricas de

analisis y especificacion, es posible adaptar las metricas que se usan frecuentemente para

estimacion de proyectos y aplicarlas en este contexto. Dichas metricas examinan el modelo de

requerimientos con la intencion de predecir el “tamano” del sistema resultante. En ocasiones

(mas no siempre), el tamano es un indicador de la complejidad del diseno y casi siempre es un

indicador creciente de codificacion, integracion y esfuerzo de pruebas.

Métrica basada en funciones: Puede usarse de manera efectiva como medio para medir la

funcionalidad que entra a un sistema.4 Al usar datos historicos, la metrica PF puede entonces

usarse para: 1) estimar el costo o esfuerzo requerido para disenar, codificar y probar el software;

4 Acerca de las metricas PF se han escrito cientos de libros, ensayos y articulos. En [IFP05]

puede encontrar una valiosa bibliografia.

 Los puntos de funcion se derivan usando una relacion empirica basada en medidas contables

(directas) del dominio de informacion del software y en valoraciones cualitativas de la

complejidad del software. Los valores de dominio de informacion se definen en la forma

siguiente:

 Número de entradas externas (EE). Cada entrada externa se origina de un usuario o se

transmite desde otra aplicacion, y proporciona distintos datos orientados a aplicacion o

informacion de control. Con frecuencia, las entradas se usan para actualizar archivos

lógicos internos (ALI). Las entradas deben distinguirse de las consultas, que se

cuentan por separado.

 Número de salidas externas (SE). Cada salida externa es datos derivados dentro de la

aplicacion que ofrecen informacion al usuario. En este contexto, salida externa se

refiere a reportes, pantallas, mensajes de error, etc. Los items de datos individuales

dentro de un reporte no se cuentan por separado.

 Número de consultas externas (CE). Una consulta externa se define como una entrada

en linea que da como resultado la generacion de alguna respuesta de software

inmediata en la forma de una salida en linea (con frecuencia recuperada de un ALI).

 Número de archivos lógicos internos (ALI). Cada archivo lógico interno es un

agrupamiento logico de datos que reside dentro de la frontera de la aplicacion y se

mantiene mediante entradas externas.

 Número de archivos de interfaz externos (AIE). Cada archivo de interfaz externo es un

agrupamiento logico de datos que reside fuera de la aplicacion, pero que proporciona

información que puede usar la aplicacion.

 Métricas para calidad de la especificación: Proponen una lista de caracteristicas que pueden

usarse para valorar la calidad del modelo de requerimientos y la correspondiente especificacion

de requerimientos: especificidad (falta de ambiguedad), completitud, corrección,

comprensibilidad, verificabilidad, consistencia interna y externa, factibilidad, concisión,

rastreabilidad, modificabilidad, precisión y

reusabilidad. Ademas, los autores observan que las especificaciones de alta calidad se

almacenan electronicamente, son ejecutables o al menos interpretables, se anotan mediante

importancia relativa, son estables, tienen version, se organizan, cuentan con referencia cruzada y

se especifican en el nivel correcto de detalle.

MÉTRICAS PARA EL MODELO DE DISEÑO:

Es inconcebible que el diseno de una nueva aeronave, un nuevo chip de computadora o un

nuevo edificio de oficinas se realizara sin definir medidas de diseno, ni determinar las métricas

para varios aspectos de la calidad del diseno ni usarlos como indicadores para guiar la forma en

la que evoluciona el diseno. Y aun asi, con frecuencia el diseno de los sistemas complejos

basados en software procede virtualmente sin medicion. La ironia de esto es que estan

disponibles metricas del diseno para el software, pero la gran mayoria de los ingenieros del

software continúan sin percatarse de su existencia. Las metricas de diseno para software de

computadora, al igual que todas las demas métricas de software, no son perfectas. El debate

continua acerca de su eficacia y sobre la forma en la que deben aplicarse. Muchos expertos

argumentan que se requiere mas experimentacion antes de poder usar las medidas de diseno,

aunque el diseno sin medicion es una alternativa inaceptable. En las siguientes secciones se

examinan algunas de las metricas de diseno mas comunes para software de computadora. Cada
una puede proporcionarle comprension mejorada y todas pueden ayudar a que el diseno

evolucione hacia un mayor nivel de calidad.

Métricas del diseño arquitectónico:

Métricas para diseño orientado a objetos: Hay mucho de subjetivo en el diseno orientado a

objetos: un disenador experimentado “sabe” como caracterizar un sistema OO de modo que

implemente de manera efectiva los requerimientos del cliente. Pero, conforme un modelo de

diseno OO crece en tamano y complejidad, una vision mas objetiva de las caracteristicas del

diseno puede beneficiar tanto al disenador experimentado (quien adquiere comprension

adicional) como al novato (quien obtiene un indicio de la calidad que de otro modo no tendria

disponible). En un tratamiento detallado de las metricas de software para sistemas OO, describe

nueve caracteristicas distintas y mensurables de un diseno OO:

 Tamaño. El tamano se define en funcion de cuatro visiones: poblacion, volumen,

longitud y funcionalidad. La población se mide al realizar un conteo estatico de

entidades OO, tales como clases u operaciones. Las medidas de volumen son identicas

a las medidas de poblacion, pero se recolectan de manera dinamica: en un instante de

tiempo determinado. La longitud es una medida de una cadena de elementos de diseno

interconectados (por ejemplo, la profundidad de un arbol de herencia es una medida de

longitud). Las metricas de funcionalidad proporcionan un indicio indirecto del valor

entregado al cliente por una aplicación OO.

 Complejidad. Como el tamano, existen muchas visiones diferentes de la complejidad

del software. Whitmire ve la complejidad en terminos de caracteristicas estructurales

al examinar como se relacionan mutuamente las clases de un diseno OO.

 Acoplamiento. Las conexiones fisicas entre elementos del diseno OO (por ejemplo, el

numero de colaboraciones entre clases o el de mensajes que pasan entre los objetos)

representan el acoplamiento dentro de un sistema OO.

 Suficiencia. define suficiencia como “el grado en el que una abstraccion posee las

caracteristicas requeridas de el o en el que un componente de diseno posee

características en su abstraccion, desde el punto de vista de la aplicacion actual”.

Dicho de otra forma, se pregunta: “Que propiedades debe poseer esta abstraccion

(clase) para serme util?. En esencia, un componente de diseno (por ejemplo, una clase)

es suficiente si refleja por completo todas las propiedades del objeto de dominio de

aplicacion que se modela, es decir, si la abstraccion (clase) posee sus caracteristicas

requeridas.

 Completitud. La unica diferencia entre completitud y suficiencia es “el conjunto de

características contra las cuales se compara la abstraccion o el componente de diseno”.

La suficiencia compara la abstraccion desde el punto de vista de la aplicacion actual.

La completitud considera multiples puntos de vista, y plantea la pregunta: “.que

propiedades se requieren para representar por completo al objeto de dominio

problema?”. Puesto que el criterio para completitud considera diferentes puntos de

vista, tiene una implicacion indirecta en el grado en el que puede reutilizarse la

abstraccion o el componente de diseno.

 Cohesión. Como su contraparte en software convencional, un componente OO debe

diseñarse de manera que tenga todas las operaciones funcionando en conjunto para

lograr un solo proposito bien definido. La cohesividad de una clase se determina al

 examinar el grado en el que “el conjunto de propiedades que posee es parte del

problema o dominio de diseno”.

 Primitivismo. Una caracteristica que es similar a la simplicidad, el primitivismo

(aplicado tanto a operaciones como a clases), es el grado en el que una operacion es

atomica, es decir, la operacion no puede construirse a partir de una secuencia de otras

operaciones contenidas dentro de una clase. Una clase que muestra un alto grado de

primitivismo encapsula solo operaciones primitivas.

 Similitud. El grado en el que dos o mas clases son similares en terminos de su

estructura, funcion, comportamiento o proposito se indica mediante esta medida.

 Volatilidad. Como se menciona muchas veces en este libro, los cambios en el diseno

pueden ocurrir cuando se modifican los requerimientos o cuando ocurren

modificaciones en otras partes de una aplicacion, lo que da como resultado la

adaptacion obligatoria del componente de diseno en cuestion. La volatilidad de un

componente de diseno OO mide la probabilidad de que ocurrira un cambio.

En realidad, las metricas de producto para sistemas OO pueden aplicarse no solo al modelo de

diseno, sino tambien al de requerimientos. En las siguientes secciones se estudian las métricas

MÉTRICAS PARA EL CÓDIGO FUENTE

Métricas para pruebas: Estas métricas ayudan a diseñar casos de pruebas efectivos y a

evaluar la eficacia de las pruebas:

 Métricas de cobertura de instrucciones y ramas

Métricas relacionadas con los defectos

Efectividad de la prueba

Métrica en el proceso

Tipos de Métricas y su aplicación

MÉTRICAS PARA EL MODELO DE ANÁLISIS

Métricas basadas en la función

La métrica del punto de función se utiliza como medio para predecir el tamaño de un sistema
obtenido a partir de un modelo de análisis. Para visualizar esta métrica se utiliza un diagrama de
flujo de datos, el cual se evaluar para determinar las siguientes medidas clave que son necesarias
para el cálculo de la métrica de punto de función:

· Número de entradas del usuario

· Número de salidas del usuario

· Número de consultas del usuario

· Número de archivos

· Número de interfaces externas

Métricas para calidad de la especificación

Existe una lista de características para poder valorar la calidad del modelo de

análisis y la correspondiente especificación de requisitos: Especificidad, corrección,

compleción, comprensión, capacidad de verificación, consistencia externa e interna,

capacidad de logro, concisión, traza habilidad, capacidad de modificación, exactitud y

capacidad de reutilización. Aunque muchas de las características anteriores pueden ser

de naturaleza cuantitativa, Davis [Pressman ‘98] sugiere que todas puedan

representarse usando una o más métricas. Por ejemplo asumimos que hay ni requisitos

en una especificación, tal como

ni = nf + nnf

Donde nf es el numero de requisitos funcionales y nnf es el número de requisitos no

funcionales ( por ejemplo, rendimiento). Para determinar la especificidad de los requisitos, Davis

[Pressman ‘98] sugiere una métrica basada en la consistencia de la interpretación de los revisores

para cada requisito:

Q1 = nui / nr

Donde nui es el numero de requisitos para los que todos los revisores tuvieron

interpretaciones idénticas. Cuanto más cerca de uno este el valor de Q1 menor será la

ambigüedad de la especificación. La compleción de los requisitos funcionales pueden terminarse

calculando la relación

Q2 = nu / (ni * ns)

donde nu es el número de requisitos de función únicos, ni es el número de entradas (estímulos)

definidos o implicados por la especificación y ns es el número de estados especificados. La

relación Q2 mide porcentaje de funciones necesarias que se han especificado para un sistema, sin

embargo, no trata los requisitos no funciónales. Para incorporarlos a una métrica global

completa, debemos considerar el grado de validación de los requisitos:

Q3 = nc / (nc + nnv)
donde nc es el número de requisitos que se han validados como correctos y nnv el número de

requisitos que no se han validado todavía.

MÉTRICAS PARA EL MODELO DE DISEÑO:

Métricas del diseño arquitectónico

Métricas de diseño a nivel de componentes

Las métricas de diseño a nivel de componentes se concentran en las características internas de

los componentes del software e incluyen medidas de la cohesión, acoplamiento y complejidad

del módulo. Estas tres medidas pueden 88 ayudar al desarrollador de software a juzgar la calidad

de un diseño a nivel de componentes. Las métricas presentadas son de “caja blanca” en el sentido

de que requieren conocimiento del trabajo interno del módulo en cuestión. Las métricas de

diseño en los componentes se pueden aplicar una vez que se ha desarrollado un diseño

procedimental. También se pueden retrasar hasta tener disponible el código fuente.

Métricas de diseño de interfaz

MÉTRICAS PARA EL CÓDIGO FUENTE

MÉTRICAS PARA PRUEBAS

Métricas de Halstead aplicadas para probar

Métricas para pruebas orientadas a objetos

MÉTRICAS PARA MANTENIMIENTO