Métricas asociadas a la

Evaluación de SI - Parte 2
Ing. Joffre León Veas, MAE

2017-2017
2013-2013
Twitter: @JoffreLeonVeas Correo:
Correo:jleon@ups.edu.ec
jleon@ups.edu.ec
“Cuando puedes medir sobre lo que estás diciendo y expresarlos en
números, sabes algo sobre ello, pero cuando no puedes medirlo ni
expresarlo en números entonces tu conocimiento es precario e
insatisfactorio”. Lord Kelvin, Finales de Siglo XIX

“Lo que no sea medible, hazlo medible”. Galileo Galilei

“No se puede controlar lo que no se puede medir”. Tom De Marco

Contenido
3.0. Introducción a las métricas
3.1. Definiciones asociadas a métricas
3.2. Métricas de producto
3.3. Métricas de proceso
3.4. Métricas orientados a objetos
3.5. Otras métricas
Métricas software
El objetivo de todo proceso de medición es
recopilar indicadores cuantitativos sobre entidades
software, siendo una entidad software todo
elemento software [relacionado] sobre el que se
puede aplicar un proceso de medición y que están
caracterizadas por una serie de atributos.
...no se puede [debe] medir una entidad o un
atributo de manera aislada
Métricas software
De acuerdo a modelos de evaluación y mejora
como ISO 15504, CMM, CMMI, a la hora de
incrementar el nivel de madurez de una
organización hay que establecer una base
cuantitativa que esté enfocada sobre:
● Medición de Proyecto (gestión)
● Medición de Producto (calidad/aspectos técnicos)
● Medición del Proceso (capacidad/gestión)
Métricas software

Alternativas de
Fuentes de
Entidades
Medición de proceso
La medición del proceso [software] implica las mediciones de las
actividades relacionadas con el software, siendo algunos de sus
atributos típicos el esfuerzo, el costo y los defectos encontrados.
(Fenton y Pfleeger, 1997)
Medición de proceso
Las métricas del proceso de software se utilizan para
propósitos estratégicos y en muchas propuestas, la
medición se realiza extrayendo las características de
tareas específicas de la ingeniería de software y
obteniendo como resultados métricas sobre errores
detectados antes de la entrega del software, defectos
detectados e informados por los usuarios finales,
productos de trabajo entregados, el esfuerzo humano y
el tiempo consumido,... (Pressman, 2002)
Medición de proceso
Por este motivo, el enfoque de medición del
proceso [software] se ha centrado en recopilar una
serie de métricas de todos los proyectos y
durante un largo período de tiempo.
El objetivo entonces es proporcionar
indicadores que lleven a mejoras de los
procesos software a largo plazo.
Medición de proceso
Otro enfoque de medición del
proceso es a nivel conceptual, ya
que es posible que la complejidad
u otras características de calidad
del modelo del proceso puedan
afectar a su ejecución y por ende
a la calidad de los productos
finales obtenidos.
Medición de proceso
En este sentido se pueden encontrar algunos
estudios para evaluar la mantenibilidad de los
modelos de los proceso software. (García, 2004)
Se definen una serie de métricas sobre modelos de
procesos representados con el lenguaje SPEM
(Software Process Engineering Metamodel)
(OMG, 2002), pero que pueden ser aplicados a
otros lenguajes de modelado.
Medición de proceso
El modelo conceptual de SPEM está basado en
la idea de que un proceso de desarrollo de
software consiste en la colaboración entre
entidades abstractas y activas, denominadas
“roles de proceso”, que realizan operaciones
denominadas “actividades”, sobre entidades
tangibles denominadas “productos de
trabajo”.
Medición de proceso
Para las métricas de los modelos de procesos se
consideran dos niveles de alcance:
Nivel de modelo, son métricas que se aplican
para medir la complejidad estructural del proceso
en su conjunto.
Nivel de elementos fundamentales, mide los
elementos del modelo, tales como actividades,
roles definidos en el proceso y productos de trabajo
Medición de proceso
Métrica Definición

NA(MP) Número de actividades del modelo de procesos (MP)

NPT(MP) Número de productos de trabajo del modelo de procesos (MP)

NRP(MP) Número de roles que intervienen en el modelo de procesos (MP)

NDPT_In(MP) Número de dependencias de entrada de los productos en las actividades del MP

NDPT_Out(MP) Número de dependencias de salida de los productos en las actividades del MP

NDPT(MP) Número de dependencias de productos de trabajo

Métricas a Nivel de Modelo de Procesos

Medición de proceso
Métrica Definición

NPA(MP) Número total de dependencias de dependencias entre actividades

NCA(MP) Nivel de conectividad entre actividades

RDPT_In(MP) Proporción de dependencias de entrada de productos de trabajo

RDPT_Out(MP) Proporción de dependencias de salida de productos de trabajo

RPTA(MP) Proporción de productos de trabajo y actividades

RRPA(MP) Proporción de roles de proceso y actividades

Métricas a Nivel de Modelo de Procesos

Medición de proceso
Métrica Fórmula

NDPT(MP) NDPT(MP) = NDPT_In(MP) + NDPT_Out(MP)

NCA(MP) NCA(MP) = NA(MP) / NDPA(MP)

RDPT_In(MP) RDPT_In(MP) = NDPT_In(MP) / NDPT(MP)

RDPT_Out(MP) RDPT_Out(MP) = NDPT_Out(MP) / NDPT(MP)

RPTA(MP) RPTA(MP) = NRP(MP) / NA(MP)

RRPA(MP) RRPA(MP) = NRP(MP) / NA(MP)

Métricas a Nivel de Modelo de Procesos

Medición de proceso

Métricas a Nivel de Modelo de Procesos

Medición de proceso
Métrica Valor Métrica Valor

NA 5 NDPA 4

NPT 8 NCA 1,25

NRP 4 RDPT_In 0,68

NDPT_In 13 RDPT_Out 0,32

NDPT_Out 6 RPTA 1,6

NDPT 19 RRPA 0,8

Métricas a Nivel de Modelo de Procesos

Medición de proceso
Para demostrar la utilidad práctica de una métrica
es necesario llevar a cabo una validación empírica
mediante experimentos.
De esta forma ha sido posible comprobar la
correlación existente entre las métricas NA,
NPT, NDPT_In, NDPT_Out, NDPT, NDPA y
NCA con la mantenibilidad de los procesos
software. (Canfora et al., 2005)
Medición del Proyecto
La medición del proyecto y sus recursos asociados
constituye el elemento principal sobre el que se
basa el estudio de las métricas del proceso
software.
Cuando se mide el proyecto el objetivo que se
pretende es el de reducir el costo total del proyecto
así como el tiempo de desarrollo de este.
Medición del Proyecto
Los indicadores de proyecto permiten al
administrador de software (Pressman, 2002):
● Evaluar el estado del proyecto en curso.
● Realizar el seguimiento de los riesgos potenciales.
● Detectar áreas problemas antes de que se vuelvan
en áreas críticas.
● Ajustar el flujo y las áreas de trabajo.
● Evaluar las habilidades de los equipo de trabajo.
Medición del Proyecto
En relación a las métricas de proceso, las
mediciones del proyecto de software se consideran
a nivel táctico, es decir, las métricas de proyecto y
los indicadores derivados de éstas son utilizadas
por el administrador de proyecto y el equipo de
software para adaptar o ajustar el flujo de trabajo
del proyecto y las actividades técnicas.
Medición del Proyecto
El primer tipo de métricas de proyecto software
pueden ser obtenidas durante la fase de
estimación.
Las métricas recopiladas de proyectos anteriores se
utilizan como la base a partir de la cual se realizan
la estimación de costos, tiempos y esfuerzo
asociados al proyecto.
Medición del Proyecto
A medida que se cumplen las actividades del
proyecto, las métricas actuales se comparan con las
estimaciones originales y la planificación del
proyecto (seguimiento).
El administrador del proyecto utiliza estos datos
para evaluar, supervisar y controlar el avance de
las actividades del proyecto.
Medición del Proyecto
Para la estimación del tamaño del software cabe
destacar la métrica de los Punto Función, que se
estudiará más adelante.
Para la estimación de los costos de un proyecto
software caben destacar los modelos COCOMO
“Constructive Cost Model” y su refinamiento
COCOMO II.
Medición del Proyecto
En relación a la estimación de proyectos software,
en el modelo de Putman y Myers (2003) se
desarrolla la ecuación básica del software,
expresada como:

Producto = Productividad*Esfuerzo*Tiempo
Medición del Proyecto
Donde:
● Producto, representa la cantidad de funcionalidad
expresada en tamaño, (LOC, Puntos Función, etc.)
● Esfuerzo, el esfuerzo total del personal del proyecto
para desarrollar el producto, usualmente medida en
personas/mes.
● Tiempo, duración del proyecto, medida en meses.
● Productividad, relación entre la funcionalidad
producida en el tiempo y el esfuerzo dedicado.
Medición del Proyecto
La ecuación luego fue refinada en base al análisis
de los resultados históricos de una base de
proyectos, quedando:
Tamaño de = Índice de x a x b
Esfuerzo Tiempo
producto productividad

siendo, a = 1/3; b = 4/3;

Tamaño = número de líneas de código fuente
(sin espacios en blanco y comentarios)
Medición del Proyecto
Otro de los elementos clave a medir a nivel de
proyectos son sus recursos, que son entre otros, el
personal, la infraestructura hardware y software,...
Una métrica muy utilizada es la productividad
del personal que se obtiene así:
Productividad del personal = Tamaño / Esfuerzo
Medición del Producto
● Métricas clásicas
○ Métricas de código fuente
○ Métricas de complejidad
● Métricas para sistemas orientados a objetos
○ Ámbito de Diseño
○ Ámbito Conceptual
● Métricas para Base de datos
○ Ámbito conceptual
○ Ámbito lógico
Medición del Producto
Cabe destacar en primer lugar las métricas de
código fuente, siendo las más representativas las
siguientes:
● Líneas de código fuente (LOC)
● Longitud total (LT)
Medición del Producto
Líneas de código fuente (LOC)
Es la métrica más popular y más utilizada.
Problema al definir qué debe ser una línea de
código. ¿Se deben considerar los comentarios? ¿Y
las declaraciones? ¿Y las líneas en blanco?
En general, se recomienda separar la medición de
líneas de código de los comentarios.
Medición del Producto
Para facilitar la obtención e interpretación de la
métrica LOC, el SEI ha definido listas de
comprobación, en las que se indica que se debe
considerar:
● Todo código ejecutable,
● Declaraciones no ejecutables,
● Directivas de compilación
● No se consideran las líneas en blanco.
Medición del Producto
Longitud total, Total length (LT)
Se la define como la suma del Número de líneas de
código que no son comentarios (NCLOC) más el
número de líneas de código que son comentarios
(CLOC):
LT = NCLOC + CLOC
Medición del Producto
Densidad de comentarios, Density comments,
(DC) que da una idea sobre el punto hasta el cual
está documentado el código, se define como:

DC = CLOC / LOC
Medición del Producto
Otras métricas para evaluar la longitud de un
programa son:
● Número de sentencias de programación,
similar a LOC.
● SIZE1, se define como el número de puntos y
comas; solo aplicable a lenguajes que usan este
símbolo para separar sentencias.
Medición del Producto
Otras métricas para evaluar longitud,...
Métricas de las ciencias del software, que
intenta independizar las métricas del lenguaje de
programación.
Se basan en los tokens, que son unidades
sintácticas elementales distinguibles por el
compilador y que pueden ser divididos en
operadores y operandos.
Medición del Producto
Métricas de las ciencias del software, las
métricas son:
● La longitud de un programa,
● El volumen de un programa y
● El esfuerzo de implementación de un programa.
Medición del Producto
Las métricas base definidas para los elementos
indicados son:
μ1 = número de operadores diferentes que aparecen en el
programa.
μ2 = número de operandos diferentes que aparecen en el
programa.
N1 = número total de veces que aparece el operador.
N2 = número total de veces que aparece el operando.

Métricas de las ciencias del software

Medición del Producto
A partir de las métricas base se definen una serie
de métricas derivadas, de las cuales las
principales con:
Número de bits requeridos para
especificar un programa
Volumen de un programa:
V = N*log2(μ) ; μ = μ1 + μ2
Longitud global del programa:
N’ = μ1*log2(μ1) + μ2*log2(μ2)

Métricas de las ciencias del software

Medición del Producto
Entre las métricas clásicas de complejidad de un
elemento software, destacan las siguientes:
● Complejidad ciclomática.
● Fan-in (concentración) y Fan-out (expansión)
● Complejidad de un módulo
Medición del Producto
Complejidad ciclomática, V(G), es una métrica
definida para evaluar la complejidad de un
programa.
Está basada en la teoría de grafos y mide el número
de caminos linealmente independientes de un
programa, que pueden ser representados mediante
grafos de flujo de control.
 Medición del Producto
Complejidad ciclomática, V(G)

Grafos de control.
Representación de las estructuras básicas de un programa.
Medición del Producto
A partir del grafo de control, las alternativas de
cálculo de esta métrica son las siguientes:
● V(G) = A - N + 2, siendo A el número de arcos
y N el número de nodos.
● V(G) = r, siendo r el número de regiones
cerradas del grafo.
● V(G) = c + 1, siendo c el número de nodos de
condición.
Medición del Producto
A mayor valor de la métrica V(G) entonces mayor
la complejidad del programa.
Se indica también que un valor razonable de esta
métrica para que un módulo sea mantenible debe
ser menor de diez, V(G) < 10.
Medición del Producto
a. V(G) = A - N + 2
V(G) = 14 - 11 + 2
V(G) = 5
b. V(G) = r
V(G) = 5
c. V(G) = c + 1
V(G) = 4 + 1
V(G) = 5
Medición del Producto
Fan-in y Fan-out, propuestas por Henry y
Kafura en 1981, ambas métricas trabajan sobre la
estructura de un módulo representado como un
árbol o grafo de llamadas entre módulos.
El fan-in de un módulo m es el número de flujos
que terminan en m.
El fan-out de un módulo m es el número de flujos
que salen de m.
Medición del Producto
Complejidad de un módulo, está basada en las
métricas fan-in y fan-out y fue creada también
Henry y Kafura en 1981, siendo su definición:
MHK = longitud(i) * [fan-in(i) * fan-out(i)]2

Donde, longitud(i) es el número de sentencias de

lenguaje de programación en el módulo i.
 Medición del Producto

Diagrama de Estructura. Programa de Gestión de Préstamos bibliotecarios.

Medición del Producto

Módulo Fan-In Fan-out [Fan-in*Fan-out]2 Longitud MHK

Gestionar Peticiones 2 2 16 10 160

Consultar stock 1 1 1 14 14

Tratar Petición 1 1 1 20 20

Informar Petición 1 0 0 6 0

Leer Petición Préstamo 0 1 0 8 0

Rechazar Petición 1 0 0 5 0
Métricas Orientadas a Objetos
El software desarrollado siguiendo el
paradigma orientado a objetos difiere en
importante medida del software desarrollado
usando enfoque tradicionales.
Ello planteó la necesidad de definir nuevas
métricas adaptadas a las características
particulares de este paradigma.
Métricas Orientadas a Objetos
En la bibliografía se pueden encontrar diversas
propuestas de métricas para SOO, a saber:
● Métricas MOOSE (Chidamber y Kremerer, 1994)
● Métricas MOOD (Brito e Abreu y Carapuca , 1994)
● Métricas de Lorenz y Kidd (1994)
● Métricas para UML
● Puntos Función para SOO
Métricas Orientadas a Objetos
Métricas MOOSE, compuesto por las
siguientes métricas:
1. Métodos ponderados por clase
2. Profundidad del árbol de herencia de una clase
3. Número de hijos
4. Acoplamiento entre objetos
5. Respuesta de una clase
6. Falta de cohesión en los métodos
Métricas Orientadas a Objetos
Métodos ponderados por clase (WMC), mide
la complejidad de una clase.
Si todos los métodos son igualmente complejos,
entonces WMC es igual al número de métodos
definidos en la clase.

Donde, Ci es una clase dada que tiene los métodos

M1,...Mn siendo su complejidad respectiva c1,...cn
Métricas Orientadas a Objetos
Profundidad del árbol de herencia de una
clase (DIT), mide el máximo nivel en la
jerarquía de herencia.
Se trata de la cuenta directa de los niveles de la
jerarquía de la herencia, considerando que el nivel
cero de la jerarquía es la clase raíz. Se considera
una medida del número de clase que en potencia se
pueden ver afectadas por algún cambio en la clase.
Métricas Orientadas a Objetos
Número de hijos (NOC), es el número de
subclases subordinadas a una clase en la
jerarquía, es decir la cantidad de subclases que
pertenecen a una clase.
Es un indicador del nivel de reutilización, de
la posibilidad de haber creado abstracciones
erróneas y del nivel de pruebas requerido.
Métricas Orientadas a Objetos
Acoplamiento entre objetos (CBO), indica
para una clase el número de otras clases con las
que está acoplada.
Un objeto está acoplado a otro, cuando actúa sobre
ese objeto; por ejemplo cuando un método de un
objeto utiliza un método de otro objeto.
Esta métrica se considera útil para predecir el
esfuerzo para el mantenimiento y las pruebas.
Métricas Orientadas a Objetos
Respuesta de una clase (RFC), indica el
número de métodos que pueden ser ejecutados
potencialmente como respuesta a un mensaje
recibido por un objeto de esa clase.
RFC se calcula contando las ocurrencias de
llamadas a otras clases de una clase particular.
Métricas Orientadas a Objetos
Falta de cohesión en los métodos (LCOM),
establece en qué medida los métodos hacen
referencia a atributos.
Se calcula como el número de pares de funciones
sin variables compartidas de instancia menos el
número de pares con variables de instancia
compartidas.
Métricas Orientadas a Objetos
Falta de cohesión en los métodos (LCOM) es
una métrica de la cohesión de una clase en base al
número de atributos comunes usados por
diferentes métodos.
Un valor alto en LCOM implica falta de cohesión,
es decir, escasa similitud entre los métodos siendo
siempre deseable un alto grado de cohesión en los
métodos de una clase.
Métricas Orientadas a Objetos
Métricas MOOD. El objetivo de estas métricas es
medir los principales mecanismos de paradigma
OO, tales como encapsulamiento, herencia,
polimorfismo y paso de mensajes y su consecuente
influencia sobre la calidad del software y la
productividad en el desarrollo.
Son aplicadas en los diagramas de clases en la fase
de diseño.
Métricas Orientadas a Objetos
Métricas MOOD.
● Factor de ocultamiento de los métodos (MHF)
● Factor de ocultamiento de los atributos (AHF)
● Factor de herencia de los métodos (MIF)
● Factor de herencia de los atributos (AIF)
● Factor de polimorfismo (PF)
Métricas Orientadas a Objetos
Factor de ocultamiento de los métodos
(MHF). Mide la proporción entre los métodos
definidos como protegidos o privados y el número
total de métodos.
MHF se propone como una medida de
encapsulación, cantidad relativa de información
oculta.
Métricas Orientadas a Objetos
Factor de ocultamiento de los atributos
(AHF). Se define como el cociente entre la suma
de las invisibilidades de todos los atributos
definidos en todas las clases y el número total de
atributos definidos en el sistema considerado.
La invisibilidad de un atributo, es el
porcentaje del total de clases desde las cuales los
atributos son invisibles. Mide encapsulación.
Métricas Orientadas a Objetos
El factor de herencia de los métodos (MIF)
se define como el cociente entre la suma de los
métodos heredados en todas las clases del sistema
considerado y el número total de métodos
existentes (tanto localmente como heredados) en
todas las clases.
MIF se define como una medida de herencia y por
tanto como una medida de reutilización.
Métricas Orientadas a Objetos
El factor de herencia de los atributos (AIF)
se define como el cociente entre la suma de los
atributos heredados en todas las clases del sistema
considerado y el número total de atributos
existentes (tanto localmente como heredados) en
todas las clases.
AIF también se define como una medida de
herencia y por tanto, medida de reutilización.
Métricas Orientadas a Objetos
El factor de polimorfismo (PF) se define como
el cociente entre el número actual de posibles
diferentes situaciones de polimorfismo y el número
máximo de posibles situaciones distintas de
polimorfismo para la clase Ci.
PF es una medida de polimorfismo y una
medida indirecta de la asociación dinámica en un
sistema.
Métricas Orientadas a Objetos
Métricas para UML. Se basan en las diversas
propuestas de métricas para los distintos tipos de
diagramas UML.
● Métricas de Casos de Uso
● Métricas de Diagramas de Clases UML
● Métricas de Diagramas de Estados
● Métricas de Expresiones OCL
Métricas Orientadas a Objetos
Métricas de Casos de Uso. Marchesi (1998) que
propuso un conjunto de métricas de
complejidad para diagramas de caso de uso
consistentes en:
● Número de casos de uso (Ncu)
● Número de actores (Na)
● Número de relaciones de inclusión y de
extensión (Nri, Nre)
Métricas Orientadas a Objetos
Diagramas de Clases UML. Genero et al.
(2004) definieron un conjunto de métricas para la
complejidad estructural de diagramas de clase
debido al uso de relaciones de UML, tales como
asociaciones, generalizaciones, dependencias y
agregaciones.
Estas métricas, pueden ser buenos indicadores de
las características de mantenibilidad.
Métricas Orientadas a Objetos
Diagramas de Clases UML.
● NDep, número total de relaciones de dependencias
en el diagrama de clases.
● NAggH, número total de jerarquías de agregación,
estructura todo-parte, dentro de un diagrama de
clases.
● NGenH, número total de jerarquías de
generalización dentro de un diagrama de clases.
Métricas Orientadas a Objetos
Diagramas de Clases UML.
● NAssoc, número total de asociaciones.
● NAgg, número total de relaciones de agregación
dentro de un diagrama de clases, cada par todo-parte
de una relación de agregación.
● NGen, número total de relaciones de generalización
dentro de un diagrama de clases, cada par padre-hijo
de una relación de generalización.
Métricas Orientadas a Objetos
Diagramas de Clases UML.
MaxDIT, Valor máximo de MIT,
profundidad del árbol de herencia, calculada
para cada clase del diagrama de clases.
DIT, para una clase dentro de una jerarquía de
generalización es el camino más largo desde la
clase hasta la raíz de la jerarquía.
Métricas Orientadas a Objetos
Diagramas de Clases UML.
MaxHAgg, Valor máximo de HAgg, calculada
para cada clase del diagrama de clases.
HAgg, para una clase dentro de una jerarquía de
agregación es el camino más largo desde la clase
hasta las hojas.
Métricas Orientadas a Objetos
Taller. Actividad Grupal.
Dado los siguientes diagramas de casos de uso y
diagrama de clases, calcule las métricas siguientes:
● Métricas de diagramas de casos de uso
● Métricas UML
● Métricas MOOSE
Otras métricas
Puntos Función, fue definida por Albrecht en
1979 con el fin de predecir el esfuerzo y el costo de
desarrollo.
Un punto función es una medida sintética del
tamaño funcional de un sistema independiente de
la tecnología y lenguaje de programación utilizado
para desarrollarlo.
Otras métricas
La fórmula general para calcular los Puntos
Función, es:
PF = PFSA *FCT
Donde,
PFSA, son los puntos función sin ajustar, y
FCT, es un factor de corrección técnica.
Otras métricas
Para calcular los PF sin ajustar es necesario contar
el número de elementos de cada uno de los
siguientes tipos de elementos del sistema:
● Entradas externas
● Salidas externas
● Consultas externas
● Archivos lógicos internos
● Archivos de interfaz externos
Lección (posibles temas)
¿Qué aspectos técnicos (temas) pueden ser necesarios de estudiar en el
proceso software/producto software?
¿Cómo podríamos medir la complejidad de un proyecto/proceso?
¿Cómo podríamos medir la complejidad de un programa
estructurado/orientado a objetos? ¿Qué variables servirían?
¿Qué elementos podemos medir de la fase de
análisis/diseño/construcción/pruebas? ¿Qué variables servirían?
¿Cómo podríamos medir la productividad de un equipo de
desarrollo/programador? ¿Qué variables debemos tener en cuenta?
¿Cómo podríamos medir la mantenibilidad de un programa/sistema?
Referencias bibliográficas
● Piattini Mario y Otros. Calidad de Sistemas Informáticos.
Alfaomega Rama. Tercera Edición. Año 2015.
● Piattini Mario y Otros. Medición y estimación del software.
Técnicas y métodos para mejorar la calidad y la productividad.
Alfaomega Rama. Primera Edición. Año 2008.
● Roger Y. Lee. Software Engineering: A Hands-On Approach.
Atlantis Press. Año 2013.