METRICAS DEL SOFTWARE

MSc. I.S Judith del Pilar Rodríguez

Tenjo
 Directa
Indirecta
Medida

C Permite resolver problemas

O
 Formulación
N Características de un  Colección
C proceso de medición  Análisis
E Medición  Interpretación
P  Realimentación
T Atributos internos
O Atributos externos
S
C Valorar Calidad y fiabilidad
L
A Estimar Tiempo y esfuerzo
V
E  Estimación del costo y el esfuerzo
S  Acumulación de datos
Actividades  Medición de la productividad
 Elaboración de modelos de seguridad
 Valoración de capacidades de
madurez
 Definiciones claras
Métrica  Definir el modelo
 Establecer criterio de conteo
Diseño
 Decidir que es bueno
 Reporte de la métrica
 Clasificaciones adicionales

 Simple y fácil de calcular

 Empírica e intuitiva
 Consistente en el empleo de
Características unidades y tamaño.
 Independiente del lenguaje de
programación.
 Un mecanismo para la
realimentación de calidad.
MEDIDAS
 Medición y Métricas

Medición es el acto de determinar una medida

Una medida proporciona una indicación cuantitativa de la

extensión, la cantidad, la dimensión, la capacidad o el tamaño
de algún atributo del producto o proceso.

Métrica, es la medida cuantitativa del grado de en que un

sistema, componente o proceso posee un atributo determinado.

Un indicador es una métrica o una combinación de métricas que

proporciona conocimiento acerca del proceso de software, un
proyecto de software o el propio producto
 El proceso de medición- actividades

Formulación Formulación: Obtención de medidas y

métricas del software apropiadas para
la presentación del software en
cuestión.
Colección: Mecanismo empleado para
acumular datos necesarios para
obtener las métricas formuladas.
Retroalimentación Colección
Análisis: Cálculo de las métricas y la
Actividades aplicación
de la de herramientas matemáticas.
Interpretación: La evaluación de los
medición
resultados de las métricas en un
esfuerzo por conseguir una visión
interna de la calidad de la
presentación.
Retroalimentación: Recomendaciones
obtenidas de la interpretación de
Interpretación Análisis métricas y técnicas transmitidas al
equipo de desarrollo de software.
El proceso de medición
Métricas del modelo del análisis
En esta fase es deseable que las métricas técnicas
proporcionen una visión interna a la calidad del
modelo de análisis.

Estas métricas examinan el modelo de análisis con la

intención de predecir el “tamaño” del sistema
resultante; es probable que el tamaño y la
complejidad del diseño estén directamente
relacionadas.

Otras Métricas :
Métrica Bang  Modelo
de Análisis
Métrica de Especificación
 • La métrica de punto de función PF se usa para medir la funcionalidad que entrega
un sistema , empleando datos históricos el PF se usa para estimar el costo o el
esfuerzo requerido para diseñar codificar y probar el software Predecir el numero
de errores que se encontraran durante la prueba Pronosticar el numero de
METRICAS BASADAS componentes, de líneas de código proyectadas o ambas en el
EN LA FUNCION sistema implementado.

• Se derivan al normalizar las medidas de calidad y/o productividad para considerar

el tamaño que se produjo.
• No se aceptan universalmente como la mejor forma de medir el proceso de
Métricas orientadas software.
al tamaño

• BANG: Se aplica para desarrollar una indicación del tamaño del software a
implementar como consecuencia del modelo de análisis.
• ESPECIFICACION: Davis y colegas proponen una lista de características que pueden
METRICAS BANG Y emplearse para valorar la calidad del modelo de análisis y la correspondiente
Métricas de cakidad especificación de requisitos.
de ka especificación
METRICAS ?
 ¿Qué son las métricas?
Es la medición es esencial para cualquier disciplina de
ingeniería y la ingeniería de software no es una excepción.

Las métricas de software se refieren aun amplio rango de

medidas para el software dentro del contexto de la
planificación del proyecto de software, las métricas de
calidad pueden ser aplicadas a organizaciones, procesos y
productos los cuales directamente afectan a la estimación.

Existen métricas que podemos utilizar para evaluar lo que

estamos haciendo en ingeniería de software.
 Una métrica es una medida efectuada
sobre algún aspecto del sistema en
Why? desarrollo o del proceso empleado
que permite, previa comparación con
unos valores (medidas) de referencia,
obtener conclusiones sobre el aspecto
medido con el fin de adoptar las
decisiones necesarias.

Con esta definición, la definición y

aplicación de una métrica no es un
objetivo en sí mismo sino un medio
para controlar el desarrollo de un
sistema de software.
 ¿Qué son las métricas?
Se definen las métricas de software como "La aplicación
continua de mediciones basadas en técnicas para el
proceso de desarrollo del software y sus productos, para
suministrar información relevante a tiempo, así
el administrador junto con el empleo de estas técnicas
mejorará el proceso y sus productos" .

Figura . Concepto de Métricas.

Para que sea útil en el contexto del mundo real, una métrica del
software debe ser objetiva, simple y calculable, consistente en el
empleo de unidades y tamaños, persuasiva, además debería ser
independiente del lenguaje de programación y proporcionar una
realimentación eficaz para el desarrollador de software

¿Por qué asegurarnos de que las métricas cumplen estas condiciones?

Las métricas deben ser un instrumento que ayude a mejorar el proceso, producto o
proyecto de software, no tiene mucho sentido aplicar métricas que lejos de ayudar a
los desarrolladores constituyan un problema; bien por ser demasiado complejas,
porque no se entiendan correctamente los objetivos que persiguen o porque arrojen
resultados imprecisos que no puedan ser interpretados por los ingenieros de software.

Es importante entonces que una métrica pueda obtenerse fácilmente, que se

entienda por qué y para qué se utiliza, que los cálculos no produzcan resultados
ambiguos o en los que existan extrañas combinaciones de unidades, y que la
interpretación de valores obtenidos esté acorde a las nociones intuitivas
del ingeniero de software.
Fuente: CHOQUE, Aspiazu. Ingeniería del software, principios y conceptos. México: Mc Graw Hill, 1994. p.123.
Who ?
 • Las métricas sobre el producto están orientadas a estimar las características del mismo
antes de su desarrollo.
• Estas estimaciones se basan en el conocimiento que los desarrolladores adquieren a partir
de datos obtenidos de proyectos anteriores.
Producto • A) Tamaño estimado del código B) Complejidad estimada C) Robustez

• Las métricas del proceso se recopilan de todos los proyectos y durante un largo período de
tiempo.
• Su intento es proporcionar indicadores que lleven a mejoras de los procesos de software a
largo plazo.. Un indicador es una métrica o una combinación de métricas que proporcionan
Proceso una visión profunda del proceso del software, del proyecto de software o del producto en
si.

• Engloba todos los recursos, actividades y artefactos, que se organizan para lograr un producto de
software de calidad, es de vital importancia definir algunas mediciones que ayuden al
mejoramiento del mismo.
• A nivel de proyecto se minimiza la planificación de desarrollo haciendo los ajustes necesarios para
evitar retrasos o riesgos potenciales, minimizar los defectos, y por tanto la cantidad de trabajo
Proyecto que ha de rehacerse, lo que ocasiona una reducción del coste global del proyecto, además puede
evaluarse la calidad de los productos en el momento actual y cuando sea necesario.
Métricas del Proyecto

La primera aplicación de métricas de proyectos

en la mayoría de los proyectos de software
ocurre durante la estimación.
Las métricas recopiladas de proyectos anteriores
se utilizan como una base desde la que se
realizan las estimaciones del esfuerzo y del
tiempo para el actual trabajo del software. A
medida que avanza un proyecto, las medidas del
esfuerzo y del tiempo consumido se comparan
con las estimaciones originales (y la planificación
de proyectos).
 Métricas del Proyecto
El gestor utiliza estos datos para supervisar y controlar el avance. A medida que
comienza el trabajo técnico, otras métricas de proyectos comienzan a tener significado.
Se miden los índices de producción representados mediante páginas de documentación,
las horas de revisión, los puntos de función y las líneas fuentes entregadas, en el
proyecto se sigue la pista de los errores detectados durante todas las tareas de
ingeniería del software. Cuando va evolucionando el software desde la especificación
del diseño, se recopilan las métricas técnicas para evaluar la calidad del mismo y para
proporcionar indicadores que influirán en el enfoque tomado para la generación y
prueba del código.

Finalmente los indicadores de proyecto permiten:

• Evaluar el estado del proyecto en curso.

• Seguir la pista de los riesgos potenciales.
• Detectar las Áreas de problemas antes de que se
conviertan en "críticas".
• Ajustar el flujo y las tareas del trabajo.
• Evaluar la habilidad del equipo del proyecto en
controlar la calidad de los productos de trabajo del
software.
 Métricas proceso
La medición del proceso implica las
mediciones de las actividades relacionadas
con el software siendo algunos de sus
atributos típicos el esfuerzo, el coste y los Para mejorar un proceso se deben medir los
defectos encontrados. atributos del mismo, desarrollar métricas de
acuerdo a estos atributos y utilizarlas para
Las métricas permiten tener una visión proporcionar indicadores que conduzcan la Actualmente existen muchas métricas, y
profunda del proceso de software que mejora del proceso. éstas deben usarse conforme se ajusten al
ayudará a tomar decisiones más proceso.
fundamentadas, ayudan a analizar el Los errores detectados antes de la entrega
Las métricas del proceso se caracterizan por:
trabajo desarrollado, conocer si se ha del software, la productividad, recursos y
mejorado o no con respecto a proyectos tiempo consumido y ajuste con la •El control y ejecución del proyecto.
anteriores, ayudan a detectar áreas planificación son algunos de los resultados •Medición de tiempos del análisis, diseño,
implementación, implantación y posti- mplantación.
con problemas para poder remediarlos a que pueden medirse en el proceso, así como •Medición de las pruebas (errores, cubrimiento,
tiempo y a realizar mejores estimaciones. las tareas específicas de la ingeniería del
resultado en número de defectos y número de éxito).
software.
•Medición de la transformación o evolución del
producto

¿Por qué el proceso?

existen varios factores que determinan la calidad del software y la eficiencia de la organización, entre ellos están la
complejidad del producto, las tecnologías y las personas, así como algunas condiciones de entorno que también
tienen su impacto, estas pueden ser condiciones de gestión (Ej.: plazo de entrega, regla de empresa), entornos de
desarrollo y características del cliente, sin embargo en el centro de todas ellas se encuentra el proceso pues es el
único factor de los controlables al mejorar la calidad del software y su rendimiento como organización. Analizando
y mejorando el proceso se puede obtener mejores productos.
Métricas del Producto
Las métricas del producto se centran en las
características del software y no en cómo
fue producido.
Un producto no es solo el software o
sistema funcionando sino también los
artefactos, documentos, modelos,
módulos, o componentes que lo
conforman, por tanto, las métricas del
producto deben hacerse sobre la base de
medir cada uno de estos.

En los artefactos del producto se mide,

entre otras cosas, el tamaño, la calidad
(teniendo en cuenta los defectos, la
complejidad, la primitividad, entre otros),
la totalidad, rastreabilidad, volatilidad,
esfuerzo.
 METRICAS- SOFTWARE
Proceso  Tiempo y costo de
desarrollo.
 Reusabilidad
 Productividad
Métricas del
Software
 Tamaño.
 Estructura lógica
Producto
 Estructura de datos
 Puntos de función
............
Fuente: EJIOGU, L. Software engineering with formal mectrics. Brasilia: Pearson, 1996.
 Otras clasificaciones de las métricas

Uno puede distinguir el objetivo de las propiedades subjetivas (la métrica).

Generalmente hablando, el indicador de la métrica siempre debe producir los valores

idénticos para una métrica dada.

Incluso para la métrica subjetiva, son las medidas del proceso de software, como el
tiempo de desarrollo global, el tipo de metodología usado ó el nivel de experiencia
del personal de la programación.

Los observadores calificados pueden medir los diferentes valores dados para una
métrica, desde que su juicio subjetivo este involucrado llegando al valor moderado.
 Volviendo métricas del Producto
Métricas orientadas al tamaño.
Provienen de la normalización de las
medidas de calidad y/o productividad
considerando el tamaño del software
que se haya producido. LOC
KLOC
Varias métricas intentan cuantificar el Líneas de código DSI
software por el tamaño. NCSS
NSLOC
La métrica que usa más esto Punto de función
Métricas del
ampliamente es LOC; padece la producto según Volumen del
deficiencia obvia que su valor no el tamaño C. Bang programa
puede medirse hasta después que el
Longitud del
proceso codificación se haya Métricas de halstead programa
completado.
Los puntos función del sistema y el Vocabulario del
programa
Bang tienen la ventaja de ser
predecibles en la fase del plan en el Dificultad del
programa
proceso de desarrollo y, se puede decir
que posiblemente antes.
Algunas métricas definidas por
Halstead también usadas miden el
tamaño del software (longitud y
volumen del programa) (Véase la
Figura ).
 VENTAJAS DE LAS MÉTRICAS DESVENTAJAS DE LAS MÉTRICAS

 Son fáciles de calcular  Son dependientes del lenguaje de programación.

 Muchos modelos de  Perjudica a los programas cortos pero bien
estimación de software usan diseñados.
LOC o KLOC como datos de  Su uso en estimación es difícil porque hay que
entrada. estimar las LOC a producirse mucho antes de que
se complete el análisis y el diseño.

Fuente: FENTON, Norman. Software mectrics. London: Chapman & Hall, 1991. p.63

Líneas de código (LOC). Las métricas de las líneas de código (LOC), posiblemente
son las más altamente usadas para hallar el tamaño del programa.

involucran tratamiento de líneas pálidas y líneas del comentario, declaraciones no

ejecutables, las declaraciones múltiples línea, y líneas múltiples por declaración,
así como la pregunta de cómo contar las líneas de código rehusadas.

La definición más común de LOC parece contar cualquier línea que no sea un
espacio en blanco o línea de comentario, sin tener en cuenta el número de
declaraciones por línea.
Definiciones importantes LOC
LOC. Líneas de código es la más habitual y antigua
KLOC. Miles de líneas de código. Es la unidad de medida que
adoptan la mayoría de modelos clásicos de estimación de
costos, en la calificación de un proyecto informático.
DSI. Instrucciones de código fuente realmente entregados, y
su múltiplo KDSI, que surgieron para que se tuviera en
cuenta que, en los nuevos entornos de desarrollo y
construcción de software
NCSS. Líneas de código fuente sin tener en cuenta los
comentarios, y su múltiplo
KNCSS. Por el hecho de considerar que en un buen proceso
de construcción los programas incluyen líneas de
comentario o que una línea de tratamiento se puede escribir
en diferentes líneas de código para aumentar la legibilidad y
mejorar la mantenibilidad del software.
NSLOC. Nuevas líneas de código fuente, tal como se realiza
en el modelo COCOMO 2 para que se tenga en cuenta que
sólo deben contarse las líneas de código nuevas sin contar
las que incorpore automáticamente el entorno de
programación.
 Punto de función.
Sugiere un acercamiento a
la medida de productividad.
Se obtienen utilizando una
relación empírica basada en
medidas cuantitativas del
dominio de información de
software y valorizaciones
subjetivas de la complejidad
del software.
Esto quiere decir que la
estimación se refiere a los
resultados que se obtienen
de un software y no cómo
se producen internamente
estos resultados.
Esta técnica aporta una
medida estándar del
tamaño de los sistemas de
información, y sirve de base
para la estimación del
esfuerzo requerido para el
desarrollo de los proyectos.
La medida de los SI
mediante los puntos de
función proporciona una
estimación del tamaño del
software independiente de
la tecnología utilizada en su
desarrollo y dependiente
únicamente de la
funcionalidad que el sistema
proporciona al usuario.
 Estas medidas aíslan el tamaño intrínseco del
Los Puntos Funcionales pueden ser entendidos sistema de los factores del medio, facilitando el
y evaluados por usuarios que no son técnicos estudio de factores que influyen en la
producción.

Las razones de Albrecht,

para proponer los Puntos
Funcionales como medidas
de tamaño de un sistema
tomadas de Pressman ’98,

Estas medidas pueden determinarse al inicio

Estas medidas están basadas; en las
del ciclo de desarrollo, lo que permite utilizar
observaciones de los usuarios externos del
los Puntos Funcionales en la estimación de
sistema, y es tecnología independiente.
procesos.
 Métrica de
flujo de
Métricas de complejidad del información
proceso
Métrica
ciclómatica de
complejidad
Que paso
con …. cantidad de
Métricas de estructura de datos
datos
Variables vivas

MÉTRICAS DEL
PROCESO M Métrica de
É spans
T
R
Métricas de estructura I Número de
lógica o de control C decisiones
A
S Métrica de
flujo de
D información
Métricas del esfuerzo de E Métrica de
desarrollo L costo
PROCESO
 Métricas de complejidad del proceso

Métrica ciclomática de complejidad. Esta medida

se deriva del grafo de flujo de control de un
programa y mide el número de caminos
independientes a través de un programa. Lo que
está relacionado con la facilidad para probar y
mantener el código. Una aproximación al valor del
número ciclomático se obtiene de la siguiente
expresión:
Donde e es el número de líneas del diagrama de
flujo, n es el número de nodos, y p el total de
elementos interconectados. Otra aproximación
sugiere que el número de elementos
interconectados es siempre dos (inicio y final), por
lo que:
V (G)  e  n  2 p |

El número de complejidad ciclomática puede e  n  t 1

asimilarse al número de líneas que constituirían el
esqueleto de un diagrama cuyo flujo se ha
simplificado al máximo. V (G)  e  n  2  t  1
diagrama más simple, que es aquel que posee un
sólo camino, presenta un ,un posible límite de
complejidad estaría en torno a , más allá de esta
cifra, las tareas de prueba y mantenimiento
resultan muy complicadas. Si t representa el
número de predicados, se puede demostrar que:
 Métricas de complejidad del proceso
Y de aquí:
= m
Dado que t y DE son prácticamente la misma cosa:
V (Gprog)   DEi  m
i 1
V (G)  DE  1
La entropía es otra medida relacionada con la complejidad y
Por otra parte, también se puede demostrar que la el análisis de diagramas de flujo. La expresión general es:
complejidad ciclomática de un programa formado por varios
módulos, es igual a la suma de las distintas complejidades. Si
n 1
m es el número de módulos: Z n   Log 2( piX  Qj ); x  2
m m i 1
V (Gprog) 
 V (Gi)  ni  2m
i 1 i 1

Donde Qi es la probabilidad de que el elemento de decisión i-

ésimo (símbolo IFTHEN) esté en serie con el anterior. Por su
parte pi es igual a 1 menos la cantidad anterior.
Zn está relacionada con MIN, el número de regiones
delimitadas por un diagrama de flujo. En una sola línea de
flujo MIN vale 1, con un bucle o una decisión es 2, con varias
decisiones anidadas su cálculo se complica y la entropía da
una expresión más exacta que el cálculo manual.
La entropía ha querido ser la métrica de unión entre
complejidad y actualmente varias herramientas de medida
del software la emplean para valorar la complejidad frente a
métricas más clásicas como el número de complejidad
ciclomática. En la cuadro10 se pueden apreciar las
dificultades de esta métrica.
 DIFICULTADES DE LAS MÉTRICAS CICLOMÁTICAS

La métrica ha sido asociada con la tasa de errores en módulos, sin embargo no ha sido demostrado que

provee mejor información que otros métodos.

Hay dificultades prácticas cuando se trata de el grafo de algunos programas y que es a menudo el grafo de un

programa equivalente se obtiene más rápido que el del original. Esto hace pensar sobre que es lo que

realmente se esta calculando.

La métrica resulta muy superficial tratando ciertos tipos de problemas, por ejemplo se obtiene el mismo

valor en con tres bucles en secuencia que con tres bucles anidados.

Un problema fundamental con el uso de la métrica como medida de la testeabilidad del programa es que se

basa exclusivamente en el flujo de control y obvia el flujo de datos. Hay muchos programas que pueden ser

escritos el uso de estructuras de control, mediante tablas y arrays u otras prácticas de programación

orientada a datos, por lo tanto el valor de la métrica puede estar muy influido por el estilo del programador.
Métricas de estructura de datos.

Todo software se crea fundamentalmente para procesar datos. Datos que entran
son procesados y salen. Por lo tanto es importante dar una breve descripción de
las de métricas para estos datos del sistema.

Cantidad de datos. Una variable es un string de caracteres alfanuméricos que es

definido por un programador y que es usado para representar algún valor durante
compilación o ejecución. La cantidad de variables se conoce como VARS, y puede
ser obtenida mediante una lista de referencias cruzadas, excluyendo variables
definidas pero nunca usadas.

¿Cómo se relaciona VARS con los operando definidos anteriormente?

N 2  VARS  cons tan tes únicas  labels

Esta métrica sólo refleja el número de variables únicas, sin indicar su grado de uso. Las
métricas siguientes cubren ese aspecto.
 Métricas de estructura de datos.
Variables vivas. Una variable está viva desde la primera a la
última referencia dentro de un procedimiento, por lo tanto, el
número promedio de variables vivas (lv promedio) es la suma
de la contabilización de variables vivas dividido el número de
sentencias ejecutables en el procedimiento.

Métricas de estructura lógica o de control

Métricas de estructura lógica o de control. La estructura lógica de un programa es
el mecanismo que le permite realizar las distintas funciones para las que fue
construido.

La estructura lógica del programa representa los algoritmos empleados en su

diseño y procesa los datos (la expresión Algoritmos + Estructuras de Datos =
Programas WIRT76 es una estupenda definición de programa).

Spans (separación o amplitudes) de variables. La métrica spans de variables (SP)

captura la frecuencia con la cual una variable es usada dentro de un programa o
procedimiento. Una variable referenciada “n” veces tiene “n-1” spans.
 Métricas de esfuerzo de desarrollo

Métricas de esfuerzo de desarrollo. El esfuerzo requerido para construir un sistema

puede ser medido con muchas unidades.

Desde las discriminaciones mentales de Halstead, hasta el número real de horas y

minutos que invierte un programador, la variedad es enorme, sin embargo hay una
medida que destaca por su universalidad: la persona- mes o meses -hombre. Por
otra parte, aunque el esfuerzo es muy importante, en realidad la más importante
métrica del esfuerzo es el costo.

La importancia de la medida del esfuerzo y coste responde más a necesidades de

tipo administrativo y de gestión que estrictamente técnicas. Pero por ello no deben
menospreciarse: el aspecto económico del software, que es el que subyace a la
gestión, determina la viabilidad de los proyectos.

El conocimiento del esfuerzo invertido ayuda a valorar la productividad y a preparar

las medidas de corrección oportunas para mejorar el trabajo del equipo y, estimar
las necesidades de futuros proyectos.
 Where ?
Proceso de desarrollo
METRICAS PARA EL MODELO DE ANALISIS MÉTRICAS PARA EL CÓDIGO FUENTE

Funcionalidad entregada Métricas de Halstead

Tamaño del sistema Métricas de complejidad
Calidad de la especificación Métricas de longitud

METRICAS PARA EL MODELO DE DISEÑO MÉTRICAS PARA PRUEBAS

Métricas arquitectónicas Métricas de cobertura de instrucciones

Métricas a nivel de componentes y ramas
Métricas del diseño de la interfaz Métricas relacionadas con los defectos
Métricas especializadas en diseño Efectividad de la prueba
orientado a objetos Métricas en el proceso
 Métricas y Calidad
Métricas de calidad. Son todas las métricas de software que definen de una u otra
forma la calidad del software; en la figura, se observa tales métricas como exactitud,
estructuración o modularidad, pruebas, mantenimiento, reusabilidad, cohesión del
módulo, acoplamiento del módulo, etc. Estas son los puntos críticos en el diseño,
codificación, pruebas y mantenimiento.

Métricas de
mantenibilidad.

Métricas de
Testeabilidad.

Métrica de flexibilidad.

Métrica de corrección. Medición de remoción de

MÉTRICAS DE defectos de software.
CALIDAD Métricas de defectos. Medición de la eficacia de
la remoción de defectos.
Métricas de facilidad de Defectos informados por los
uso. clientes
Métricas integridad. Medición de la eficacia de
la eliminación de defectos.

Métricas de facilidad de El índice de mantenibilidad

mantenimiento. (IM).