PDF de programación - Capitulo 3 Métricas técnicas

CAPÍTULO 3

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:



3.1 Atributos Internos y Atributos Externos



Los atributos internos de un producto, proceso o recurso son aquellos que

podemos medir puramente en términos del producto, proceso o recurso del

mismo. Pueden ser medidos directamente. Por ejemplo: la longitud de un

programa o el

tiempo

transcurrido de cualquier documento de software

[Fenton‘91].

Los atributos externos de un producto, proceso o recurso son aquellos que

solamente pueden ser medidos con respecto al cómo el producto, proceso o

recurso se relacionan a su ambiente. Estos tienden a ser los que el administrador

y el usuario del software comúnmente gustan de medir y predecir. Por ejemplo el

administrador de software le gustaría saber el costo de eficacia de algunos

procesos o de la productividad de su personal, mientras los usuarios les gustaría

saber la usabilidad, fiabilidad, o portabilidad de un sistema que ellos observan



15

para comprar. Desgraciadamente los atributos externos son los más difíciles de

medir, porque estos no pueden ser medidos directamente [ Fenton ’91]. En la tabla

3.1 se describe la estructura, y se dan ejemplos de varios tipos de atributos.



3.2 Medidas Directas y Medidas Indirectas



La medida directa de un atributo es aquella, en donde no se depende de

cualquier otro atributo. [ Fenton´91].

La medida Indirecta de un atributo es aquella en la que se involucra la medición de

uno o más atributos [Fenton´91].



3.3 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.



16

Construcción de especificaciones



Personal

Equipo
Software
Hardware

Oficinas
...
Procesos

Diseño detallado
Pruebas

...

Productos
Especificaciones

Diseños

Código

Datos de prueba
...



Entidades



Atributos

Recursos

Internos

Externos

edad, precio, ..

tamaño de

tamaño, estructuras ..
precio, tamaño ..
precio, velocidad,
memoria, ..
tamaño, temperatura, luz, ..
...

tiempo, esfuerzo, número de
cambios, ..
tiempo, esfuerzo,..
número de errores de código
encontrados, tiempo, ..
...

tamaño, usabilidad
modularidad, funcionalidad, ..
acoplamiento,
tamaño, usabilidad, ..
funcionalidad,
algorítmica, control de flujo
tamaño, nivel de protección, ..
...

modularidad,

complejidad

experiencia,

productividad,
inteligencia ..
productividad, calidad ..
usabilidad, seguridad ..
seguridad, ..

confort, calidad,..
...

calidad, costo, estabilidad

costo

costo, costo efectivo, ..
estabilidad,
costo,
efectivo, ..
...

comprensibilidad,
mantenimiento, ..
calidad, complejidad,
mantenimiento, ..
seguridad, usabilidad,
mantenimiento
calidad,..
...

Tabla 3.1 Estructura de Atributos [Fenton ‘91]

Se ha producido una gran cantidad de literatura sobre las métricas del

software y es común la crítica de algunas métricas (incluyendo algunas de las

presentadas en este documento). Sin embargo, muchas de las críticas se



17

centralizan en aspectos esotéricos y pierden el objetivo primario de la medición en

el mundo real, que es: el ayudar al ingeniero a establecer una manera sistemática

y objetiva de conseguir una visión interna de su trabajo y mejorar la calidad del

producto como resultado.

Sin embargo sigue existiendo la necesidad de medir y controlar la

complejidad del software, y aunque es difícil de adquirir un solo valor de esta

“métrica de calidad”, sí debería ser posible desarrollar medidas de diferentes

atributos internos del programa (por ejemplo: modularidad efectiva, independencia

funcional y otros atributos). Las métricas y las medidas conseguidas de ellas

pueden usarse como guías independientes de la calidad de los modelos de

análisis y de diseño. Pero también surgen problemas aquí. Fenton [‘91] lo advierte

cuando dice: “El peligro de intentar encontrar medidas que caractericen tantos

atributos diferentes es que inevitablemente las medidas tienen que satisfacer

objetivos incompatibles. Esto es contrario a la teoría de representación de la

medición”.

Aunque la declaración de Fenton es correcta, mucha gente cuestiona que la

medición técnica llevada a cabo en las primeras fases del proceso del software les

proporcione a los desarrolladores de software un mecanismo consistente y

objetivo para valorar la calidad.

No obstante conviene preguntarse, ¿Qué validez tienen las métricas

técnicas?. Es decir, ¿Cómo están relacionadas las métricas técnicas con la

fiabilidad y la calidad a largo plazo de un sistema basado en computadora,

Fenton[‘9l] comenta que, a pesar de las conexiones intuitivas entre la estructura

interna de los productos de software (métricas técnicas), sus productos externos y



18

los atributos del proceso, ha habido de hecho, muy pocos intentos científicos para

establecer relaciones específicas.



3.4 Identificación del Usuario



En el desarrollo de métricas se requiere identificar claramente al usuario. Lo

primero que debemos hacer para identificar a un usuario es preguntarnos:

¿Quién necesita la información?

¿Quién va a emplear la métrica?

Si la métrica no tiene un usuario – no utilizarla?

En las preguntas anteriores podemos observar que la selección de una métrica

empieza con la identificación de los programas que el usuario quiere medir.

¿Quién necesita la información? Los requerimientos del usuario determinan el

programa de métricas. Si el programa de métricas no tiene a un usuario se

recomienda no establecer dicho programa.



3.5 Diseño de métricas


Enseguida se planearan los pasos para diseñar métricas: [Lem Ejiogo ‘91]

Paso 1: Definiciones claras

El primer paso en el diseño de una métrica es el dar una definición estándar para

las entidades y sus atributos a ser medidos.

Cuando nosotros empleamos

términos como

“errores”,

“defectos”,

“problema reportado”, “tamaño” y aún “proyecto”, otra gente podría interpretar



19

-
-
-
estas palabras en su propio contexto con significados que pueden variar de

nuestra intención al definirlos. Estas interpretaciones aumentan sus diferencias

cuando se emplean términos más ambiguos como: Calidad, mantenible, amigable

al usuario y otros más.

Los ingenieros, administradores u otras personas involucradas en el

proyecto pueden emplear diferentes términos para la misma cosa. Por ejemplo, el

término defecto

reportado, problema

reportado,

incidente

reportado,

falla

reportada, o reporte de llamada del cliente pueden ser empleados por varias

organizaciones para dar significado a la misma cosa. Pero desgraciadamente,

pueden también referirse a distintas entidades. Para evitar estos problemas se

sugiere:

• Adoptar definiciones estándares y escribirlas

• Aplicarlas con consistencia

• Usar las sugerencias de la industria

• Escoger definiciones que cumplan los objetivos organizacionales

Desafortunadamente, hay muy pocos estándares en la industria para la

mayoría de las definiciones de los atributos del software. Cada uno cuenta con

una opinión y este debate podría continuar por muchos años. Al abordar este

problema se sugieren adoptar definiciones estándares hacia dentro de la

organización y aplicarlos consistentemente. Se pueden usar sugerencias de la

industria como base para empezar, seleccionar las definiciones que cumplan con

los objetivos de la organización y emplearlos para la creación de definiciones

propias.



20



Paso 2: Definir el modelo

El siguiente paso es definir un modelo para la métrica. En términos sencillos, el

modelo define el cómo calcular la métrica. Por ejemplo, para la Inspección del

código de las métricas primitivas, se puede usar los siguientes modelos

[Fenton‘91]:

• Líneas de código inspeccionadas = loc

• Horas empleadas en la preparación = hrs-prep

• Medida de preparación = loc / hrs-prep

La mayoría de los modelos incluyen un elemento de simplificación. Cuando

nosotros creamos un modelo de medición de software necesitamos ser

pragmáticos. Si tratamos de incluir todos los elementos que afectan al atributo o

que caracterizan a la entidad el modelo utilizado ll