En esta fase, las métricas técnicas proporcionan 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.
Dentro de las métricas del modelo de análisis tenemos:
|
Métricas basadas en la Función |
|
La métrica del punto de función se utiliza 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 conceptualización de esta métrica ya fue expuesta en la unidad 2, de éste módulo. |
|
Métrica Bang |
||||||||||||||||||||||||
|
Puede aplicarse para desarrollar una indicación del tamaño del software a implementar como consecuencia del modelo del análisis. Para calcular la métrica bang, el desarrollador de software evalúa primero un conjunto de primitivas. Las primitivas se determinan evaluando el modelo de análisis y desarrollando cuentas para los siguientes elementos:
Además, se determinan medidas adicionales para:
|
Se concentran en las características de la arquitectura del programa, con énfasis en la estructura arquitectónica y en la 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.
La complejidad estructural, S(i), de un módulo i se define de la siguiente manera: S(i)=f2out(i). Donde fout(i) es la expansión del módulo i. La expansión indica el número de módulos que son invocados directamente por el módulo i.
La complejidad del sistema, C(i), se define como la suma de las complejidades estructural y de datos : C(i)= S(i) + D(i)
La complejidad de datos, D(i), proporciona una indicación de la complejidad en la interfaz interna de un módulo i y se define como: D(i)=v(i)/[fout(i) + 1]. Donde v(i) es el número de variables de entrada y salida que entran y salen del módulo i.
Card y Glass definen las siguientes tres medidas de complejidad:
Fenton sugiere varias métricas de morfología simples que permiten comparar diferentes arquitecturas mediante un conjunto de dimensiones directas.
Las métricas a aplicar son:
· Tamaño= n + a . Donde n es el número de nodos (módulos) y a es el número de arcos (líneas de control). Para la arquitectura mostrada se tiene tamaño= 17+18=35.
· Profundidad= camino más largo desde el nodo raíz a un nodo hoja. Para el ejemplo Profundidad= 4
· Amplitud=número máximo de nodos de cualquier nivel de la arquitectura. Para el ejemplo amplitud= 6
· Relación arco a nodo, r=a/n, mide la densidad de conectividad de la arquitectura y proporciona una indicación sencilla de acoplamiento de la arquitectura. Para el ejemplo r=18/17= 1.06
MÉTRICAS DEL CODIGO FUENTE
Utiliza un conjunto de medidas primitivas que pueden obtenerse una vez que se han generado o estimado el código después de completar el diseño.
Estas medidas son:
n1 : número de operadores diferentes que aparecen en el programa.
n2 : número de operandos diferentes que aparecen en el programa.
N1 : número total de veces que aparece el operador.
N2 : número total de veces que aparecen el operando.
Halstead utiliza medidas primitivas para desarrollar expresiones par la longitud global del programa; volumen mínimo potencial para un algoritmo; el volumen real (número de bits requeridos para especificar un programa); el nivel del programa (una medida de la complejidad del software); nivel del lenguaje (una constante para un lenguaje dado); y otras características tales como el esfuerzo de desarrollo,tiempo de desarrollo e incluso el número esperado de fallos en el software.
Halstead propone las siguientes métricas:
· Longitud N se puede estimar como: N = n1 log2 n1 + n2 log2 n2.
· Volumen de programa se define como: V = N n1 log2(n1 + n2).
Tomando en cuenta que V variará con el lenguaje de programación y representa el volumen de información (en bits) necesarios para especificar un programa.
MÉTRICAS PARA PRUEBAS
Las métricas para pruebas se concentran en el proceso de prueba, no en las características técnicas de las pruebas mismas. En general, los responsables de las pruebas deben fiarse en las métricas de análisis, diseño y código para que sirvan de guía en el diseño y ejecución de los casos de prueba.
El esfuerzo de las pruebas también se puede estimar utilizando métricas obtenidas de las medidas de Halstead.
Usando la definición del volumen de un programa, V, y nivel de programa, NP, el esfuerzo de la ciencia del software puede calcularse como:
NP = 1/[(n1/2) x (N2/n2)] (Ec. 1)
e = V/NP (Ec. 2)
El porcentaje del esfuerzo global de pruebas a asignar a un módulo k se puede estimar utilizando la siguiente relación:
Porcentaje de esfuerzo de pruebas(k) = e(k)/åe(i) (Ec. 3)
Donde e(k) se calcula para el módulo k utilizando las ecuaciones (Ec. 1) y (Ec. 2), la suma en el denominador de la ecuación (Ec. 3) es la suma del esfuerzo de la ciencia del software a lo largo de todos los módulos del sistema.
A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una indicación de la compleción de las pruebas:
|
Medida de amplitud de las pruebas. |
Proporciona una indicación de cuantos requisitos se han probado del numero total de ellos. Indica la compleción del plan de pruebas. |
|
Profundidad de las pruebas |
Medida del porcentaje de los caminos básicos independientes probados con relación al número total de estos caminos en el programa. Se puede calcular una estimación razonablemente exacta del número de caminos básicos sumando la complejidad ciclomática de todos los módulos del programa. |
|
Perfiles de fallos |
Se emplean para dar prioridad y categorizar los errores. La prioridad indica la severidad del problema. Las categorías de los fallos proporcionan una descripción de un error, de manera que se puedan llevar a cabo análisis estadístico de errores. |
MÉTRICAS DEL MANTENIMIENTO
Todas las métricas descritas pueden utilizarse para el desarrollo de nuevo software y para el mantenimiento del existente.
El estándar IEEE 982.1-1988 sugiere el índice de madurez del software (IMS) que proporciona una indicación de la estabilidad de un producto software basada en los cambios que ocurren con cada versión del producto. Con el IMS se determina la siguiente información:
· MT= Número de módulos en la versión
· actualFc = Número de módulos en la versión actual que se han cambiado
· Fa= Número de módulos en la versión actual que se han añadido
· Fe= Número de módulos en la versión actual que se han eliminado
El índice de madurez del software se calcula de la siguiente manera:
IMS= [MT - (Fc + Fa + Fe)]/MT
A medida que el IMS se aproxima a 1 el producto se empieza a estabilizar. El IMS puede emplearse también como métrica para la planificación de las actividades de mantenimiento del software.