1

�

Métricas

Juan Pablo Quiroga GonzálezDpto. de Ingeniería de Sistemas y ComputaciónUniversidad de los Andes - 2004

�

ReferenciasLibros� Humphrey, Watts. A discipline for

software Engineering. Addison-Wesley, 1995. Capítulo 7.

� Pressman, Roger. Software Engineering. A practitioner’s approach. McGrawHill. 2001. 5ta Edición. Cáps. 19 y 24

2

�

ReferenciasOtros � Software Metrics. Mill, Everald.

www.sei.cmu.edu/publications/documents/cms/cm.012.html

� Métricas de calidad de la NASA para Sistemas Orientado a Objetos.� http://satc.gsfc.nasa.gov/metrics/index.html� http://satc.gsfc.nasa.gov/support/index.html

�

Métricas - ¿Para qué sirven?� Obtener una comprensión cuantitativa

del proceso. � Evaluar un producto, un proceso o una

organización. � Controlar un producto o un proceso. � Producir un estimado o un plan. � Mejorar la productividad y la calidad del

software� Comprender la efectividad del proceso

3

�

Necesidad� El problema es la crisis del software

�Mejorar el plan de trabajo�Mejorar la estimación de los costos�Mejorar la calidad de los productos�Mejorar la productividad

� No hay forma de evaluar el proceso� Mejoramiento de la administración de

los proyectos se basa en lograr medir aspectos primordiales para el desarrollo.

�

Necesidad

� Lo importante de las métricas de software es la identificación y la medición de parámetros esenciales que afectan el desarrollo del software.

4

�

Definición

� Métricas de software trata de las mediciones del producto de software y el proceso mediante el cual son desarrollados.

�

Características de una buena métrica� Es simple y es definida precisamente� Objetiva� Fácilmente obtenible� Válida� Robusta� Además es importante que tenga una escala

de medición apropiada.� En especial se preocupa por evaluar la

funcionalidad y el presupuesto de un proyecto.

5

Escala de mediciones� Es importante determinar la escala y

para eso debe evaluar para qué se estámidiendo.

� Tipos de datos�Nominal ( Igual, diferente )

� Categorías� Ej. Categorías de los objetos

�Ordinal ( mayor o menor )� Rangos� Ej. Experiencia del programador (alta, baja,

media)

�

Escala de mediciones� Intervalo ( más o menos )

� Diferencias� Ej. Complejidad

�Radio ( Proporciones )� Cero absoluto� Ej. LOC

6

��

Clasificación de las medidas� Objetiva

�Cuenta o determina magnitudes numéricas�Ej. Líneas de código (Producto)� Tiempo de desarrollo (Proceso)

� Subjetiva � Implica un juicio humano�Ej. Clasificación de los objetos (Producto)

� Nivel de experiencia de un programador(Proceso)

��

Clasificación de las medidas� Absoluta

�Es independiente de las medidas de otros elementos en una muestra

�Ej. Tamaño de un programa

� Relativa �Es dependiente de las medidas de otros

elementos en una muestra�Ej. Tamaño promedio de las categorías de

objetos

7

��

Clasificación de las medidas� Explícita (Primitiva)

�Se toma directamente�Ej. LOC � Número de defectos en pruebas

� Derivada ( Calculada )�Se calcula a partir de otras medidas �Ej. LOC/Hora

� Porcentaje de tiempo por fase

��

Clasificación de las medidas� Dinámica

�Depende del tiempo y cambia con el transcurso de éste

�Ej. Rangos de predicción

� Estática�Una vez tomada permanece invariante�Ej. Tiempo de desarrollo

8

��

Clasificación de las medidas� Predictiva

�Puede obtenerse o generarse con anticipación al evento medido

�Ej. Tiempo estimados� Número de defectos estimados por fase

� Explicativa �Se calcula después de ocurrido el evento�Ej. Tiempo real� Número de defectos reales

��

Las métricas y el proceso definido� El proceso definido sirve como modelo

mental para entender el proceso y preguntarse sobre él.

� Igualmente ayuda a recolectar información útil sobre el proceso

� Al medir actividades complejas, conviene hacer una división de las mismas. Una definición inicial del proceso puede ayudar mucho.

� Ejemplo: pruebas

9

��

Métricas del proceso de software� Las métricas del proceso de software se

dividen en: �Métricas del producto �Métricas del proceso �Métricas de los recursos

��

Métricas de producto� Miden el tamaño o cantidad de un

producto que se produjo o se piensa producir�Desde los requerimientos�Hasta el sistema instalado

� Métricas del producto deben medir:�Complejidad del diseño del software�El tamaño del programa final�Número de páginas producidas por

documentación

10

�

Métricas de producto� Ejemplos:

�LOC �Páginas de documentación �Número de formularios diseñados

(interfaz)�Número de clases escritas �etc.

�

Métricas de producto� Pueden aplicarse a diversos tipos de

productos: �Módulos �Manuales �Componentes �etc.

� Pueden restringirse a fases específicas (i. e. LOC modificadas durante pruebas).

11

��

Métricas de productoimportantes� Tamaño

�Líneas de código� No se pueden medir antes directamente� Depende de la definición del estándar de

conteo (líneas físicas, líneas lógicas)

�Puntos de función� Medir con anterioridad el programa� No son medibles al final directamente

��

Métricas de productoimportantes� Tamaño

�Bang� Mide las funciones como indicativo del tamaño

del software� Algorítmos

�PROBE� Es medible bastante bien desde la fase de

diseño al utilizar programación orientada a objetos, aunque depende del Proxy.

12

��

Métricas de productoimportantes� Complejidad

�Ciclomática v(G) (Cyclomatic) McCabe� Flujo de control� Grafos

� V(G) = e – n + 2� E = número de límites� N = número de nodos

� Esta relacionado con el esfuerzo de programa, el desempeño de debug y el esfuerzo de mantenimiento.

��

Métricas de productoimportantes� Complejidad

�Extensiones de v(G) - Myers� Normalmente McCabe no diferencia

condiciones sencillas y complejas� V(G)´=v(g)[l,u]� L y u son los límites superior e inferior de

complejidad

�Extensiones de v(g) - Stetter� Añadir las declaraciones de datos y referencias

de datos

13

��

Métricas de productoimportantes� Complejidad

�Nodos� Describir el grafo del flujo de control de un

programa con un nodo por cada instrucción o un bloque de instrucciones secuenciales.

�Flujo de información� C = [longitud del procedimiento] *

� [fanin * fanout]^2

� Fanin = Información que entra� Fanout = información que sale

��

Métricas de productoimportantes� Halstead

�Medir varias cosas de un programa�Vocabulario del programa

� Medir los tokens diferentes

�Longitud del programa� Medir el número total de operadores y

operandos de un programa

�Volumen del programa� Tamaño que ocupa

14

��

Métricas de productoimportantes� Calidad

�Métricas de errores� Número de cambios de requerimientos� Número de cambios de diseño� Número de errores detectados en inspecciones� Número de errores detectados en pruebas� Número de cambios de código requeridos.

��

Métricas de productoimportantes� Calidad

�Métricas de confiabilidad� MTTF – Mean time to failure

�Métricas de mantenibilidad� Complejidad de las actividades de

mantenimiento v(g)

15

�

Métricas de proceso� Cuantifican el comportamiento del proceso. � Usualmente son objetivas, absolutas,

explícitas y dinámicas. � Son típicas las métricas que cuentan

eventos: � Número de defectos detectados en inspección � Número de requisitos modificados � Número de defectos de diseño detectados

durante las pruebas

�

Métricas de proceso� También son usuales las métricas

relativas al tiempo: �Tiempo total de desarrollo (tiempo de ciclo) �Porcentaje del tiempo total de desarrollo

dedicado a las pruebas �Tiempo promedio de corrección de un

defecto en pruebas

16

��

Métricas de recursos� Se refieren a los recursos utilizados en el

proyecto, usualmente tiempo de trabajo. � Es importante usar unidades adecuadas. En

medidas personales usualmente minutos. � Medir el tiempo en minutos puede parecer

excesivo, pero es sencillo: Una vez se hace las unidades son poco importantes.

� La información detallada puede ayudar a detectar y eliminar fuentes de distracción y otras causas de baja productividad

��

Métricas de recursos� Empíricas

� Wolverton – Indicar los recursos en una matriz de vida del producto

� Categorizan los elementos del software� Se compara con algo similar para indicar el costo.

� Modelos estadísticos� Medir el esfuerzo en personas por mes� E = a L^b, L=LOC� a y b se calculan haciendo una regresión con

información histórica

17

��

Métricas de recursos� Basadas en teoría

�Rayleigh Model� Medir el número de personas que debe existir

en un proyecto en cualquier momento

�Modelo de Halstead� Medir el tiempo requerido para desarrollar un

programa basado en discriminaciones mentales elementarias (basadas en el vocabulario) y el código requerido

��

Métricas de recursos� Modelos compuestos

�COCOMO – Boehm� Mide el esfuerzo para medir el costo del

programa� Depende de la forma de desarrollo (orgánica,

semisuelta y embebida) y del nivel del modelo (básico, intermedio y detallado)

� Se miden atributos de costo

18

��

Métricas de recursos� Modelos compuestos

�SOFTCOST – Tausworthe� Incluye factores de calidad� Depende de un conjunto de preguntas

�SPQR – Jones� Software Productivity, Quality and Reliability� Factores bien definidos y no definidos que

miran los tres aspectos anteriores

��

Métricas de recursos� Modelos compuestos

�COPMO - Thebaut� Contar esfuerzo adicional requerido cuando se

desarrolla en equipo� Número de personas que hay durante la vida

del proyecto

19

��

Métricas de recursos� Modelos compuestos

�ESTIMACS – Robin� Estimador del esfuerzo de desarrollo del

sistema� Estimador del costo y staff� Estimador de configuración de hardware� Estimador de riesgos� Analizador de portafolio ( Incluir información de

otros proyectos )

��

El paradigma Objetivo-Pregunta-Métrica (OPM)� Desarrollado por Basili para guiar los

esfuerzos de medición. � Consiste en:

� Definir los objetivos principales (con respecto a recolección de datos) en la actividad que se va a realizar.

� Construir un conjunto de preguntas que ayude a alcanzar dichos objetivos.

� Definir y recolectar la información necesaria para responder dichas preguntas.

20

�

OPM aplicado al PSP� Objetivos fundamentales:

�Entender como funciona el proceso personal de desarrollo de software.

�Determinar los pasos que podrían tomarse para mejorar la calidad de los productos.

�Determinar el impacto de los cambios del proceso en la productividad.

�Establecer mecanismos para evaluar el mejoramiento del proceso.

�Facilitar la producción de planes más precisos.

�

OPM aplicado al PSP� Preguntas de apoyo:

�¿Cuáles aspectos de mi desempeño son importantes?

�¿Cómo pueden medirse dichos aspectos? �¿Cuál es el mejor desempeño que he

alcanzado? �¿Qué puedo aprender de dicho logro? �¿Qué han alcanzado otras personas? �¿Cuáles métodos de otras personas

podrían ayudarme?

21

��

Recolección de datos� La recolección de información es una

actividad fundamental para el análisis y mejoramiento del proceso de software.

� Típicamente, la recolección se hace manualmente: �El computador no puede saber que

estamos haciendo. �La información de defectos no se puede

obtener del análisis automático del código

��

Recolección de datos

�Es difícil saber determinar de manera automática la fase del proceso en que se originó un defecto

�La información recolectada manualmente puede, sin embargo, tratarse con herramientas automatizadas.

22

��

Formularios� Los formularios pueden resultar muy útiles

para desarrollar planes y estimados. � También son útiles como depósitos de

información. � En algunos casos los formularios cerrados

son mejores, en otros sirven más los formularios abiertos y expansibles.

� Al diseñar formularios, conviene probarlos primero. Esto puede hacerse con datos de proyectos anteriores.

��

Otras herramientas� La base de datos de errores

�Mantiene un registro de los errores detectados y corregidos en los diversos proyectos a lo largo del tiempo.

� La hoja de cálculo �Permite adelantar muchos de los cálculos

y conteos propios del PSP de manera automática.

23

��

Otras herramientas� El cuaderno de ingeniería

�Permite documentar las decisiones de trabajo y esbozar soluciones de problemas. Sirve como vehículo de documentación para el análisis posterior.

��

Posibles problemas con la medición del proceso� La recolección de datos es compleja y

demanda tiempo y esfuerzo. � Si no se tiene una clara motivación,

fácilmente puede convertirse en una labor tediosa.

� Aunque el PSP define en primera instancia el proceso, es importante entenderlo y determinar el valor personal de la información recolectada.

24

��

Posibles problemas con la medición del proceso� La información personal debe

analizarse con objetividad. El no hacerlo puede traer consecuencias negativas.

� El compartir la información personal requiere cuidado y prudencia. Una vez más el actuar descuidadamente pueden causar problemas.

��

Métricas para sistemas orientado a objetos� Características

�Localización� Característica del software que indica la

manera en que la información estáconcentrada en el programa

�Encapsulamiento� El empaquetamiento de una colección de

items.

25

�

Métricas para sistemas orientado a objetos� Características

�Ocultamiento de información� Suprimir los detalles operacionales de un

componente de un programa

�Herencia� El mecanismo que permite que las

responsabilidades de un objeto puedan ser propagadas a otros objetos

�

Métricas para sistemas orientado a objetos� Características

�Abstracción� Mecanismo que permite a los diseñadores

enfocarse en los detalles esenciales de un componente del programa con un poco conocimiento de los detalles de bajo nivel.

26

��

Métricas OO – Orientada a clases� Suite de Métricas CK

�Creada por S.R. Chidamber y C.F. Kemereren 1.991

�Revisada por Basili en 1.996

��

Métricas OO – Orientada a clases – Suite de métricas CK� WMC - Pesado de métodos por clase *

�WMC – Weighted methods per class�WMC = SUM( ci )�Donde ci es la complejidad del método i�Puede ser la complejidad ciclomática�La complejidad está relacionado con el

esfuerzo requerido para implementar y probar una clase.

27

��

Métricas OO – Orientada a clases – Suite de métricas CK� DIT – Profundidad del árbol de herencia

� DIT – Depth of the inheritance tree� Máxima longitud de un nodo del árbol a la raíz de

este.� Indica dificultades potenciales cuando se intenta

predecir el comporamiento de una clase.� Un DIT alto implica una alta complejidad del

diseño� También indica un alto nivel de reutilización

��

Métricas OO – Orientada a clases – Suite de métricas CK� NOC - Número de hijos

�NOC – Number of children�Las subclases que estan inmediatamente

subordinadas a una clase se denominan hijas

�Un alto NOC aumenta el esfuerzo para realizar las pruebas también aumenta

28

��

Métricas OO – Orientada a clases – Suite de métricas CK� CBO - Acoplamiento entre objetos de la

clase *�CBO - Coupling between object classes�Número de clases directamente

relacionadas para lograr responder a un servicio (cualquier tipo de asociación)

�Altos valores de CBO complican las modificaciones y las pruebas

�Normalmente CBO debe mantenerse bajo

��

Métricas OO – Orientada a clases – Suite de métricas CK� RFC – Respuesta de una clase *

� RFC – Response for a class� Es el conjunto de métodos que potencialmente se

ejecutan en respuesta de un mensaje recibido por un objeto de esa clase

� Se suman los métodos públicos de la clase más los métodos que son llamados dentro del código interno de la clase

� Aumenta la dificultad de las pruebas� Aumenta la complejidad del diseño

29

��

Métricas OO – Orientada a clases – Suite de métricas CK� LCOM – Falta de cohesión de los

métodos�LCOM – Lack of cohesion in methods�Cuando un método de una clases accede

a uno o más atributos de la clase.�LCOM es el número de métodos que

acceden uno o más atributos iguales.� Por ej. El analizador y el modificador por

atributo, si hay cuatro atributos, el LCOM mínimo sería de 8

�LCOM muy altos indican fallas en el diseño

��

Métricas OO – Orientada a clases – Otras suites� Lorenz y Kidd

�Class size – CS�Number of operatiosn overriden by a

subclass – NOO�Number of operations added by a subclass

– NOA�Specialization Index – SI

� SI = ( NOO x level ) / Mtotal� Mtotal número de métodos totales de la clase

30

�

Métricas OO – Orientada a clases – Otras suites� MOOD

�Metrics for Object-oriented design�Harrison, Counsell y Nithi�Method inheritance factor – MIF�Coupling Factor – CF�Polymorphism factor - PF

�

Métricas OO – Orientada a operaciones� Propuesta por Lorenz y Kidd 1994� Tamaño promedio de una operación

�Osavg Average operation size�Líneas de código de cada método�También se puede contar por el número de

mensajes asociados al método�Si es muy alto puede indica que las

responsabilidades no están bien dadas y hay que hacer subdivisión de ellas

31

��

Métricas OO – Orientada a operaciones� OC - Complejidad de la operación

�OC – Operation complexity�Utilizando para medir la complejidad

ciclomática�Se debe mantener baja

��

Métricas OO – Orientada a operaciones� NPavg -Número promedio de

parámetros por operación�Npavg – average number of parameters

per operation�Aumenta la complejidad de colaboración

entre objetos�Más complejas las pruebas�Se debe mantener bajo

32

��

Métricas OO – Pruebas� Encapsulamiento

�LCOM - Lack of cohesion in methods�PAP - Percent public and protected�PAD – Public access to data members

� Herencia�NOR – Number of root classes�FIN – Fan in , múltiple herencia�NOC – Number of children�DIT – Depth of the inheritance tree

��

Métricas OO – Proyecto� Creadas por Lorenz y Kidd 1994� Número de casos de uso o escenarios

�NSS – Number of scenario scripts�La cantidad de casos de uso es

proporcional al número de clases requeridas para cumplir los requerimientos

�Es un indicador fuerte del tamaño del programa

33

��

Métricas OO – Proyecto� Número de clases llave *

�NKC – Number of key classes�Clases que directamente están

relacionadas con la lógica del negocio�Altos valores de NKC indican un trabajo

substancial de desarrollo�Se espera que entre el 20 y el 40% de las

clases sean de este estilo, las demás corresponden a interfaz, comunicaciones, bases de datos, etc.

��

Métricas OO – Proyecto� NSUB - Número de subsistemas

�NSUB – Number of subsystems�Provee una buena forma de saber :

� Las necesidad de recursos� Planeación ( desarrollo paralelo )� Esfuerzo de integración

34

��

Métricas OO – Proyecto� Otras métricas utilizadas relacionadas

con la productividad�Número de clases promedio por

desarrollador�Número promedio de métodos por mes-

persona� Otra forma de estimar el esfuerzo, duracción,

necesidades de personal

��

Metrics� Basado en dos conjuntos de métricas� Object Oriented Metrics, measures of

complexity. Brian Henderson. PrenticesHall. 1996

� OO Design Quality Metrics. An Analysisof Dependencies. Robert Martin. �Agile Software Development, Principles,

Patterns and Practices

35

�

Metrics

�

Metrics� Number of classes

� Cantidad de clases� Problemas:

� Difícil de mantener� Bajo desempeño

36

��

Metrics� Number of children

� Número de subclases de una clase� Problemas:

� Difícil de mantener dado que un cambio en una clase padre afecta las hijas

��

Metrics� Number of interfaces

�Número de interfaces�Problemas:

� Muy poco indica mucho acoplamiento entre las clases aunque es una medida un poco subjetiva

37

��

Metrics� Depth of inheritance tree (DIT)

� Profundidad del árbol de herencia� Problemas:

� Grande implica poca mantenibilidad� Difícil de probar

��

Metrics� Number of Overriden Methods (NORM)

� Número de métodos redefinidos de una clase ancestro

� Problemas:� Difícil de probar� Difícil de mantener� Fallas en el diseño

38

��

Metrics� Number of Methods (NOM)

�Número de métodos de una clase�Problemas:

� Difícil de mantener� Fallas en el diseño, demasiadas

responsabilidades

��

Metrics� Number of attributes

� Número de atributos de una clase� Problemas:

� Fallas en el diseño, demasiadas responsabilidades

39

��

Metrics� LOC

�Líneas de código� Total / Promedio / Desviación Estándar� Por clase / Por Método

�Problemas:� Entre más grande más difícil de mantener� Fallas en el diseño� Problemas de cohesión en el método y en la

clase

��

Metrics� Specialization Index (SI)

� NORM*DIT/NOM� Problemas:

� Entre más grande más difícil de mantener� Difícil de probar

40

�

Metrics� McCabe Cyclomatic Complexity

� Realiza un conteo del número de posibles camino en un método ( ver el código como un grafo)

� Por cada opción posible se suma uno ( if,switch, ?, for, while, &&, || )

� Problemas:� Entre más grande más difícil de mantener� Muy difícil de probar

�

Metrics� Weighted methods per class (WMC)

� Suma de la complejidad de McCabe para todos los métodos de una clase.

� Problemas:� Entre más grande más difícil de mantener� Muy difícil de probar

41

��

Metrics� Lack of cohesion of methods (LCOM)

� Es el número promedio de métodos que acceden a cada uno de los atributos de la clase, menos el número de métodos de la clase diividido por 1-m

� En java el uso de get y set puedo aumentarlo aunque realmente no es importante por lo que metrics no los tiene en cuenta.

� Problemas:� Cercano a 1 indica una clase poco cohesiva que debe

ser divida en varias otras clases

��

Metrics

� Afferent Coupling (Ca)�Número de clases fuera del paquete que

dependen de clases dentro del paquete�Problemas:

� Alto acoplamiento

42

��

Metrics

� Efferent Coupling (Ce)�Número de clases del paquete que dependen

de clases de fuera del paquete�Problemas:

� Alto acoplamiento

��

Metrics

� Instability (I)�Ce/(Ca+Ce)�Problemas:

� Alto acoplamiento

43

��

Metrics� Abstractness (A)

� Número de clases abstractas e interfaces divido por el número total de tipos (incluyendo clases concretas) en un paquete

� Problemas:� Dificil de probar

��

Metrics

� Normalized distance from main sequence(Dn)� |A+I-1|, debe ser cercano a 0 para un buen

diseño de paquete�Problemas:

� Mal diseño del paquete

44

��

Metrics� Number of static methods

� Número de métodos de clase� Problemas

� Problemas en el diseño al combinarse con métodos de instancia

��

Metrics� Number of static attributes

�Número de atributos de clase�Problemas

� Problemas en el diseño al combinarse con atributos de instancia

� Es realmente una clase?

45

�

Metrics� Number of parámetros

� Número de parámetros de un método� Sensible al cambio, es mejor el uso de un objeto

que contenga los parámetros� Problemas

� Más casos para probar el método

Metrics� Nested block depth

� Cantidad de bloques en un método� Partir el método en otros métodos privados� Problemas

� Demasiada complejidad por lo tanto difícil de mantener