You are on page 1of 18

Métricas de productividad y calidad

• La medición es fundamental para cualquier disciplina de
ingeniería.

• En el contexto de la planificación de proyecto, nos preocupamos
principalmente por las métricas de productividad y de calidad:
– Medir el rendimiento de desarrollo como función del
esfuerzo aplicado.
– Evaluar la calidad del desarrollo realizado.
– Crear una base histórica para poder planificar próximos
proyectos.

• Nos interesa saber
– ¿Cual fue la productividad del desarrollo de software en
anteriores proyectos?
– ¿Como era la calidad del software producido?
– ¿Cómo se pueden extrapolar al presente los datos de
productividad anteriores?
– ¿Que técnicas son las más adecuadas según que proyectos?

• Encontramos dificultades en ponernos de acuerdo sobre que
medir y como evaluar las medidas en el software.

I-2-1
Clasificación de las métricas

• Las mediciones se pueden englobar en dos categorías:

– Medidas directas
• El coste y el esfuerzo aplicado.
• El número de líneas de código (LDC), velocidad de
ejecución, memoria, defectos.

– Medidas indirectas
• Funcionalidad, calidad, complejidad, eficiencia,
fiabilidad, mantenimiento.

• Dependiendo de lo que se quiera medir, las métricas se clasifican
en:

– Métricas orientadas al tamaño
• Son medidas directas sobre el resultado y la calidad del
software

– Métricas orientadas a la función
• Son medidas indirectas

– Métricas orientadas a la persona
• Proporcionan información sobre la forma en que la gente
desarrolla software y sobre el puntos de vista humano de
la efectividad de las herramientas y métodos.

I-2-2
Clasificación de la métricas

• Podemos clasificar el campo de las métricas del software en
– Métricas de productividad.
• Miden el rendimiento del proceso

– Métricas de calidad.
• Miden como se ajusta el software a los requisitos
implícitos y explícitos del cliente.

– Métricas técnicas.
• Se centra en las características del software
(complejidad lógica, grado de modularidad).

I-2-3
Métricas orientadas al tamaño

• Las métricas del software orientadas al tamaño son medidas
directas del software y del proceso por el cual se desarrolla. A
continuación se muestran una serie de valores:
– Esfuerzo: 24
– Ptas: 12
– KLDC: 20,4
– Páginas de documentos: 123
– Errores: 18
– Peronal: 4

• Con los datos de la tabla se puede desarrollar, para cada
proyecto, un conjunto de métricas sencillas de productividad y
de calidad orientadas al tamaño. También se pueden calcular
valores medios con todos los proyectos.

– Productividad = KLDC / persona-mes

– Calidad = errores / KLDC

– Costes = pesetas / KLDC

– Documentación = páginas /KLDC

I-2-4
Polémica de las métricas orientadas al
tamaño
• Las métricas orientadas al tamaño son bastante polémicas.

• La mayor parte de la discusión gira en torno al uso de las líneas
de código (LDC) como medida clave.

• Defensores
– LDC es un artificio que se puede calcular fácilmente para
todos lo proyectos.
– Muchos modelos de estimación del software existentes
utilizan LDC como clave de entrada
– Existe un amplio conjunto de datos y de literatura basados
en LDC.

• Detractores
– LDC es altamente dependiente del lenguaje de
programación.
– Perjudica a los programas cortos pero bien diseñado.
– No se puede adaptar fácilmente a lenguajes no
procedimentales.

I-2-5
Métricas orientadas a la función

• Las métricas del software orientadas a la función son medidas
indirectas del software y del proceso por el cual se desarrolla.

• Se centran en la “funcionalidad” o “utilidad” del programa.

• Albrecht, sugirió el método del punto de función.

• Los puntos de función (PFs) se obtienen utilizando una relación
empírica basada en medidas cuantitativas del dominio de
información del software y valoraciones subjetivas de la
complejidad del software.

• Se basa en la evaluación de cinco características del ámbito de la
información.

• La evaluación de cada una de estas características se pondera por
un determinado peso dependiendo de si se considera simple,
media o compleja.

I-2-6
P.F.: Características del ámbito de la
información
– Número de entradas de usuario. (simple * 3, medio * 4 y
complejo * 6)
• Entrada de usuario que proporciona al software diferentes
datos orientados a la aplicación.

– Número de salidas de usuario. (simple *4, medio *5 y
complejo *7)
• Salidas que proporcionan al usuario información
orientada a la aplicación (informes, pantallas, mensajes
de error, etc.)

– Número de peticiones de usuario. (simple * 3, medio *4 y
complejo *6)
• Una petición está definida como una entrada interactiva
que resulta de la generación de algún tipo de respuesta en
forma de salida interactiva (entrada-salida).

– Número de archivos (simple *7, medio *10 y complejo *15)
• Se cuenta cada archivo lógico.

– Número de interfaces externas. (simple * 5, medio * 7 y
complejo *10)
• Se cuentan todas las interfaces legibles por la máquina
(por ejemplo, archivos de datos en cinta o disco) que son
utilizados para transmitir información a otro sistema.

I-2-7
P. F.: Cálculo de los P. F.

• A cada uno de estos valores se le asocia una complejidad. Las
organizaciones que utilizan métodos de puntos de función
desarrollan criterios para determinar si una entrada determinada
es simple, media o compleja. No obstante, la determinación de la
complejidad es algo subjetivo.

• Para calcular los puntos de función, se utiliza la siguiente
relación:
– PF = cuanta_total x (0,65 + 0,01 x suma(Fi))
– donde cuenta_total es la suma de las características
ponderadas del ámbito.
– Fi (i = 1 hasta 14) son los valores de ajuste de complejidad
basados en las respuestas a las cuestiones señaladas en la
siguiente transparencia.

• Los valores constantes de la ecuación anterior y los factores de
peso aplicados a las cuentas de los ámbitos de información han
sido determinados empíricamente.

• Una vez calculados los puntos de función, se usan de forma
análoga a las LDC como medida de la productividad, calidad y
otros atributos del software:
– Productividad = PF / personas_mes
– Calidad = errores / PF
– Costes = pesetas / PF
– Documentación = páginas / PF

I-2-8
P. F.: Valores de ajuste de complejidad

• Cada una de las siguientes cuestiones se evalúa en una escala de 0
a 5:
– 0 = Sin influencia 1 = Incidental
– 2 = Moderado 3 = Medio
– 4 = Significativo 5 = Esencial

1. ¿Requiere el sistema copias de seguridad y recuperación fiables?
2. ¿Se requieren comunicaciones de datos?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿Es crítico el rendimiento?
5. ¿Será ejecutado 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 o variadas
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 y la 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 para ser
fácilmente utilizada por el usuario?

I-2-9
P. F.: Puntos de características

• Se denomina puntos de características, a la métrica que
incorpora a los puntos de función la complejidad de los
programas.

• La medida del punto de característica da cabida a aplicaciones
cuya complejidad algorítmica es alta. Las aplicaciones de software
de tiempo real, de control de procesos y de sistemas empotrados
tienden a tener una complejidad algorítmica alta y son por lo tanto
fácilmente tratables por puntos de características.

• Además de los valores del ámbito de información, la métrica del
punto de característica tiene en cuenta otra característica del
software, los algoritmos. Un algoritmo se define como “un
problema de complejidad computacional limitada que se incluye
dentro de un determinado programa de computadora”. La
inversión de una matriz, la decodificación de una cadena de bits o
el manejo de una interrupción, son todos ellos ejemplos de
algoritmos.

• Para calcular los puntos de característica, se suman las siguientes
cantidades.
– Número de entradas de usuario * 4
– Número de salidas de usuario * 5
– Número de peticiones al usuario * 4
– Número de archivos * 7
– Número de interfaces externos * 7
– Algoritmos * 3

I-2-10
P. F.: Punto de características

• Se usa un único valor de peso para cada uno de los parámetros
de medida y se calcula el valor del punto de características
global mediante la ecuación anterior.

• Los PF y los PC representan lo mismo: “funcionalidad” o
“utilidad” en forma de software.

• Ambas medidas dan los mismos resultados para aplicaciones
convencionales de sistemas de información, pero para sistemas
más complejos de tiempo real, la cuenta de puntos de
característica es frecuentemente entre un 20 y 35 por 100 mayor
que la cuenta determinada sólo mediante puntos de función.

• Comentarios a la métrica del punto de función y de
característica:

– Defensores
• PF y PC son independientes del lenguaje de
programación.

– Detractores
• Requiere cierta habilidad, experiencia y subjetividad.

I-2-11
Cinco factores importantes que inciden
en la productividad del software
– Factores humanos.
• El tamaño y la experiencia de la organización de
desarrollo.
– Factores del problema.
• La Complejidad del problema a resolver y el número de
cambios en las restricciones o los requisitos del diseño.
– Factores del proceso.
• Técnicas del análisis y diseño utilizadas, disponibilidad
de lenguajes y herramientas CASE y técnicas de revisión.
– Factores del producto.
• Fiabilidad y rendimiento del sistema basado en
computadora.
– Factores de los recursos.
• Disponibilidad de herramientas CASE, recursos de
hardware y software.
• Tanto PF como LDC han resultado ser predicciones relativamente
precisas del esfuerzo y del coste de desarrollo de software. Sin
embargo para usar LDC y PF en las técnicas de estimación, se tiene
que establecer una línea base de información histórica.
• ¿Se debe compara la relación LDC/persona_mes de un grupo con
los datos similares de otro grupo?
• ¿Deben los gestores evaluar el rendimiento de las personas usando
estas medidas?
• Hay muchos factores que influyen en la productividad, haciendo
que la comparación sea mal interpretada.

I-2-12
Métricas para la calidad del software

• Las métricas de calidad contemplan la complejidad del
programa, la modularidad efectiva y el tamaño total del
programa.

• Factores de calidad
– McCall y Cavano propusieron un conjunto de factores de
calidad hacia el desarrollo de métricas de calidad de
software. Estos factores evaluaban el software desde tres
puntos de vista distintos:

• Operación del producto (su uso)

• Revisión del producto (su modificación)

• Transición del producto (“transportarlo”)

I-2-13
Medidas de calidad

• Aunque existen muchas formas de medir la calidad del software, las
métricas a posteriori son las más ampliamente utilizadas. Estas
incluyen:

– Corrección
• Es el número de defectos por KLDC, donde defecto se
define como la falta comprobada de conformidad con los
requisitos. Los defectos los comunica un usuario del
programa después de que el programa ha sido distribuido
para su uso general y se cuentan durante un período de
tiempo estándar, típicamente un año.

– Facilidad de mantenimiento
• El mantenimiento del software representa más esfuerzo
que cualquier otra actividad de la Ingeniería del software.
Es la facilidad con la cual se puede corregir un programa
si se encuentra un error, adaptarlo si su entorno cambia, o
mejorarlo si el cliente desea un cambio en los requisitos.

• No hay forma de medir directamente la facilidad de
mantenimiento; por lo tanto, debemos utilizar medidas
indirectas.

• Una métrica sencilla es el tiempo medio entre cambios
(TMEC), el tiempo que lleva analizar el cambio requerido,
diseñar una modificación apropiada, implementar el
cambio, probarlo y distribuir el cambio a todos los
usuarios.

I-2-14
Medidas de calidad

– Integridad
• Este atributo mide la habilidad de un sistema para
resistir ataques contra su integridad (tanto accidentales
como intencionados). Ataque puede producirse sobre
cualquiera de los tres componentes del software:
programas, datos y documentos.

• Para medir la integridad, se tienen que definir dos
atributos adicionales: amenaza y seguridad. Amenaza es
la probabilidad de que un ataque de un tipo determinado
ocurra en un tiempo determinado. La seguridad es el
probabilidad de que se pueda repeler el ataque de un
determinado tipo. La integridad del sistema se puede
definir como:
– Integridad = suma ( 1 - amenaza * (1 - seguridad))

– Facilidad de uso
• La facilidad de uso intenta cuantificar la interfaz con el
usuario y se puede medir en función de cuatro
características:
– Habilidad intelectual y/o física requerida para
aprender el sistema.
– Tiempo requerido para llegar a ser moderadamente
eficiente en el uso del sistema.
– Aumento neto en productividad.
– Valoración subjetiva de la disposición de los
usuarios hacia el sistema.

I-2-15
Integración de la métricas en la
Ingeniería del Software
• La mayoría de los que desarrollan software no miden y,
desgraciadamente, la mayoría tiene pocas ganas de comenzar a
hacerlo. El intentar reunir medidas donde nadie las ha reunido
anteriormente se encuentra frecuentemente con una cierta
resistencia.
• Argumentos a favor de las métricas del software.
– Si no medimos, no hay forma de determinar si estamos
mejorando.

– La medición proporciona beneficios a nivel estratégico, a
nivel de proyecto y a nivel técnico.

– Mediante la obtención y la evaluación de medidas de
calidad y de productividad, los directivos de gestión pueden
establecer objetivos significativos para mejorar el proceso
de ingeniería del software.

– El software es un objetivo comercial estratégico para
muchas empresas.

– Los rigores del trabajo diario de un proyecto del software
dejan poco tiempo para planteamientos estratégicos.

I-2-16
Integración de la métricas en la
Ingeniería del Software
– Las siguientes preguntas se responderían si tuviésemos
métricas de proyectos anteriores:
• ¿Qué requisitos del usuario son más susceptibles al
cambio?

• ¿Qué módulos del sistemas son más propensos a error?

• ¿Cómo se debe planificar la prueba para cada módulo?

• ¿Cuántos errores puedo esperar cuando comience la
prueba?

I-2-17
Establecimiento de una línea base

– Mediante el establecimiento de una línea base para las
métricas, se pueden obtener beneficios a nivel estratégico ,
de proyecto y técnico.

– La línea base es el conjunto de datos recogidos de
anteriores proyectos de software.

– Para que sea una ayuda efectiva en la planificación
estratégica y/o en las estimaciones de coste y esfuerzo, los
datos de la línea base tienen que poseer los siguientes
atributos:

• Los datos deben ser razonablemente precisos.

• Los datos deben obtenerse de muchos proyectos.

• Las medidas tienen que ser consistentes (por ejemplo,
las LDC tienen que ser interpretadas de igual forma
para todos los proyectos de los que se hayan obtenido
datos).

• Las aplicaciones deben ser similares a la que vaya a
ser estimada.

I-2-18