Métricas Técnicas del Software

Métricas Técnicas del Software

Un elemento clave de cualquier proceso de ingeniería es la medición. Empleamos medidas para entender mejor los atributos de los modelos que creamos. Pero, fundamentalmente, empleamos las medidas para valorar la calidad de los productos de ingeniería o de los sistemas que construimos.

A diferencia de otras disciplinas, la ingeniería del software no está basada en leyes cuantitativas básicas de la Física. Las medidas absolutas, tales como el voltaje, la masa, la velocidad o la temperatura no son comunes en el mundo del software. En su lugar, intentamos obtener un conjunto de medidas indirectas que dan lugar a métricas que proporcionan una indicación de la calidad de algún tipo de representación del software. Como las medidas y métricas del software no son absolutas, están abiertas a debate. Fenton [FENBl] trata este aspecto cuando dice:

La medición es el proceso por el que se asignan números o símbolos a los atributos de las entidades en el mundo real, de tal manera que las definan de acuerdo con unas reglas claramente definidas.... En las ciencias físicas, medicina y, más recientemente, en las ciencias sociales, somos ahora capaces de medir atributos que previamente pensábamos que no eran medibles... Por supuesto, tales mediciones no están tan refinadas como las de las ciencias físicas..., pero existen [y se toman importantes decisiones basadas en ellas]. Sentimos que la obligación de intentar «medir lo no medible» para mejorar nuestra comprensión de entidades particulares es tan poderosa en la ingeniería del software como en cualquier disciplina.

Pero algunos miembros de la comunidad de software continúan argumentando que el software no es medible o que se deberían posponer los intentos de medición hasta que comprendamos mejor el software y los atributos que habría que emplear para describirlo. Esto es un error.

Aunque las métricas técnicas para el software de computadora no son absolutas, nos proporcionan una manera sistemática de valorar la calidad basándose en un conjunto de «reglas claramente definidas». También le proporcionan al ingeniero del software una visión interna en el acto, en vez de a posteriori. Esto permite al ingeniero descubrir y corregir problemas potenciales antes de que se conviertan en defectos catastróficos.

Características fundamentales de las métricas de software

Se han propuesto cientos de métricas para el software, pero no todas proporcionan un soporte práctico para el desarrollador de software. Algunas demandan mediciones que son demasiado complejas, otras son tan esotéricas que pocos profesionales tienen la esperanza de entenderlas y otras violan las nociones básicas intuitivas de lo que realmente es el software de alta calidad.

Ejiogu [EJI91] define un conjunto de atributos que deberían acompañar a las métricas efectivas del software. La métrica obtenida y las medidas que conducen a ello deberían ser:

Simples y fáciles de calcular. Debería ser relativamente fácil aprender a obtener la métrica y su cálculo no debería demandar un esfuerzo o cantidad de tiempo inusuales.

Empírica e intuitivamente persuasivas. La métrica debería satisfacer las nociones intuitivas del ingeniero sobre el atributo del producto en cuestión (por ejemplo, una métrica que mide la cohesión de un módulo debería aumentar su valor a medida que crece el nivel de cohesión).

Consistentes y objetivas. La métrica debería siempre producir resultados sin ambigüedad. Un tercer equipo debería ser capaz de obtener el mismo valor de métrica usando la misma información del software.

Consistentes en el empleo de unidades y tamaños. El cálculo matemático de la métrica debería emplear medidas que no conduzcan a extrañas combinaciones de unidades. Por ejemplo, multiplicando el número de personas de un equipo por las variables del lenguaje de programación en el programa resulta una sospechosa mezcla de unidades que no son intuitivamente persuasivas.

Independientes del lenguaje de programación. Las métricas deberían basarse en el modelo de análisis, modelo de diseño o en la propia estructura del programa. No deberían depender de los caprichos de la sintaxis o semántica del lenguaje de programación.

Un eficaz mecanismo para la realimentación de calidad. La métrica debería proporcionar, al desarrollador de software, información que le lleve a un producto final de mayor calidad.

MÉTRICAS DEL MODELO DE ANÁLISIS

A. Métricas basadas en la función La métrica de punto de función (PF) se puede usar como medio para predecir el tamaño de un sistema que se va a obtener de un modelo de análisis.

B. La 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 [DEM82], la métrica bung 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 [DEM82] 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.

MÉTRICAS EN EL MODELO DE DISEÑO

A. Métricas del diseño arquitectónico. Las métricas de diseño de alto nivel se concentran en las características de la arquitectura del programa con especial é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.

B. 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 [BIE94] 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.

Dhama [DHA95] 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.

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.

C. Métricas de diseño de interfaz

Aunque existe una significativa cantidad de literatura sobre el diseño de interfaces hombre-máquina (vea el Capítulo lS), se ha publicado relativamente poca información sobre métricas que proporcionen una visión interna de la calidad y facilidad de empleo de la interfaz.

Sears [SEA931 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.

Tomado de: Ingenieria.del.Software.Un.Enfoque.Practico.-.Roger.S.Pressman.V.Edicion.McGraw-Hill