Métricas Orientadas a la Función

Las métricas del software orientadas a la función utilizan una medida de la

funcionalidad entregada por la aplicación como un valor de normalización. Ya
que la «funcionalidad>>no se puede medir directamente, se debe derivar
indirectamente mediante otras medidas directas.

Las métricas orientadas a la función fueron propuestas por primera vez por
Albretch, quien sugirió una medida llamada punto defunción.

Los puntos de función se derivan con una relación empírica según las medidas
contables (directas) del dominio de información del software y las evaluaciones de
la complejidad del software.

Número de entradas de usuario. Se cuenta cada entrada de usuario que

proporciona diferentes datos orientados a la aplicación. Las entradas se deberían
diferenciar de las peticiones, las cuales se cuentan de forma separada.

Número de salidas de usuario. Se cuenta cada salida que proporciona al usuario

información orientada a la aplicación. En este contexto la salida se refiere a
informes, pantallas, mensajes de error, etc.

Número de peticiones de usuario. Una petición se define como una entrada

interactiva que produce la generación de alguna respuesta del software
inmediata en forma de salida interactiva.

Número de archivos. Se cuenta cada archivo maestro lógico (esto es, un grupo
lógico de datos que puede ser una parte de una gran base de datos o un archivo
independiente).

Número de interfaces externas. Se cuentan todas las interfaces legibles por la

máquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para
transmitir información a otro sistema.

Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor
de complejidad. Para calcular puntos de función (PF), se utiliza la (4.5) relación
siguiente:
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. Desarrollada por Tom
DeMarco, la métrica Bang es una indicación, independiente de la implementación
del tamaño del sistema. Para calcular la métrica bang, el desarrollador de software
debe evaluar primero un conjunto de primitivas (elementos del modelo de análisis
que no se subdividen más en el nivel de análisis). Las primitivas se determinan
evaluando el modelo de análisis y desarrollando cuentas para los siguientes
elementos:

Primitivas funcionales (Pfu) transformaciones (burbujas) que aparecen en el nivel

inferior de un diagrama de flujo de datos.

Elementos de datos (ED) Los atributos de un objeto de datos, los elementos de

datos no compuestos y aparecen en el diccionario de datos.

Objetos (OB) objeto de datos.

Relaciones (RE) Las conexiones entre objetos de datos.

Transiciones (TR) El número de transacciones de estado en el diagrama de

transición de estado.

Ademas de las seis primitivas nombradas arriba, se determina medidas adicionales.

Primitivas modificadas de función manual (PMFu) funciones que caen fuera del
límite del sistema y que deben modificarse para acomodarse al nuevo sistema.

Elementos de datos de entrada (EDE) Aquellos elementos de datos que se

introducen en el sistema.

Elementos de datos de salida (EDS) Aquellos elementos de datos que se sacan del
sistema.

Elementos de datos retenidos (EDR) Aquellos elementos de datos que son retenidos
(almacenados) por el sistema.

Muestras (tokens) de datos (TCi) Las muestras de datos (elementos de datos que no
se subdividen dentro de una primitiva funcional) que existen en el límite de la i-
ésima primitiva funcional (evaluada para cada primitiva).

Conexiónes de relación (Rei) Las relaciones que conectan el i-ésimo objeto en el

modelo de datos con otros objetos.
Métricas de la calidad de Especificación.

Existe una lista de características para poder valorar la calidad del modelo de
análisis y la correspondiente especificación de requisitos: Especificidad, corrección,
compleción, comprensión, capacidad de verificación, consistencia interna y
externa, capacidad de logro, concisión, traza de habilidad, capacidad de
modificación, exactitud, capacidad de reutilización. Aunque muchas de las
características anteriores pueden ser de naturaleza cuantitativa, Davis sugiere que
todas pueden representarse usando una o más métricas. Por ejemplo asumimos
que hay ni requisitos en una especificación, tal como:

fig 0001

Donde nf es el numero de requisitos funcionales y Nnf es el número de requisitos no

funcionales (por ejemplo, rendimiento).

Para determinar la especificidad de los requisitos, Davis sugiere una métrica

basada en la consistencia de la interpretación de los revisores para cada requisito:

fig 0002

Donde nui es el número de requisitos para los que todos los revisores tuvieron
interpretaciones idénticas. Cuanto más cerca de uno este el valor de Q1 menor
será la ambiguedad de la especificación.

La compleción de los requisitos funcionales pueden determinarse calculando la

relación:

fig 0003

Donde nu es el número de requisitos de función únicos, ni es el número de entradas

(estímulos) definidos o implicados por la especificación y ns es el número de estados
especificados. La relación Q2 mide porcentaje de funciones necesarias que se han
especificado para un sistema, sin embargo, no trata los requisitos no funcionales.
Para incorporarlos a una métrica global completa, debemos considerar el grado
de validación de los requisitos:

fig 0004

Donde nc es el número de requisitos que se han validad como correctos y Nnv el

número de requisitos que no se han validad todavía.