PDF de programación - Tema 09 - Métricas - Ingeniería del Software

Tema 09 –
Métricas

Ingeniería del Software

Rubén Fuentes Fernández

Dep. Ingeniería del Software e Inteligencia Artificial

Facultad de Informática

Universidad Complutense Madrid

Trabajando con Antonio Navarro, Juan Pavón y Pablo Gervás

Contenidos

•

Introducción
– Problemática

• Aspectos de la solución

– Medidas, métricas e indicadores
– Métricas del proceso
– Métricas del proyecto
– Métricas de productividad
– Métricas de calidad
– Línea base de métricas

Rubén Fuentes Fernández

Ingeniería del Software

2

1

Introducción

• La existencia de medidas numéricas facilita el conocimiento 

de un fenómeno.

• Hay cuatro razones para medir:

– Caracterizar
– Evaluar
– Predecir
– Mejorar

Rubén Fuentes Fernández

Ingeniería del Software

3

Medidas, métricas e indicadores

• A la hora de medir manejamos 3 conceptos diferentes:

– Una medida proporciona una indicación cuantitativa de la extensión, 
cantidad, dimensiones, capacidad o tamaño de algunos atributos de 
un proceso o producto.

• Ej. un programa tiene 10000 LDC (Líneas De Código)

– Una métrica es una medida cuantitativa del grado en que un sistema, 

componente o proceso posee un atributo dado.

• Ej. la productividad del proyecto fue de 500 LDC/PM (LDC / Persona‐Mes)

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

proporcionan una visión profunda del proceso del software, del 
proyecto de software o del producto en sí.

• Ej. la productividad media de nuestra empresa es de 500 LDC/PM y en el 

último proyecto ha sido de 250 LDC/PM.

Rubén Fuentes Fernández

Ingeniería del Software

4

2

Proceso y factores del proyecto

Producto

Características

del cliente

Condiciones
del negocio

Proceso

Personas

Tecnología

Entorno de
desarrollo

Rubén Fuentes Fernández

Ingeniería del Software

5

Mediciones en el proceso y del proyecto

• El objetivo es doble, porque se busca establecer:

– Métricas del proyecto  indicadores del proyecto
– Métricas del proceso  indicadores del proceso

• Las métricas del proceso son estratégicas.

– Determinan el curso del proceso de producción de productos.
– Múltiples proyectos.

• Las métricas del proyecto son tácticas.
– Determinan el curso del proyecto actual.

• Técnicamente no existe gran diferencia entre ambas.

– Podemos concebir las métricas del proceso como recopilaciones de 

métricas del proyecto.

Rubén Fuentes Fernández

Ingeniería del Software

6

3

Indicadores en el proceso y el proyecto

• Los indicadores del proyecto permiten al gestor:

– Evaluar el estado del proyecto en curso.
– Seguir la pista de riesgos potenciales.
– Detectar áreas problemáticas antes de que se conviertan en críticas.
– Ajustar el flujo y las tareas de trabajo.
– Evaluar la habilidad del equipo del proyecto en controlar la calidad de 

los productos de trabajo de la Ingeniería del Software (IS).

• Los indicadores del proceso permiten:

– Al gestor, evaluar lo que funciona y lo que no.
– A la organización, tener una visión profunda de la eficacia de un 

proceso ya existente.

Rubén Fuentes Fernández

Ingeniería del Software

7

Métricas y mejora del proceso

• Métricas del proceso  indicadores del proceso  mejora en 

el proceso

• Si la gestión del proyecto se basa en el personal, el problema, 

el proceso y el propio proyecto, ¿por qué nos centramos en 
mejorar el proceso?
– Porque el proceso es un factor clave y controlable para mejorar la 

calidad del software y el rendimiento de la organización.

Rubén Fuentes Fernández

Ingeniería del Software

8

4

Métricas privadas y públicas del proceso

• Métricas privadas:
– Índices de defectos
– Errores de desarrollo

• Públicas para el equipo:

– Índices de defectos
– Errores de desarrollo
– LDC
– Puntos Función (PF)

Rubén Fuentes Fernández

Ingeniería del Software

9

Uso de las métricas del proceso

• Las métricas del proceso pueden ser muy útiles, pero hay que 

saber interpretarlas.

• Unas normas básicas de interpretación son:
– Utilizar el sentido común al interpretar los datos.
– Proporcionar una realimentación regular a particulares y equipos.
– Establecer métricas claras y objetivos para alcanzarlas.
– Si una métrica identifica un área problemática no se debería 

considerar como negativa.

– Hay que interpretar todas las métricas en su conjunto, y no primar una 

en particular.

– No utilizar métricas para evaluar o amenazar a particulares o equipos.

Rubén Fuentes Fernández

Ingeniería del Software

10

5

Mejora estadística del proceso

• La utilización de métricas e indicadores fiables da lugar a una 

mejora estadística del proceso del software.

• Esta mejora se basa en un análisis de fallos que identifica la 
causa y origen de errores y defectos para varios proyectos de 
software.
– El error es un fallo en un producto generado durante el proceso de IS 

que es detectado antes de la entrega al cliente.

– El defecto es un fallo detectado después de la entrega al cliente.

Rubén Fuentes Fernández

Ingeniería del Software

11

Análisis de fallos del proceso

1. Se categorizan por origen todos los errores y defectos de 

varios proyectos.

2. Se registra el coste de corregir cada error o defecto.
3. El número de errores y de defectos de cada categoría se 

cuentan y se ordenan decrecientemente.

4. Se computa el coste global de errores y defectos de cada 

categoría.

5. Los datos resultantes se analizan para detectar las categorías 

que producen el coste más alto para la organización.

6. Se desarrollan planes para modificar el proceso con el 

intento de eliminar (o reducir la frecuencia de apariciones 
de) la clase de errores y defectos que sean más costosos.

Rubén Fuentes Fernández

Ingeniería del Software

12

6

Diagrama de frecuencias de fallos

• Aplicando los pasos 1 y 2 del proceso de análisis de fallos se 

puede elaborar un diagrama de frecuencias con la distribución 
de fallos.

Causas de
fallo y su
origen para
varios
proyectos

Rubén Fuentes Fernández

Ingeniería del Software

13

Diagrama de espina de fallos

• También se puede optar por desarrollar un diagrama de 

espina para ayudar a diagnosticar los datos presentados en el 
diagrama de frecuencias.

• En el diagrama de espina las                                                     

líneas horizontales identifican                                         
problemas y las verticales                                                    
posibles causas.

• Se dan diagramas para cada                                                   
origen de defectos y se                                                         
estudian para mejorar el                                                     
proceso.

Rubén Fuentes Fernández

Ingeniería del Software

14

7

Métricas del proyecto

• Las métricas del proyecto se emplean para determinar el 

curso del proyecto actual.
– La primera aplicación de las métricas del proyecto ocurre durante la 

estimación.

• Se emplean datos históricos para hacerla.

– Después el gestor utiliza los datos de las métricas para supervisar y 

controlar el avance.

• A medida que avanza el proyecto, las medidas del esfuerzo y el tiempo se 

comparan con las de la planificación.

• Permiten modificar el enfoque técnico para mejorar la calidad si es 

necesario.

• En el proyecto también se emplean métricas técnicas o de 
producto para medir las técnicas de diseño y programación.

Rubén Fuentes Fernández

Ingeniería del Software

15

Métricas del software

• El contexto de uso identifica al tipo de métrica.
• Por ello nos referiremos globalmente a las métricas del 

producto y del proceso como métricas del software.

Métrica del SW
Tamaño

PF (resp. PC)

Otras

Productividad
€ / LDC
PgDoc / KLDC
€ / PF
PgDoc / PF
LDC / PM
PF / PM
€ / PgDoc

Calidad
errores / KLDC
defectos / KLDC
errores / PF
defectos / PF
errores / PM
errores / (errores + defectos)

Rubén Fuentes Fernández

Ingeniería del Software

16

8

Métricas de productividad

• Orientadas al tamaño

– Se obtienen considerando las medidas de productividad y 

normalizándolas por el tamaño del código (ej. LDC) o del equipo (ej. 
persona).

• Orientadas a la función

– Se obtienen considerando las medidas de productividad y 

normalizándolas por una medida de la funcionalidad (ej. PF) entregada 
por la aplicación.

– Como la funcionalidad no se puede medir directamente, se debe 

derivar indirectamente de otras medidas directas.

• Otras

– Cruciales pero no están normalizadas por tamaño ni funcionalidad, 

aunque sí por ejemplo por esfuerzo (ej. PM).

Rubén Fuentes Fernández

Ingeniería del Software

17

Pautas para el cálculo de LDC

• Debe contabilizarse cada línea nueva o modificada.
•

Las líneas para la instrumentación de código no deben incluirse en 
el tamaño total, salvo que tengan un carácter definitivo.
– Ej. código usado para pruebas.
Las líneas de código de programas de prueba tan solo se 
contabilizan si se desarrollan con el nivel de calidad exigido al 
entregar el producto.

•

• Se contabilizan las líneas correspondientes a las llamadas al sistema 

operativo.

• No se consideran los comentarios.
• No se contabiliza el pseudocódigo.
• Cada ocurrencia de macro o include se considera como una línea.
• El código generado por macros o includes sólo se considera una vez.

Rubén Fuentes Fernández

Ingeniería del Software

18

9

LDC: ventajas y limitaciones

• Las LDC no están comúnmente aceptadas.

– Su cálculo no es trivial.

• Ventajas:

•

– Fácil de calcular.
– Existen muchos modelos de estimación basados en LDC.
– Existen muchas medidas de LDC.
Inconvenientes:
– Dependientes de los lenguajes de programación.
– Perjudican a los programas cortos pero bien diseñados.
– Difícil su uso en estimación debido al nivel de detalle que requieren.

Rubén Fuentes Fernández

Ingeniería del Software

19

Puntos de función

• La funcionalidad de un programa viene representada por el 
Punto de Función (PF), que se deriva de las mediciones del 
software.

• Se basan en una combinación de caracte