METRICAS TECNICAS

Métricas del Diseño Arquitectónico

Estas métricas de diseño centradas en la arquitectura del programa, prestan importancia a la

estructura arquitectónica y a la eficiencia de los módulos.
Son de caja negra en el sentido que no requieren ningún conocimiento del trabajo interno de un
módulo en particular del sistema
Métricas de diseño en los componentes

Las métricas de diseño a nivel de componentes se concentran en las características internas de los
componentes del software e incluyen medidas de la cohesión, acoplamiento y complejidad del
módulo.

Métricas de cohesión: Para medir la cohesión se puede usar el trabajo de Bieman y Ott, el cual
define varios conceptos:

 Número de elementos (tokens), Rebanada de datos (data slice), Adhesivo (glue)

Superadhesivo (superglue).

Con ellas se calcula la cohesión funcional fuerte

 CFF = número de superadhesivos / número de elementos

Cohesión Funcional Débil, se calcula así:

 CFD=número de adhesivos/ número de elementos.

Mientras más cercano sean CFF ó CFD a 1, mayor será la cohesión del módulo.

METRICAS DE DISEÑO DE INTERFAZ DE USUARIO

El diseño de interfaz de usuario o ingeniería de la interfaz es el resultado de definir la forma,

función, usabilidad, ergonomía y otros aspectos que afectan a la apariencia externa de
las interfaces de usuario en sistemas de todo tipo.

La conveniencia de la representación es una valiosa métrica de diseño de interfaces hombre-

máquina que se emplea para valorar diferentes distribuciones propuestas de IGU (Interfaz
Gráfica de Usuario).

Una IGU típica usa entidades de representación como iconos gráficos, texto, menús, ventanas y
otras para ayudar al usuario a completar tareas. Para realizar una tarea dada usando una IGU, el
usuario debe moverse de una entidad de representación a otra. Las posiciones absolutas y
relativas de 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 otra contribuirán a la conveniencia de la interfaz.

Métricas orientadas a clases

Chidamber y Kemerer propusieron uno de los conjuntos de métricas de software OO de mayor

referencia. En ocasiones llamada suite de métricas CK. Una clase encapsula datos y la función que
los manipula. Con frecuencia es el “padre” de las subclases (en ocasiones llamadas hijos) que
heredan sus atributos y operaciones.

 PROFUNDIDAD DEL ÁRBOL DE HERENCIA (PAH): Esta métrica es “la máxima longitud desde el
nodo hasta la raíz del árbol”. Conforme crece la PAH, es probable que las clases de nivel
inferior hereden muchos métodos. Esto conduce a potenciales dificultades cuando se intenta
predecir el comportamiento de una clase.
 NUMERO DE HIJOS (NDH): Las subclases que son inmediatamente subordinadas a una clase
en la jerarquía de clase se denominan hijos. Conforme crece el número de hijos, el reusó
aumenta, pero también, como el NDH aumenta, la abstracción representada por la clase padre
puede diluirse si algunos de los hijos no son miembros adecuados de la clase padre. Conforme
el NDH aumenta, la cantidad de pruebas (requeridas para ejercitar cada hijo en su contexto
operativo) también aumentará.

Métricas de código fuente

Estás métricas asignadas como cuantitativas por Halstead, se derivan después de que se ha
generado el código o se estima una vez que el diseño esté completo.
Composición del lenguaje: token, operadores, palabras reservadas, identificadores, constante y
signos especiales. De esta forma se obtiene una medida más realista de la cantidad de información
contenida en el código fuente.
Las medidas son:

● n1: el número de operadores diferentes que aparecen en el programa.

● n2: el número de operandos diferentes que aparecen en el programa.
● N1: el número total de ocurrencias de operadores
● N2: el número total de ocurrencias de operandos
Volumen (V): Da un peso extra al número de operadores y operandos únicos. Por ejemplo, si dos
programas tienen la misma longitud N pero uno tiene mayor número de operadores y operandos
únicos, que naturalmente lo hacen más difícil de entender y mantener, este tendrá un mayor
volumen.
Se calcula como V = N x log2(n) donde n = n1 + n2

Por ejemplo, consideremos el siguiente trozo de programa:

if (N < 2)
{ A = B * N;
System.out.println("El resultado es : " + A);
}
A partir de aquí se deduce:
 ● Operadores Únicos n1 = 6 (if, {}, system.out.println, =, *,<)
● Ocurrencias de Operadores N1 = 6 (if, {}, system.out.println, =, *,<)
● Operandos Únicos n2 = 4 (N, A, B, 2)
● Ocurrencias de Operandos N2 = 6 (N, 2, A, B, N, A)

Volumen (V) = 27.509 * log2(6+4) = 91.382

Métricas de Diseño para WebApps

El diseño web abarca actividades técnicas y otras que no lo son. La visión y el sentido del
contenido se desarrollan como parte del diseño gráfico, la plantilla estética de la interfaz de
usuario se crea como parte de diseño de la interfaz y la estructura técnica de la webapp se
modela como parte del diseño arquitectónico y de navegación.

Entre las métricas que se utilizan para el diseño de webApp están las siguientes:

● Métricas de interfaz.
● Métricas estéticas (Diseño gráfico).
● Métricas de contenido.
● Métricas de navegación

Métricas de Contenido: Las métricas en estas categorías se enfocan en la complejidad del

contenido y en los grupos de objetos de contenidos que se organizan en páginas.

● Complejidad de página (Número promedio de tipos diferentes de medios usados en la página).

● Complejidad gráfica (Número de medios gráficos por página).
● Complejidad de audio (Número promedio de audio por página).
● Complejidad de animación (Número promedio de animaciones por página).

MÉTRICAS ORIENTADAS A OBJETOS

El conjunto de métricas a usar debe dejar claro qué aspectos de la calidad son los que propone
medir y a quién van dirigidos. Subdivisiones:

Métricas a nivel de sistema Métricas a nivel de clases

Métricas a nivel de herencia Métricas a nivel de métodos

Métricas a nivel de Herencia: La relación de herencia se ve como un compromiso, es decir, un

acuerdo entre el rehúso que proporciona y la dificultad en el entendimiento y mantenibilidad de
los sistemas. La herencia puede ser sustituida por delegación, además reduce el acoplamiento ya
que el cliente no conoce al proveedor y este puede ser reemplazado sobre la marcha. El
mecanismo de delegación debe ser tenido en cuenta cuando el objetivo es la reutilización de
código.

Número de hijos. (Number of Children –NOC-): Es un indicador del nivel de rehúso, la posibilidad
de haber creado abstracciones erróneas y es un indicador del nivel de test requerido. Es el
número de subclases subordinadas a una clase en la jerarquía, es decir, el número de subclases
que pertenecen a una clase.

Métricas Orientadas a Operaciones

Existen menor cantidad de métricas de este tipo por el hecho de que son las clases las que
preponderan en el software OO. Tres métricas simples, propuestas por Lorenz y Kidd son
apropiadas:
• Tamaño promedio de operación (TOprom): La cantidad de líneas de código no son una
buena unidad de medida para determinar la calidad de una operación, por lo tanto, para
determinar ésta se persigue la contabilización de mensajes
• Complejidad de la operación (CO): En este caso puede utilizarse cualquier métrica existente
para el software tradicional debido a que esta medición no se ve relacionada con el
paradigma de la POO.
• Número promedio de parámetros por operación (NPprom): Tan largo como sea el número
de parámetros de operación, mas compleja será la colaboración entre objetos

Métricas para pruebas

Durante la etapa de pruebas se utilizaran las métricas de medida de amplitud, madurez y

profundidad de las pruebas, densidad de defectos, perfil de fallos, entre otras.

• Profundidad de las pruebas: es el Porcentaje de los caminos básicos independientes

probados en relación al total de ellos sumando la complejidad ciclomática de todos los
módulos del programa.

• La densidad de defectos: ofrece una medida sobre la proporción de defectos con

respecto a la cantidad de elementos de especificación