You are on page 1of 27

1

Proceso de Software y Métricas de Proyectos
Ingeniería del Software de Gestión 1
Facultad de Informática
Juan Pavón Mestras
Dep. Sistemas Informáticos y Programación
Universidad Complutense Madrid
http://www.fdi.ucm.es/profesor/jpavon
Este material está basado en el curso preparado por A.Navarro, U Este material está basado en el curso preparado por A.Navarro, UCM CM
(que a su vez sigue el texto del libro de (que a su vez sigue el texto del libro de Pressman Pressman, capítulo 4) , capítulo 4)
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 2
Objetivos
n Cómo medir el progreso de un proyecto de software
2
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 3
Introducción
n La existencia de medidas numéricas facilita el
conocimiento de un fenómeno
n Las métricas del software ayudan en el proyecto:
n En la estimación, control de calidad, evaluación de
productividad y control de proyectos
n En la evaluación de la calidad de los productos y trabajos
técnicos
n En la toma de decisiones tácticas según avanza el proyecto
n Las métricas del software permiten mejorar el proceso
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 4
Introducción
n Hay cuatro razones para medir:
n Caracterizar
• Para comprender mejor los procesos, los recursos, los entornos y
establecer las líneas base para comparaciones con evaluaciones
futuras
n Evaluar
• Para determinar el estado con respecto al diseño
• Para valorar la consecución de objetivos de calidad
• Para evaluar el impacto de la tecnología y las mejoras del
proceso
n Predecir
• Para poder planificar
• Para la extrapolación de tendencias
n Mejorar
• La calidad del producto
• El rendimiento del proceso
3
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 5
Medidas, métricas e indicadores
n Una medida proporciona una indicación cuantitativa de la
extensión, cantidad, dimensiones, capacidad o tamaño de
algunos atributos de un proceso o producto
n Ejemplo: un programa tiene 10.000 líneas de código (LDC)
n Medición es el acto de determinar una medida
n Ejemplo: Ana será la encargada de medir las LDC de cada
módulo del sistema
n Una métrica es una medida cuantitativa del grado en que
un sistema, componente o proceso posee un atributo dado
n Una métrica relaciona medidas individuales sobre algún
aspecto
n Ejemplo: la productividad de este proyecto fue de 500
(LDC/persona-mes)
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 6
Medidas, métricas e indicadores
n Las medidas no sirven para comparar, necesitamos
métricas
n En el país A ganan 1000 (€/pm), y en el país B ganan 1500
(€/pm)
• ¿viven mejor en el país B que en el país A?
n Un bocata cuesta 3€ en el país A, y en el país B cuesta 5€.
Echemos cuentas:
• País A: 1000(€/pm)/3(€/BM) = 333,33 (BM/pm)
• País B: 1500(€/pm)/5(€/BM) = 250 (BM/pm)
n Conclusión: no sabemos donde se vive mejor, pero en el país
A una persona durante un mes puede comer un 33% más de
bocatas que en el país B
4
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 7
Medidas, métricas e indicadores
n Es decir,
n La medida captura una característica individual
n La medición permite capturar dicha característica
n La métrica permite relacionar y comparar mediciones
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 8
Medidas, métricas e indicadores
n Las métricas son el fundamento de los indicadores
n Un indicador es una métrica o combinación de métricas
que proporcionan una visión profunda del proceso del
software, del proyecto de software o del producto en sí
n Ejemplo: en el país A, no han aumentado los sueldos en los
últimos tres años, pero el índice Bocatas se ha duplicado en
ese periodo
n Ejemplo: la productividad media de nuestra empresa es de
500(LDC/pm) y en el último proyecto ha sido de
250(LDC/pm)
n Un indicador permite al gestor ajustar el producto, el
proyecto o el proceso para mejorar
n Ejemplo: en 4 equipos de proyecto software, el de menor
productividad no usa una técnica que usan los otros. Se
deduce que puede ser recomendable utilizar esa técnica en
ese equipo
5
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 9
Métricas de proyecto y de proceso
n Nuestros objetivos son establecer:
n Métricas del proyecto à indicadores del proyecto
n Métricas del proceso à indicadores del proceso
n Los indicadores del proyecto permiten al gestor:
n Evaluar el estado del proyecto en curso
n Seguir la pista de riesgos potenciales
n Detectar áreas problemáticas antes de que se conviertan en
críticas
n Ajustar el flujo y las tareas de trabajo
n Evaluar la habilidad del equipo del proyecto en controlar la
calidad de los productos de trabajo de la IS
n Los indicadores del proceso permiten:
n Al gestor, evaluar lo que funciona y lo que no
n A la organización, tener una visión profunda de la eficacia de
un proceso ya existente
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 10
Métricas de proyecto y de proceso
n Técnicamente no existe gran diferencia entre las métricas
del proyecto y del proceso
n Podemos concebir las métricas del proceso como
recopilaciones de métricas del proyecto
6
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 11
Métricas de proyecto y de proceso
n Métricas del proceso à indicadores del proceso à mejora
en el proceso
n Cuestiones:
n Si la gestión se basa en el personal, problema y proceso,
¿por qué nos centramos en mejorar el proceso?
n ¿Por qué el proceso es un factor clave y controlable para
mejorar la calidad del software y el rendimiento de la
organización?
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 12
Métricas de proyecto y de proceso
n El proceso y diversos factores de un proyecto
7
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 13
Métricas del proceso
n ¿Cómo medir el proceso?
n Las métricas del proceso se extraen de las métricas del
proyecto
n En cualquier caso hay métricas privadas y otras públicas
• Métricas privadas (de uso individual):
• Índices de defectos (individual, por módulo)
• Errores encontrados durante el desarrollo
• Públicas para el equipo:
• Índices de defectos
• Errores encontrados en revisiones técnicas del proyecto
• LDC
• Puntos de función por módulo y función
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 14
Métricas del proceso
n Las métricas del proceso pueden ser muy útiles, pero hay que
saber interpretarlas
n Normas básicas de interpretación:
n Utilizar el sentido común al interpretar los datos de métricas
n Proporcionar una realimentación regular a particulares y
equipos
n No utilizar métricas para evaluar a particulares
n Establecer métricas claras y objetivos para alcanzarlas
n No utilizar métricas para amenazar a particulares o equipos
n Si una métrica identifica un área problemática no se debería
considerar como negativa
• Considerarlos como un indicador de mejora de proceso
n Hay que interpretar todas las métricas en su conjunto, y no
primar una en particular
• No obsesionarse con una sola métrica, excluyendo otras
importantes
8
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 15
Métricas del proceso y mejora del proceso
n La utilización de métricas e indicadores fiables da lugar a
una mejora estadística del proceso del software (MEPS)
n Esta mejora se basa en un análisis de fallos que identifica
la causa y origen de errores y defectos para varios
proyectos de software
n Error: fallo en un producto generado durante el proceso de
IS que es detectado antes de la entrega al cliente
n Defecto: fallo detectado después de la entrega al cliente.
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 16
Métricas del proceso y mejora del proceso
n Análisis de fallos:
1. Se categorizan por origen todos los errores y defectos de
varios proyectos
2. Se registra el coste de corregir cada error y defecto
3. Los errores y defectos de cada categoría se cuentan y se
ordenan de mayor a menor coste
4. Se computa el coste global de errores y defectos de cada
categoría
5. Los datos resultantes se analizan para detectar las
categorías que producen el coste más alto para la
organización
6. Se desarrollan planes para modificar el proceso con el
propósito de eliminar (o reducir la frecuencia de apariciones
de) la clase de errores y defectos que sean más costosos
9
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 17
Métricas del proceso y mejora del proceso
n Aplicando los pasos 1 y 2 se puede desarrollar una
distribución de fallos
Causas de fallos y su origen para varios proyectos [R.Grady, 1992]
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 18
Métricas del proceso y mejora del proceso
n Para ayudar a diagnosticar los datos presentados en el diagrama
de frecuencias se puede utilizar un diagrama de espina
n Las líneas horizontales identifican problemas
n Las líneas diagonales identifican posibles causas
10
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 19
Métricas del proyecto
n Las métricas del proceso son estratégicas:
n Determinan el curso del proceso de producción de software
n Las métricas del proyecto son tácticas:
n Permiten adaptar el flujo de trabajo del proyecto actual y las
actividades técnicas
n La primera aplicación de las métricas del proyecto ocurre
durante la estimación
n Se realiza a partir de datos históricos
n A medida que avanza el proyecto, las medidas del esfuerzo y
el tiempo se comparan con las de planificación
n El gestor utiliza estos datos para supervisar y controlar el
avance
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 20
Métricas del proyecto
n Utilización de las métricas del proyecto:
n Para minimizar la planificación del desarrollo
• Haciendo los ajustes necesarios que eviten retrasos y mitiguen
problemas y riesgos potenciales
n Evaluar la calidad de los productos en el momento actual
• Modificando el enfoque técnico para mejorar la calidad, si es
necesario
n Mejor calidad ->
Menos defectos -> Menos trabajo -> Menor coste
11
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 21
Métricas del software
n Como el contexto de uso identifica al tipo de métrica, nos
referiremos a las métricas del producto y del proceso
como métricas del software
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 22
Métricas del software. Clasificación
Productividad Calidad
Orientadas al Tamaño
Euros pgDoc
LDC KLDC
errores defectos
KLDC KLDC
Orientadas a la Función
(PF, PC, PF3D)
euros pgDoc
PF PF
errores defectos
PF PF
Otras
LDC PF euros
pm pm PgDoc
errores/pm TMC,
desperdicios, integridad,
EED, PFBD, FDF, TMF,
disponibilidad
Métricas del software
LDC: Líneas de código
KLDC: Miles de líneas de código
PF: Punto de función
PgDoc: Página de documentación
pm: personas/mes
LDC: Líneas de código
KLDC: Miles de líneas de código
PF: Punto de función
PgDoc: Página de documentación
pm: personas/mes
12
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 23
Métricas de productividad orientadas al tamaño
n Se obtiene considerando las medidas de productividad y
normalizándolas por el tamaño del código, es decir las
Líneas De Código (LDC)
Proyecto LDC Esfuerzo* Coste*
€(000)
Pag.
Doc.
Errores Defectos Personas
P1 12.100 24 120 365 134 29 3
P2 27.200 62 314 1224 321 86 5
P3 20.200 43 224 1050 256 64 6
...................................................................................
*Incluye todas las actividades de IS (análisis, diseño, codificación y prueba)
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 24
Métricas de productividad orientadas al tamaño
n ¿Qué es el esfuerzo?
esfuerzo = #personas * #tiempo
n Es una medida que indica que da igual tener dos personas
trabajando tres meses, que tres personas trabajando dos
meses
e = 3(p) * 2(m) = 6(pm)
e = 2(p) * 3(m) = 6(pm)
13
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 25
Métricas de productividad orientadas al tamaño
n Métricas orientadas al tamaño
n Coste: #euros/#LDC
↓mejor
Ejemplo: P1: 120000(€)/12100(LDC) = 9,92 (€/LDC)
n Documentación: #pgDoc/#KLDC
↑mejor
Ejemplo: P2: 1224(pgDoc)/27,2(KLDC) = 45(pgDoc/KLDC)
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 26
Métricas de productividad orientadas al tamaño
n ¿Cómo calcular las LDC?
n Debe contabilizarse cada línea nueva o modificada
n Las líneas para las pruebas no deben incluirse en el tamaño
total, salvo que tengan un carácter definitivo
n Las líneas de código de programas de prueba tan solo se
contabilizan si se desarrollan con el nivel de calidad exigido
al entregar el producto
n Se contabilizan las líneas correspondientes a las llamadas al
sistema operativo
n No se consideran los comentarios
n No se contabiliza el pseudo-código
n Cada ocurrencia de macro o include se considera como una
línea
n El código generado por macros o include solo se considera
una vez
14
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 27
Métricas de productividad orientadas al tamaño
n Las LDC no están comúnmente aceptadas
n Ventajas:
n Fácil de calcular
n Existen muchos modelos de estimación basados en LDC
n Existen muchas medidas de LDC
n Inconvenientes:
n Dependientes de los lenguajes de programación
n Perjudican a los programas cortos, pero bien diseñados
n Difícil uso en estimación debido al nivel de detalle
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 28
Métricas de productividad orientadas a la función
n Se obtienen considerando las medidas de productividad y
normalizándolas por una medida de la funcionalidad
entregada por la aplicación
n Como la funcionalidad no se puede medir directamente, se
debe derivar indirectamente de otras medidas directas
15
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 29
Métricas de productividad orientadas a la función
n La funcionalidad de un programa se puede medir por el
Punto de Función (PF)
n Se deriva de las mediciones del software
• Medidas directas del dominio
• Medidas indirectas: complejidad del software
n Se calcula en base a la expresión
PF = cuenta-total * (0,65 + 0,01* Σ
i=1..14
F
i
)
donde cuenta-total y cada F
i
(valores de ajuste de la
complejidad) se obtienen de la siguiente manera
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 30
Métricas de productividad orientadas a la función
n Cálculo de cuenta-total
1. Medir cinco características del dominio de información:
• Número de Entradas de usuario
• Cada entrada de usuario que proporcione diferentes datos orientados
a la aplicación
• Número de Salidas de usuario
• Cada salida que proporcione al usuario información orientada a la
aplicación (e.g. informes, pantallas, mensajes de error, etc.)
• Número de Peticiones de usuario
• Entradas interactivas que producen la generación de alguna
respuesta del software inmediata en forma de salida interactiva
• Número de Archivos
• Cada archivo maestro lógico, i.e., cada grupo de datos que puede ser
una parte de una gran base de datos o sistema de archivos
• Número de Interfaces externas
• Interfaces legibles por la máquina que se utilizan para transmitir
información a otro sistema (e.g. disco, red, etc.).
16
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 31
Métricas de productividad orientadas a la función
n Cálculo de cuenta-total
2. Rellenar los valores en la siguiente tabla
3. Cada cuenta se pondera con un valor de complejidad
• Esto lo determina cada organización para cada tipo de proyecto
4. Se hace la suma para obtener la cuenta-total
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 32
Métricas de productividad orientadas a la función
n Valores de ajuste complejidad (F
i
)
n Se calculan respondiendo a las siguientes preguntas en una escala
de 0 (no importante o aplicable) a 5 (absolutamente esencial):
1. ¿Requiere el sistema copias de seguridad y de recuperación fiables?
2. ¿Se requiere comunicación de datos?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿Es crítico el rendimiento?
5. ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente
utilizado?
6. ¿Requiere el sistema entrada de datos interactiva?
7. ¿Requiere la entrada de datos interactiva que las transacciones de
entrada se lleven a cabo sobre múltiples pantallas u operaciones?
8. ¿Se actualizan los archivos maestros de forma interactiva?
9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?
10.¿Es complejo el procesamiento interno?
11.¿Se ha diseñado el código para ser reutilizable?
12.¿Están incluidas en el diseño la conversión e instalación?
13.¿Se ha diseñado el sistema para soportar múltiples instalaciones en
diferentes organizaciones?
14.¿Se ha diseñado la aplicación para facilitar los cambios y ser fácilmente
utilizada por el usuario?
17
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 33
Métricas de productividad orientadas a la función
n Una vez calculado el valor de PF, las métricas son
análogas a las orientadas al tamaño
- Coste: #euros/#PF
↓mejor
- Documentación: #pgDoc/#PF
↑mejor
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 34
Métricas de productividad orientadas a la función
n Punto de Característica (PC)
n Una ampliación de la medida de PF
n La medida de PF tiene su origen en aplicaciones de gestión
n Prima por tanto la dimensión de datos, obviando cuestiones
de complejidad funcional
n Esto hace a la medida de PF inadecuada para sistemas de
ingeniería o empotrados
n Solución: ampliar los parámetros de medición para tener en
cuenta los algoritmos
n El PC es una ampliación de la medida de PF aplicable a
sistemas con una fuerte componente funcional (por
ejemplo, tiempo real)
18
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 35
Métricas de productividad orientadas a la función
n Punto de Característica (PC)
n Consiste en ampliar la tabla de cuenta-total de PF con un
parámetro de medición algoritmos
• Un algoritmo es un problema de cálculo limitado que se incluye
dentro de un programa
• Una búsqueda, una operación de matrices, una codificación, manejar
una interrupción
• El factor de ponderación depende de la importancia que se
quiera dar a este parámetro (e.g. 10, 15, 20)
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 36
Métricas de productividad orientadas a la función
n Los PF tampoco están comúnmente aceptados
n Ventajas
n Independientes del lenguaje de programación
n Permiten hacer estimaciones más fácilmente
n Inconvenientes
n Basadas en cálculos subjetivos
n Parámetros y factores no evidentes
n No tienen un significado físico directo
19
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 37
Relación LDC-PF
n Qué funcionalidad aproximada proporciona una línea de código
en un lenguaje de programación
12 SQL
16 Powerbuilder
22 Smalltalk
32 Visual Basic
53 Ada95
64 C++
90 Pascal
106 Fortran
106 COBOL
128 C
320 Ensamblador
LDC/ PF ( media) Lenguaj e de programación
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 38
Otras métricas de productividad
n Son cruciales pero no están normalizadas por LDC ni por
PF
n Productividad: #LDC/#persona-mes
↑mejor
P3: 20200(LDC)/43(pm) = 469,77 (LDC/pm)
n Productividad: #PF/#persona-mes
↑mejor
n Coste documentación: #euros/#páginas doc.
↓mejor
P1: 120000(€)/365(pgDoc) = 328,77(€/pgDoc)
20
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 39
Factores que inciden en la productividad
n Los gestores no deben utilizar directamente las métricas
de productividad para evaluar al personal
n Ya que no todos los proyectos son iguales
n Hay muchos factores que afectan a la productividad:
• Factores humanos. Tamaño y experiencia de la organización de
desarrollo
• Factores del problema. La complejidad del problema que se debe
resolver y el número de cambios en las restricciones o los
requisitos de diseño
• Factores del proceso. Técnicas de análisis y diseño que utilizan,
lenguajes y herramientas CASE y técnicas de revisión
• Factores del producto. Fiabilidad y rendimiento del sistema
• Factores del recurso. Disponibilidad de herramientas CASE y
recursos de hardware y software
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 40
Factores que inciden en la productividad
n Discusión: ¿no es contradictoria esta tabla con las PPP de
gestión?
40 Recurso
140 Producto
50 Proceso
40 Problema
90 Humano
Variación
aproximada (%)
Factor
Variación de la productividad en función del factor (según Jones)
21
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 41
Métricas de calidad del software
n Métricas técnicas
n Objetivas
• Corrección, fiabilidad, eficiencia, usabilidad, etc.
n Para evaluar la calidad del análisis, modelos de diseño,
código fuente, casos de prueba
n Métricas de calidad
n Efectividad de las actividades de control y garantía de calidad
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 42
Métricas de calidad del software
n Errores
n #errores/#KLDC
↓mejor
P2: 321(e)/12,1(KLDC) = 26,53 (e/KDLC)
n #errores/#PF
↓mejor
n #errores/#persona-mes
↓mejor
P3: 256(e)/43(pm) = 5,95 (e/pm)
22
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 43
Métricas de calidad del software
n Factores que afectan a la calidad del software [Gilb 1988]
1. Corrección
n Grado en que el software lleva a cabo su función requerida
#defectos/#KLDC
↓mejor
P1: 29(d)/12,1(KLDC) = 2,4 (d/KLDC)
#defectos/#PF
↓mejor
Un defecto es una falta verificada de conformidad con los requisitos
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 44
Métricas de calidad del software
2. Facilidad de mantenimiento
n Facilidad con la que se puede corregir un programa si se
encuentra un error, se puede adaptar a su entorno si
cambia, o mejorar si el cliente desea un cambio de requisitos
n Métrica orientada al tiempo: Tiempo Medio de Cambio (TMC)
• Tiempo que se tarda en analizar la petición de cambio, en
diseñar una modificación adecuada, implementar el cambio, en
probarlo y en distribuir el cambio a todos los usuarios
• Cuanto más fácil sea de mantener un programa, más bajo
tendrá su TMC
n Métrica orientada al coste: Desperdicios (Hitachi, 1981)
• Coste en corregir defectos encontrados después de haber
distribuido el software a los usuarios finales
23
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 45
Métricas de calidad del software
3. Integridad
n Mide la habilidad de un sistema para resistir ataques (tanto
accidentales como intencionados) contra su seguridad
n El ataque puede producirse en cualquier componente del
software (programas, datos o documentos)
n Para medir la integridad debemos medir la seguridad y la
amenaza, las cuales se estiman o deducen de la evidencia
empírica
• Amenaza: probabilidad de que se produzca un ataque de tipo
determinado en un momento determinado
• Seguridad: probabilidad de que se pueda repeler el ataque de un
tipo determinado en un momento determinado
integridad = Σ
tipo-ataques
[(1-amenaza)*(1-seguridad)]
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 46
Métricas de calidad del software
n Ejemplo
a
P1
no oculta ficheros
no hace backup
P2
oculta ficheros
hace backup

Amenaza Seguridad Amenaza Seguridad
....................
borrado BD
aplicación
0,7 0 0,2 0,8
....................
a

integridad
P1borrado
= 1 – 0,7 * (1 – 0) = 0,3
integridad
P2borrado
= 1 – 0,2 * (1 – 0,8= 0,96
24
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 47
Métricas de calidad del software
4. Facilidad de uso
n Intento por medir lo amigable que puede ser un programa
con el usuario
n Se puede medir en función de cuatro características:
1. Habilidad intelectual y/o física para aprender el sistema
2. Tiempo requerido para llegar a ser moderadamente eficiente en
el uso del sistema
3. Aumento neto de la productividad (sobre el sistema que
reemplaza) medida cuando alguien utiliza el sistema de manera
moderadamente eficiente
4. Valoración subjetiva (a veces obtenida mediante un
cuestionario) de la disposición de los usuarios hacia el sistema
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 48
Métricas de calidad del software
n Eficacia de la Eliminación de Defectos (EED)
n Métrica de la habilidad de filtrar las actividades de la garantía de
calidad y de control al aplicarse a todas las actividades del marco de
trabajo del proceso
n Considerada globalmente para un proyecto:
EED = E/(E+D)
E: número de errores encontrados antes de la entrega
D: número de defectos
n Objetivo: EED = 1 (no se han encontrado defectos en el software)
n Si E es muy grande, EED estará próxima a 1
• Cuanto más errores encontremos antes de la entrega, mejor funcionarán
las técnicas de garantía de calidad
n EED también puede utilizarse dentro del proyecto para medir la
habilidad de un equipo para encontrar errores antes de pasar a la
siguiente actividad
EED
i
= E
i
/(E
i
+E
i+1
)
E
i
: errores detectados en la actividad i de IS
E
i+1
: errores detectados en la actividad i+1 de IS que no se detectaron y
provienen de la actividad i
n Objetivo: EEDi = 1
25
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 49
Métricas de calidad del software
n Eficacia de la Eliminación de Defectos (EED)
n Consejo:
• Utilizar EED como una medida de la eficiencia en las primeras
actividades de gestión de calidad del software
• Si EED es bajo durante el análisis y diseño, emplear algún
tiempo mejorando la forma de conducir las revisiones técnicas
formales
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 50
Fiabilidad del software
n Fiabilidad del software: ausencia de fallos
n Probabilidad de Fallo Bajo Demanda (PFBD)
n Mide la probabilidad de que un sistema falle cuando se le
hace una petición de servicio
PFBD = #fallos/#peticiones
↓mejor
• Ejemplo: una PFBD de 0,001 significa que el sistema tiene un
fallo cada mil peticiones
n Frecuencia de fallo
n Mide la frecuencia de aparición de fallo de funcionamiento
FDF = #fallos/#unidad tiempo
↓mejor
• Ejemplo: una FDF de 0,006 indica que se producen 3 fallos cada
500 unidades de tiempo
26
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 51
Fiabilidad del software
n Tiempo medio de fallo (TMF)
n Mide el tiempo transcurrido entre fallos del sistema
TMF = #unidades de tiempo/#fallos
↑mejor
• Ejemplo: un TMF de 166,66 indica en 500 unidades de tiempo
transcurridas se han producido 3 fallos
• Si no hay cambios, TMF = 1/FDF
n Disponibilidad
n Mide el tiempo en que un sistema puede ser usado con
normalidad
dispon. = #tiempo disponible/# tiempo funcionando
↑mejor
• Ejemplo: Una disponibilidad de 0,95 indica que el sistema está
disponible 950 unidades de cada 1000 unidades de tiempo.
• Unidad de tiempo (CPU, días, etc.)
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 52
Línea base de métricas
n Una línea base de métricas es una recopilación de
métricas de varios proyectos que sirve para establecer
indicadores
n Un ejemplo sencillo es la tabla de LDC de la trasparencia 23
n No tiene nada que ver con el concepto de línea base que
veremos en configuración
n Para ser útil debe tener los siguientes atributos:
n Los datos deben ser razonablemente exactos
n Los datos deben extraerse del mayor número de proyectos
que sea posible
n Las medidas deben ser consistentes
n Las aplicaciones deben ser semejantes para hacer la
estimación
27
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 53
Línea base de métricas
n Proceso de recopilación de métricas del software
n Recopilación de medidas (lo más difícil)
n Cálculo de métricas (LDC, PF, calidad, ...)
n Evaluar las métricas y aplicar en la estimación, trabajo técnico,
control de proyectos y mejora del proceso
• Produce el grupo de indicadores que guían el proyecto y el proceso
Proceso de
IS
Proyecto de
software
Producto de
software
Recopilación
de datos
Evaluación
de métricas
Cálculo
de métricas
Medidas
Indicadores
Métricas
Juan Pavón Mestras
Facultad de Informática UCM, 2004
Métricas 54
Conclusiones
n Medir: conocer
n Medida -> métrica -> indicador -> mejora del proceso
n Métricas del proceso, proyecto y software
n Métricas proceso: estratégicas
n Métricas proyecto: tácticas
n Métricas técnicas
n Métricas orientadas al tamaño y a la función
n Métricas de productividad y calidad