Metricas y Ptos de Funcion

MEDICIN DEL
SOFTWARE
MEDICIN DEL SOFTWARE

Las Frases:
Software Engineers are not just good
programers
...Physicists are primarily expected, and
trained, to extend our knowledge, while EEs are
expected to develop products or techniques for
product production. Each career path attracts a
distinct type of student and requires a distinct
educational program.
Most students choose to study EE rather than
Physics because they like building things....
[Parnas99]

1.
2.
3.
4.
5.
6.
7.
8.
9.
Conceptos bsicos
Medidas y modelos
Alcance de las mtricas
Clasificacin de las mtricas
Procesos
Productos
Recursos
Recogida de datos mtricos
Base Histrica
Obtencin de informacin
Mtodo Objetivo/Pregunta/Mtrica
Medicin de atributos internos del producto
Longitud
Funcionalidad
Complejidad
Medidas estructurales
Medicin de atributos externos del producto
Medicin de recursos
Mtricas para sistemas orientados a objetos
3
La Frase:
Debemos recordar que otras disciplinas
cientficas ya han aplicado los
conceptos bsicos de la medicin. En
Ingeniera del Software no hay que
reinventar demasiado, simplemente
aplicar y adaptar la teora ya
existente a las mtricas del software
[Dolado00, pag 39]
La posibilidad de medir es el fundamento de

las disciplinas cientficas y de ingeniera.
Sin poder medir es muy difcil evaluar y
experimentar las tcnicas y los mtodos de
ingeniera del software.
La medicin contribuye a superar algunos
problemas habituales en el desarrollo del
software:
Proporciona requerimientos verificables

expresados en trminos medibles.
Proporciona evidencia cuantificable para
apoyar las decisiones.
Hace ms visible el desarrollo y permite
identificar problemas anticipadamente.
Permite hacer predicciones de coste y tiempo.
Recomienda estrategias de prueba e identifica
los mdulos problemticos.
Permite valorar los efectos en la productividad
y en la calidad.
No se puede controlar lo que no se puede

medir (DeMarco, 1982) y no se puede
predecir lo que no se puede medir (Fenton y
Pfleeger, 1997).
5
1. Conceptos Bsicos
Medida
Una medida proporciona una indicacin cuantitativa de extensin,

cantidad, dimensiones, capacidad y tamao de algunos atributos de un
proceso o producto.
OJO!, problemas con la cualitativas y semi-cualitativas que se
dan con bastante frecuencia.
Medicin
Es el proceso por el que se asignan nmeros o smbolos a atributos de

entidades del mundo real de tal forma que los describe de acuerdo con
reglas claramente definidas. Medida cuantitativa del grado en que
un sistema, componente o proceso posee un atributo dado (IEEE,
1993).
Entidad
medida
se aplica a
1..*
posee
1..*
Atributo
*
Mundo real
(emprico)
Valor
(magnitud)
1..*
mide
se expresa en
1
1
cuantifica
*
Unidad
Mundo formal
(matemtico)
Modelo estructural (parcial) de Kitchenham et al.
1. Conceptos Bsicos
FORMULACIN
Definicin de medidas y mtricas
COLECCIN
Obtencin de datos
ANLISIS
Clculo de mtricas
INTERPRETACIN
REALIMENTACIN
Evaluacin de los resultados
Recomendaciones obtenidas
Proceso de medicin de Roche
1. Conceptos Bsicos
Mtrica
Medida cuantitativa del grado en que un sistema, componente o proceso

posee un atributo dado (IEEE, 1993).
Indicador
Mtrica o combinacin de mtricas que proporcionan una visin

profunda, del proceso de software, del proyecto de software o del
producto en s .
Los indicadores de proceso permiten tener una visin profunda
de la eficacia de un proceso ya existente. Se recopilan de todos los

proyectos de la organizacin durante un largo perodo de tiempo
con objeto de obtener mejoras de los procesos de software a largo
plazo.
Los indicadores de proyecto permiten:
Evaluar el estado del proyecto en curso.
Seguir la pista de los riesgos potenciales.
Detectar reas de problemas antes de que sean crticas.
Ajustar el flujo y las tareas del trabajo.
Evaluar la habilidad del equipo del proyecto en controlar la

calidad de los productos.
Los indicadores de producto permiten evaluar su calidad.

Modelo
Una abstraccin de la realidad que permite observar los detalles de una
entidad o concepto desde una perspectiva particular. El modelo muestra
qu hacer no cmo hacerlo ni quin lo hace.
La Frase:
All models are wrong but
some are useful
[George Box]
2. Medidas
Medidas directas e indirectas:

Una medida directa de una entidad o atributo
no involucra a ninguna otra entidad o atributo
(longitud del cdigo fuente, duracin del proceso
de prueba, nmero de defectos...).
Una medida indirecta se obtiene a partir de
medidas directas (productividad, estabilidad de
requisitos, densidad de defectos en un
mdulo...).
Objetivos de las medidas:
Evaluacin: comprobacin del cumplimiento de
ciertas caractersticas por una entidad que ya
existe(calidad del diseo, fiabilidad del
software...).
Prediccin: estimacin de los atributos que
tendr una entidad que no existe an (coste de
un proyecto, esfuerzo necesario).
El proceso se mide para mejorarlo, rentabilizarlo y

optimizarlo.
El proyecto se mide para gestionarlo, controlarlo, adaptar el flujo
del trabajo y las actividades, y para realizar estimaciones para
futuros proyectos.
El producto se mide para aumentar su calidad o comprobar que
se ajusta a las especificaciones contractuales.
10
3. Alcance de las mtricas

Las mtricas del software abarcan muchas actividades y son mltiples las
razones que justifican su uso :
Estimacin de coste y esfuerzo (o al menos reduccin de

estos)
Modelos y medidas de productividad
Recoleccin de datos (Por amor al arte?...)
Modelos y evaluacin de la calidad (AENOR, ISO, etc.)
Modelos de fiabilidad
Estn incluidos en la mayora de los modelos de calidad.
La especializacin de los modelos de fiabilidad permite

aumentar el entendimiento y control de los productos.
Evaluacin del rendimiento (Pude ser cualitativo)
Aunque es otro aspecto de la calidad, la valoracin del

rendimiento incluye caractersticas observables como tiempos
de respuesta y caractersticas internas como eficiencia de los
algoritmos.
Mtricas estructurales y de complejidad
Para realizar predicciones sobre atributos de calidad

(fiabilidad, facilidad de mantenimiento ...) se pueden medir
atributos estructurales sobre representaciones del software
que estn disponibles antes que el cdigo.
Valoracin de capacidad de madurez (CMMI).
Se pueden medir diferentes atributos del desarrollo para

evaluar la capacidad de una organizacin de desarrollar
software de calidad.
Gestin mediante mtricas
La realizacin de grficos basados en diferentes medidas a lo

largo del proyecto permite conocer el estado del mismo.
Evaluacin y comparacin de mtodos y herramientas
Las investigaciones cuidadosas, con anlisis y mediciones

controladas sobre una herramienta o mtodo permiten
hacerlos ms productivos para situaciones particulares.
Justificacin del uso de nuevos mtodos y /o herramientas
Justificacin de formacin adicional
11
3. Alcance de las mtricas

1.
En cunto podra ser mejorada la productividad si no

tuviese que gastar tiempo en mantenimiento?
2.
Cunto tiempo le cost el ltimo ao adaptar su

presupuesto en trabajar con nuevas versiones de
compiladores, bases de datos o sistemas operativos?
3.
Cules de las aplicaciones que desarrolla su empresa

demanda el mayor tiempo de soporte al usuario?
4.
Cunto tiempo se gasta realmente en testing?
5.
Cre que sus desarrolladores dedican suficiente tiempo a

actividades de diseo?
6.
Su proceso de desarrollo ha madurado en los ltimos aos?
7.
El esfuerzo dedicado a mejorar la calidad del software est

reduciendo el tiempo que se dedica a corregir errores ?
8.
Con qu precisin es usted capaz de estimar proyectos

futuros?
9.
En cuntos proyectos han trabajado cada uno de sus

desarrolladores en el ltimo ao?
10. Cul es el nmero medio de horas por semana que sus

desarrolladores dedican a un proyecto?
Fuente: Karl E. Wiegers, Process Impact, www.processimpact.com
12
4. Clasificacin de las mtricas
El primer paso de la medicin es identificar los atributos o

entidades a medir. Estos pueden ser de tres tipos:
Procesos: atributos de actividades relacionadas con

el software.
Productos: componentes, entregas o documentos

resultantes de una actividad de proceso.
Recursos: entidades requeridas por una actividad de

proceso
Dentro de cada clase anterior se puede distinguir:
Atributos internos: Son aquellos que pueden ser

medidos examinando el proceso, producto o recurso
mismo.
Atributos externos: se miden con respecto a como

el proceso, producto o recurso se relaciona con su
entorno.
ENTIDADES
ATRIBUTOS
Internos
Productos
Especificaciones,
diseo, cdigo...
Procesos
Realizacin de la
especificacin, del
diseo, del cdigo...
Recursos
Personal, equipos,
hardware, software...
Externos
Tamao, reusabilidad,
modularidad, funcionalidad,
acoplamiento, complejidad...
Comprensin, mantenibilidad,
calidad, fiabilidad ...
Tiempo, esfuerzo, cambios en

requisitos, fallos en la
especificacin
Calidad, coste, estabilidad
Edad, precio, tamao del equipo, Productividad, experiencia,

velocidad, tamao de memoria
calidad, usabilidad, fiabilidad
13

del software: procesos
Los aspectos relacionados con el proceso de desarrollo de

software que pueden medirse son:
Atributos internos que pueden medirse directamente:
Duracin de un proceso o de una de sus actividades.
Esfuerzo asociado con el proceso o con una de sus

actividades.
Nmero de incidentes de un tipo determinado que

ocurren durante el proceso o una de sus actividades.
...
Esas medidas pueden combinarse con otras para tener un
mayor conocimiento del proceso de desarrollo.
Ejemplo: coste/nmero de errores
Atributos externos del Proceso:

Controlabilidad
Observabilidad
Estabilidad
...
A menudo se proponen medidas de atributos externos en
funcin de atributos internos.
Ejemplo: la efectividad del mantenimiento del cdigo

puede medirse en funcin de la proporcin entre el
nmero de errores descubiertos y el nmero de
errores corregidos.
14

del software: procesos
Segn CMMI, pueden existir 6 niveles de
madurez en el proceso de desarrollo de
Software:
- CMMI level 0: Incomplete.
- CMMI level 1: Performed.
- CMMI level 2: Managed.
- CMMI level 3: Defined.
- CMMI level 4: Quantitatively managed.
- CMMI level 5: Optimizing.
http://www.sei.cmu.edu/cmmi/
PSL logra el nivel 5 en CMMI y se ubica en un grupo de

solo 8 compaas en el mundo que lo han alcanzado.
(Medelln, Colombia, Julio 25, 2003).
Software de primer mundo a precios de pas en
vas de desarrollo...
http://www.psl.com.co/
15

del software: productos
Atributos externos, que dependen del comportamiento del
producto en un entorno determinado:
Usabilidad
Integridad
Eficiencia
Reusabilidad
Portabilidad
...
Atributos internos del producto:
Medidas de tamao (longitud del cdigo, funcionalidad...)
Medidas de diseo
Acoplamiento: grado de interdependencia entre mdulos

Cohesin: grado en el los componentes locales de un mdulo
colaboran para realizar una tarea concreta
Modularidad
.................
Medidas de complejidad (estructuras de datos, estructura

lgica...)
...
El uso principal de los atributos internos es la

prediccin de los atributos externos.
16

del software: recursos
Los recursos incluyen cualquier entrada en la

produccin de software. Las medidas de
recursos ayudan a controlar el proceso
indicando cmo el proceso est usando y
transformando las entradas en salidas.
Los recursos internos que se pueden medir
directamente son:
Personal
Materiales
Herramientas
Mtodos
...
Los recursos externos pueden obtenerse a
partir de los anteriores:
Coste
Productividad
productividad = cantidad de salida /

esfuerzo de entrada
17
5. Recogida de datos mtricos
Propiedades de los datos:
Correctos: la recogida debe hacerse de acuerdo a las

reglas exactas de la definicin o de la mtrica.
Exactos: la diferencia entre el valor resultante de la

medida y el valor real del dato debe ser lo mnima
posible.
Precisos: el nmero de cifras utilizadas para expresarlos

debe ser la apropiada.
Consistentes: evaluaciones diferentes sobre los mismos

datos deben dar los mismos resultados.
Replicables: deben servir para comparar datos

obtenidos en circunstancias diferentes.
Asociados con una actividad o periodo de tiempo

particular.
Eleccin
Proceso, y recogida
Datos sin
producto
de datos refinar
recurso
Extraccin
Valores de
Datos Anlisis
atributos
refinados
derivados
Medicin directa
Medicin
indirecta
Modelo de recogida de datos
El objetivo es mejorar mediante la medicin, el

anlisis y la realimentacin
18
5. Recogida de datos mtricos
El primer paso en la aplicacin de las mtricas es decidir qu

medir. Los objetivos para el proyecto y producto deben estar
bien definidos.
Base Histrica. Ejemplo 1.
Obtencin de informacin. Ejemplo 2.
El enfoque GQM (Goal-Question-Metric) puede utilizarse para
seleccionar e implementar mtricas de una manera efectiva
(http:www.gqm.nl). Se aplican varios pasos:
Lista de los objetivos y agentes.

reas de medicin. Definicin de trminos.
Para cada objetivo obtener las preguntas que deben contestarse
para saber si se estn cumpliendo los objetivos.
Decidir qu medir para poder contestar las preguntas de forma
adecuada.
OBJETIVO: Evaluar la efectividad del estndar de codificacin

PREGUNTAS: Quien est usando
el estndar?
MEDIDAS
INTERMEDIAS:
Tcnicos usando
el estndar
MTRICAS
Total tcnicos
?......
Cual es la
productividad del
codificador?
Cual es la calidad
del cdigo?
Esfuerzo en
codificacin con y Cantidad
de cdigo
sin estndar
?.....
Ejemplo de mtricas derivadas con el mtodo GQM
Errores
?...
19
5. GQM (Goal Question Metric)
OBJETIVOS
Mejorar la planificacin del proyecto.
Incrementar la contencin de defectos.
Incrementar la Fiabilidad.
AREAS DE MEDICIN
Defectos entregados y defectos
entregados por tamao.
...
DEFINICIN DE TRMINOS
PROBLEMA SOFTWARE.
ERROR, DEFECTO, FALLO AVERA..
MTODOS GQM:
Objetivo: mejorar la planificacin del proyecto.
Pregunta: Cul es la precisin en la estimacin del valor real
del plazo del proyecto?
Mtrica: Precisin en la estimacin del plazo (SEA)
SEA=Duracin real /duracin estimada
20
6. Medicin de atributos
internos del producto
Los atributos internos describen los productos de
software de forma que dependen nicamente del
producto mismo.
El producto puede ser descrito en funcin de su

tamao. Se pueden definir un conjunto de atributos
para medir el tamao del software:
Longitud: tamao fsico del producto.
Funcionalidad: funciones que proporciona el
producto al usuario.
Complejidad (de tiempo o espacio): recursos
necesarios (de tiempo o memoria de ordenador)
para implementar una solucin particular.
Las propiedades estructurales del software son
atributos internos relacionados con la calidad del
producto. Los tipos de medidas estructurales son:
Flujo de control: secuencia en que se ejecutan
las instrucciones.
Flujo de datos: seguimiento de cmo los datos se
crean y se manejan por un programa.
Estructura de los datos: organizacin de los
datos independiente del programa.
Los principales productos que resulta til medir son la
especificacin, el diseo y el cdigo.
21
internos del producto:
Longitud
Cdigo
El numero de lneas de cdigo (LOC) es la medida ms usada

para medir la longitud del cdigo fuente.
Se han realizado muchas propuestas para contarlas. La ms

extendida es la de HP que no contabiliza las lneas
comentadas ni en blanco. La abreviatura que se usa para
estas lneas es NCLOC o ELOC (effective lines of code).
Es til medir por separado las lneas comentadas

(CLOC) para calcular esfuerzo, productividad, etc. La
longitud total ser:
LOC = NCLOC + CLOC
Tambin puede se til calcular la densidad de

comentarios:
CLOC/LOC
Para propsitos tales como la prueba es importante conocer

cuanto cdigo ejecutable se produce, para ello se mide el
nmero de sentencias ejecutables (ES), ignorando los
comentarios, declaraciones de datos y cabeceras.
Otra propuesta consiste en contabilizar nicamente el

cdigo entregado al cliente. Se cuenta el nmero de DSI
(delivered source instruction) que incluye las declaraciones
de datos, las cabeceras y las instrucciones fuente.
22
Referentes al cdigo
Cdigo
Nmero de mtodos estticos.
Afferent Coupling: Nmero de clases fuera del paquete que

dependen de clases dentro del paquete.
Efferent Coupling: Nmeor de clases dentro del paquete que

dependen de clases fuera del paquete.
Nested Block Depth: profundidad en bloques anidados.
Lack of Cohesion in Methods (LCOM), Falta de cohesin en

mtodos: Si es cerca de 1 quiere decir que se nos aconseja que
dividamos la clase en varias subclases.
23
longitud
Mtricas de Halstead (1977):
Considera un programa P como un conjunto de tokens

(unidad sintctica ms elemental distinguible por un
compilador) que se pueden clasificar como operandos y
operadores
Las mtricas bsicas para los tokens son:
n1: nmero de operadores nicos
n2: nmero de operandos nicos
N1: nmero total de ocurrencias de operadores
N2: nmero total de ocurrencias de operandos
Mtricas compuestas para un programa:
El tamao (N) o longitud de un programa:

N = N1 + N2
Vocabulario (n) de un programa:

n = n1 + n2
Longitud estimada:
L = N1 log2 n1 + N2 log2 n2
Volumen:
V = N log2 n
donde N = N1 + N2 y n = n1 + n2
Esfuerzo de implementacin:
E = (n1 N2 N log2 n ) / (2 n2)
Tiempo de desarrollo de un programa:

T=E/B
B : n de discriminaciones mentales por segundo. Lo fija
en 18.
24
longitud
Especificaciones y diseo
Los documentos de especificacin de requisitos y

de diseo tienen representaciones de muchos tipos
(texto, grficos, smbolos...)
La medicin del atributo longitud exige la

identificacin de elementos atmicos que puedan
contarse. Ejemplo:
Diagramas de flujo de datos: procesos,
entidades externas, almacenes de datos y flujo
de datos.
Especificaciones algebraicas: salidas, funciones,
operaciones y axiomas.
Se pueden definir pginas de documentacin como

objetos atmicos.
Vista
Diagrama
Objetos atmicos
Diagrama de flujo de datos
Burbujas
Diccionario de datos
Elementos de datos
Datos
Diagrama entidad relacin
Objetos, relaciones
Estado
Diagrama de transicin de
estados
Estados, transiciones
Funcional
Ejemplo de componentes atmicos del anlisis estructurado
25
funcionalidad
Puntos de funcin (PF)
Medida de la funcionalidad propuesta por Albrecht. Es una

medida del producto y del proceso que se sigue para
desarrollarlo. Est centrado en la funcionalidad o
utilidad del producto.
Los PF se obtienen utilizando una relacin emprica

basada en items del producto y valoraciones subjetivas de
la complejidad del mismo.
El paso previo al clculo de los PF, es el clculo de PFS

(unadjusted function point count), puntos de funcin sin
ajustar:
Se determinan los siguientes elementos de alguna

representacin del software:
Entradas externas: entradas de usuario que

proporcionan datos a la aplicacin.
Salidas externas: Salidas que proporcionan

informacin al usuario.
Consultas externas: peticiones interactivas que

requieren una respuesta.
Ficheros externos: interfaces con otros

sistemas legibles por la mquina.
Ficheros internos: ficheros maestros lgicos del

sistema.
A cada elemento se le asigna un ndice de

complejidad entre tres: simple, media o complejo. A
cada ndice le corresponde un factor de ponderacin.
26
funcionalidad
Item
Simple
Entradas externas
Salidas externas
Consultas externas
Ficheros externos
Ficheros internos
3
4
3
7
5
Factor de peso
Medio
Complejo
4
5
4
10
7
6
7
6
15
10
Items y factores de peso para calcular los PFS

15
PFS = ((nmero de items de la clase i) pesoi)

i=1
Para completar el clculo de los PF es necesario conocer el factor

de complejidad tcnica (FCT) que engloba los 14 factores.
Componentes del factor de complejidad tcnica

F1 Copias de seguridad y
recuperacin fiables
F2 Comunicacin de datos
F6 Entrada interactiva de
datos
F7 Facilidad operativa
F3 Funciones distribuidas
F8 Actualizacin interactiva F13 Mltiples sitios

F9 Interfaces complejas
F14 Facilidad de cambios
F4 Rendimiento
F5 Configuracin muy
cargada
F11 Reusabilidad
F12 Facilidad de instalacin
F10 Procesamiento complejo

27
funcionalidad
Cada componente de la tabla anterior se sita en una

escala entre 0 y 5 segn su influencia:
Ninguna influencia
0
Incidental
1
Moderado
2
Medio
3
Significativo
4
Esencial
5
La siguiente frmula combina los 14 factores:
14
FCT = 0.65 + 0.01 Fi
i=1
Los valores constantes de la ecuacin y los factores de

ponderacin se obtienen empricamente.
Clculo final de los puntos de funcin:

FP = UFC * FCT
La tcnica de puntos de funcin presenta problemas debido a

la subjetividad de la aplicacin de los factores y a la
inexactitud de las medidas.
Puntos de funcin o lneas de cdigo?
Existen factores de conversin (Albrecht/Jones) que permiten
relacionar el nmero medio de LDC requerido para construir un
PF en diferentes lenguajes.
28
funcionalidad
Fuente: Pressman, 5 edicin, pag. 62
Lenguaje de Programacin
Ensamblador
C
COBOL
FORTRAN
Pascal
C++
Ada95
Visual Basic
SmallTalk
SQL
Java
LDC/PF
320
128
106
106
90
64
53
32
22
12
58
http://irb.cs.uni-magdeburg.de/sw-eng/us/java/fp/
29
funcionalidad
Puntos objeto
Utiliza una medida del tamao que puede ser aplicada al
comienzo del desarrollo. Para realizar el clculo de los puntos
objeto se realiza una medida inicial contando el nmero de
pantallas, informes y componentes de 3GL de la aplicacin. A
cada objeto se le asigna un factor de peso segn su grado de
dificultad. Los pesos reflejan el esfuerzo relativo requerido
para implementar un objeto de un determinado nivel.
Tipo de objeto
Simple
Medio
Difcil
Pantalla
Informe
Componente 3GL
1
2
-
2
5
-
3
8
10
Tipos de objeto y factores de peso
Puntos de caracterstica
Sistemas en tiempo real , control de procesos,
empotrados,...
sistemas
30
medidas estructurales
Flujo de control
Grafos de flujo de control
Las medidas de flujo de control generalmente se modelan

mediante grafos dirigidos denominados grafos de flujo o
grafos de flujo de control
Un grafo dirigido est formado por un conjunto de puntos

(nodos) y lneas (arcos). Cada arco tiene asignada una
direccin representada por una flecha.
Un arco se puede describir como un conjunto ordenado de

pares, <x,y>, donde x e y son los nodos conectados por el
arco.
En un grafo de flujo se pueden definir los siguientes conceptos:
Grado de entrada a un nodo: nmero de arcos que

llegan al nodo.
Grado de salida: nmero de arcos que salen del nodo.
Camino: secuencia consecutiva de arcos dirigidos, algunos

de los cuales pueden atravesarse ms de una vez.
Camino simple: camino que no tiene arcos repetidos.
Nodos procedimiento: nodos cuyo grado de salida es

igual a uno.
Nodos predicado: nodos cuyo grado de salida esa mayor

que uno.
31
Los nodos principio y fin del grafo se representan

rodeados por una circunferencia.
x1
x2
xn
Pn
x1, x2 ... xn
A
x
D0
if A then x
x1
a1
x2
a2
...
xn
Cn
Case A of
a1 : x1
a2 : x2
an : xn
x
D2
while A do X
an
D3
repeat X until A
Grafos de flujo para diferentes estructuras de programa

32
internos del producto: medidas
estructurales
Complejidad ciclomtica de McCabe:
La complejidad de un programa se
mide mediante el nmero ciclomtico
(v) de su grafo de flujo (F):
v(F) = e n + 2
siendo e el nmero de arcos y n el
nmero de nodos de F.
El nmero ciclomtico:
Mide el nmero de caminos linealmente

independientes.
Es un indicador til de la dificultad de
prueba y mantenimiento de un programa o
mdulo.
Para valores superiores a 10 en un
determinado mdulo, ste puede ser
problemtico.
33
Complejidad ciclomtica de McCabe:
Determina en nmero de caminos a travs de
un programa.
Sirve para predecir los mdulos que son ms
propensos a errores.
Determina el nmero de casos de prueba
para asegurarse que todas las sentencia de un
componente han sido ejecutadas al menos
una vez.
Cyclomatic
Complexity
Risk Evaluation
1-10
a simple program,
without much risk
11-20
more complex,
moderate risk
21-50
complex, high risk

program
greater than 50
untestable program
(very high risk)
http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html
34
DEMO
http://www.hypercisioninc.com/jmetra/jmetradoc.html
jMetra is a simple Code Metrics Collection and
Analysis Package for Java
http://www.it.swin.edu.au/projects/jmetric/products/jmetric/
JMetric aims to bring current OO-metrics, and metrics
tools research to the practitioner.
http://www.qido.at/
QiDO is a provider of quality management at the
source of your projects. What you get is a
permanent overview about the status of your
software development.
35
Practica, referencias
http://www.eclipse.org
http://jalopy.sourceforge.net/
http://metrics.sourceforge.net/
36
externos del producto
Los atributos externos de un producto son aquellos que pueden

medirse nicamente con respecto a cmo el producto se
relaciona con su entorno.
Los atributos externos slo son medibles cuando el producto
est completo.
La mayora estn relacionados con algn aspecto de la calidad.
Los modelos de calidad recogen atributos denominados

factores de calidad (atributos de alto nivel).
Los factores de calidad puede descomponerse en atributos

de bajo nivel denominados criterios de calidad.
Los criterios de calidad pueden asociarse con un conjunto

de atributos de bajo nivel medibles directamente
obteniendo las mtricas de calidad.
FACTOR
MTRICA
CRITERIO
Cuenta de fallos
Facilidad de
correccin
Grado de prueba
Mantenibilidad
Chequeabilidad
Esfuerzo
Expansibilidad
Cuenta de
cambios
Descomposicin del factor mantenibilidad
37
El modelo de calidad estndar ISO 9126
En el estndar denominado Evaluacin de Productos
Software: Caractersticas de calidad y guas para su

uso, la calidad se descompone en seis factores:
Funcionalidad
Fiabilidad
Eficiencia
Usabilidad
Mantenibilidad
Portabilidad
El estndar define un proceso para evaluar la calidad del
software segn la figura adjunta.
ISO 9126 y otras informaciones tcnicas

Especificacin de
requisitos
de calidad
Definicin de
requisitos de
calidad
Seleccin de
mtricas
Requisitos de gestin
Definicin de
niveles de
clasificacin
Definicin de
criterios de
valoracin
Desarrollo de Productos
software
Medicin
Clasificacin
Resultados
Valoracin
Modelo del proceso de evaluacin ISO 9126
38
El modelo de calidad
estndar ISO 9126
Usabilidad: Un conjunto de atributos que tienen que ver

con el esfuerzo necesario para uso...
39
El modelo de calidad
estndar ISO 9126
Objetivo: Evaluacin de Calidad de productos
Tiene 3 fases:
DEFINICIN DE REQUISITOS:
Necesidades tcnicas iniciales -> [ Definicin de QR]
Especificacin de QR (QRS).
FASE DE PREPARACIN:
QRS --> [ Seleccin de mtricas ] --> Mtricas
QRS --> [ Definir niveles de evaluacin] --> Niveles evaluacin
QRS --> [ Definicin de criterios de valoracin] -> Criterios
FASE DE EVALUACIN:
Productos, Mtricas --> [ Medicin ] -> Valores medidos
Valores medidos, niveles evaluacin --> [ Evaluacin ]
--> niveles evaluados.
Niveles evaluados, Criterios --> [ valoracin ] --> Resultado
40
Medicin de la portabilidad
Se entiende por portabilidad la facilidad de mover una aplicacin

de un entorno a otro.
La portabilidad se puede expresar como:

portabilidad = 1 - (ET/ER)
ET: medida de los recursos necesarios para mover el sistema a
otro entorno (Target Environment).
ER: medida de los recursos necesarios para crear el sistema en
el entorno residente (Resident Environment)
Medicin de la densidad de defectos
Para cualquier producto software se pueden considerar dos tipos

de defectos:
Defectos conocidos
Defectos latentes
La densidad de defectos se puede definir en funcin de los

primeros:
nmero de defectos conocidos
Densidad de defectos =
tamao del producto
41
Medida de la calidad basada en defectos
Se puede medir la calidad en funcin de la relacin:

Tiempo empleado en la correccin de defectos post-release
Tiempo total de desarrollo del sistema
Medidas de usabilidad (I)
Boehm define usabilidad como el grado en que un producto se

puede usar de forma apropiada y prctica.
La buena usabilidad incluye:
Manuales bien estructurados
Buen uso de mens y grficos
Mensajes de error informativos
Funciones de ayuda
Interfaces consistentes
La usabilidad se puede descomponer en atributos medibles de los
siguientes tipos:
Nivel de entrada
Nivel de aprendizaje
Facilidad de manejo
42
Medidas de usabilidad (II)
Las medidas de usabilidad se suelen expresar en funcin del

rendimiento del usuario. Se han propuesto varias medidas de
ese tipo:
Efectividad de las tareas:

% de efectividad = (cantidad * calidad)/100
Eficiencia temporal:
eficiencia = efectividad/tiempo de tarea

Periodo de tiempo productivo:
tiempo de tarea - tiempo no productivo
periodo productivo =
x 100
tiempo de tarea
Eficiencia relativa del usuario:

eficiencia del usuario
eficiencia relativa =
x 100
eficiencia del experto
43
Medidas de mantenibilidad (I)
La mantenibilidad de un producto refleja su facilidad de

comprensin, mejora y correccin.
Se puede aplicar tanto al cdigo como a los documentos de

diseo y especificacin de requisitos.
Una medida de mantenibilidad es la denominada MTTR (mean

time to repair). Para calcularla se requiere conocer:
Tiempo de reconocimiento del problema
Tiempo de demora administrativa.../
Tiempo de recoleccin de herramientas..
Tiempo de anlisis del problema
Tiempo de especificacin del cambio
Tiempo de cambio
Otras medidas dependientes del entorno son:
Nmero de problemas no resueltos
Tiempo utilizado en problemas no resueltos
Porcentaje de cambios que introducen nuevos fallos
Nmero de mdulos modificados en la implementacin de un

cambio
44
Medidas de mantenibilidad (II)
La mantenibilidad puede predecirse tambin a partir de atributos

internos como la complejidad o la calidad de la
documentacin.
Se han realizado estudios sobre la relacin entre el nmero

ciclomtico y el esfuerzo de mantenimiento.
En [Porter y Selby, 1990] se utilizan rboles de decisin para
lby, 1990] se utilizan rboles de decisin para

eterminar los atributos ms influyentes en la aparicin
de errores de interfaz entre mdulos durante el
enimiento del sistema.
[Belady y Lehman, 1976] sugieren un modelo para
predecir el esfuerzo de mantenimiento en funcin de
tributos externos e internos
c-d)
-d)
tal de mantenimiento
al de mantenimiento
ductivo
prica
mplejidad
45
8. Medicin de recursos
Los recursos son las entidades que se requieren en las

actividades de proceso. Los recursos incluyen cualquier
entrada en la produccin de software: personal,
materiales, herramientas, mtodos, coste,
productividad, .....
El coste generalmente se mide, a partir del resto de los
recursos, pudindose ver como el coste de las entradas
afecta al coste de las salidas.
La productividad es otro atributo externo importante
que depende del proceso de desarrollo. Normalmente se
mide de la forma:
cantidad de salida/ cantidad de entrada
La productividad de un recurso de software se mide en
funcin de la proporcin entre lo que entra y sale de un
proceso de produccin de software.
Ecuacin de productividad:
tamao de software/ esfuerzo
Unidades ms utilizadas:
Tamao: lneas de cdigo, PF,....
Esfuerzo: personas-mes, persona-da,....
46
Productividad
La medicin de la productividad en funcin del nmero

de lneas de cdigo puede presentar problemas:
Dependencia de la tcnica de contar
Dependencia del lenguaje de programacin
Penalizacin del buen estilo de programacin ...
Para solventar esos problemas algunos autores han
propuesto medir la productividad a partir de la
funcionalidad.
Ventajas de los puntos de funcin:
Reflejan mejor el valor de la salida
Pueden usarse en cualquier momento del ciclo de
vida
Se pueden utilizar para medir el progreso
comparando los puntos de funcin completados
frente a los incompletos.
Problemas que presentan los puntos de funcin: son
ms difciles de medir que las lneas de cdigo y tienen
un componente subjetivo.
47
Equipos
La estructura del equipo del proyecto es un factor clave en la
productividad.
El factor particular que afecta a la productividad es la complejidad de
las comunicaciones: complejidad causada por el nmero de individuos
implicados y el mtodo de comunicacin requerido entre los miembros de

un proyecto (Grady/Caswell).
Equipos segn su estructura: jerrquico, democrtico, .....

Si se representa la estructura mediante un grafo (nodo= miembro, arco=
camino de comunicacin entre miembros):
Tamao: n de nodos del grafo.
Densidad de comunicacin: relacin entre arcos y nodos.
...
Fenton establece la siguiente escala ordinal para medir la experiencia
de cada miembro del equipo: 0 (ninguna), 1 (familiaridad pero sin
experiencia, prctica), 2 (experiencia prctica de ms de 20 h en un
proyecto), 3 (experiencia de entre 21 y 100h en varios proyectos), 4
(amplia experiencia).
La experiencia del equipo se calcula hallando la media de las medidas de
experiencia individual.
Algunos mtodos como COCOMO utilizan escalas de medida ordinales
(muy baja, baja, nominal, alta y muy alta) para cada uno de los atributos
de personal: experiencia en la aplicacin, en el lenguaje, en el uso de
herramientas, ...
La productividad del equipo no slo depende de las
productividades individuales de sus miembros, sino tambin de
la comunicacin entre ellos.
48
Mtodos y herramientas
Existen pocos estudios sobre el grado en que las herramientas
aumentan la productividad.
Los modelos de estimacin del esfuerzo requieren una medida del
nivel de uso de mtodos y herramientas.
El modelo COCOMO incluye dos guas de coste: uso de herramientas y uso
de tcnicas modernas de programacin con escalas de medida (muy baja,
baja, nominal, alta, muy alta)
Fenton propone la siguiente escala para evaluar el uso de herramientas por

cada diseador:
0
1
2
3
4
5
No se usan herramientas.
Las herramientas sirven de ayuda en el 20% de la documentacin.
Las herramientas se usan para documentar al menos el 50% del
diseo de alto nivel.
Las herramientas se usan para documentar al menos el 50% del
diseo de alto nivel y diseo detallado.
Las herramientas se usan para el diseo y la generacin automtica
de cdigo de al menos el 50% del sistema.
Las herramientas se usan para el diseo y la generacin
automtica de cdigo de al menos el 90% del sistema.
Escalas similares se utilizan para cuantificar otros recursos:
Homogeneidad y compatibilidad del equipo del proyecto.
Uso de correo electrnico y otras facilidades de comunicacin.
Nivel de soporte administrativo.
Nivel de recursos de informacin.
...
49
9. Mtricas para sistemas

orientados a objetos
La mayora de las mtricas orientadas a objetos se

basan en las caractersticas distintivas del software
orientado a objetos respecto al software
convencional:
Localizacin: forma en que se concentra la
informacin dentro de un programa
Encapsulamiento: empaquetamiento de una
coleccin de elementos.
Ocultamiento de la informacin: supresin de
los detalles operativos de un componente.
Herencia: mecanismo que permite la
propagacin de responsabilidades de un objeto a
otro.
Abstraccin: mecanismo que permite
concentrarse en los detalles esenciales de un
componente sin considerar los de nivel inferior.
Clasificacin de las mtricas:
Mtricas orientadas a clases
Mtricas orientadas a operaciones
Mtricas para pruebas orientadas a objetos
Mtricas para proyectos orientados a objetos.
50

Conjunto de mtricas CK (Chidamber/Kemerer)

Mtodos ponderados por clase (MPC): recoge
la nocin de complejidad.
Para una clase C con M1, M2, ...,Mn mtodos con
un peso de complejidad c1, c2, ..., cn
respectivamente,
MPC = ci
Profundidad del rbol de herencia (PAH):
longitud del camino mximo entre un nodo y la

raz del rbol.
Nmero de hijos (NH): es el nmero de
descendientes inmediatos de una clase (nodo).
Acoplamiento entre clases (AC): nmero de
clases que se acoplan con una clase dada.
Respuesta para una clase (RPC): es el nmero
de mtodos locales a una clase ms el nmero de
mtodos llamados por los mtodos locales.
Mtrica de falta de cohesin (MFC): nmero de
mtodos locales que no acceden a atributos
comunes.
51

Mtricas de Lorenz y Kidd (Lorenz/Kidd)
Tamao de clase (TC). El tamao general de una

clase se determina utilizando las siguientes
medidas:
Nmero total de operaciones
Nmero de atributos
Nmero de operaciones invalidadas por una

subclase (NOI). La invalidacin consiste en la
sustitucin en la subclase de una operacin
heredada por una versin especializada.
Nmero de operaciones aadidas por una

subclase (NOA): operaciones propias de la
subclase que no aparecen en las superclases.

ndice de especializacin (IE):
IE = (NOI nivel)/ Mtotal
nivel: nivel de la clase en la jerarqua de clases

Mtotal: Nmero total de mtodos de la clase
52

Mtricas orientadas a operaciones
Mtricas de Churcher y Shepperd
Tamao medio de operacin (TOmed): Nmero
de mensajes enviados por la operacin.

Complejidad de operacin (CO): se puede
aplicar cualquier mtrica de complejidad del
software convencional.
Nmero medio de parmetros por operacin

(NPmed).
Mtricas para pruebas orientadas a objetos (Binder)
Encapsulamiento
Carencia de cohesin en mtodos (CCM): se
aplica la mtrica CK.
Porcentaje pblico y protegido (PPP):
porcentaje de atributos pblicos de la clase.

Acceso pblico a datos miembro(APD): nmero
de clases que pueden acceder a atributos de otras
clases.
53

Mtricas para pruebas orientadas a objetos
Herencia
Nmero de clases raz (NCR): nmero de
jerarquas de clases distintas.

Admisin (ADM): indicacin de la herencia
mltiple.
Nmero de descendientes (NDD) y
profundidad del rbol de la herencia (APM): se
aplican las correspondientes mtricas CK.
Mtricas para proyectos orientados a objetos
Mtricas de Lorenz y Kidd (Lorenz/Kidd).
Nmero de guiones de escenario (NGE): un
guin de escenario es una secuencia detallada de

pasos que describen la interaccin entre el usuario y
la aplicacin.
Nmero de clases clave (NCC): clases que se
centran en el dominio de negocio del problema en
cuestin.
Nmero de subsistemas (NSUB): proporcionan
una idea de la asignacin de recursos, de la
planificacin y del esfuerzo global de integracin.
54
Referencias
Basili, V.R. y Weiss, D., A Methodology for collecting valid software engineering
data, IEEE Transaction on Software Engineering,10(6), 728-38 1984.
Basili, V.R. y Rombach, H.D., The TAME project: Towards improvement-oriented
software environments, IEEE Transaction on Software Engineering,14(6), 75873, 1988.
Belady, L.A., and Lehman, M.M., A Model of Large Program Development, IBM
Systems Journal, 15 (3), pp. 225-252, 1976.
Binder, R., Testing Object-Oriented Systems, American Programmer, 7(4), 22-29,
1994.
Chidamber, S.R. y Kemerer, C.F., A metrics suite for object-oriented design ,IEEE
Trans. Software Engineering, 20(6), 476-493, 1994.
Churcher, N.I. and Shepperd, M.J., Towards Conceptual Framework for ObjectOriented Metrics, ACM Software Engineering Notes, 20 (2), 67-76, 1995.
DeMarco, T., Structured Analysis and Sistem Specification, Yourdon Press, 1978.
DeMarco, T., Controlling Software Projects, Yourdon Press, 1982.
Dolado, J.J. y Fernndez, L. (coordinadores). Medicin para la Gestin en la
Ingeniera del Software. Ra-ma, 2000.
Fenton, N.E. y Pfleeger, S.L., Software metrics. A rigorous & practical approach ,
1997.
Halstead, M.H., Elements of Software Science, Elsevier North-Holland, 1977.
IEEE Software Engineering Standards,. Standard 610.12-1990, 1993.
Lorenz, M. and Kidd, J., Object_oriented Software Metrics, Prentice Hall 1994.
McConnell, S., Desarrollo y gestin de proyectos informticos, Mc Graw Hill 1997.
Paulk, M. et al., Capability Maturity Model for Software, Software Engineering
Institute, Carnie Mellon University, Pittsburgh, P.A., 1993.
Pressman, R.S., Ingeniera del Software. Un enfoque prctico, Mc Graw Hill, 55
2001.
Medicin de atributos
internos del producto.
Funcionalidad
Entrada:
1. Nombre del documento a revisar
Fichero externo:
1. Documento a
revisar
Usuario
Consulta:
1. Palabras procesadas?
Corrector
ortogrfico
Salidas:
1.
Nmero total palabras
revisadas
2.
Nmero total de
errores detectados
3.
Lista de palabras con
errores ortogrficos
Entradas externas:
Salidas externas:
Consultas externas:
Ficheros externos:
Ficheros internos:
Fichero
interno:
1. Diccionario
PFS:
FCT:
PF:
56

Metricas y Ptos de Funcion

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Metricas y Ptos de Funcion

Uploaded by

Copyright:

Available Formats

MEDICIN DEL

MEDICIN DEL SOFTWARE

MEDICIN DEL SOFTWARE

MEDICIN DEL SOFTWARE

MEDICIN DEL SOFTWARE

La posibilidad de medir es el fundamento de

Proporciona requerimientos verificables

No se puede controlar lo que no se puede

Una medida proporciona una indicacin cuantitativa de extensin,

Es el proceso por el que se asignan nmeros o smbolos a atributos de

Modelo estructural (parcial) de Kitchenham et al.

Definicin de medidas y mtricas

Evaluacin de los resultados

Proceso de medicin de Roche

Medida cuantitativa del grado en que un sistema, componente o proceso

Mtrica o combinacin de mtricas que proporcionan una visin

Los indicadores de proceso permiten tener una visin profunda

de la eficacia de un proceso ya existente. Se recopilan de todos los

Los indicadores de proyecto permiten:

Evaluar el estado del proyecto en curso.

Seguir la pista de los riesgos potenciales.

Detectar reas de problemas antes de que sean crticas.

Ajustar el flujo y las tareas del trabajo.

Evaluar la habilidad del equipo del proyecto en controlar la

Los indicadores de producto permiten evaluar su calidad.

MEDICIN DEL SOFTWARE

Medidas directas e indirectas:

El proceso se mide para mejorarlo, rentabilizarlo y

3. Alcance de las mtricas

Estimacin de coste y esfuerzo (o al menos reduccin de

Modelos y medidas de productividad

Recoleccin de datos (Por amor al arte?...)

Modelos y evaluacin de la calidad (AENOR, ISO, etc.)

Estn incluidos en la mayora de los modelos de calidad.

La especializacin de los modelos de fiabilidad permite

Evaluacin del rendimiento (Pude ser cualitativo)

Aunque es otro aspecto de la calidad, la valoracin del

Mtricas estructurales y de complejidad

Para realizar predicciones sobre atributos de calidad

Valoracin de capacidad de madurez (CMMI).

Se pueden medir diferentes atributos del desarrollo para

Gestin mediante mtricas

La realizacin de grficos basados en diferentes medidas a lo

Evaluacin y comparacin de mtodos y herramientas

Las investigaciones cuidadosas, con anlisis y mediciones

Justificacin del uso de nuevos mtodos y /o herramientas

Justificacin de formacin adicional

3. Alcance de las mtricas

En cunto podra ser mejorada la productividad si no

Cunto tiempo le cost el ltimo ao adaptar su

Cules de las aplicaciones que desarrolla su empresa

Cunto tiempo se gasta realmente en testing?

Cre que sus desarrolladores dedican suficiente tiempo a

Su proceso de desarrollo ha madurado en los ltimos aos?

El esfuerzo dedicado a mejorar la calidad del software est

Con qu precisin es usted capaz de estimar proyectos

En cuntos proyectos han trabajado cada uno de sus

10. Cul es el nmero medio de horas por semana que sus

4. Clasificacin de las mtricas

El primer paso de la medicin es identificar los atributos o

Procesos: atributos de actividades relacionadas con

Productos: componentes, entregas o documentos

Recursos: entidades requeridas por una actividad de