ESTRUCTURA PARA LAS MTRICAS DEL SOFTWARE

La medicin asigna nmeros o smbolos a atributos de entidades en el mundo real. Para conseguirlo es necesario un modelo de medicin que comprenda un conjunto consistente de reglas. Existe la necesidad de medir y controlar la complejidad del software, es bastante difcil obtener un solo valor para representar una "mtrica de calidad", sin embargo es posible desarrollar medidas de diferentes atributos internos del programa como ser: modularidad efectiva, independenci a funcional y otros atributos. Estas mtricas y medidas obtenidas pueden utilizarse como indicadores independientes de la calidad de los modelos de anlisis y diseo. Los principios bsicos de la medicin, sugeridos por Roche, pueden caracterizarse mediante cinco actividades:
y

Formulacin. Obtencin de medidas y mtricas del software apropiadas para la representacin del software en cuestin. Coleccin. Mecanismo empleado para acumular datos necesarios para obtener las mtricas formuladas. Anlisis. Clculo de las mtricas y la aplicacin de herramientas matemticas. Interpretacin. Evaluacin de los resultados de las mtricas en un esfuerzo por conseguir una visin interna de la calidad de la representacin.

Realimentacin. Recomendaciones obtenidas de la in terpretacin de mtricas tcnicas transmitidas al equipo software.

La mtrica obtenida y las medidas que conducen a ello deberan ser:

y y y y y y

Simple y fcil de calcular. Emprica e intuitivamente persuasiva. Consistente y objetiva. Consistente en el empleo de uni dades y tamaos. Independiente del lenguaje de programacin. Un eficaz mecanismo para la realimentacin de calidad.

La experiencia indica que una mtrica tcnica se usa nicamente si es intuitiva y fcil de calcular. Si se requiere docenas de contadores y se han de utilizar complejos clculos, la mtrica no ser ampliamente utilizada.

Mtricas del Modelo de Anlisis

En esta fase se obtendrn los requisitos y se establecer el fundamento para el diseo. Y es por eso que se desea una visin interna a la cali dad del modelo de anlisis. Sin embargo hay pocas mtricas de anlisis y especificacin, se sabe que es posible adaptar mtricas obtenidas para la aplicacin de un proyecto, en donde las mtricas examinan el modelo de anlisis con el fin de predecir el tamao del sistema resultante, en donde resulte probable que el tamao y la complejidad del diseo estn directamente relacionadas. Es por eso que se vern en las siguientes secciones las mtricas orientadas a la funcin, la mtrica bang y las mtricas de la calidad de especificacin.

Mtricas basadas en la Funcin

y

La mtrica del punto de funcin (PF) se puede utilizar como medio para predecir el tamao de un sistema obtenido a partir de un modelo de anlisis. Para visualizar esta mtrica se utiliza un diagram a de flujo de datos, el cual se evaluar para determinar las siguientes medidas clave que son necesarias para el clculo de la mtrica de punto de funcin:

y y y y y y y y

Nmero de entradas del usuario Nmero de salidas del usuario Nmero de consultas del usuario Nmero de archivos Nmero de interfaces externas La cuenta total debe ajustarse utilizando la siguiente ecuacin:

PF = cuenta-total x (0,65 + 0,01 x Fi) donde : PF = 50 x (0,65 + 0,01 x 46) = 56

Basndose en el valor previsto del PF obtenido del modelo de anlisis, el equipo del proyecto puede estimar el tamao global de implementacin de las funciones de interaccin. Asuma que los datos de los que se dispone indican que un PF supone 60 lneas de cdigo (se utilizar un lenguaje orientado a objetos) y que en un esfuerzo de un mes-persona se producen 12 PF. Estos datos histricos proporcionan al gestor del proyecto una importante informacin de planificacin basada en el modelo de anlisis en lugar de estimaciones preliminares

Otras Mtricas para el Modelo de Anlisis

Puede emplearse para desarrollar una indicacin del tamao del software a implementar como consecuencia del modelo de anlisis. Desarrollada por Tom DeMarco [Ejiogo 91], la mtrica bang es una indicacin, independiente de la implementacin, del tama o del sistema [Ejiogo 91]. Para calcular la mtrica bang, el desarrollador de software debe evaluar primero un conjunto de primitivas (elementos del modelo de anlisis que no se subdividen ms en el nivel de anlisis) Las primitivas se determinan evaluando el modelo de anlisis 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 o bjeto de datos, los elementos de datos no compuestos y aparecen en el diccionario de datos. - Objetos (OB) Objetos de datos. - Relaciones (RE) Las conexiones entre objetos de datos. - Transiciones (TR) El nmero de transacciones de estado en el diagrama de transicin de estado. Adems de las seis primitivas nombradas arriba, se determinan medidas adicionales para: - Primitivas modificadas de funcin manual (PMFu) Funciones que caen fuera del lmite del sistema y que deben modificarse para acomodarse al n uevo sistema. - Elementos de datos de entrada (EDE) Aquellos elementos de datos que se introducenen el sistema. - Elementos de datos de salida (EDS) Aquellos elementos de datos que se sacan en el 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 limite de la i-sima primitiva funcional (evaluada para cada primitiva). - Conexiones de relacin (Rei) Las relaciones que conectan el i -simo objeto en el modelo de datos con otros objetos.

Mtricas de la Calidad de Especificacin

Existe una lista de caractersticas para poder valorar la calidad del modelo de anlisis y la correspondiente especificacin de requisitos: Especificidad, correccin, complecin, comprensin, capacidad de verificacin, consistencia externa e interna, capacidad de logro, concisin, traza habilidad, capacidad de modificacin, exactitud y capacidad de reutilizacin. Aunque muchas de las caractersticas anteriores pueden ser de naturaleza cuantitativa, Davis [Pressman98] sugiere que todas puedan representarse usando una o ms mtrica s. Por ejemplo asumimos que hay ni requisitos en una especificacin, tal como : ni = nf + nnf (4.8) Donde nf es el numero de requisitos funcionales y nnf es el nmero de requisitos no funcionales ( por ejemplo, rendimiento). Para determinar la especificida d de los requisitos, Davis [Pressman 98] sugiere una mtrica basada en la consistencia de la interpretacin de los revisores para cada requisito: Q1 = nui / nr Donde nui es el numero de requisitos para los que todos los revisores tuvieron interpretaciones idnticas. Cuanto ms cerca de uno este el valor de Q1 menor ser la ambigedad de la especificacin. La complecin de los requisitos funcionales pueden terminarse calculando la relacin Q2 = nu / (ni * ns) donde nu es el nmero de requisitos de fun cin nicos, ni es el nmero de entradas (estmulos) definidos o implicados por la especificacin y ns es el nmero de estados especificados. La relacin Q2 mide porcentaje de funciones necesarias que se han especificado para un sistema, sin embargo, no tr ata los requisitos no funcinales. Para incorporarlos a una mtrica global completa, debemos considerar el grado de validacin de los requisitos: Q3 = nc / (nc + nnv) donde nc es el nmero de requisitos que se han validados como correctos y nnv el nmero de requisitos que no se han validado todava

Mtricas del modelo de Diseo

y

La gran irona de las mtricas de diseo para el software es que las mismas estn disponibles, pero la gran mayora de los desarrolladores de software continan sin saber que existen.

No son perfectas y contina el debate sobre su eficacia y como deberan aplicarse. Algunos expertos sealan que es necesario mayor experimentacin hasta que se puedan emplear adecuadamente. Sin embargo el diseo sin medicin es una alternativa inaceptab le.

Mtricas de diseo de alto nivel

y

Se concentran en las caractersticas de la arquitectura del programa , con nfasis en la estructura arquitectnica y en la eficiencia de los mdulos. Estas mtricas son de caja negra en el sentido que no requieren ning n conocimiento del trabajo interno de un mdulo en particular del sistema.