1) El documento habla sobre métricas técnicas para medir la calidad del software. 2) Describe factores de calidad como la facilidad de mantenimiento, portabilidad y reusabilidad. 3) Explica que las métricas pueden medir atributos directamente como defectos por línea de código o indirectamente como facilidad de uso.

1. CAPITULO 18
METRICAS TECNICAS DEL SOFTWARE
Un elemento clave de cualquier proceso de ingeniería es la medición. Empleamos medidas para entender
mejor los atributos de los modelos que creamos, para valorar la calidad de los productos de ingeniería o los
sistemas que construimos. Permiten al ingeniero descubrir y corregir problemas potenciales antes de que se
conviertan en defectos catastróficos.
La medición es el proceso por el que se asignan números o símbolos a los atributos de las entidades en el
mundo real, de tal manera que las definan de acuerdo con unas reglas claramente definidas.
18.1 CALIDAD DEL SOFTWARE
Tres puntos importantes:
1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los
requisitos es una falta de calidad.
2. 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.
3. 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.
18.1.1. FACTORES DE CALIDAD DE MCCALL
Los factores que afectan a la calidad del software se pueden categorizar en dos amplios grupos:
1. Factores que se pueden medir directamente (defectos por punto de función, etc)
2. Factores que se pueden medir sólo indirectamente (facilidad de uso o mantenimiento)
En todos los casos debe aparecer la medición. Debemos comparar el soft con un dato y llegar a una
conclusión sobre la calidad.
Factores de calidad del software se concentran en tres aspectos importantes: sus características operativas,
su capacidad de cambio y su adaptabilidad a nuevos entornos.
FACILIDAD DE MANTENIMIENTO PORTABILIDAD
FLEXIBILIDAD REUSABILIDAD
FACILIDAD DE PRUEBA INTEROPERATIVIDAD
REVISIÓN DEL PRODUCTO TRANSICIÓN DEL PRODUCTO
OPERACIÓN DEL
PRODUCTO
CORRECCION FIABILIDAD USABILIDAD INTEGRIDAD EFICIENCIA
♦ CORRECCIÓN: hasta dónde satisface un programa su especificación y logra los objetivos.
♦ FIABILIDAD: hasta dónde se puede esperar que un programa lleve a cabo su función con la
exactitud requerida.
♦ EFICIENCIA:la cant. de recursos informáticos y código necesaria para que un prog. realice su
función.
♦ INTEGRIDAD: hasta dónde se puede controlar el acceso al soft a los datos por personas no
autorizadas.
♦ USABILIDAD: facilidad de manejo

2. ♦ FACILIDAD DE MANTENIMIENTO: el esfuerzo necesario para localizar y arreglar un error del
programa
♦ FLEXIBILIDAD: el esfuerzo necesario para modificar un programa operativo.
♦ FACILIDAD DE PRUEBA
♦ PORTABILIDAD: el esfuerzo necesario para transferir el programa de un entorno de sistema
hardware y/o software a otro.
♦ REUSABILIDAD: capacidad de reutilización
♦ INTEROPERATIVIDAD: el esfuerzo necesario para acoplar un sistema con otro.
Las métricas definidas por MacCall pueden medirse solamente de manera subjetiva. Métricas:
♦ FACILIDAD DE AUDITORIA: la facilidad con la que se puede comprobar el cumplimiento de los
estándares.
♦ EXACTITUD : exactitud de los cálculos y del control.
♦ ESTANDARIZACION DE COMUNICACIONES: el grado de empleo de estándares de interfaces,
protocolos y anchos de banda.
♦ COMPLECIÓN: el grado con que se a logrado la implementación total de una función.
♦ CONCISIÓN: lo compacto que es el programa en términos de líneas de código
♦ CONSISTENCIA: el empleo de un diseño uniforme y de técnicas de documentación a lo largo del
proyecto de desarrollo del software.
♦ ESTANDARIZACIÓN DE DATOS: el empleo de estructuras y tipos de datos estándares a lo largo
del programa
♦ TOLERANCIA AL ERROR: el daño causado cuando el programa encuentra un error.
♦ EFICIENCIA DE EJECUCIÓN: el rendimiento del funcionamiento de un programa
♦ CAPACIDAD DE EXPANSIÓN: el grado con que se pueden ampliar el diseño arquitectónico, de
datos o procedimental
♦ GENERALIDAD: la amplitud de aplicación potencial de los componentes del programa
♦ INDEPENDENCIA DEL HARDWARE: el grado con que se desacopla el soft del hard donde
opera.
♦ INSTRUMENTACIÓN el grado con que el programa vigila su propio funcionamiento e identifica
los errores que ocurren.
♦ MODULARIDAD: la independencia funcional de componentes del programa
♦ OPERATIVIDAD: la facilidad de operación de un programa
♦ SEGURIDAD: la disponibilidad de mecanismos que controlan o protegen los programas y los datos.
♦ AUTODOCUMENTACIÓN:el grado en el que el código fuente proporciona documentación
significativa
♦ SIMPLICIDAD: grado de facilidad con que se puede entender un programa.
♦ INDEPENDENCIA DEL SISTEMA SOFTWARE: el grado de indep. del progr. respecto a las
características de lenguaje de programación no estandar, características del sist. operativo y otras
restricciones del entorno.
♦ TRAZABILIDAD: la capacidad de seguir una representación del diseño o un componente real del
programa hasta los requisitos.
♦ FORMACIÓN: el grado en que ayuda al soft a manejar el sistema a los nuevos usuarios.
18.1.2. FURPS
Define los siguientes atributos para cada uno de los cinco factores principales:
♦ FUNCIONALIDAD: se valora evaluando el conjunto de características y capacidades del programa, la
generalidad de las funciones entregadas y la seguridad del sistema global.
♦ FACILIDAD DE USO: se valora considerando factores humanos, la estética, consistencia y
documentación general.
♦ FIABILIDAD: se evalúa midiendo la frecuencia y gravedad de los fallos, la capacidad de recuperación
de un fallo y la capacidad de predicción del programa.
♦ RENDIMIENTO: se mide por la velocidad de procesamiento, el tiempo de respuesta, consumo de
recursos, rendimiento efectivo total y eficiencia.

3. ♦ CAPACIDAD DE SOPORTE: combina la capacidad de ampliar el programa, adaptabilidad y
servicios, así como capacidad de hacer pruebas, compatibilidad, capacidad de configuración, facilidad de
instalación de un sistema y la facilidad con la que se pueden localizar los problemas.
18.1.3. LA TRANSICION A UNA VISION CUANTITATIVA
Las métricas representan medidas indirectas, nunca medimos la calidad sino alguna manifestación de la
calidad. Examinaremos un conjunto de métricas del soft que pueden aplicarse a la valoración cuantitativa de
la calidad.
18.2. UNA ESTRUCTURA PARA LAS METRICAS TECNICAS DEL SOFTWARE
18.2.1. EL RETO DE LAS MÉTRICAS TÉCNICAS
La medición es esencial si se desea conseguir calidad.
18.2.2. PRINCIPIOS DE MEDICION
Métricas técnicas:
1. Ayudan a la evaluación de los modelos de análisis y de diseño
2. Proporcionan una indicación de la complejidad de diseños procedimentales y código fuente
3. Ayudan en el diseño de pruebas más efectivas.
Proceso de medición. Actividades:
1. Formulación: la obtención de medidas y métricas del soft apropiadas.
2. Colección: mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas.
3. Análisis: el cálculo de las métricas y la aplicación de herramientas matemáticas.
4. Interpretación: la 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.
5. Realimentación: recomendaciones obtenidas de la interpretación de las métricas técnicas transmitidas al
equipo de soft.
Principios que se pueden asociar con la formulación de la métricas técnicas:
♦ Los objetivos de la medición deberían establecerse antes de empezar la recogida de datos.
♦ Todas las técnicas sobre métricas deberían definirse sin ambiguedades.
♦ Las métricas deberían obtenerse basándose en una teoría válida para el dominio de aplicación.
♦ Hay que hacer las métricas a medida para acomodar mejor los productos y procesos específicos.
18.2.3 CARACTERÍSTICAS FUNDAMENTALES DE LAS MÉTRICAS DEL SOFTWARE
Atributos que deberían acompañar a las métricas efectivas del software:
♦ Simple y fácil de calcular
♦ Empírica e intuitivamente persuasiva: la métrica debería satisfacer las nociones intuitivas del ingeniero
sobre el atributo del producto en cuestión.
♦ Consistente y objetiva: la métrica debería producir resultados sin ambigüedad.
♦ Consiste en el empleo de unidades y tamaños: el cálculo matemático de la métrica debería emplear
medidas que no conduzcan a extrañas combinaciones de unidades.
♦ Independiente del lenguaje de programación
♦ Un eficaz mecanismo para la realimentación de calidad: la métrica debería proporcionar al desarrollador
del software información que le lleve a un producto final de mayor calidad.
18.3. METRICAS DEL MODELO DE ANALISIS
El trabajo técnico en la ingeniería del software empieza con la creación del modelo de análisis. En esta fase
se obtienen los requisitos y se establece el fundamento para el diseño. Por lo tanto, son deseables las
métricas técnicas que proporcionan una visión interna de la calidad del modelo de análisis.
18.3.1 MÉTRICAS BASADAS EN LA FUNCION
La métrica de punto de función (PF) se puede usar como medio para predecir el tamaño de un sistema que
se va a obtener de un modelo de análisis. Cinco características de dominios de información:

4. ♦ 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.
18.3.2. LA METRICA DE BANG
Al igual que la métrica de función, la métrica bang puede emplearse para desarrollar una indicación del
tamaño del software a implementar como consecuencia del modelo de análisis. La métrica bang es “una
indicación independiente de la implementación del tamaño del sistema”. Para calcular esta métrica, el
desarrollador debe evaluar primero un conjunto de primitivas. Las primitivas se determinan evaluando el
modelo de análisis y desarrollando cuentas para los siguientes elementos:
♦ PRIMITIVAS FUNCIONALES- PFU:transformaciones que aparecen en el nivel inferior de un dfd.
♦ ELEMENTOS DE DATOS- ED: los atributos de un objeto de datos, los elementos de datos no
compuestos y aparecen el el diccionario de datos.
♦ OBJETOS- OB: objetos de datos.
♦ RELACIONES- RE: las conexiones entre objetos
♦ ESTADOS-ES: el nro de estados observables por el usuario en el diagrama de transición de estado.
♦ TRANSICIONES – TR: el número de transiciones de estado en el diagrama de transición de estado.
Además de estás primitivas, se determinan las cuentas adicionales para:
♦ PRIMITIVAS MODIFICADAS DE FUNCION MANUAL: funciones que caen fuera del límite del
sistema y que deben modificarse para acomodarse el nuevo sistema.
♦ ELEMENTOS DE DATOS DE ENTRADA
♦ ELEMENTOS DE DATOS DE SALIDA
♦ ELEMENTOS DE DATOS RETENIDOS: elementos de datos que son almacenados por el sistema.
La mayoría del software se puede asignar a uno de los dos dominios siguientes:
♦ Dominio de función: las aplicaciones de este dominio hacen hincapie en la transformación de datos y
no poseen generalmente estructuras de datos complejas.
♦ Dominio de datos: estas aplicaciones tienden a tener modelos de datos complejos
18.3.3. METRICAS DE LA CALIDAD DE ESPECIFICACION
Lista de características que pueden emplearse para valorar la calidad del modelo de análisis y la
correspondiente especificación de requisitos:
♦ Especificidad
♦ Compleción
♦ Corrección
♦ Compresión
♦ Capacidad de verificación
♦ Consistencia interna y externa
♦ Capacidad de logro
♦ Concisión
♦ Trazabilidad
♦ Capacidad de modificación
♦ Exactitud
♦ Capacidad de reutización.
Se apunta a que las especificaciones de alta calidad deben estar almacenadas electrónicamente, ser
ejecutables o al menos interpretables, anotadas por importancia y estabilidad relativas, con su versión
correspondiente, organizadas, con referencias cruzadas y especificadas al nivel correcto de detalle.
18.4 .METRICAS DEL MODELO DE DISEÑO
18.4.1. METRICAS DE DISEÑO DE ALTO NIVEL

5. Estás métricas se concentran en las características de la arquitectura del programa (estructura arquitectónica
y eficiencia de los módulos). Estas métricas son de caja negra en el sentido que no requieren ningún
conocimiento del trabajo interno de un módulo en particular del sistema.
Tres medidas de la complejidad del diseño del soft:
♦ Complejidad estructural
♦ Complejidad de datos
♦ Complejidad del sistema
A medida que crecen los valores de complejidad arquitectónica o global del sistema también aumenta. Esto
lleva a una mayor probabilidad de que aumente el esfuerzo necesario para la integración y las pruebas.
18.4.2. METRICAS DE DISEÑO EN LOS COMPONENTES
Estás métricas se concentran en las características internas de los componentes del soft e incluyen medidas
de la cohesión, acoplamiento y complejidad del módulo. Estas tres medidas pueden ayudar al desarrollador
del soft a juzgar la calidad de un diseño a nivel de componentes.
Estás métricas son de caja blanca en el sentido que requieren conocimiento del trabajo interno del módulo.
Estás métricas se pueden aplicar una vez que se ha desarrollado un diseño procedimental. También se puede
retrasar hasta tener disponible el código fuente.
Métricas de cohesión: Se definen 5 conceptos y medidas:
♦ Porción de datos: una porción de datos es una marcha atrás a través de un módulo que busca valores de
datos que afectan a la localización del módulo en el que empezó la marcha atrás. Se pueden definir tanto
porciones de programas como porciones de datos:
♦ Símbolos léxicos (tokens) de datos: las variables definida para un módiulo pueden definirse como
señales de datos para el módulo.
♦ Señales de unión: el conjunto de señales de datos que se encuentran en uno o más porciones de datos.
♦ Señales de superunión: las señales de datos comunes a todas las porciones de datos de un módulo.
♦ Pegajosidad: la pegajosidad relativa de una señal de unión es directamente proporcional al número de
porciones de datos que liga.
Métricas de acoplamiento:El acoplamiento del módulo proporciona una indicación de la “conectividad” de
un módulo con otros modulos, datos globales y el entorno exterior.
Las medidas necesarias para calcular el acoplamiento de módulo se definen en término de los siguientes tres
acoplamientos:
♦ Para el acoplamiento de flujo de datos y de control:
- Número de parámetros de datos de entrada
- Número de parámetros de control de entrada
- Número de parámetros de datos de salida
- Número de parámetros de control de salida
♦ Para el acoplamiento global
- Número de variables globales usadas como datos
- Número de variables globales usadas como control
♦ Para el acoplamiento de entorno
- Número de módulos llamados
- Número de módulos que llaman al módulo en cuestión
Métricas decomplejidad: Se pueden calcular una variedad de métricas del soft para determinar la
complejidad del flujo de control del programa. Muchas de éstas se basan en una representación denominada
grafo de flujo.
La métrica de complejidad más usada para el soft es la complejidad ciclomática: puede emplearse para
proporcionar una indicación cuantitativa del tamaño máximo del módulo.
18.4.3. METRICAS DE DISEÑO DE INTERFAZ
Se sugiere la conveniencia de la representación (CR) como una valiosa métrica de diseño para interfaces
hombre–máquina. Una IGU (interfaz Gráfica del Usuario) típica usa entidades de representación – iconos,

6. gráficos, ventanas, etc – para ayudar al usuario a completar tareas. Para realizar una tarea usando una IGU,
el usuario debe moverse de una entidad de representación a otra. Las posiciones absolutas y relativas a cada
entidad de representación, la frecuencia con que se utilizan y el coste de la transición de una entidad de
representación a la siguiente contribuirán a la conveniencia de la interfaz.
La CR se emplea para valorar diferentes distribuciones propuestas de IGU y la sensibilidad de una
representación en particular a los cambios en las descripciones de tareas. El diseñador de interfaces puede
emplear el cambio en la conveniencia de la representación, como guía en la elección de la mejor
representación de IGU para una aplicación en particular.
La selección de un diseño IGU puede guiarse con métricas tales como CR, pero el árbitro final debería ser la
respuesta del usuario basada en prototipos IGU.
18.5 METRICAS DEL CODIGO FUENTE
La ciencia del soft usa un conj. de primitivas que pueden obtenerse una vez que se ha completado o estimado
el código después de completar el diseño:
- Número de operadores diferentes que aparecen en el programa
- Número de operandos diferentes que aparecen en el programa.
- Número total de veces que aparece el operador
- Número total de veces que aparece el operando.
Se usa las medidas primitivas para desarrollar expresiones para:
- La longitud global del programa
- Volumen mínimo potencial para un algoritmo
- Volumen real
- Nivel del programa
- Nivel del lenguaje
- Esfuerzo de desarrollo
- Tiempo de desarrollo
- Número esperado de fallos.
18.6. METRICAS PARA PRUEBAS
Los responsables de la pruebas deben fiarse en las métricas de análisis, diseño y codigo para que les guien en
el diseño y ejecución de los casos de prueba.
♦ Métricas basadas en la función
♦ Métricas bang
♦ Métricas de diseño de alto nivel
El analista debería invertir un esfuerzo extra para descubrir errores en el módulo antes de integrarlo en un
sistema. A medida que se van haciendo las prueba, tres medidas proporcionan una indicación de la
compleción de las pruebas:
♦ Amplitud de las pruebas: indica cuantos requisitos se han probado
♦ Profundidad de las pruebas: indica procentaje de los caminos básicos probados en relación con el número
total de estos caminos en el programa.
♦ Perfiles de fallos: categorizar los errores descubiertos. Severidad del problema
18.7. METRICAS DEL MANTENIMIENTO
Todas la métricas del software presentadas en este capítulo pueden usarse para el desarrollo de nuevo soft y
para el mantenimiento del existente. Se han propuesto métricas diseñadas explícitamente para actividades de
mantenimiento. El estándar IEEE 982.1-1988 sugiere un índice de madurez del software que proporciona
una indicación de la estabilidad de un producto software (basada en los cambios que ocurren con cada
versión del producto). Se determina la siguiente información:
♦ Número de módulo en la versión actual.
♦ Número de módulos en la versión actual que se han cambiado
♦ Número de módulos en la versión actual que se han añadido.
♦ Número de módulos en la versión anterior que se han borrado en la versión actual.