Este documento presenta conceptos básicos sobre métricas técnicas de software. Define términos como medida, medición, indicador y métrica. Explica que las métricas de software comprenden actividades como control de calidad, fiabilidad, productividad y más. Luego describe factores de calidad como los de McCall y la ISO 9126, e introduce estructuras para métricas de software y ejemplos de métricas orientadas a tamaño y función. Finalmente, propone métricas sencillas para pequeñas organizaciones de software.

1. Métricas Técnicas del
Software
Ingeniería en Informática y Sistemas
Administración de Proyectos de Sistemas
1

2. Conceptos básicos
 Medida:
Proporciona una indicación cuantitativa de la
cantidad, dimensiones o tamaño de algunos
atributos de un producto. Puede tratarse, por lo
tanto, del resultado de una medición
 Medición
Acto de determinar una medida

3. …conceptos básicos
 Indicador
– Magnitud utilizada para medir o comparar los
resultados efectivamente obtenidos, en la
ejecución de un proyecto, programa o actividad.
– Los indicadores tienen como principal función
señalar datos, procedimientos a seguir,
fenómenos, situaciones específicas.
 Métrica
Es una medida del grado en que un sistema,
componente o proceso posee un atributo dado

4. …conceptos básicos
 Métricas de software
Las métricas del software comprenden un amplio
rango de actividades diversas:
– Aseguramiento y control de calidad
– Modelos de fiabilidad
– Modelos y evaluación de ejecución
– Modelos y medidas de productividad

5. …conceptos básicos
 Dentro del proceso de planificación de desarrollo de
software, una de las salidas son las Métricas de Calidad en
el proyecto.
 Para explicar el concepto de métrica hay que hacer una
diferenciación entre métrica y medición.
 Una métrica de calidad es una definición operativa que
describe un atributo del producto o del proyecto. Una
medición es un valor real.
 La tolerancia define la variación permisible de las
métricas.

6. …conceptos básicos
 Para ejemplificar los tres conceptos: una métrica de calidad
en el proyecto puede ser el tiempo de respuesta de un
sistema informático para elaborar un reporte de datos
específico.
 Por ejemplo en un sistema de banca por internet. El reporte
es la lista de movimientos del día en una cuenta bancaria.
Una métrica de calidad en el proyecto podría ser:
– Elaborar el Reporte X en un tiempo de 3 segundos de espera para
el usuario con una tolerancia de un segundo, asumiendo que su
conexión a internet funciona correctamente
– Una medición de esta característica sería la medición real de este
tiempo una vez que el sistema se encuentra en producción: 3,1
segundos, 2,8 segundos, 2,3 segundos, etc.

7. Calidad del Software
 Los requisitos del Software son la base de las
medidas de calidad. La falta de concordancia con los
requisitos es una falta de calidad.
 Unos estándares específicos definen un conjunto de
criterios de desarrollo que guían la manera en que se
hace la ingeniería del Software. Si no se siguen los
criterios , habrá seguramente poca calidad.
 Existe un conjunto de requisitos implícitos que ha
menudo no se nombran. Si el software cumple con
sus requisitos explícitos pero falla en los implícitos ,
la calidad del software no será fiable.
7

8. Factores de calidad de McCall
 Los factores que afectan la calidad se pueden
categorizar en:
– Factores que se pueden medir directamente,
como por ejemplo los defectos por punto de
función.
– Factores que se pueden medir sólo
indirectamente, como por ejemplo la facilidad de
uso o mantenimiento.
 En todos los casos debe aparecer la medición.
Debe ser posible comparar el software
(documentos, programas, datos) con una
referencia y llegar a una conclusión sobre la
calidad.
8

9. Factores de calidad
McCall y colegas (1997)
9
Revisión del
Producto
Transición del
producto
Operación
del producto
Corrección Fiabilidad Usabilidad Disponibilidad Integridad Eficiencia
Facilidad de
mantenimiento
Flexibilidad
Facilidad de prueba
Portabilidad
Reusabilidad
Interoperatividad

10. Operación del Producto
 Corrección : Hasta donde satisface un programa su
especificación y logra los objetivos del cliente.
 Fiabilidad: Hasta dónde se puede esperar que un
programa lleve a cabo de su función con la exactitud
requerida.
 Eficiencia: La cantidad de recursos informáticos y de
código necesarios para que un programa realice su
función.
10

11.  Integridad: Hasta dónde se puede controlar
el acceso al software o a los datos por
personas no autorizadas.
 Usabilidad (facilidad de manejo):El
esfuerzo necesario para aprender a operar
los datos de entrada e interpretar las salidas
de un programa.
11

12. Revisión del producto
 Facilidad de mantenimiento: El esfuerzo
necesario para localizar y arreglar un error
en un programa.
 Flexibilidad: El esfuerzo necesario para
modificar un programa operativo.
 Facilidad de prueba: El esfuerzo necesario
para probar un programa para asegurarse de
que realiza su función pretendida.
12

13. Transición del producto
 Portabilidad: El esfuerzo necesario para transferir el
programa de un entorno de sistema hardware y/o
software a otro entorno diferente.
 Reusabilidad ( capacidad de reutilización): Hasta
donde se puede volver a emplear un programa ( o
partes de un programa) en otras aplicaciones.
 Interoperatividad: El esfuerzo necesario para acoplar
un sistema con otro.
13

14.  Es difícil desarrollar medidas directas de los
factores de calidad señalados anteriormente, por
consiguiente se definen un conjunto de métricas
para desarrollar expresiones que utilicen los
factores de acuerdo a la siguiente relación:
Fq = c1 x m1 + c2 x m2 +….+cn x mn
Fq es factor de calidad
Cn son coeficientes de regresión
Mn son las métricas que afectan al factor calidad
14

15.  Lamentablemente muchas de las métricas definidas
por McCall solamente pueden medirse de manera
subjetiva.
 Las métricas se acomodan en una lista de
comprobación que se emplea para puntuar atributos
específicos del software.
 El esquema de puntuación que se propone es una
escala del 0 (bajo) al 10 (alto)
15

16. Factores de Calidad ISO 9126
 El estándar identifica seis atributos clave de
calidad:
 Funcionalidad: El grado en que el software
satisface las necesidades indicadas por los
siguientes subatributos: idoneidad, corrección,
interoperatividad,conformidad y seguridad.
 Confiabilidad: Cantidad de tiempo que el
software está disponible para su uso. Estaá
referido por los siguientes subatributos:
madurez, tolerancia a fallos y facilidad de
recuperación.
16

17.  Usabilidad: Grado en que el software es fácil de
usar. Viene reflejado por los siguientes subatributos:
facilidad de comprensión, facilidad de aprendizaje y
operatividad.
 Eficiencia: Grado en que el software hace óptimo el
uso de los recursos del sistema. Viene reflejado por
los siguientes subatributos: tiempo de uso y recursos
utilizados.
 Facilidad de mantenimiento: La facilidad con que
una modificación puede ser realizada. Está indicada
por los siguientes subatributos: facilidad de análisis ,
facilidad de cambio, estabilidad y facilidad de
prueba.
 Portabilidad: La facilidad con que el software
puede ser llevado de un entorno a otro. Está referido
por los siguientes subatributos: facilidad de
instalación, facilidad de ajuste, facilidad de
adaptación al cambio
17

18. Estructura para las métricas del
Software
 La medición asigna números o símbolos a atributos de
entidades en el mundo real. Para conseguirlo es
necesario un modelo de medición que comprenda un
conjunto consistente de reglas.
 Existe la necesidad de medir y controlar la complejidad
del software, es bastante difícil obtener un solo valor
para representar una "métrica de calidad", sin embargo
es posible desarrollar medidas de diferentes atributos
internos del programa como ser: modularidad efectiva,
independencia funcional y otros atributos. Estas
métricas y medidas obtenidas pueden utilizarse como
indicadores independientes de la calidad de los modelos
de análisis y diseño.
18

19.  Los principios básicos de la medición, sugeridos
por Roche, pueden caracterizarse mediante cinco
actividades:
– Formulación. Obtención de medidas y métricas
del software apropiadas para la representación del
software en cuestión.
– Colección. Mecanismo empleado para acumular
datos necesarios para obtener las métricas
formuladas.
– Análisis. Cálculo de las métricas y la aplicación
de herramientas matemáticas.
– Interpretación. Evaluación de los resultados de las
métricas en un esfuerzo por conseguir una visión
interna de la calidad de la representación.
– Realimentación. Recomendaciones obtenidas de
la interpretación de métricas técnicas transmitidas
al equipo software.
19

20.  Ejiogu define un conjunto de atributos
que deberían acompañar a las métricas
efectivas del software. La métrica
obtenida y las medidas que conducen a
ello deberían ser:
– Simple y fácil de calcular.
– Empírica e intuitivamente persuasiva.
– Consistente y objetiva.
– Consistente en el empleo de unidades y
tamaños.
– Independiente del lenguaje de
programación.
– Un eficaz mecanismo para la
realimentación de calidad.
20

21. La experiencia indica que una
métrica técnica se usa únicamente
si es intuitiva y fácil de calcular. Si
se requiere docenas de contadores
y se han de utilizar complejos
cálculos, la métrica no será
ampliamente utilizada.
21

22. Métricas orientadas a tamaño
 Se relacionan con el tamaño de alguna
salida de una actividad. La medida más
común son las líneas de código fuente
entregadas. También se utiliza el número de
instrucciones de código objeto entregado o
el número de páginas de la documentación
del sistema
22

23.  En el proyecto alfa: se
desarrollaron 12.100 líneas de
código (LDC) con 24 personas-
mes y con un coste de $168.000.
Se desarrollaron 365 páginas de
documentación, se registraron
134 errores antes de que el
software se entregara y se
encontraron 29 errores después
de entregárselo al cliente dentro
del primer año de utilización.

24.  Con los datos anteriores se pueden desarrollar para cada proyecto un
conjunto de métricas simples orientadas al tamaño:
 Errores por KLDC (miles de líneas de código)
 defectos por KLDC
 Q por LDC
 Páginas de documentación por KLDC
 Además, se pueden calcular otras métricas interesantes:
 Errores por persona-mes
 LDC por persona-mes
 Q por página de documentación

25. Métricas basadas en la Función
 La métrica del punto de función (PF) se puede
utilizar como medio para predecir el tamaño de
un sistema obtenido a partir de un modelo de
análisis. Para visualizar esta métrica se utiliza un
diagrama de flujo de datos, el cual se evaluar
para determinar las siguientes medidas clave que
son necesarias para el cálculo de la métrica de
punto de función:
 Número de entradas del usuario
 Número de salidas del usuario
 Número de consultas del usuario
 Número de archivos
 Número de interfaces externas
25

26.  La cuenta total debe ajustarse utilizando
la siguiente ecuación:
PF = cuenta-total x (0,65 + 0,01 x Fi)
 Donde cuenta-total es la suma de todas
las entradas PF obtenidas en una tabla y
Fi (i=1 a 14) son los "valores de ajuste de
complejidad".
26

27. Valores de ajuste de complejidad
1. ¿Requiere el sistema copias de seguridad y de recuperación
confiables?
2. ¿Se requiere comunicación de datos?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿Es crítico el rendimiento es decir es crucial el desempeño?
5. ¿Se ejecutará el sistema en un entorno operativo existente y
fuertemente utilizado?
6. ¿Requiere el sistema entrada de datos en línea?
7. ¿Requiere la entrada de datos interactiva que las transacciones de
entrada se lleven a cabo sobre múltiples pantallas u operaciones?

28. …valores de ajuste de complejidad
8. ¿Se actualizan los ALI en línea?
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?
Cada una de las preguntas se responde usando una escala con rangos
desde 0 (no importante o aplicable) hasta 5 (absolutamente esencial).

29. Para el ejemplo anterior descrito se asume que la Fi es 46
PF = 50 x (0,65 + 0,01 x 46) = 56
29
Factor de ponderación
Parámetro de medición Cuenta Simple Media Compl.
Número de entradas del usuario 3 X 3 4 6 = 9
Número de salidas del usuario 2 X 4 5 7 = 8
Número de consultas del usuario 2 X 3 4 6 = 6
Número de archivos 1 X 7 10 15 = 7
Número de interfaces externas 4 X 5 7 10 = 20
Cuenta total 50

30. Métricas Para Organizaciones Pequeñas
 Kautz describe un escenario que ocurre cuando se piensa
en programas métricos para organizaciones pequeñas de
software:
 «Mantenerlo simple», es una línea de acción que funciona
razonablemente bien en muchas actividades.
 Pero ¿cómo debe derivarse un conjunto de métricas de
software simples que proporcionen valor, y cómo se puede
estar seguro de que estas métricas sencillas lograran
satisfacer las necesidades de una organización de software?
 Puede comenzarse sin centrarse en la medición, pero sí en
los resultados

31. Una organización pequeña puede seleccionar el siguiente conjunto de
medidas fácilmente recolectables:
 Tiempo (horas o días) que transcurren desde el momento que es
realizada una petición hasta que se complete su evaluación, tcola.
 Es fuerzo (horas-persona) para desarrollar la evaluación, Weval.
 Tiempo (horas o días) transcurridos desde la terminación de la
evaluación a la asignación de una orden de cambio al personal, teval.
 Esfuerzo (horas-persona) requeridas para realizar el cambio,
Wcambio.
 Tiempo requerido (horas o días) para realizar el cambio. tcambio.
 Errores descubiertos durante el trabajo para realizar el cambio,
Ecambio
 Defectos descubiertos después de que el cambio se haya desviado a la
base del cliente, Dcambio.

32. La eficiencia de eliminación de defectos (EED)
puede ser calculada de la siguiente manera
EED = Ecambio / (Ecambio+Dcambio)

33.  Para grupos pequeños, el coste de incorporar medidas y
métricas de cálculo oscila entre el 3 y el 8 por ciento del
presupuesto del proyecto durante la fase de aprendizaje.
 Después cae a menos del 1 por ciento del presupuesto del
proyecto una vez que la ingeniería del software y la gestión
de proyectos se hayan familiarizado con el programa de
métricas

34. Métricas de proyecto webapp
 El objetivo es entregar al usuario final una
combinación de contenido y funcionalidad. Las
medidas y métricas usadas para proyectos
tradicionales de ingeniería de sistemas son
difíciles de trabajar para webapps, pero es posible
desarrollar una base de datos que permita el
acceso a medidas productivas y calidad internas
derivadas de algunos proyectos. Entre estas están:

35. …métricas de proyecto webapps
 Número de páginas web estáticas: el control sobre el
contenido no esta bajo el usuario final. La complejidad de
éstas páginas es relativamente baja y no requiere mayor
esfuerzo
 Número de páginas web dinámicas: el usuario final o
factores externos pueden personalizar el contenido de la
web. La complejidad es alta y requieren mayor esfuerzo

36. …métricas de proyecto webapps
 Número vínculos de paginas internos: estos son punteros
que indican la necesidad de un acoplamiento de la
arquitectura de la web, mientras mayor es el número,
mayor es la complejidad y el esfuerzo de diseño y
construcción de la navegación aumenta.
 Número de objetos persistentes: el tener acceso a base de
datos o archivos de datos aumenta la complejidad de la
webapp y el esfuerzo se incrementa de manera
proporcional

37. …métricas de proyecto webapps
 Otras medidas:
– Número de sistemas externos puesto en interfaz
– Número de objetos de contenido estático
– Número de objetos de contenido dinámico
– Número de funciones ejecutables