ENSAYO SOBRE LAS METRICAS

ENSAYO SOBRE LA IMPORTANCIA DE LAS MÉTRICAS EN

Métricas técnicas

Cualquier cosa que queramos medir o predecir en un software es un

atributo de cualquier entidad de un producto, proceso o recurso asociado a éste.

Cada entidad de software tiene varios atributos que pueden ser medidos. Es por

eso que se necesita hacer una distinción entre atributos que son internos o

externos y medidas directas e indirectas:

El Reto de las Métricas Técnicas

Muchos investigadores han intentado desarrollar una sola métrica que

facilite una medida completa de la complejidad del software. Aunque se han

presentado docenas de medidas de complejidad, cada una tiene un punto de vista

distinto de lo que es la complejidad y de qué atributos de un sistema llevan a la

complejidad. Comparemos con una métrica para evaluar un automóvil. Algunos

observadores podrían hacer énfasis en el diseño de la cabina, otros podrían hacer

hincapié en las características mecánicas, otros podrían considerar el precio, o el

rendimiento, o la economía de consumo o la capacidad de reutilizarlo cuando se

vaya a desechar. Como cualquiera de estas características puede competir con

las otras, es difícil obtener un solo valor del ‘atractivo’ del automóvil. Lo mismo

sucede con el software.

Reporte de la métrica

El siguiente paso es decidir como reportar la métrica. Esto incluye la definición del

formato del reporte, la obtención de los datos, mecanismos de reporte de

distribución y disponibilidad. El formato del reporte se diseña de acuerdo a lo que

se quiera dar a conocer, es por eso que se debe preguntar lo siguiente, ¿Está la

métrica incluida en una tabla con otras métricas para un periodo?, ¿Se añade

como último valor en una gráfica de tendencia que muestran los valores de la

métrica para varios periodos?. Esta gráfica de tendencia ¿Puede ser de barra,

línea o de área?, ¿Es mejor comparar valores empleando barras apiladas o

gráficas de pastel?. ¿Es mejor hacer tablas y gráficas solas o se agrega texto

detallado de análisis y se incluye en el reporte?, ¿Son metas o valores de control

los que se incluyen en el reporte?.

En el reporte de métricas, se deberá realizar cuatro pasos: ciclo de

obtención de datos, ciclo de reporte de datos, mecanismos de reporte, distribución

y disponibilidad que se describen a continuación:

El ciclo de obtención de datos define que a menudo la métrica requiere de

snap-shot(s) de los datos y en que momento los elementos de los datos están

disponibles para el cálculo de la métrica.

El ciclo de reporte define con que frecuencia el reporte es generado y

cuando se prepara para su distribución. Por ejemplo la razón principal de un

estudio de métricas puede ser por algún evento, como la terminación de una fase

en el proceso de desarrollo del software; Otras métricas como el promedio de

defectos reportados pueden obtenerse y reportarse diariamente durante las

26

pruebas del sistema, la obtención mensual de datos y el reporte mensual después

de la liberación del software.

Los mecanismos de reporte proyectan los mecanismos de entrega de las

métricas.

Al definir la distribución determina quienes reciben copias del reporte o

tienen acceso a la métrica. También aquí se define cualquier restricción al acceso

de la métrica, mecanismos de aprobación para añadir y eliminar accesos y

cambios en la distribución normal.

Mediciones del software

Para medir algo se necesita saber que entidades serán medidas y tener

una idea de los atributos (propiedades) de la entidad. Primero se debe identificar

un atributo y su significado de medición, podemos empezar acumulando datos.

Analizando los resultados de estos procesos normalmente permite la clarificación

y la re-valuación de los atributos.

Métricas Orientadas al Tamaño

Las métricas del software orientadas al tamaño provienen de la

normalización de las medidas de calidad y/o productividad considerando el

“tamaño” del software que se haya producido. Si una organización de software

mantiene registros sencillos, se puede crear una tabla de datos orientados al

tamaño, como la que muestra la figura 3.1, (Pressman ´98) que lista cada proyecto

de desarrollo de software y las medidas correspondientes de cada proyecto.

Refiriéndonos a la entrada de la figura 3.1 del proyecto alfa: se desarrollaron

12,100 líneas de código(LDC) con 24 personas-mes y con un costo de $168,000

dólares. Debe tenerse en cuenta que el esfuerzo y el costo registrados en la tabla

incluyen todas las actividades de ingeniería del software (análisis, diseño,

codificación y prueba) y no sólo la codificación. Otra información sobre el proyecto

alfa indica que se desarrollaron 365 páginas de documentación, se registraron 134

errores antes de que el software se entregara al cliente y se encontraron 29

errores después de entregárselo al cliente dentro del primer año de utilización.

También sabemos que trabajaron tres personas en el desarrollo del proyecto alfa.

Figura 3.1 Tabla de datos orientados al tamaño [Pressman ‘98]

31

Para desarrollar métricas que se puedan comparar entre distintos proyectos, se

seleccionan las líneas de código como valor de normalización. Con los

elementales datos contenidos en la tabla se puede desarrollar para cada proyecto

un conjunto de métricas simples orientadas al tamaño, tales como:

•errores por KLDC (miles de líneas de código, KiloLDC)

•defectos por KLDC

•$ por LDC

•páginas de documentación por KLDC

Además, se pueden calcular otras métricas interesantes:

•Productividad = KLDC/ persona-mes

•Calidad = errores / KLDC

•Documentación = páginas de documentación / KLDC

Las métricas orientadas al tamaño no están aceptadas universalmente

como el mejor modo de medir el proceso de desarrollo del software La mayor

parte de la discusión gira en torno al uso de las líneas de código mostradas en la

tabla 3.2 (LDC) como medida clave. Los defensores de la medida LDC afirman

que la LDC es un “artificio” que se puede calcular fácilmente

...