CAPTULO 4

Mtricas en el desarrollo del Software

4.1 Las Mtricas y la Calidad de Software

El objetivo primordial de la ingeniera del software es producir un sistema,
aplicacin o producto de alta calidad. Para lograr este objetivo, los ingenieros de
software deben emplear mtodos efectivos junto con herramientas modernas
dentro del contexto de un proceso maduro de desarrollo del software. Al mismo
tiempo, un buen ingeniero del software y buenos administradores de la ingeniera
del software deben medir si la alta calidad se va a llevar a cabo. A continuacin se
ver un conjunto de mtricas del software que pueden emplearse a la valoracin
cuantitativa de la calidad de software
El punto de vista de Qu es calidad? Es diverso, y por lo tanto existen distintas
respuestas, tales como se muestra a continuacin:
El American Heritage Dictionary [Pressman 98] define la calidad como
Una caracterstica o atributo de algo.
La definicin estndar de calidad en ISO-8402 es La totalidad de rasgos y
caractersticas de un producto, proceso o servicio que sostiene la habilidad
de satisfacer estados o necesidades implcitas [Mcdermid 91].
Concordar explcitamente al estado funcional y a los requerimientos del
funcionamiento, explcitamente a los estndares de documentacin de

60

desarrollo, e implcitamente caractersticas que son expectativas de todos

los desarrolladores profesionales de software [Pressman 93].
La calidad de un sistema, aplicacin o producto es tan buena como los
requisitos que detallan el problema, el diseo que modela la solucin, el cdigo
que transfiere a un programa ejecutable y las pruebas que ejercita el software para
detectar errores. Un buen ingeniero del software emplea mediciones que evalan
la calidad del anlisis y los modelos de diseo, as como el cdigo fuente y los
casos de prueba que se han establecido al aplicar la ingeniera del software. Para
obtener esta evaluacin de calidad, el ingeniero debe utilizar medidas tcnicas,
que evalan la calidad con objetividad, no con subjetividad. Asimismo, un buen
administrador de proyectos debe evaluar la calidad objetivamente y no
subjetivamente. A medida que el proyecto progresa el administrador del proyecto
siempre debe valorar la calidad. Aunque se pueden recopilar muchas medidas de
calidad, el primer objetivo en el proyecto es medir errores y defectos. Las mtricas
que provienen de estas medidas proporcionan una indicacin de la efectividad de
las actividades de control y de la garanta de calidad en grupos o en particulares.
Por ejemplo los errores detectados por hora de revisin y los errores detectados
por hora de prueba suministran una visin profunda de la eficacia de cada una de
las actividades envueltas en la mtrica. As los datos de errores se pueden utilizar
tambin para calcular la eficiencia de eliminacin de defectos en cada una de las
actividades del marco de trabajo del proceso.

61

4.1.1 Visin General de los Factores que Afectan a la Calidad

McCall y Cavano [John A. McDermid 91] definieron un juego de factores de

calidad como los primeros pasos hacia el desarrollo de mtricas de la calidad del
software. Estos factores evalan el software desde tres puntos de vista distintos:
(1) operacin del producto (utilizndolo), (2) revisin del producto (cambindolo) y
(3) transicin del producto (modificndolo para que funcione en un entorno
diferente, por ejemplo: portndolo) Los autores describen la relacin entre estos
factores de calidad (lo que llaman un marco de trabajo) y otros aspectos del
proceso de ingeniera del software:
En primer lugar el marco de trabajo proporciona al administrador identificar
en el proyecto lo que considera importante, como: facilidad de mantenimiento y
transportabilidad, atributos del software, adems de su correccin y rendimiento
funcional teniendo un impacto significativo en el costo del ciclo de vida. En
segundo lugar, proporciona un medio de evaluar cuantitativamente el progreso en
el desarrollo de software teniendo relacin con los objetivos de calidad
establecidos. En tercer lugar, proporciona ms interaccin del personal de calidad,
en el esfuerzo de desarrollo. Por ltimo, el personal de calidad puede utilizar
indicaciones de calidad que se establecieron como pobres para ayudar a
identificar estndares mejores para verificar en el futuro.
Es importante destacar que casi todos los aspectos del clculo han sufrido
cambios radicales con el paso de los aos desde que McCall y Cavano hicieron su
trabajo, teniendo gran influencia, en 1978. Pero los atributos que proporcionan una
indicacin de la calidad del software siguen siendo los mismos. Si una

62

organizacin de software adopta un juego de factores de calidad como una lista

de comprobacin para evaluar la calidad del software, es probable que el
software construido hoy siga exhibiendo la buena calidad dentro de las primeras
dcadas del siglo XXI. Incluso, cuando las arquitecturas del clculo sufrn
cambios radicales (como seguramente ocurrir), el software que exhibe alta
calidad en operacin, transicin y revisin continuar sirviendo a sus usuarios.

4.1.2 Medida de la calidad

Aunque hay muchas medidas de la calidad de software, la correccin,

facilidad de mantenimiento, integridad y facilidad de uso suministran indicadores
tiles para el equipo del proyecto. Gilb [Len O. Ejiogo 90] sugiere definiciones y
medidas para cada uno de ellos, tales como:

Correccin: A un programa le corresponde operar correctamente o suministrar

poco valor a sus usuarios. La correccin es el grado en el que el software lleva a
cabo una funcin requerida. La medida ms comn de correccin son los defectos
por KLDC, en donde un defecto se define como una falla verificada de
conformidad con los requisitos.
Facilidad de mantenimiento. El mantenimiento del software cuenta con ms
esfuerzo que cualquier otra actividad de ingeniera del software. La facilidad de
mantenimiento es la habilidad con la que se puede corregir un programa si se
encuentra un error, se puede adaptar si su entorno cambia o optimizar si el cliente
desea un cambio de requisitos. No hay forma de medir directamente la facilidad de
63

mantenimiento; por consiguiente, se deben utilizar medidas indirectas. Una

mtrica orientada al tiempo simple es el tiempo medio de cambio (TMC), es decir,
el tiempo que se tarda en analizar la peticin de cambio, en disear una
modificacin apropiada, en efectuar el cambio, en probarlo y en distribuir el cambio
a todos los usuarios. En promedio, los programas que son ms fciles de
mantener tendrn un TMC ms bajo (para tipos equivalentes de cambios) que los
programas que son ms difciles de mantener.
Hitachi ha empleado una mtrica orientada al costo (precio) para la
capacidad de mantenimiento, llamada desperdicios. El costo estar en corregir
defectos hallados despus de haber distribuido el software a sus usuarios finales.
Cuando la proporcin de desperdicios en el costo global del proyecto se simboliza
como una funcin del tiempo, es aqu donde el administrador logra determinar si la
facilidad de mantenimiento del software producido por una organizacin de
desarrollo est mejorando y asimismo se pueden emprender acciones a partir de
las conclusiones obtenidas de esa informacin.
Integridad. En esta poca de intrusos informticos y de virus, la integridad del
software ha llegado a tener mucha importancia. Este atributo mide la habilidad de
un sistema para soportar ataques (tanto accidentales como intencionados) contra
su seguridad. El ataque se puede ejecutar en cualquiera de los tres componentes
del software, ya sea en los programas, datos o documentos.
Para medir la integridad, se tienen que definir dos atributos adicionales:
amenaza y seguridad. La amenaza es la probabilidad (que se logra evaluar o
concluir de la evidencia emprica) de que un ataque de un tipo establecido ocurra
en un tiempo establecido. La seguridad es la probabilidad (que se puede estimar o
64

deducir de la evidencia emprica) de que se pueda repeler el ataque de un tipo

establecido, en donde la integridad del sistema se puede especificar como:
integridad = [1- amenaza x (1- seguridad)]

(4.1)

donde se suman la amenaza y la seguridad para cada tipo de ataque.

Facilidad de uso. El calificativo amigable con el usuario se ha transformado
universalmente en disputas sobre productos de software. Si un programa no es
amigable con el usuario, prcticamente est prximo al fracaso, incluso aunque
las funciones que realice sean valiosas. La facilidad de uso es un intento de
cuantificar lo amigable que pude ser con el usuario y se consigue medir en
funcin de cuatro caractersticas: (1) destreza intelectual y/o fsica solicitada para
aprender el sistema; (2) el tiempo requerido para alcanzar a ser moderadamente
eficiente en el uso del sistema; (3) aumento neto en productividad (sobre el
enfoque que el sistema reemplaza) medida cuando alguien emplea el sistema
moderadamente y eficientemente, y (4) valoracin subjetiva (a veces obtenida
mediante un cuestionario) de la disposicin de los usuarios hacia el sistema.
Los cuatro factores anteriores son slo un ejemplo de todos los que se han
propuesto como medidas de la calidad del software.

65

4.1.3 Medidas de fiabilidad y de disponibilidad.

Los trabajos iniciales sobre fiabilidad buscaron extrapolar las matemticas

de la teora de fiabilidad del hardware a la prediccin de la fiabilidad del software.
La mayora de los modelos de fiabilidad relativos al hardware van ms orientados
a los fallos debidos al desajuste, que a los fallos debidos a defectos de diseo, ya
que son ms probables debido al desgaste fsico (p. ej.: el efecto de la
temperatura, del deterioro, y los golpes) que los fallos relativos al diseo.
Desgraciadamente, para el software lo que ocurre es lo contrario. De hecho, todos
los fallos del software, se producen por problemas de diseo o de implementacin.
Considerando un sistema basado en computadora, una medida sencilla de
la fiabilidad es el tiempo medio entre fallos (TMEF) [Mayrhauser91], donde:
TMEF = TMDF+TMDR

(4.2)

(TMDF (tiempo medio de fallo) y TMDR (tiempo medio de reparacin)).

Muchos investigadores argumentan que el TMDF es con mucho, una

medida ms til que los defectos/KLDC, simplemente porque el usuario final se
enfrenta a los fallos, no al nmero total de errores. Como cada error de un
programa no tiene la misma tasa de fallo, la cuenta total de errores no es una
buena indicacin de la fiabilidad de un sistema. Por ejemplo, consideremos un
programa que ha estado funcionando durante 14 meses. Muchos de los errores
del programa pueden pasar desapercibidos durante dcadas antes de que se

66

detecten. El TMEF de esos errores puede ser de 50 e incluso de 100 aos. Otros
errores, aunque no se hayan descubierto an, pueden tener una tasa de fallo de
18 24 meses, incluso aunque se eliminen todos los errores de la primera
categora (los que tienen un gran TMEF), el impacto sobre la fiabilidad del
software ser muy escaso.
Adems de una medida de la fiabilidad debemos obtener una medida de la
disponibilidad. La disponibilidad (4.1.3.2) del software es la probabilidad de que un
programa funcione de acuerdo con los requisitos en un momento dado, y se define
como:

Disponibilidad = TMDF/(TMDF + TMDR) x 100 %

(4.3)

La medida de fiabilidad TMEF es igualmente sensible al TMDF que al

TMDR. La medida de disponibilidad es algo ms sensible al TMDR ya que es una
medida indirecta de la facilidad de mantenimiento del software.

4.1.4 Eficacia de la Eliminacin de Defectos

Una mtrica de la calidad que proporciona beneficios tanto a nivel del

proyecto como del proceso, es la eficacia de la eliminacin de defectos (EED) En
particular el EED es una medida de la habilidad de filtrar las actividades de la

67

garanta de calidad y de control al aplicarse a todas las actividades del marco de

trabajo del proceso.
Cuando se toma en consideracin globalmente para un proyecto, EED se define
de la forma siguiente:
EED = E / (E + D)

(4.4)

donde E= es el nmero de errores encontrados antes de la entrega del software al

usuario final y D= es el nmero de defectos encontrados despus de la entrega.
El valor ideal de EED es 1, donde simbolizando que no se han encontrado
defectos en el software. De forma realista, D ser mayor que cero, pero el valor de
EED todava se puede aproximar a 1 cuando E aumenta. En consecuencia cuando
E aumenta es probable que el valor final de D disminuya (los errores se filtran
antes de que se conviertan en defectos) Si se utiliza como una mtrica que
suministra un indicador de la destreza de filtrar las actividades de la garanta de la
calidad y el control, el EED alienta a que el equipo del proyecto de software
instituya tcnicas para encontrar los errores posibles antes de su entrega.
Del mismo modo el EED se puede manipular dentro del proyecto, para
evaluar la habilidad de un equipo en encontrar errores antes de que pasen a la
siguiente actividad, estructura o tarea de ingeniera del software. Por ejemplo, la
tarea de anlisis de requerimientos produce un modelo de anlisis qu se puede
inspeccionar para encontrar y corregir errores. Esos errores que no se encuentren
durante la revisin del modelo de anlisis se pasan a la tareas de diseo (en

68

donde se puede encontrar o no) Cuando se utilizan en este contexto, el EED se

vuelve a definir como:

EED = Ei / ( Ei + Ei+1)

(4.5)

Donde Ei = es el nmero de errores encontrados durante la actividad iesima de: ingeniera del software i, el Ei + 1 = es el nmero de errores encontrado
durante la actividad de ingeniera del software (i + 1) que se puede seguir para
llegar a errores que no se detectaron en la actividad i.
Un objetivo de calidad de un equipo de ingeniera de software es alcanzar
un EED que se aproxime a 1, esto es, los errores se deberan filtrar antes de
pasarse a la actividad siguiente. Esto tambin puede ser utilizado dentro del
proyecto para evaluar la habilidad de un equipo, esto con el objetivo de encontrar
deficiencias que harn que se atrase el proyecto.
Existen varias mtricas de calidad, pero las ms importantes y que
engloban a las dems, son slo cuatro: correccin, facilidad de mantenimiento,
integridad y facilidad de uso, se explican en la siguiente seccin.

4.1.5 Factores de Calidad de McCall

Los factores que perturban la calidad del software se pueden categorizar en

dos grandes grupos: (1) factores que se pueden medir directamente (por ejemplo:
defectos por puntos de funcin) y (2) factores que se pueden medir slo
indirectamente (por ejemplo: facilidad de uso o de mantenimiento).

69

McCall y sus colegas plantearon una categorizacin de factores que afectan

a la calidad de software, que se muestran en la figura 4.1 en donde se centralizan
con tres aspectos importantes de un producto de software: sus caractersticas
operativas, su capacidad de cambio y su adaptabilidad a nuevos entornos.
Refirindose a los factores de la figura 4.1, McCall proporciona las siguientes
descripciones: [Pressman 98].

Correccin: Hasta dnde satisface un programa su especificacin y consigue

los objetivos de la misin del cliente.

Fiabilidad: Hasta dnde puede quedarse un programa que lleve a cabo su

funcin pretendida con la exactitud solicitada. Cabe hacer notar que se han
propuesto otras definiciones de fiabilidad ms completas.

Facilidad de mantenimiento
Flexibilidad
Facilidad de Prueba

REVISIN DEL PRODUCTO

Portabilidad
Reusabilidad
(capacidad de reutilizacin)
Interoperatividad

TRANSICIN DEL PRODUCTO

OPERACIN DEL PRODUCTO

Correccin Fiabilidad Usabilidad (facilidad Integridad Eficiencia de manejo)

Figura 4.1 Factores que afectan a la calidad del software [Pressman98]

Eficiencia: El conjunto de recursos informticos y de cdigo necesarios para

que un programa realice su funcin.

Integridad: Hasta dnde se puede controlar el acceso al software o a los datos

por individuos no autorizados.

70

Usabilidad (facilidad de manejo): El esfuerzo necesario para aprender, operar,

y preparar datos de entrada e interpretar las salida (resultados) de un
programa.

Facilidad de mantenimiento: El esfuerzo necesario para localizar y arreglar un

error en un programa.

Flexibilidad: El esfuerzo necesario para modificar un programa operativo.

Facilidad de prueba: El esfuerzo necesario para aprobar un programa para

asegurarse de que realiza su funcin pretendida.

Portabilidad: El esfuerzo necesario para trasladar el programa de un entorno

de sistema hardware y/o software a otro.

Reusabilidad: (capacidad de reutilizacin): Hasta dnde se puede volver a

utilizar un programa (o partes) en otras aplicaciones con relacin al
empaquetamiento y alcance de las funciones que ejecuta el programa.

Interoperatividad: El esfuerzo necesario para acoplar un sistema con otro.

Es difcil y en algunos casos improbable, desarrollar medidas directas de los

factores de calidad anteriores. Es por eso, que se definen y emplean un conjunto
de mtricas para desarrollar expresiones para todos los factores de acuerdo con la
siguiente relacin:
Fq = c1 * m1 + c2 * m2 + + cn * mn

(4.6)

Donde Fq es un factor de calidad del software, cn son coeficientes de

regresin y mn son las mtricas que afectan al factor de calidad. Lo malo es que
las mtricas definidas por McCall slo pueden medirse de manera subjetiva. Las

71

mtricas van en lista de comprobacin que se emplean para apuntar atributos

especficos del software. El esquema de puntuacin presentado por McCall es una
escala del 0 (bajo) al 10 (alto) En donde se emplean las siguientes mtricas en el
esquema de puntuacin:
-

Facilidad de auditoria: La facilidad con la que se puede justificar el

cumplimiento de los estndares.

Exactitud: La exactitud de los clculos y del control.

Estandarizacin de comunicaciones: El nivel de empleo de estndares de

interfaces, protocolos y anchos de banda.

Complexin: El grado con que s a logrado la implementacin total de una

funcin.

Concisin: Lo compacto que resulta ser el programa en trminos de lneas de

cdigo.

Consistencia: El uso de un diseo uniforme y de tcnicas de documentacin a

travs del proyecto de desarrollo del software.

Estandarizacin de datos: El empleo de estructuras y tipos de datos

estndares a lo largo del programa.

Tolerancia al error: El deterioro causado cuando un programa descubre un

error.

Eficiencia de ejecucin: El rendimiento del funcionamiento de un programa.

Capacidad de expansin. El grado con que se pueden aumentar el diseo

arquitectnico, de datos o procedimental.

Generalidad: La extensin de aplicacin potencial de los componentes del

programa.
72

Independencia del hardware: El grado con que se desacopla el software del

hardware donde opera.

Instrumentacin: El grado con que el programa vigila su propio funcionamiento

Facilidad de auditoria
*
Exactitud
*
Estandarizacin de
comunicaciones
Complecin
*
*
*
Complejidad
*
Concisin
*
*
*
Consistencia
*
*
*
Estandarizacin de datos
*
*
*
Tolerancia a errores
*
Eficiencia de ejecucin
*
Capacidad de expansin
*
Generalidad
*
Independencia del hardware
Instrumentacin
*
*
Modularidad
*
*
Operatividad
*
Seguridad
*
Autodocumentacin
*
Simplicidad
*
*
Independencia del sistema
*
Trazabilidad
Facilidad de formacin
Figura 4.2 Relacin entre Factores de calidad y mtricas de
[Fenton91]

Usabilidad (facilidad de
manejo

Interoperabilidad

Portabilidad

Capacidad de pruebas

Flexibilidad

Mantenimiento

Integridad

Eficiencia

Fiabilidad

Factor de
calidad

Correccin

Mtrica de la
calidad del
software

Reusabilidad (capacidad de
reutilizacin)

e identifica los errores que suceden.

*
*

*
*

*
*

*
*

*
*

*
*

*
*

*
*
*

la calidad de software

Modularidad: La independencia funcional de componentes de programa.

Operatividad: La facilidad de operacin de un programa.

73

Trazabilidad: La capacidad de alcanzar una representacin del diseo o un

componente real del programa hasta los requisitos.

Formacin: El grado en que el software ayuda a los nuevos usuarios a manejar el

sistema.
La relacin entre los factores de calidad del software y las mtricas de la lista
anterior se muestra en la figura 4.2. Convendra decirse que el peso que se asigna
a cada mtrica depende de los productos y negocios locales.

4.1.6 FURPS
(Funcionality, Usability, Reliability, Performance, Supportability)

Hewlett-Packard ha desarrollado un conjunto de factores de calidad de software al

que se le ha dado el acrnimo de FURPS: [Pressman 98]
-

Funcionalidad. Se aprecia evaluando el conjunto de caractersticas y

capacidades del programa, la generalidad de las funciones entregadas y la
seguridad del sistema global.

Usabilidad (facilidad de empleo o uso) Se valora considerando factores

humanos, la esttica, consistencia y documentacin general.

Fiabilidad. Se evala midiendo la frecuencia y gravedad de los fallos, la

exactitud de las salidas (resultados), el tiempo medio entre fallos (TMEF), la
capacidad de recuperacin de un fallo y la capacidad de prediccin del
programa.

Rendimiento. Se mide por la velocidad de procesamiento, el tiempo de

respuesta, consumo de recursos, rendimiento efectivo total y eficacia.
74

Capacidad de soporte. Combina la capacidad de ampliar el programa

(extensibilidad), adaptabilidad y servicios (los tres representan mantenimiento),
as como capacidad de hacer pruebas, compatibilidad, capacidad de
configuracin, la facilidad de instalacin de un sistema y la facilidad con que se
pueden localizar los problemas.

4.2 Mtricas del modelo de anlisis

En esta fase se obtendrn los requisitos y se establecer el fundamento

para el diseo. Y es por eso que se desea una visin interna a la calidad del
modelo de anlisis. Sin embargo hay pocas mtricas de anlisis y especificacin,
se sabe que es posible adaptar mtricas obtenidas para la aplicacin de un
proyecto, en donde las mtricas examinan el modelo de anlisis con el fin de
predecir el tamao del sistema resultante, en donde resulte probable que el
tamao y la complejidad del diseo estn directamente relacionadas. Es por eso
que se vern en las siguientes secciones las mtricas orientadas a la funcin, la
mtrica bang y las mtricas de la calidad de especificacin.

4.2.1 Mtricas basadas en la funcin

La mtrica de punto de funcin (PF) (captulo 3.6.2) se puede usar como

medio para predecir el tamao de un sistema que se va a obtener de un modelo
de anlisis. Para instruir el empleo de la mtrica PF, se considerar una sencilla
representacin del modelo de anlisis mostrada por Pressman [98]en la figura 4.3
75

En donde se representa un diagrama de flujo de datos, de una funcin de una

aplicacin de software llamada Hogar Seguro. La funcin administra la interaccin
con el usurario, aceptando una contrasea de usuario para activar/ desactivar el
sistema y permitiendo consultas sobre el estado de las zonas de seguridad y
varios censores de seguridad. La funcin muestra una serie de mensajes de
peticin y enva seales apropiadas de control a varios componentes del sistema
de seguridad.
El diagrama de flujo de datos se evala para determinar las medidas clave
necesarias para el clculo de al mtrica de PF.:
-

nmero de entradas de usuario

nmero de salidas de usuario

nmero de consultas del usuario

nmero de archivos

nmero de interfaces externas

Sensor de prueba

Contrasea
Consulta de zona
Usuario

Consulta de sensor
Activar/desactivar

Funciones de
interaccin del
usuario con
Hogar seguro

Iterruptor de emergencia

Sensores

Configuracin de zona
Mensajes
Usuarios
Estado del sensor
Activar/desactivar
Alerta de
alarma

Contraseas, sensors
Datos de configuracin
del sistema

Subsistema de
monitorizacin y
respuesta

Figura 4.3 Diagrama de flujo de Hogar Seguro [Presmman98].

76

Hay tres entradas del usuario: contrasea, interruptor de emergencias y

activar/desactivar aparecen en la figura con dos consultas: consulta de zona y
consulta de sensor. Se muestra un archivo (archivo de configuracin del
sistema) Tambin estn presentes dos salidas de usuarios(mensajes y estado de
del sensor) y cuatro interfaces externas (sensor de prueba, configuracin de zona,
activar/desactivar y alerta de alarma).

Parmetro de medicin

Cuenta

Simple

Media

Compleja

Total

Nmero de entradas de usuario

3*

=9

Nmero de salidas de usuario

2*

=8

Nmero de consultas del usuario

2*

=6

Nmero de archivos

1*

10

15

=7

Nmero de interfaces externas

4*

10

= 20

Cuenta total

50
Tabla 4.1 Factor de ponderacin [Pressman 98]

La cuenta total mostrada en al figura 4.6.1 b debe ajustarse usando la

ecuacin:
PF = cuenta-total * (0.65 + 0.01 * Fi)

Donde cuenta-total es la suma de todas las entradas PF obtenidas de la

figura 4.6.1 b y Fi( i=1 a 14) son valores de ajuste de complejidad. Para el
propsito de este ejemplo, asumimos que Fi es 46 (un producto moderadamente
complejo) Por lo tanto:
PF = 50* [0.65+(0.01*46)]=56

77

Basndose en el valor previsto de PF obtenido del modelo de anlisis, el equipo

del proyecto puede estimar el tamao global de implementacin de las funciones
de Hogar Seguro. Asuma que los datos de los que se disponen indican que un PF
supone 60 lneas de cdigo (si se usa un lenguaje orientado a objetos) y que en
un esfuerzo de un mes- persona se producen 12 PF. Estos datos histricos
proporciona al administrador del proyecto una importante informacin de
planificacin basada en el modelo de anlisis en lugar de en estimaciones
preliminares.

4.2.2 La mtrica Bang

Puede emplearse para desarrollar una indicacin del tamao del software a
implementar como consecuencia del modelo de anlisis. Desarrollada por Tom
DeMarco [Ejiogo 91], la mtrica bang es una indicacin, independiente de la
implementacin, del tamao del sistema [Ejiogo 91]. Para calcular la mtrica
bang, el desarrollador de software debe evaluar primero un conjunto de primitivas
(elementos del modelo de anlisis que no se subdividen ms en el nivel de
anlisis) Las primitivas se determinan evaluando el modelo de anlisis 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 no compuestos y aparecen en el diccionario de datos.

Objetos (OB) Objetos de datos.

78

Relaciones (RE) Las conexiones entre objetos de datos.

Transiciones (TR) El nmero de transacciones de estado en el diagrama de

transicin de estado.

Adems de las seis primitivas nombradas arriba, se determinan medidas

adicionales para:
-

Primitivas modificadas de funcin manual (PMFu) Funciones que caen

fuera del lmite del sistema y que deben modificarse para acomodarse al
nuevo sistema.

Elementos de datos de entrada (EDE) Aquellos elementos de datos que se

introducen en el sistema.

Elementos de datos de salida (EDS) Aquellos elementos de datos que se

sacan en el sistema.

Elementos de datos retenidos (EDR) Aquellos elementos de datos que son

retenidos (almacenados) por el sistema.

Muestras (tokens) de datos (TCi) Las muestras de datos (elementos de

datos que no se subdividen dentro de una primitiva funcional) que existen
en el limite de la i-sima primitiva funcional (evaluada para cada primitiva).

Conexiones de relacin (Rei) Las relaciones que conectan el i-simo objeto

en el modelo de datos con otros objetos.

DeMarco [Ejiogo 91] sugiere que la mayora del software se puede asignar a
uno de los dos dominios siguientes, dominio de funcin o dominio de datos,
dependiendo de la relacin RE/PFu. Las aplicaciones de dominio de funcin
(encontrados comnmente en aplicaciones de ingeniera y cientficas) hacen
79

hincapi en la transformacin de datos y no poseen generalmente estructuras de

datos complejas. Las aplicaciones de dominio de datos (encontradas comnmente
en aplicaciones de sistemas de informacin) tienden a tener modelos de datos
complejos [Ejiogo 91].

Si RE / Pfu < 0,7 implica una aplicacin de dominio de funcin

Si 0,8 < RE / Pfu < 1,4 implica una aplicacin hbrida
Si RE / Pfu > 1,5 implica una aplicacin de dominio de datos.

Como diferentes modelos de anlisis harn una participacin del modelo

con mayor o menor grado de refinamiento, DeMarco sugiere que se emplee una
cuenta medida de muestras (token) por primitiva para controlar la uniformidad de
la participacin a travs de muchos diferentes modelos dentro del dominio de una
aplicacin [Ejiogo 91].
TCavg =

TC i/Pfu

(4.7)

Una vez que se ha calculado la mtrica bang , se puede empelar el historial

anterior para asociarla con el esfuerzo y el tamao. DeMarco sugiere que las
organizaciones se construyan sus propias versiones de tablas IPFuC y IOBC para
calibrar la informacin de proyectos completos de software.

80

4.2.3 Mtricas de la Calidad de Especificacin

Existe una lista de caractersticas para poder valorar la calidad del modelo
de anlisis y la correspondiente especificacin de requisitos: Especificidad,
correccin, complecin, comprensin, capacidad de verificacin, consistencia
externa e interna, capacidad de logro, concisin, traza habilidad, capacidad de
modificacin, exactitud y capacidad de reutilizacin. Aunque muchas de las
caractersticas anteriores pueden ser de naturaleza cuantitativa, Davis [Pressman
98] sugiere que todas puedan representarse usando una o ms mtricas. Por
ejemplo asumimos que hay ni requisitos en una especificacin, tal como
ni = nf + nnf

(4.8)

Donde nf es el numero de requisitos funcionales y nnf es el nmero de requisitos

no funcionales ( por ejemplo, rendimiento).
Para determinar la especificidad de los requisitos, Davis [Pressman 98]
sugiere una mtrica basada en la consistencia de la interpretacin de los revisores
para cada requisito:
Q1 = nui / nr

(4.9)

Donde nui es el numero de requisitos para los que todos los revisores tuvieron
interpretaciones idnticas. Cuanto ms cerca de uno este el valor de Q1 menor
ser la ambigedad de la especificacin.
La complecin de los requisitos funcionales pueden terminarse calculando la
relacin
Q2 = nu / (ni * ns )

(4.10)

81

donde nu es el nmero de requisitos de funcin nicos, ni es el nmero de

entradas (estmulos) definidos o implicados por la especificacin y ns es el nmero
de estados especificados. La relacin Q2 mide porcentaje de funciones necesarias
que se han especificado para un sistema, sin embargo, no trata los requisitos no
funcinales. Para incorporarlos a una mtrica global completa, debemos
considerar el grado de validacin de los requisitos:
Q3 = nc / (nc + nnv )

(4.11)

donde nc es el nmero de requisitos que se han validados como correctos y nnv el

nmero de requisitos que no se han validado todava.

4.3 Mtrica del modelo del diseo

Las mtricas para software, como otras mtricas, no son perfectas; muchos
expertos argumentan que se necesita ms experimentacin hasta que se puedan
emplear bien las mtricas de diseo. Sin embargo el diseo sin medicin es una
alternativa inaceptable. A continuacin se mostraran algunas de las mtricas de
diseo ms comunes. Aunque ninguna es perfecta, pueden proporcionarle al
diseador una mejor visin interna y as el diseo evolucionara a un mejor nivel de
calidad.

4.3.1 Mtricas de diseo de alto nivel

stas se concentran en las caractersticas de la estructura del programa

dndole nfasis a la estructura arquitectnica y en la eficiencia de los mdulos.
82

Estas mtricas son de caja negra, en el sentido de que no se requiere ningn

conocimiento del trabajo interno de ningn modo en particular del sistema.
Card y Glass [Pressman 98] proponen tres medidas de complejidad del
software: complejidad estructural, complejidad de datos y complejidad del sistema.
La complejidad estructural. S(i), de un mdulo i se define de la siguientes
manera.
S(i) = f2out (i)

(4.12)

donde f out (i) es la expansin del mdulo i.

La complejidad de datos. D(i) proporciona una indicacin de la complejidad
en la interfaz interna de un mdulo i y se define como :
D(i) = v(i) / [fout (i) + 1]

(4.13)

donde v(i) es el nmero de variables de entrada y salida del mdulo i.

Finalmente. la complejidad del sistema. C(i), se define como la suma de las
complejidades estructural y de datos, y se define como.
C(i)=S(i)+D(i)

(4.14)

A medida que crecen los valores de complejidad, la complejidad arquitectnica o

global del sistema tambin aumenta. Esto lleva a una mayor probabilidad de que
aumente el esfuerzo necesario para la integracin y las pruebas.
Una mtrica de diseo arquitectnico propuesta por Henry y Kafura [Hamdi
99] tambin emplea la expansin y la concentracin. Los autores definen una
mtrica de complejidad de la forma:.
MHK = longitud (i) x [fn(i) + fout(i)]2

(4.15)

83

donde la longitud (i) es el nmero de sentencias en lenguaje de programacin en

el mdulo (i) y fin (i) es la concentracin del mdulo i. Henry y Kafura amplan la
definicin de concentracin y expansin no slo el nmero de conexiones de
control del mdulo (llamadas al mdulo), sino tambin el nmero de estructuras de
datos del que el mdulo i recoge (concentracin) o actualiza (expansin) datos.
Para calcular el MHK durante el diseo, puede emplearse el diseo procedimental
para estimar el nmero de sentencias del lenguaje de programacin del mdulo i.
Como en las mtricas de Card y Glass mencionadas anteriormente, un aumento
en la mtrica de Henry-Kafura conduce a una mayor probabilidad de que tambin
aumente el esfuerzo de integracin y pruebas del mdulo.
Fenton [91] sugiere varias mtricas de morfologa simples (por ejemplo,
forma) que permiten comparar diferentes arquitecturas de programa mediante un
conjunto de dimensiones directas. En la Figura 4.4 , se muestra un ejemplo de una
arquitectura de software donde puede visualizarse las siguientes mtricas:
Tamao = n +a

(4.16)

Donde n es nmero de nodos (mdulos) y a es el nmero de arcos (lneas de

control) Para la arquitectura mostrada en la Figura 4.4, [Fenton91]
tamao = 17 + 18 = 35

profundidad = el camino ms largo desde el nodo raz (parte ms alta) a un nodo

hoja.

(4.17)

Para la arquitectura mostrada en la Figura 4.4

profundidad =4.

84

Nodo

Profundidad

Arco

Figura 4.4 Arquitectura de Software [Fenton 91]

anchura = mximo nmero de nodos de cualquier nivel de la arquitectura.

(4.18)

Para la arquitectura mostrada en la Figura 4.4.

anchura = 6.
Relacin arco-a-nodo, r = a/n

(4.19)

que mide la densidad de conectividad de la arquitectura y puede proporcionar una

medida sencilla del acoplamiento de la arquitectura.
Para la arquitectura mostrada en la Figura 4.4:
r = 18/17 = 1,06.
El Mando de sistemas de la Fuerza Area Americana [Pressman98] ha
desarrollado varios indicadores de calidad del software basados en caractersticas
medibles del diseo de un programa de computadora. Empleando conceptos
similares a los propuestos en IEEE Std en 1988, la Fuerza Area utiliza
informacin obtenida del diseo de datos y arquitectnico para obtener un ndice
de calidad de la estructura del diseo (ICED) que va desde 0 a 1.
Se deben comprobar los siguientes valores para calcular el ICED [Pressman98]:

85

SI = el nmero total de mdulos definidos en la arquitectura del programa

S2 = el nmero de mdulos que para funcionar correctamente dependen de
la fuente de datos de entrada o producen datos que se van a emplear en
algn otro lado en general, los mdulos de control (entre otros) no
formaran parte de S 2.
S3 = el nmero de mdulos que para que funcionen correctamente
dependen de procesos previos
S4 = el nmero de elementos de base de datos (incluye todos los objetos de
datos y todos los atributos que definen los objetos)
S5 = el nmero total de elementos nicos de base de datos
S6 = el nmero de segmentos de base de datos (registros diferentes u
objetos individuales)
S7 = el nmero de mdulos con una salida y una entrada (el proceso de
excepciones no se considera de salida mltiple)
Una vez que se han determinado los valores SI a S7 para un programa de
computadora, se pueden calcular los siguientes valores intermedios:
Estructura del programa: D1, donde D1 se define como sigue: si el diseo
arquitectnico se desarroll usando un mtodo determinado (por ejemplo,
diseo orientado a flujo de datos o diseo orientado a objetos), entonces
D1=1, de otra manera D 1=0.
Independencia del mdulo: D2=1 (S 2/S1)

(4.20)

Mdulos no dependientes de procesos previos: D3=1 (S 3/S1)

(4.21)

86

Tamao de la base de datos: D4=1 (S5/S4)

(4.22)

Compartido de la base de datos: D5=1-(S6/S4)

(4.23)

Caractersitcas de entrada/salida del mdulo: D6=1 (S7/S1)

(4.24)

Con estos valores intermedios calculados, el ICED se obtiene de la siguiente

manera:
ICED= Wi Di

(4.25)

donde i = 1 a 6, Wi es el peso relativo de la importancia de cada uno de los

valores intermedios y W

=1 (si todos los Di tiene el mismo peso, entonces

Wi=0.167).
Se puede determinar y compartir el valor de ICED de diseos anteriores
con un diseo actualmente en desarrollo. Si el ICED es significativamente inferior
a la medida, se aconseja seguir trabajando en el diseo y revisin. Igualmente, si
hay que hacer grandes cambios a un diseo ya existente, se puede calcular el
efecto de estos cambios en el ICED.

4.3.2 Mtricas de diseo en los componentes

Las mtricas de diseo a nivel de componentes se concentran en las

caractersticas internas de los componentes del software e incluyen medidas de la
cohesin, acoplamiento y complejidad del mdulo. Estas tres medidas pueden

87

ayudar al desarrollador de software a juzgar la calidad de un diseo a nivel de

componentes.
Las mtricas presentadas son de caja blanca en el sentido de que
requieren conocimiento del trabajo interno del mdulo en cuestin. Las mtricas
de diseo en los componentes se pueden aplicar una vez que se ha desarrollado
un diseo procedimental. Tambin se pueden retrasar hasta tener disponible el
cdigo fuente.

4.3.2.1 Mtricas de cohesin.

Bieman y Ott [Hamdi 99] definen una coleccin de mtricas que proporcionan
una indicacin de la cohesin de un mdulo. Las mtricas se definen con cinco
conceptos y medidas:
Porcin de datos. Dicho simplemente, una porcin de datos es una marcha
atrs a travs de un mdulo que busca valores de datos que afectan a la
localizacin del mdulo en el que empez la marcha atrs. Debera resaltarse
que se pueden definir tanto porciones de programas (que se centran en
enunciados y condiciones) como porciones de datos.
Smbolos lxicos (tokens) de datos. Las variables definidas para un mdulo
pueden definirse como seales de datos para el mdulo.
Seales de unin. El conjunto de seales de datos que se encuentran en uno o
ms porciones de datos.

88

 Seales de super-unin. Las seales de datos comunes a todas las porciones

de datos de un mdulo.
Cohesin. La cohesin relativa de una seal de unin es directamente
proporcional al nmero de porciones de datos que liga.
Bieman y Ott desarrollaron mtricas para cohesiones funcionales fuertes (CFF),
cohesiones funcionales dbiles (CFD), y pegajosidad (el grado relativo con el que
las seales de unin ligan juntas porciones de datos) Estas mtricas se pueden
interpretar de la siguiente manera [Hamdi99] .
Todas estas mtricas de cohesin tienen valores que van desde 0 a 1.
Tienen un valor de 0 cuando un procedimiento tiene ms de una salida y no
muestra ningn atributo de cohesin indicado por una mtrica particular. Un
procedimiento sin seales de super-unin, sin seales comunes a todas las
porciones de datos, no tiene una cohesin funcional fuerte (no hay seales de
datos que contribuyan a todas las salidas) Un procedimiento sin seales de unin,
es decir, sin seales comunes a ms de una porcin de datos (en procedimientos
con ms de una porcin de datos), no muestra una cohesin funcional dbil y
ninguna adhesividad (no hay seales de datos que contribuyan a ms de una
salida) La cohesin funcional fuerte y la pegajosidad se obtienen cuando las
mtricas de Bieman y Ott toman un valor mximo de 1.
Esto es una breve descripcin de las mtricas de Bieman y Ott. Sin
embargo, para ilustrar el carcter de estas mtricas, se debe la mtrica para la
cohesin funcional fuerte:

89

CFF(i) = SU(SA(i))/seales (i)

(4.26)

donde SU(SA(i)) denota seales de super-unin (el conjunto de seales de datos

que se encuentran en todas las porciones de datos de un mdulo i) Como la
relacin de seales de super-unin con respecto al nmero total de seales en un
mdulo i aumenta hasta un valor mximo de 1, la cohesin funcional del mdulo
tambin aumenta 1.

4.3.2.2

Mtricas de acoplamiento.

El acoplamiento de mdulo proporciona una indicacin de la conectividad de un

mdulo con otros mdulos, datos globales y entorno exterior. Dhama [Fenton 91]
ha propuesto una mtrica para el acoplamiento del mdulo 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 mdulo se
definen en trminos de cada uno de los tres tipos de acoplamiento apuntados
anteriormente.
Para el acoplamiento de flujo de datos y de control:
di = nmero de parmetros de datos de entrada
ci = nmero de parmetros de control de entrada
do = nmero de parmetros de datos de salida
co = nmero de parmetros de control de salida
Para el acoplamiento global
90

gd = nmero de variables globales usadas como datos

gc = numero de variables globales usadas como control

Para el acoplamiento de entorno:

w = nmero de mdulos llamados (expansin)
r = nmero de mdulos que llaman al mdulo en cuestin (concentracin)
Usando estas medidas, se define un indicador de acoplamiento de mdulo, .mc,
de la siguiente manera:
m c = k/M

(4.27)

donde k = 1 es una constante de proporcionalidad.

M = di + a* ci + do + b*co +gd + c *gc + w + r

(4.28)

donde:
a=b=c=2

Cuanto mayor es el valor de mc, menor es el acoplamiento de mdulo. Por

ejemplo, si un mdulo tiene un solo parmetro de entrada y salida de datos, no
accede a datos globales y es llamado por un solo mdulo entonces:

m= 1/(1 +0+1 +0+0+0+ l +0)= 1/3=0.33

Deberamos esperar que un mdulo como ste presentara un acoplamiento
bajo. De ah que, un valor de mc = 0,33 implica un acoplamiento bajo. Por el
contrario, si un mdulo tiene 5 parmetros de salida y 5 parmetros de entrada de

91

datos, un nmero igual de parmetros de control, accede a 10 elementos de datos

globales y tiene una concentracin de 3 y una expansin de 4,
m = 1/(5 + 2.5 + 5 + 2.5 + lO + 0 +,3 + 4) = 0.02
el acoplamiento implicado es grande.
Para que aumente la mtrica de acoplamiento a medida que aumenta el grado de
acoplamiento, se puede definir una mtrica de acoplamiento revisada:
C= 1-mc

(4.29)

donde el grado de acoplamiento no aumenta linealmente un valor mnimo

en el rango de 0,66 hasta un mximo que se aproxima a 1,0.

4.3.2.3

Mtricas de complejidad.

Se pueden calcular una variedad de mtricas del software para determinar

la complejidad del flujo de control del programa. Muchas de stas se basan en una
representacin denominada grafo de flujo, un grafo es una representacin
compuesta de nodos y enlaces (tambin denominados filos) Cuando se dirigen los
enlaces (aristas), el grafo de flujo es un grafo dirigido.
McCabe [Pressman 93] identifica un nmero importante de usos para las mtricas
de complejidad, donde pueden emplearse para predecir informacin sobre la
fiabilidad y mantenimiento de sistemas software, tambin realimentan la
informacin durante el proyecto de software para ayudar a controlar la actividad de

92

diseo, en las pruebas y mantenimiento, proporcionan informacin sobre los

mdulos software para ayudar a resaltar las reas de inestabilidad.
La mtrica de complejidad ms ampliamente usada (y debatida) para el
software es la complejidad ciclomtica, originalmente desarrollada por Thomas
McCabe. La mtrica de McCabe proporciona una medida cuantitativa para probar
la dificultad y una indicacin de la fiabilidad ltima. Estudios experimentales
indican una fuerte correlacin entre la mtrica de McCabe y el nmero de errores
que existen en el cdigo fuente, as como el tiempo requerido para encontrar y
corregir dichos errores. McCabe [Pressman 98] tambin defiende que la
complejidad ciclomtica puede emplearse para proporcionar una indicacin
cuantitativa del tamao mximo del mdulo. Recogiendo datos de varios proyectos
de programacin reales, ha averiguado que una complejidad ciclomtica de 10
parece ser el lmite prctico superior para el tamao de un mdulo, Cuando la
complejidad

ciclomtica

de

los

mdulos

excedan

ese

valor,

resultaba

extremadamente difcil probar adecuadamente el mdulo.

4.3.3 Mtricas de diseo de interfaz

Aunque existe una significativa cantidad de literatura sobre el diseo de

interfaces hombre-mquina, se ha publicado relativamente poca informacin sobre
mtricas que proporcionen una visin interna de la calidad y facilidad de empleo
de la interfaz.

93

Sears [Pressman 98] sugiere la conveniencia de la representacin (CR)

como una valiosa mtrica de diseo para interfaces hombre-mquina. Una IGU
(Interfaz Grfica de Usuario) tpica usa entidades de representacin, iconos
grficos, texto, mens, 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 representacin a otra. Las posiciones absolutas y relativas de cada
entidad de representacin, la frecuencia con que se utilizan y el costo de la
transicin de una entidad de representacin a la siguiente contribuir a la
conveniencia de la interfaz.
Para una representacin especfica (p. ej.: un diseo de una IGU
especfica), se pueden asignar costos a cada secuencia de acciones de acuerdo
con la siguiente relacin:
Costos = [frecuencia de transicin (ki) x costos de transicin (ki)]

(4.30)

donde k es la transicin i especfica de una entidad de representacin a la

siguiente cuando se realiza una tarea especfica. Esta suma se da con todas las
transiciones de una tarea en particular o conjunto de tareas requeridas para
conseguir alguna funcin de la aplicacin. El costo puede estar caracterizado en
trminos de tiempo, retraso del proceso o cualquier otro valor razonable, tal como
la distancia que debe moverse el ratn entre entidades de la representacin.
La conveniencia de la representacin se define como:

CR = 100 x [(costo de la representacin ptima CR)/

(costo de la representacin propuesta)] .
(4.31)

94

donde CR = para una representacin ptima.

Para calcular la representacin ptima de una IGU, la superficie de la
interfaz (el rea de la pantalla) se divide en una cuadrcula. Cada cuadro de la
cuadrcula representa una posible posicin de una entidad de la representacin.
Para una cuadrcula con N posibles posiciones y K diferentes entidades de
representacin para colocar, el nmero posible de distribuciones se representa de
la siguiente manera [Pressman 98]:

Nmero posible de distribuciones = [N !/

(K! * (N - K)!] * K!
(4.32)
La CR se emplea para valorar diferentes distribuciones propuestas de IGU
y la sensibilidad de una representacin en particular a los cambios en las
descripciones de tareas (por ejemplo, cambios en la secuencia y/o frecuencia de
transiciones) Es importante apuntar que la seleccin de un diseo de IGU puede
guiarse con mtricas tales como CR, pero el rbitro final debera ser la respuesta
del usuario basada en prototipos de IGU. Nielsen Levy [Pressman 98] informa;
que puede haber una posibilidad de xito si se prefiere la interfaz basndose
exclusivamente en la opinin del usuario ya que el rendimiento medio de tareas de
usuario y su satisfaccin con la IGU estn altamente relacionadas.

4.4 Mtricas de cdigo fuente

La teora de Halstead de la ciencia del software es probablemente la mejor

conocida y ms minuciosamente estudiada... medidas compuestas de la

95

complejidad (software) [Ejiogo 91]. La ciencia software propuso las primeras

leyes analticas para el software de computadora.
La ciencia del software asigna leyes cuantitativas al desarrollo del software
de computadora. La teora de Halstead se obtiene de un supuesto fundamental
[Pressman 98]: el cerebro humano sigue un conjunto de reglas ms rgido (en el
desarrollo de algoritmos) de lo que se imagina.... La ciencia del software usa un
conjunto de medidas primitivas que pueden obtenerse una vez que se ha
generado o estimado el cdigo despus de completar el diseo. Estas medidas se
listan a continuacin.
n1: el nmero de operadores diferentes que aparecen en el programa
n2: el nmero de operandos diferentes que aparecen en el programa
N1: el nmero total de veces que aparece el operador
N2: el nmero total de veces que aparece el operando
Halstead usa las medidas primitivas para desarrollar expresiones para la longitud
global del programa; volumen mnimo potencial para un algoritmo; el volumen real
(nmero de bits requeridos para especificar un programa); el nivel del programa
(una medida de la complejidad del software); nivel del lenguaje (una constante
para un lenguaje dado); y otras caractersticas tales como esfuerzo de desarrollo,
tiempo de desarrollo e incluso el nmero esperado de fallos en el software.
Halstead expone que la longitud N se puede estimar como:
N = n1 log2 n1 + n2 log2 n2

(4.33)

y el volumen de programa se puede definir como:

V = N log2 (n1 + n2)

(4.34)

96

Se debera tener en cuenta que V variar con el lenguaje de programacin

y representa el volumen de informacin
Tericamente debe existir un volumen mnimo para un algoritmo. Halstead
define una relacin de volumen L como la relacin volumen de la forma ms
compacta de un programa respecto al volumen real del programa. Por tanto L,
debe ser siempre menor de uno. En trminos de medidas primitivas, la relacin de
volumen se puede expresar como:
L = 2/n1*n2/N2

(4.35)

Halstead propuso que todos los lenguajes pueden categorizarse por nivel de
lenguaje, I, que variar segn los lenguajes. Halslead cre una teora que supona
que el nivel de lenguaje es constante para un lenguaje dado, pero otro trabajo
[Pressman 98] indica que el nivel de lenguaje es funcin tanto del lenguaje como
del programador. Los siguientes valores de nivel de lenguaje se muestran en la
tabla 4.2.

Lenguaje

Media/.I

Ingls prosaico

2.16

PL/1

1.53

ALGOL/68

2.12

FORTRAN

1.14

Ensamblador

0.88

Tabla 4.2 Valores de Nivel de Lenguaje [Pressman 98]

Parece que el nivel de lenguaje implica un nivel de abstraccin en la

especificacin

procedimental.

Los

lenguajes

de

alto

nivel

permiten

la

97

especificacin del cdigo a un nivel ms alto de abstraccin que el lenguaje

ensamblador (orientado a mquina).

4.5 Mtricas para pruebas

Aunque se ha escrito mucho sobre mtricas del software para pruebas, la

mayora de las mtricas propuestas se concentran en el proceso de pruebas, no
en las caractersticas tcnicas de las pruebas mismas. En general, los
responsables de las pruebas deben fiarse del anlisis, diseo y cdigo para que
les guen en el diseo y ejecucin los casos de prueba
Las mtricas basadas en la funcin pueden emplearse para predecir el
esfuerzo global de las pruebas Se pueden juntar y correlacionar varias
caractersticas a nivel de proyecto (p ej.: esfuerzo y tiempo las pruebas, errores
descubiertos, nmero de casos de prueba producidos) de proyectos anteriores con
el nmero de Pf producidos por un equipo del proyecto. El equipo puede despus
predecir los valores esperados de estas caractersticas del proyecto actual.
La mtrica bang puede proporcionar una indicacin del nmero de casos de
prueba necesarios para examinar las medidas primitivas. El nmero de primitivas
funcionales (Pfu), elementos de datos, (ED), objetos (0B), relaciones (RE),
estados (ES) y transiciones (TR) pueden emplearse para predecir el nmero y
tipos de pruebas de la caja negra y blanca del software Por ejemplo, el nmero de
pruebas asociadas con la interfaz hombre-mquina se puede estimar examinando
(1) el nmero de transiciones (TR) contenidas en la representacin estadotransicin del IHM y evaluando las pruebas requeridas para ejecutar cada
98

transicin, (2) el nmero de objetos de datos (0B) que se mueven a travs de la

interfaz y (3) el nmero de elementos de datos que se introducen o salen.
Las mtricas de diseo de alto nivel proporcionan informacin sobre
facilidad o dificultad asociada con la prueba de integracin y la necesidad de
software especializado de prueba (p. ej.: matrices y controladores) La complejidad
ciclomtica (una mtrica de diseo de componentes) se encuentra en el ncleo de
las pruebas de caminos bsicos, un mtodo de diseo de casos de prueba.
Adems, la complejidad ciclomtica puede usarse para elegir mdulos como
candidatos para pruebas ms profundas. Los mdulos con gran complejidad
ciclomtica tienen ms probabilidad de tendencia a errores que los mdulos con
menor complejidad ciclomtica
Por esta razn, el analista debera invertir un esfuerzo extra para descubrir
errores en el mdulo antes de integrarlo en un sistema. El esfuerzo de las pruebas
tambin se puede estimar usando mtricas obtenidas de medidas de Halstead.
Usando la definicin del volumen de un programa V, y nivel de programa, NP, el
esfuerzo de la ciencia del software, puede calcularse como;

NP=1 / [(n1 / 2) * (N2 / n2)]

e = V / NP

(4.36)
(4.37)

El porcentaje del esfuerzo global de pruebas a asignar un mdulo k para estimar

usando la siguiente relacin:
porcentaje de esfuerzo de pruebas (k) = e(k)/ e(i)

(4.38)

99

donde e(k) se calcula para el mdulo k usando las ecuaciones (4.35 y 4.36) y
suma en el denominador de la ecuacin (4.37) es la suma del esfuerzo de la
ciencia del software a lo largo de todos los mdulos del sistema.
A medida que se van haciendo las pruebas tres medidas diferentes
proporcionan una indicacin de la complexin de las pruebas. Una medida de la
amplitud de las pruebas proporciona una indicacin de cuantos (del nmero total
de ellos) se han probado. Esto proporciona una indicacin de la complexin del
plan de pruebas. La profundidad de las prueba es una medida del porcentaje de
los caminos bsicos independientes probados en relacin al nmero total de estos
caminos en el programa. Se puede calcular una estimacin razonablemente
exacta del nmero de caminos bsicos sumando la complejidad ciclomtica de
todos los mdulos del programa. Finalmente, a medida que se van haciendo las
pruebas y se recogen los datos de los errores, se pueden emplear los perfiles de
fallos para dar prioridad y categorizar los errores descubiertos. La prioridad indica
la severidad del problema. Las categoras de los fallos proporcionan una
descripcin de un error, de manera que se puedan llevar a cabo anlisis
estadsticos de errores.

4.6 Mtricas de mantenimiento

Se han propuesto mtricas diseadas explcitamente para actividades de

mantenimiento. El estndar IEEE 982.1-1988 [Pressman 98] sugiere un ndice de
madurez del software (IMS) que proporciona una indicacin de la estabilidad de un

100

producto de software (basada en los cambios que ocurren con cada versin del
producto) Se determina la siguiente informacin:
M r = nmero de mdulos en la versin actual
Fc = nmero de mdulos en la versin actual que se han cambiado
Fa = nmero de mdulos en la versin actual que se han aadido
Fd = nmero de mdulos de la versin anterior que se han borrado en la
versin actual
El ndice de madurez del software se calcula de la siguiente manera:

IMS = [Mr (Fa + Fc + Fd)]/ Mr

(4.39)

A medida que el IMS se aproxima a 1.0 el producto se empieza a estabilizar. El

IMS puede emplearse tambin como mtrica para la planificacin de las
actividades de mantenimiento del software. El tiempo medio para producir una
versin de un producto software puede correlacionarse con el IMS desarrollndose
modelos empricos para el mantenimiento.

101