Métricas del Modelo del Diseño

Es inconcebible que el diseño de un nuevo avión, un nuevo chip de computadora o un nuevo edificio de oficinas se realizara sin definir las medidas del diseño, sin determinar las métricas para varios aspectos de la calidad del diseño y usarlas para guiar la evolución del diseño. Y sin embargo, el diseño de sistemas complejos basados en computadora a menudo consigue proseguir sin virtualmente ninguna medición. La ironía es que las métricas de diseño para el software están disponibles, pero la gran mayoría de los desarrolladores de software continúan sin saber que existen.

Las métricas de diseño para el software, como otras métricas del software, no son perfectas. Continúa el debate sobre la eficacia y cómo deberían aplicarse. Muchos expertos argumentan que se necesita más experimentación hasta que se puedan emplear las métricas de diseño. Y sin embargo, el diseño sin medición es una alternativa inaceptable.

MÉTRICAS DEL DISEÑO ARQUITECTÓNICO

Se centran en la arquitectura del programa y 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.

Card y Glass definen tres medidas de la complejidad del diseño del software: complejidad estructural, complejidad de datos y complejidad del sistema.

La complejidad estructural, S(i), de un módulo i se define de la siguiente manera:

 donde es la expansión' del módulo 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:

donde v(i) es el número de variables de entrada y salida que entran y salen del módulo i.

La complejidad del sistema, C(i), se define como la suma de las complejidades estructural y de datos, y se define como:

MÉTRICAS DE DISEÑO A NIVEL DE 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 las «3Cs» la cohesión, acoplamiento y complejidad del módulo. Estas tres medidas pueden ayudar al desarrollador de software a juzgar la calidad de un diseño a nivel de los componentes.

Las métricas presentadas en esta sección son de caja blanca en el sentido de que requieren conocimiento del

trabajo interno del módulo en cuestión. Las métricas de diseño de los componentes se pueden aplicar una vez que se ha desarrollado un diseño procedimental. También se pueden retrasar hasta tener disponible el código fuente.

Métricas de Cohesión: Bieman y Ott definen una colección de métricas que proporcionan una indicación de la cohesión de un módulo. Las métricas se definen con cinco conceptos y medidas:

Porción de datos. Dicho simplemente, una porción de datos es una marcha atrás a través de un módulo que busca valores de datos que afectan a la localización de módulo en el que empezó la marcha atrás. Debería resaltarse que se pueden definir tanto porciones de programas (que se centran en enunciados y condiciones) como porciones de datos.

Muestras (tokens) de datos. Las variables definidas para un módulo pueden definirse como muestras de datos para el módulo.

Señales de unión. El conjunto de muestras de datos que se encuentran en una o más porciones de datos.

Señales de superunión. La muestras de datos comunes a todas las porciones de datos de un módulo.

Pegajosidad. La pegajosidad relativa de una muestra de unión es directamente proporcional al número de porciones de datos que liga.

Métricas de acoplamiento: El acoplamiento de módulo proporciona una indicación de la conectividad» de un módulo con otros módulos, datos globales y el entorno exterior. En el Capítulo 13, el acoplamiento se estudió en términos cualitativos.

Dhama ha propuesto una métrica para el acoplamiento del módulo que combina el acoplamiento de flujo de datos y de control, acoplamiento global y acoplamiento de entorno. Las medidas necesarias para calcular el acoplamiento de módulo se definen en términos de cada uno de los tres tipos de acoplamiento apuntados anteriormente.

Para el acoplamiento de flujo de datos y de control:

di = número de parámetros de datos de entrada

ci = número de parámetros de control de entrada

do = número de parámetros de datos de salida

co = número de parámetros de control de salida

Para el acoplamiento global:

g, = número de variables globales usadas como datos

g, = número de variables globales usadas como control

Para el acoplamiento de entorno:

w = número de módulos llamados (expansión)

r = número de módulos que llaman al módulo en cuestión

Métricas de Complejidad: Se pueden calcular una variedad de métricas del software para determinar la complejidad del flujo de control del programa. Muchas de éstas se basan en una representación denominada

gafo de flujo. Un gafo es una representación compuesta de nodos y enlaces (también denominados aristas). Cuando se dirigen los enlaces (aristas), el grafo de flujo es un grafo dirigido.

McCabe identifica un número importante de usos para las métricas de complejidad:

Las métricas de complejidad pueden emplearse para predecir la información crítica sobre la fiabilidad y mantenimiento de sistemas software de análisis automáticos de código fuente (o información de diseño procedimental). Las métricas de complejidad también realimentan la información durante el proyecto de software para ayudar a controlar la [actividad del diseño]. Durante las pruebas y el mantenimiento, proporcionan una detallada información sobre los módulos software para ayudar a resaltar las áreas de inestabilidad potencial.

McCabe también defiende que la complejidad ciclomática puede emplearse para proporcionar una indicación cuantitativa del tamaño máximo del módulo. Recogiendo datos de varios proyectos de programación reales, ha averiguado que una complejidad ciclomática de 10 parece ser el límite práctico superior para el tamaño de un módulo. Cuando la complejidad ciclomática de los módulos excedían ese valor, resultaba extremadamente difícil probar adecuadamente el módulo. 

MÉTRICAS DE DISEÑO DE INTERFAZ

Sears sugiere la conveniencia de la representación (CR) como una valiosa métrica de diseño para interfaces hombre-máquina. Una IGU (Interfaz Gráfica de Usuario) típica usa entidades de representación 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 siguiente contribuirán a la conveniencia de la interfaz.

Para una representación específica (por ejemplo, un de una IGU específica), se pueden asignar costes a cada secuencia de acciones de acuerdo con la siguiente relación:

Para calcular la representación óptima de una IGU, la superficie de la interfaz (el área de la pantalla) se divide en una cuadrícula. Cada cuadro de la cuadricula representa una posible posición de una entidad de la representación. Para una cuadrícula con N posibles posiciones y K diferentes entidades de representación para colocar, el número posible de distribuciones se representa de la siguiente manera:

A medida que crece el número de posiciones de representación, el número de distribuciones posibles se hace muy grande. Para encontrar la representación óptima (menor coste). Sears propone un algoritmo de búsqueda en árbol.

La CR se emplea para valorar diferentes distribuciones propuestas de IGU y la sensibilidad de una representación en particular a los cambios en las descripciones de tareas (por ejemplo, cambios en la secuencia y/o frecuencia de transiciones). El diseñador de interfaces puede emplear el cambio en la conveniencia de la representación, ACR, como guía en la elección de la mejor representación de IGU para una aplicación en particular.

Es importante apuntar que la selección de un diseño de IGU puede guiarse con métricas tales como CR, pero el árbitro final debería ser la respuesta del usuario basada en prototipos de IGU. Nielsen y Levy informan que «existe una gran posibilidad de éxito si se elige una interfaz basándose solamente en la opinión del usuario. El rendimiento medio de tareas de usuario y su satisfacción con la IGU están altamente relacionadas.»