Metricas Software PDF

1
MEDICIN DEL
SOFTWARE
2
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]
3
1. Conceptos bsicos
2. Medidas y modelos
3. Alcance de las mtricas
4. Clasificacin de las mtricas
Procesos
Productos
Recursos
5. Recogida de datos mtricos
Base Histrica
Obtencin de informacin
Mtodo Objetivo/Pregunta/Mtrica
6. Medicin de atributos internos del producto
Longitud
Funcionalidad
Complejidad
Medidas estructurales
7. Medicin de atributos externos del producto
8. Medicin de recursos
9. Mtricas para sistemas orientados a objetos
4
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]
5
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).
6
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.
OJ O!, 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
Unidad
Valor
(magnitud)
Atributo
posee
cuantifica
mide
se aplica a
se expresa en
*
1
*
1
1
1..*
1..*
1
1
1..*
Mundo real
(emprico)
Mundo formal
(matemtico)
Modelo estructural (parcial) de Kitchenhamet al.
7
1. Conceptos Bsicos
FORMULACIN
Definicin de medidas y mtricas
COLECCIN
Obtencin de datos
ANLISIS
Clculo de mtricas
INTERPRETACIN
Evaluacin de los resultados
REALIMENTACIN
Recomendaciones obtenidas
Proceso de medicin de Roche
8
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.
9
La Frase:
All models are wrong but
some are useful
[George Box]
10
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.
11
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.
J ustificacin del uso de nuevos mtodos y /o herramientas
J ustificacin de formacin adicional
12
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
13
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.
ATRIBUTOS ENTIDADES
Internos Externos
Productos
Especificaciones,
diseo, cdigo...
Tamao, reusabilidad,
modularidad, funcionalidad,
acoplamiento, complejidad...
Comprensin, mantenibilidad,
calidad, fiabilidad ...
Procesos
Realizacin de la
especificacin, del
diseo, del cdigo...
Tiempo, esfuerzo, cambios en
requisitos, fallos en la
especificacin
Calidad, coste, estabilidad
Recursos
Personal, equipos,
hardware, software...
Edad, precio, tamao del equipo,
velocidad, tamao de memoria
Productividad, experiencia,
calidad, usabilidad, fiabilidad

14
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.
15
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, J ulio 25, 2003).
Software de primer mundo a precios de pas en
vas de desarrollo...
http://www.psl.com.co/
16
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.
17
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
18
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.
Proceso,
producto
recurso
Datos sin
refinar
Datos
refinados
Valores de
atributos
derivados
Eleccin
y recogida
de datos
Extraccin
Anlisis
Medicin directa Medicin
indirecta
Modelo de recogida de datos
El objetivo es mejorar mediante la medicin, el
anlisis y la realimentacin
19
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.
MEDIDAS
INTERMEDIAS:
OBJETIVO: Evaluar la efectividad del estndar de codificacin
PREGUNTAS:
Quien est usando
el estndar?
Cual es la
productividad del
codificador?
Cual es la calidad
del cdigo?
Tcnicos usando
el estndar
Cantidad
de cdigo
Errores
Esfuerzo en
codificacin con y
sin estndar
Total tcnicos
MTRICAS
?......
?...
?.....
Ejemplo de mtricas derivadas con el mtodo GQM
20
5. GQM (Goal Question Metric)
OBJ ETIVOS
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
21
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.
22
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.
23
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.
24
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:
n
1
: nmero de operadores nicos
n
2
: nmero de operandos nicos
N
1
: 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 = N
1
log
2
n
1
+ N
2
log
2
n
2
Volumen:
V = N log
2
n
donde N = N
1
+ N
2
y n = n
1
+ n
2
Esfuerzo de implementacin:
E = (n
1
N
2
N log
2
n ) / (2 n
2
)
Tiempo de desarrollo de un programa:
T = E / B
B : n de discriminaciones mentales por segundo. Lo fija
en 18.
25
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
Funcional
Diagrama de flujo de datos

Diccionario de datos
Burbujas

Elementos de datos
Datos Diagrama entidad relacin Objetos, relaciones
Estado
Diagrama de transicin de
estados
Estados, transiciones

Ejemplo de componentes atmicos del anlisis estructurado
26
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.
27
funcionalidad
Factor de peso
Item Simple Medio Complejo
Entradas externas 3 4 6
Salidas externas 4 5 7
Consultas externas 3 4 6
Ficheros externos 7 10 15
Ficheros internos 5 7 10
15
PFS = ((nmero de items de la clase i) peso
i
)
i=1
Para completar el clculo de los PF es necesario conocer el factor
de complejidad tcnica (FCT) que engloba los 14 factores.
Items y factores de peso para calcular los PFS
Componentes del factor de complejidad tcnica
F
1
Copias de seguridad y
recuperacin fiables
F
6
Entrada interactiva de
datos
F
11
Reusabilidad
F
2
Comunicacin de datos
F
7
Facilidad operativa
F
12
Facilidad de instalacin
F
3
Funciones distribuidas
F
8
Actualizacin interactiva
F
13
Mltiples sitios
F
4
Rendimiento
F
9
Interfaces complejas
F
14
Facilidad de cambios
F
5
Configuracin muy
cargada
F
10
Procesamiento complejo

28
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 F
i
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/J ones) que permiten
relacionar el nmero medio de LDC requerido para construir un
PF en diferentes lenguajes.
29
funcionalidad
Lenguaje de Programacin LDC/ PF
Ensamblador
320
C
128
COBOL
106
FORTRAN
106
Pascal
90
C++
64
Ada95
53
Visual Basic
32
SmallTalk
22
SQL
12
J ava
58
http:/ / irb.cs.uni-magdeburg.de/ sw-eng/ us/ java/ fp/
Fuente: Pressman, 5 edicin, pag. 62
30
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 1 2 3
Informe 2 5 8
Componente 3GL - - 10
Tipos de objeto y factores de peso
Puntos de caracterstica
Sistemas en tiempo real , control de procesos, sistemas
empotrados,...
31
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.
32
Los nodos principio y fin del grafo se representan
rodeados por una circunferencia.
x
1
x
2
x
n
P
n
x
1,
x
2 ...
x
n
A
x D
0
if A then x
C
n
Case A of
a
1
: x
1
a
2
: x
2
a
n
: x
n
x
1
x
2
a
1
a
2
x
n
...
a
n
A
x
x
A
D
2
whileA do X
D
3
repeat X until A
Grafos de flujo para diferentes estructuras de programa
33
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.
34
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
35
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.
36
Practica, referencias
http://www.eclipse.org
http://jalopy.sourceforge.net/
http://metrics.sourceforge.net/
37
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.
Mantenibilidad
Facilidad de
correccin
Chequeabilidad
Expansibilidad
Cuenta de fallos
Grado de prueba
Esfuerzo
Cuenta de
cambios
FACTOR
CRITERIO
MTRICA
Descomposicin del factor mantenibilidad
38
El modelo de calidad estndar I SO 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.
Modelo del proceso de evaluacin ISO 9126
Definicin de
requisitos de
calidad
ISO 9126 y otras informaciones tcnicas
Seleccin de
mtricas
Definicin de
niveles de
clasificacin
Definicin de
criterios de
valoracin
Desarrollo de
software
Medicin
Clasificacin
Valoracin
Especificacin de
requisitos de calidad
Productos
Resultados
Requisitos de gestin
39
El modelo de calidad
estndar ISO 9126
Usabilidad: Un conjunto de atributos que tienen que ver
con el esfuerzo necesario para uso...
40
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
41
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
42
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)
Boehmdefine 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
43
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
44
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
45
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
46
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,....
47
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.
48
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.
49
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 No se usan herramientas.
1 Las herramientas sirven de ayuda en el 20% de la documentacin.
2 Las herramientas se usan para documentar al menos el 50% del
diseo de alto nivel.
3 Las herramientas se usan para documentar al menos el 50% del
diseo de alto nivel y diseo detallado.
4 Las herramientas se usan para el diseo y la generacin automtica
de cdigo de al menos el 50% del sistema.
5 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.
. . .
50
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.
51
Conjunto de mtricas CK(Chidamber/Kemerer)
Mtodos ponderados por clase (MPC): recoge
la nocin de complejidad.
Para una clase C con M
1
, M
2
, ...,M
n
mtodos con
un peso de complejidad c
1
, c
2
, ..., c
n
respectivamente,
MPC = c
i
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.
52
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)/ M
total
nivel: nivel de la clase en la jerarqua de clases
M
total
: Nmero total de mtodos de la clase
53
Mtricas orientadas a operaciones
Mtricas de Churcher y Shepperd
Tamao medio de operacin (TO
med
): 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
(NP
med
).
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.
54
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.
55
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), 758-
73, 1988.
Belady, L.A., and Lehman, M.M., A Model of Large ProgramDevelopment, IBM
Systems J ournal, 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 Object-
Oriented Metrics, ACM Software Engineering Notes, 20 (2), 67-76, 1995.
DeMarco, T., Structured Analysis and SistemSpecification, 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 GrawHill 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 GrawHill, 2001.
56
Medicin de atributos
internos del producto.
Funcionalidad
Entrada:
1. Nombre del documento a revisar
Corrector
ortogrfico
Usuario
Entradas externas: PFS:
Salidas externas: FCT:
Consultas externas: PF:
Ficheros externos:
Ficheros internos:
Fichero
interno:
1. Diccionario
Fichero externo:
1. Documento a
revisar
Consulta:
1. Palabras procesadas?
Salidas:
1. Nmero total palabras
revisadas
2. Nmero total de
errores detectados
3. Lista de palabras con
errores ortogrficos

Metricas Software PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metricas Software PDF

Cargado por

Copyright:

Formatos disponibles

1

También podría gustarte