2.1
Concepto de métrica.
2.1.1.
Medición
Es el proceso por el cual los
números o símbolos son asignados a atributos o entidades en el mundo real tal
como son descritos de acuerdo a reglas claramente
definidas” [Fenton ´91].
2.1.2
Medida
“proporciona una indicación
cuantitativa de extensión, cantidad, dimensiones, capacidad y tamaño de algunos
atributos de un proceso o producto” [Pressman´98].
2.1.3
Métrica
“Es una medida cuantitativa del grado en que
un sistema, componente o proceso posee un atributo dado” [Len O. Ejiogo
´91].
2.1.4 Métricas de Software
Michael [‘99] define las
métricas de software como “La aplicación continua de mediciones basadas en
técnicas para el proceso de desarrollo del software y sus productos para
suministrar información relevante a tiempo, así el administrador junto con el
empleo de estas técnicas mejorará el proceso y sus productos”. Las métricas de
software proveen la información necesaria para la toma de decisiones técnicas.
Las métricas son la
maduración de una disciplina, que, según Pressman [’98] van a ayudar a la evaluación de los modelos de análisis y de
diseño, en donde proporcionarán una
indicación de la complejidad de diseños procedimentales y de código fuente, y ayudaran
en el diseño de pruebas más efectivas. Es por eso que propone un proceso de
medición, el cual se puede caracterizar por cinco actividades:
1.
Formulación: La obtención de medidas y
métricas del software apropiadas para la representación de software en
cuestión.
2.
Colección: El mecanismo empleado para
acumular datos necesarios para obtener las métricas formuladas.
3.
Análisis: El cálculo de las métricas y
la aplicación de herramientas matemáticas.
4.
Interpretación: La evaluación de los
resultados de las métricas en un esfuerzo por conseguir una visión interna de
la calidad de la representación.
5.
Realimentación: Recomendaciones obtenidas de
la interpretación de métricas técnicas trasmitidas al equipo de software.
2.1.5
Características de las métricas
Simple y fácil de calcular: debería ser relativamente
fácil de aprender a obtener la métrica y su cálculo no obligara a un esfuerzo o
a una cantidad de tiempo inusuales.
Empírica e intuitivamente
persuasiva: la métrica debería satisfacer las
nociones intuitivas del ingeniero de software 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).
Consistente en el empleo de
unidades y tamaños: el cálculo matemático de la métrica
debería utilizar medidas que no lleven 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 concluyentes.
Independiente del lenguaje de
programación: las métricas deberían apoyarse 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 mecanismo eficaz para la
realimentación de calidad: la métrica debería suministrar al
desarrollador de software información que le lleve a un producto final de
superior calidad.
2.2
Tipos de métricas de calidad de software.
2.2.1
Clasificación de las Métricas
La clasificación de una
métrica de software refleja o describe la conducta del software. A continuación
se muestra una breve clasificación de métricas de software, descritas por Lem
O. Ejiogu [‘91]:
a) Según criterios
Métricas de complejidad:
Son todas las
métricas de software que definen de una u otra forma la medición de la
complejidad; Tales como volumen, tamaño, anidaciones, costo (estimación),
agregación, configuración, y flujo. Estas son los puntos críticos de la
concepción, viabilidad, análisis, y diseño de software.
Métricas de calidad: Son todas las métricas de
software que definen de una u otra forma la calidad del software; Tales como
exactitud, estructuración o modularidad, pruebas, mantenimiento, reusabilidad,
cohesión del módulo, acoplamiento del módulo, etc. Estas son los puntos
críticos en el diseño, codificación, pruebas y mantenimiento.
Métricas de competencia: Son todas las métricas que
intentan valorar o medir las actividades de productividad de los programadores
o practicantes con respecto a su certeza, rapidez, eficiencia y competencia. No
se ha alcanzado mucho en esta área, a pesar de la intensa investigación
académica.
Métricas de desempeño: Corresponden a las métricas
que miden la conducta de módulos y sistemas de un software, bajo la supervisión
del sistema operativo o hardware. Generalmente tienen que ver con la eficiencia
de ejecución, tiempo, almacenamiento, complejidad de algoritmos
computacionales, etc.
Métricas estilizadas: Son las métricas de
experimentación y de preferencia; Por ejemplo: estilo de código, identación,
las convenciones denominando de datos, las limitaciones, etc. Pero estas no se
deben confundir con las métricas de calidad o complejidad.
Variedad de métricas: tales como portabilidad, facilidad de
localización, consistencia. Existen pocas investigaciones dentro del área.
Estas
clasificaciones de métricas fortalecen la idea, de que más de una métrica puede
ser deseable para valorar la complejidad y la calidad del software.
b) Según el contexto en que
se aplican:
Métricas de proceso: Se recopilan de todos los
proyectos y durante un largo periodo de tiempo y se caracteriza por control y ejecución Del proyecto y Medición de tiempos de las
fases.
Métricas de proyecto: Permiten evaluar el estado
del proyecto y seguir la pista de los riesgos.
Métricas de producto: Se centran en las características del
software y no en cómo fue producido, también son productos los
artefactos, documentos, modelos, y componentes que conforman el
software. Se miden cosas como el tamaño, la calidad, la totalidad, la
volatilidad, y el esfuerzo.
