20 de noviembre de 2012

Métricas del Modelo de Análisis

En esta fase es deseable que las métricas técnicas proporcionen una visión interna a la calidad del modelo de análisis. Estas métricas examinan el modelo de análisis con la intención de predecir el "tamaño" del sistema resultante; es probable que el tamaño y la complejidad del diseño estén directamente relacionadas.


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
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 de la figura 9.2 y Fi (i=1 a 14) son los "valores de ajuste de complejidad"

Para el ejemplo descrito en la figura 9.2 se asume que la EFi es 46 (un producto moderadamente complejo), por consiguiente:
                                                       PF = 50 x (0,65 + 0,01 x 46) = 56

Basándose en el valor previsto del PF obtenido del modelo de análisis, el equipo del proyecto puede estimar el tamaño global de implementación de las funciones de interacción. Asuma que los datos de los que se dispone indican que un PF supone 60 líneas de código (se utilizará un lenguaje orientado a objetos) y que en un esfuerzo de un mes-persona se producen 12 PF. Estos datos históricos proporcionan al gestor del proyecto una importante información de planificación basada en el modelo de análisis en lugar de estimaciones preliminares.


MÉTRICA BANG

Al igual que la métrica de punto 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.

Desarrollada por 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 son datos no compuestos y aparecen en el diccionario de datos.
Objetos (OB). Objetos de datos.
Relaciones (RE). Las conexiones entre objetos de datos.
Estados (ES). El número de estados observables por el usuario en el diagrama de transición de estados.
Transiciones (TR). El número de transiciones de estado en el diagrama de transición de estados.


Además de las seis primitivas apuntadas arriba, se determinan las cuentas adicionales para:

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).
Conexiones de relación (REi). Las relaciones que conectan el i-ésimo objeto en el modelo de datos con otros objetos.

DeMarco sugiere que la mayoría del software se puede asignar a uno de los dos dominios siguientes, dominio de función o dominio de datos, dependiendo de la relación RE/PFu. Las aplicaciones de dominio de
función (encontradas comúnmente en aplicaciones de ingeniería y científicas) hacen hincapié en la transformación de datos y no poseen generalmente estructuras de datos complejas. Las aplicaciones de dominio de datos (encontradas comúnmente en aplicaciones de sistemas de información) tienden a tener modelos de datos complejos.
       RE/PFu < 0,7 implica una aplicación de dominio de función
     0,8 < RE/PFu < 1,4 indica una aplicación híbrida
     RE/PFu > 13 implica una aplicación de dominio de datos

Como diferentes modelos de análisis harán una partición del modelo con mayor o menor grado de refinamiento. DeMarco sugiere que se emplee una cuenta media de muestra (token) por primitiva 
                                                                
                                                                             Teavg= DC,IPFu 

para controlar la uniformidad de la partición a través de muchos diferentes modelos dentro del dominio de una aplicación.
Para calcular la métrica bang para aplicaciones de dominio de función, se emplea el siguiente algoritmo:

Asignar a bang un valor inicial = 0;
Mientras queden primitivas funcionales por evaluar
Calcular cuenta-token alrededor del límite de la primitiva i;
Calcular el incremento PFu corregido (IPFuC)
Asignar la primitiva a una clase
Evaluar la clase y anotar el peso valorado
Multiplicar IPFuC por el peso valorado
bang = bang + ponderación IPFuC;  
FinMientras

La cuenta-token se calcula determinando cuántos símbolos léxicos (tokens) diferentes son «visibles» dentro de la primitiva. Es posible que el número de símbolos léxicos (tokens) y el número de elementos de datos sea diferente, si los elementos de datos pueden moverse desde la entrada a la salida sin ninguna transformación interna. La IPFuC corregida se determina de una tabla publicada por DeMarco. A continuación, se presenta una versión muy abreviada:


La ponderación valorada apuntada en el algoritmo anterior se calcula de dieciséis clases diferentes de primitivas funcionales definidas por DeMarco. Se asigna una ponderación que va de 0,6 (encaminamiento simple de datos) a 2,5 (funciones de gestión de datos) dependiendo de la clase de la primitiva.
Para aplicaciones de dominio de datos, se calcula la métrica bang mediante el siguiente algoritmo:

Asignar a bang el valor inicial = 0;
Mientras queden objetos por evaluar en el modelo de datos
Calcular la cuenta de relaciones’ del objeto i
Calcular el incremento de OB corregido (IOBC); bang = bang t IOBC;
FinMientras

El IOBC corregido se determina también de una tabla publicada por DeMarco. A continuación se muestra una versión abreviada:


Una vez que se ha calculado la métrica bang, se puede emplear el historial anterior para asociarla con el esfuerzo y el tamaño. DeMarco sugiere que las organizaciones se construyan sus propias versiones de tablas
IPFuC e IOBC para calibrar la información de proyectos completos de software.


MÉTRICAS DE LA CALIDAD DE LA ESPECIFICACIÓN

Davis y sus colegas proponen una lista de características que pueden emplearse para valorar la calidad del modelo de análisis y la correspondiente especificación de requisitos: especificidad (ausencia de ambigüedad), compleción, corrección, comprensión, capacidad de verificación, consistencia interna y externa, capacidad de logro, concisión, trazabilidad, capacidad de modificación, exactitud y capacidad de reutilización. Además, los autores apuntan 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.

Aunque muchas de las características anteriores parecen ser de naturaleza cualitativa, Davis sugiere que todas puedan representarse usando una o más métricas. Por ejemplo, asumimos que hay n, requisitos en una especificación, tal como

donde nf es el número de requisitos funcionales y nnf es el número de requisitos no funcionales (por ejemplo,
rendimiento).
Para determinar la especificidad (ausencia de ambigüedad) de los requisitos. Davis sugiere una métrica basada en la consistencia de la interpretación de los revisores para cada requisito:


donde nUi es el número de requisitos para los que todos los revisores tuvieron interpretaciones idénticas. Cuanto más cerca de 1 esté el valor de Q, menor será la ambigüedad de la especificación.
La compleción de los requisitos funcionales pueden determinarse calculando la relación


donde u, es el número de requisitos únicos de función, ni es el número de entradas (estímulos) definidos o implicados por la especificación y n, es el número de estados especificados. La relación Q, mide el 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.




donde n, es el número de requisitos que se han validado como correctos y n," el número de requisitos que no se han validado todavía.

No hay comentarios:

Publicar un comentario en la entrada