Capítulo 23

MÉTRICAS DEL PRODUCTO

OBJETIVOS
1. Analizar el marco conceptual para las métricas del producto.
2. Conocer cuáles son las métricas para:
a) El modelo de requerimientos.
b) El modelo de diseño.
c) El diseño de webapps.
d) Código fuente.
e) Pruebas.
f) Mantenimiento.
MARCO CONCEPTUAL PARA LAS MÉTRICAS
DE PRODUCTO
Las métricas de producto ayudan a los ingenieros de
software a obtener comprensión acerca del diseño y la
construcción del software que elaboran, al enfocarse en
atributos mensurables específicos de los productos de
trabajo de la ingeniería del software.

Pero algunos miembros de la comunidad del software continúan

argumentando que el software es “inmensurable” o que los intentos
por medir deben posponerse hasta comprender mejor el software y
los atributos que deben usarse para describirlo.
¡Esto es un error!
Medidas, métricas e indicadores
• Una medida proporciona un indicio cuantitativo de la extensión, cantidad, dimensión, capacidad
o tamaño de algún atributo de un producto o proceso.

• La medición es el acto de determinar una medida.

• El IEEE define métrica como “una medida cuantitativa del grado en el que un sistema,
componente o proceso posee un atributo determinado”.

• Un indicador es una métrica o combinación de métricas que proporcionan comprensión acerca

del proceso de software, el proyecto de software o el producto en sí.
Medidas, métricas e indicadores
• Se establece una medida cuando se ha recolectado un solo punto de
datos:

El número de errores descubiertos dentro de un solo componente de

software

• La medición ocurre como resultado de la recolección de uno o más puntos

de datos:

Algunas revisiones de componente y pruebas de unidad se investigan para

recolectar medidas del número de errores de cada uno.

• Una métrica de software relaciona en alguna forma las medidas

individuales:

El número promedio de errores que se encuentran por revisión.

El número promedio de errores que se encuentran por unidad de prueba.
El reto de la métrica de producto
Aunque existe la necesidad de medir y de controlar la complejidad del software, y si bien un solo
valor de esta métrica de calidad es difícil de derivar, es posible desarrollar medidas de diferentes
atributos internos de programa, por ejemplo:

• Modularidad efectiva
• Independencia funcional

Sin embargo, es justo preguntar cuán válidas son las métricas de producto, es decir,

¿Cuán cercanamente se alinean las métricas de producto con la confiabilidad a largo plazo y con la
calidad de un sistema basado en computadora?

La medición es esencial si debe lograrse la calidad.

Principios de medición
Roche sugiere un proceso de medición que puede caracterizarse
mediante cinco actividades:

• Formulación. La derivación de medidas y métricas de software

apropiadas para la representación del software que se está
construyendo.
• Recolección. Mecanismo que se usa para acumular datos requeridos
para derivar las métricas formuladas.
• Análisis. El cálculo de métricas y la aplicación de herramientas
matemáticas.
• Interpretación. Evaluación de las métricas resultantes para
comprender la calidad de la representación.
• Retroalimentación. Recomendaciones derivadas de la interpretación
de las métricas del producto, transmitidas al equipo de software.
Principios de medición
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”).
• 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.
Principios de medición
Roche sugiere los siguientes principios para la recolección y el análisis:

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.

Atributos de las métricas de software efectivas
La métrica derivada y las medidas que conducen a ella deben ser:

• Simple y calculable.
• Empírica e intuitivamente convincente.
• Congruente y objetiva.
• Constante en su uso de unidades y dimensiones.
• Independiente del lenguaje de programación.
• Un mecanismo efectivo para retroalimentación de alta calidad.
MÉTRICAS PARA EL MODELO DE
REQUERIMIENTOS/Métrica basada en funciones
La métrica de punto de función (PF) puede usarse de manera efectiva como medio para medir la
funcionalidad que entra a un sistema.
Al usar datos históricos, la métrica PF puede entonces usarse para:
1) Estimar el costo o esfuerzo requerido para diseñar, codificar y probar el software;
2) Predecir el número de errores que se encontrarán durante las pruebas, y
3) Prever el número de componentes y/o de líneas fuente proyectadas en el sistema implementado.

Los puntos de función se derivan usando una relación empírica basada en medidas contables
(directas) del dominio de información del software y en valoraciones cualitativas de la complejidad
del software.
Métrica basada en funciones
Los valores de dominio de información 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 aplicación, y proporciona distintos datos orientados a aplicación o información de
control. 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 aplicación
que ofrecen información al usuario. En este contexto, salida externa se refiere a reportes,
pantallas, mensajes de error, etc.
• Número de consultas externas (CE). Una consulta externa se define como una entrada en línea
que da como resultado la generación de alguna respuesta de software inmediata en la forma de
una salida en línea.
• Número de archivos lógicos internos (ALI). Cada archivo lógico interno es un agrupamiento lógico
de datos que reside dentro de la frontera de la aplicación y se mantiene mediante entradas
externas.
• Número de archivos de interfaz externos (AIE). Cada archivo de interfaz externo es un
agrupamiento lógico de datos que reside fuera de la aplicación, pero que proporciona
información que puede usar la aplicación.
Métrica basada en funciones
Una vez recolectados dichos datos, la tabla se completa y
un valor de complejidad se asocia con cada conteo.
La determinación de complejidad es un tanto subjetiva.
Para calcular puntos de función (PF), se usa la siguiente
relación:

donde conteo total es la suma de todas las entradas PF

obtenidas.
Métrica basada en funciones
Los Fi (i = 1 a 14) son factores de ajuste de valor (FAV) con base en respuestas a las siguientes preguntas:

1. ¿El sistema requiere respaldo y recuperación confiables?

2. ¿Se requieren comunicaciones de datos especializadas para transferir información hacia o desde la
aplicación?
3. ¿Existen funciones de procesamiento distribuidas?
4. ¿El desempeño es crucial?
5. ¿El sistema correrá en un entorno operativo existente enormemente utilizado?
6. ¿El sistema requiere entrada de datos en línea?
7. ¿La entrada de datos en línea requiere que la transacción de entrada se construya sobre múltiples
pantallas u operaciones?
8. ¿Los ALI se actualizan en línea?
Métrica basada en funciones
9. ¿Las entradas, salidas, archivos o consultas son complejos?
10. ¿El procesamiento interno es complejo?
11. ¿El código se diseña para ser reutilizable?
12. ¿La conversión y la instalación se incluyen en el diseño?
13. ¿El sistema se diseña para instalaciones múltiples en diferentes organizaciones?
14. ¿La aplicación se diseña para facilitar el cambio y su uso por parte del usuario?

Cada una de estas preguntas se responde usando una escala que varía de 0 (no importante o aplicable) a 5
(absolutamente esencial).
Los valores constantes en la ecuación y los factores ponderados que se aplican a los conteos de dominio de
información se determinan de manera empírica.
Métrica basada en funciones
• La función gestiona la interacción del usuario, acepta la
contraseña de éste para activar o desactivar el sistema y
permite consultas sobre el estado de las zonas de
seguridad y de varios sensores de seguridad.
• La función despliega una serie de mensajes de
advertencia y envía señales de control adecuadas a varios
componentes del sistema de seguridad.
• El diagrama de flujo de datos se evalúa para determinar
un conjunto de medidas de dominio de información clave
que son requeridas para calcular la métrica de punto de
función.
• Se muestran tres entradas externas (contraseña, botón
de pánico y activar/desactivar), junto con dos consultas
externas (consulta de zona y consulta de sensor).
• Se muestra un ALI (archivo configuración sistema) y
también están presentes dos salidas externas (mensajes y
estado de sensor) y cuatro AIE (sensor de prueba,
establecimiento de zona, activar/desactivar y alerta de
alarma).
Métrica basada en funciones
Se muestran estos datos, junto con la complejidad
adecuada.
El conteo total que se muestra debe ajustarse usando la
ecuación.
Para los propósitos de este ejemplo, suponga que (Fi )
es 46 (un producto moderadamente complejo).
Por tanto,
Métrica basada en funciones
Métricas para calidad de la especificación
Davis propone una lista de características que pueden usarse para valorar la calidad del modelo de
requerimientos y la correspondiente especificación de requerimientos:

• Especificidad (falta de ambigüedad),

• Completitud,
• Corrección,
• Comprensibilidad,
• Verificabilidad,
• Consistencia interna y externa,
• Factibilidad,
• Concisión,
• Rastreabilidad,
• Modificabilidad,
• Precisión y
• Reusabilidad
Métricas para calidad de la especificación
Las especificaciones de alta calidad:

• Se almacenan electrónicamente,
• Son ejecutables o al menos interpretables,
• Se anotan mediante importancia relativa,
• Son estables,
• Tienen versión,
• Se organizan,
• Cuentan con referencia cruzada y
• Se especifican en el nivel correcto de detalle
MÉTRICAS PARA EL MODELO DE DISEÑO
• Con frecuencia el diseño de los sistemas complejos basados en software procede
virtualmente sin medición.

• La ironía de esto es que están disponibles métricas del diseño para el software, pero la gran
mayoría de los ingenieros del software continúan sin percatarse de su existencia.

• Las métricas de diseño para software de computadora, al igual que todas las demás métricas
de software, no son perfectas.

• El debate continúa acerca de su eficacia y sobre la forma en la que deben aplicarse.

• Muchos expertos argumentan que se requiere más experimentación antes de poder usar las
medidas de diseño, aunque el diseño sin medición es una alternativa inaceptable.
Métricas del diseño arquitectónico
Las métricas del diseño arquitectónico se enfocan en características de la arquitectura del
programa con énfasis en la estructura arquitectónica y en la efectividad de los módulos o
componentes dentro de la arquitectura.

Card y Glass definen tres medidas de complejidad del diseño de software:

• Complejidad estructural,
• Complejidad de datos y
• Complejidad del sistema.
MÉTRICAS DE DISEÑO PARA WEBAPPS
Un útil conjunto de medidas y métricas para webapps proporciona respuestas cuantitativas a las
siguientes preguntas:

• ¿La interfaz de usuario promueve usabilidad?

• ¿La estética de la webapp es apropiada para el dominio de aplicación y agrada al usuario?
• ¿El contenido se diseñó de tal forma que imparte más información con menos esfuerzo?
• ¿La navegación es eficiente y directa?
• ¿La arquitectura de la webapp se diseñó para alojar las metas y objetivos especiales de los
usuarios de la webapp, la estructura de contenido y funcionalidad, y el flujo de navegación
requerido para usar el sistema de manera efectiva?
• ¿Los componentes se diseñaron de manera que se reduce la complejidad procedimental y se
mejora la exactitud, la confiabilidad y el desempeño?
MÉTRICAS DE DISEÑO PARA WEBAPPS
Métricas de interfaz. Para webapps pueden considerarse las siguientes medidas:
MÉTRICAS DE DISEÑO PARA WEBAPPS
Métricas estéticas (diseño gráfico). El diseño estético se apoya en el juicio cualitativo y por lo
general no es sensible a la medición ni a las métricas. Se proponen un conjunto de medidas que
pueden ser útiles para valorar el impacto del diseño estético:
MÉTRICAS DE DISEÑO PARA WEBAPPS
Métricas de contenido. Las métricas en esta categoría se enfocan en la complejidad del contenido
y en los grupos de objetos de contenido que se organizan en páginas.
MÉTRICAS DE DISEÑO PARA WEBAPPS
Métricas de navegación. Las métricas en esta categoría abordan la complejidad del flujo de
navegación. En general, son útiles sólo para aplicaciones web estáticas, que no incluyen vínculos y
páginas generados de manera dinámica.
MÉTRICAS PARA CÓDIGO FUENTE
• La teoría de Halstead de la “ciencia del software” propuso las primeras “leyes” analíticas para
el software de computadora.

• Halstead asignó leyes cuantitativas al desarrollo de software de computadora, usando un

conjunto de medidas primitivas que pueden derivarse después de generar el código o de que el
diseño esté completo.

• Las medidas son:

MÉTRICAS PARA PRUEBAS
La mayoría de las métricas proponen enfocarse en el proceso de las pruebas, no en las
características técnicas de las pruebas en sí.

En general, los examinadores deben apoyarse en las métricas de análisis, diseño y código para
guiarlos en el diseño y la ejecución de los casos de prueba.

• Métricas de Halstead aplicadas para probar.

• Métricas para pruebas orientadas a objetos.
MÉTRICAS PARA MANTENIMIENTO
Todas las métricas de software pueden usarse para el desarrollo de nuevo software y para el
mantenimiento del software existente. Sin embargo, se han propuesto métricas diseñadas
explícitamente para actividades de mantenimiento.

IEEE Std. 982.1-1988 sugiere un índice de madurez de software (IMS) que proporcione un indicio
de la estabilidad de un producto de software (con base en cambios que ocurran para cada
liberación del producto). Para ello, se determina la siguiente información:
MÉTRICAS PARA MANTENIMIENTO
El índice de madurez del software se calcula de la forma siguiente:

Conforme el IMS tiende a 1.0, el producto comienza a estabilizarse.

El IMS también puede usarse como una métrica para planificar actividades de mantenimiento de
software.
El tiempo medio para producir una liberación de un producto de software puede correlacionarse con el
IMS, y es posible desarrollar modelos empíricos para esfuerzo de mantenimiento.
Otros tipos de métricas

• Métricas para diseño orientado a objetos

• Métricas orientadas a clase: la suite de métricas CK
• Métricas orientadas a clase: La suite de métricas MOOD
• Métricas OO propuestas por Lorenz y Kidd
• Métricas de diseño en el nivel de componente
• Métricas orientadas a operación
• Métricas de diseño de interfaz de usuario