MÉTRICAS TÉCNICAS DEL SOFTWARE
Adiferencia 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.
¿Qué es? Por su naturaleza, la ingeniería
es una disciplina cuantitativa. Los
ingenieros usan números para ayudarse
en el diseño y cálculo del proucto
a construir. Hasta hace poco
tiempo. los ingenieros del software disponían
de pocas refer
cucmfitativaquele
ayudan a los ingenieros del software
a profundizar en el diseño y construcción
de los productos que desarrollan. ¿crias tos
¿Quién lo hace? Los ingenieros del software
usan las métricas técnicas para
ayudarse en el desarrollo de software
de mayor calidad.
mr qué es igiporiante? Siempre habrd
elementos cualitativos para la creación
del software. El problema estriba en que
la valoración cualitativa puede no ser
suficiente. Un ingeniero del software
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.
323
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO
En el Capítulo 4 estudiábamos las métricas del software tal y como se aplican a nivel del proceso y del proyecto. En
este capítulo, nuestro punto de atención se desplaza a las medidas que se pueden emplear para valorar la calidad del producto
según se va desarrollando. Estas medidas de atributos internos del producto le proporcionan al desarrollador de software
una indicación en tiempo real de la eficacia del análisis, del diseño y de la estructura del código, la efectividad de los
casos de prueba, y la calidad global del software a construir.
Incluso los desarrolladores del software más hastiados
estarán de acuerdo en que un software de alta calidad es
una de las metas más importantes. Pero, ¿cómo definimos
la calidad? En el Capítulo 8 propusimos diferentes maneras
de interpretar la calidad del software e introdujimos
una definición que hacía hincapié en la concordancia con
los requisitos funcionales y de rendimiento explícitamente
establecidos, los estándares de desarrollo explícitamente
documentados y las características implícitas que se esperan
de todo software desarrollado profesionalmente.
No cabe duda de que la definición anterior podría
modificase o ampliarse y discutirse eternamente. Para
los propósitos de este libro, la definición sirve para hacer
énfasis en tres puntos importantes:
1.
2.
3.
Los requisitos del software son la base de las medidas
de la calidad. La falta de concordancia con los
requisitos es una falta de calidad'.
Unos estándares específicos definen un conjunto de
criterios de desarrollo que guían la manera en que se
hace la ingeniería del software. Si no se siguen los
criterios, habrá seguramente poca calidad.
Existe un conjunto de requisitos implícitos que a
menudo no se nombran (por ejemplo, facilidad de
mantenimiento). Si el software cumple con sus requisitos
explícitos pero falla en los implícitos, la calidad
del software no será fiable.
La calidad del software es una comple-ja mezcla de
factores que variarán a través de diferentes aplicaciones
y según los clientes que las pidan. En las siguientes
secciones, se identifican los factores de la calidad
del software y se describen las actividades humanas
necesarias para conseguirlos.
19.1.1. Factores de calidad de McCall
Los factores que afectan a a la calidad del software se
pueden categorizar en dos amplios grupos: (1) factores
que se pueden medir directamente (por ejemplo, defectos
por punto de función) y (2) factores que se pueden
medir sólo indirectamente (por ejemplo, facilidad de
uso o de mantenimiento). En todos los casos debe aparecer
la medición. Debemos comparar el software (documentos,
programas, datos) con una referencia y llegar
a una conclusión sobre la calidad.
% CLAVE
Es interesante onotar que los factores de calidad
de McCall son tan válidos hoy como cuando fueron
los primeros propuestos en los años 70. Además,
es razonable indicar que los factores que afectan
a la calidad del software no cambian.
McCall y sus colegas [MCC77] propusieron una Útil
clasificación de factores que afectan a la calidad del software.
Estos factores de calidad del software, mostrados
en la Figura 19.1, se concentran en tres aspectos importantes
de un producto software: sus características operativas,
su capacidad de cambios y su adaptabilidad a
nuevos entornos.
Facilidad de mantenimiento Portabilidad
Reusabilidad
lnteroperatividad
Flexibilidad
La relación entre los factores de calidad del software
y las métricas de la lista anterior se muestra en la Figura
19.2. Debería decirse que el peso que se asigna a cada
métrica depende de los productos y negocios locales.
componentes de programa.
19.1.2. FURPS
Los factores de calidad descritos por McCall y sus colegas
[MCC77] representan sólo una de las muchas listas
de comprobación sugeridas para la calidad del software.
Hewlett-Packard [GRA87] ha desarrollado un conjunto
de factores de calidad del software al que se le ha
19.2.2. Principios de medición
Antes de introducir una serie de métricas técnicas que
(1) ayuden a la evaluación de los modelos de análisis y
diseño, (2) proporcionen una indicación de la complejidad
de los diseños procedimentales y del código fuente,
y (3) ayuden en el diseño de pruebas más efectivas, es
importante entender los principios básicos de la medición.
Roche [ROC94] sugiere un proceso de medición
que se puede caracterizar por cinco actividades:
formulación: la obtención de medidas y métricas del
software apropiadas para la representación del software
en cuestión.
colección: el mecanismo empleado para acumular datos
necesarios para obtener las métricas formuladas.
análisis: el cálculo de las métricas y la aplicación de
herramientas matemáticas.
¿Cuáles son los pasos
para un proceso
de medición correcto?
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.
realimentación (feedback): recomendaciones obtenidas
de la interpretación de métricas técnicas transmitidas
al equipo que construye el software.
Los principios que se pueden asociar con la formulación
de las métricas técnicas son los siguientes [ROC94]:
Los objetivos de la medición deberían establecerse
antes de empezar la recogida de datos.
Todas las técnicas sobre métricas deberían definirse
sin ambigüedades.
¿Qué reglas debemos
observar cuando
establecemos medidas técnicas?
Las métricas deberían obtenerse basándose en una
teoría válida para el dominio de aplicación (por ejemplo,
las métricas para el diseño han de dibujarse sobre
conceptos y principios básicos de diseño y deberían
intentar proporcionar una indicación de la presencia
de un atributo que se considera beneficioso).
Hay que hacer las métricas a medida para acomodar
mejor los productos y procesos específicos [BAS84].
Aunque la formulación es un punto de arranque crítico,
la recogida y análisis son las actividades que dirigen
el proceso de medición. Roche [ROC94] sugiere
los siguientes principios para estas actividades:
Siempre que sea posible, la recogida de datos y el
análisis debe automatizarse.
Por encima de todo, intento obtener medidos técnicos
simples. No te obsesiones por lo métrico «perfecto»
porque no existe.
Se deberían aplicar técnicas estadísticas válidas para
establecer las relaciones entre los atributos internos
del producto y las características externas de la calidad
(por ejemplo, ¿está correlacionado el nivel de
complejidad arquitectónico con el número de defectos
descubiertos en la producción?).
Se deberían establecer una directrices de interpretación
y recomendaciones para todas las métricas.
Además de los principios apuntados anteriormente,
el éxito de una actividad de métrica está ligada al soporte
de gestión. Se deben considerar los fondos, la formación
y la promoción si se quiere establecer y mantener
un programa de medición técnica.
19.2.3. Características fundamentales de las
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:
métricas del software
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.
¿Cómo podemos valorar
la calidad de una métrica
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
del software propuesta?
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.
La métrica de complejidad más ampliamente usada
(y debatida) para el software es la complejidad ciclomática,
originalmente desarrollada por Thomas McCabe
[MCC76] y estudiando con detalle en la Sección 17.4.2.
La métrica de McCabe proporciona una medida cuantitativa
para probar la dificultad y una indicación de la fiabilidad
última. Estudios experimentales indican una fuerte
correlación entre la métrica de McCabe y el número de
errores que existen en el código fuente, así como el tiempo
requerido para encontrar y corregir dichos errores.
CLAVE
la complejidod ciclomático es solamente uno más
de los muchos métricus de camplejidad.
McCabe también defiende que la complejidad ciclomática
puede emplearse para proporcionar una indicación
cuantitativa del tamaño máximo del módulo. Recogiendo
datos de varios proyectos de programación reales, ha
averiguado que una complejidad ciclomática de 10 parece
ser el límite práctico superior para el tamaño de un
módulo. Cuando la complejidad ciclomática de los módulos
excedían ese valor, resultaba extremadamente difícil
probar adecuadamente el módulo. Vea en el Capítulo 17
un estudio sobre la complejidad ciclomática como guía
para el diseño de casos de prueba de caja blanca.
19.4.3. 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.
Para una representación específica (por ejemplo, un
diseño de una IGU específica), se pueden asignar costes
a cada secuencia de acciones de acuerdo con la
siguiente relación:
Costes = C [frecuencia de transición (k) x
donde k es la transición específica de una entidad de
representación a la siguiente cuando se realiza una tarea
específica. Esta suma se da con todas las transiciones
de una tarea en particular o conjunto de tareas requeridas
para conseguir alguna función de la aplicación. El
coste puede estar caracterizado en términos de tiempo,
retraso del proceso o cualquier otro valor razonable, tal
como la distancia que debe moverse el ratón entre entidades
de la representación.
La conveniencia de la representación se define como:
(19.8)
donde CR = 100 para una representación Óptima.
Para calcular la representación óptima de una IGU,
la superficie de la interfaz (el área de la pantalla) se divide
en una cuadrícula. Cada cuadro de la cuadncula representa
una posible posición de una entidad de la
representación. Para una cuadrícula con N posibles posix
coste de transición (k) ] (19.7)
CR = 100 x [(coste de la representación Óptima CR) /
/ (coste de la representación propuesta)]
335
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO
ciones y K diferentes entidades de representación para
colocar, el número posible de distribuciones se representa
de la siguiente manera [SEA93]:
número posible de distribuciones =
= [ N! / (K! x ( N - K ) ! ] x K!
A medida que crece el número de posiciones de representación,
el número de distribuciones posibles se hace
muy grande. Para encontrar la representación óptima
(menor coste). Sears [SEA931 propone un algoritmo de
búsqueda en árbol.
(1 9.9)
las métricas del diseno de interface son vólidas, pero
sobre todo, son absolutamente necesarios para asegura/
que a los usuarios finales les ograda la inteface y estén
sotisfechos con los interocciones requeridas.
La CR se emplea para valorar diferentes distribu- 1
ciones propuestas de IGU y la sensibilidad de una representación
en particular a los cambios en las descripciones
de tareas (por ejemplo, cambios en la secuencia y/o frecuencia
de transiciones). El diseñador de interfaces puede
emplear el cambio en la conveniencia de la
representación, ACR, como guía en la elección de la
mejor representación de IGU para una aplicación en
particular.
Es importante apuntar que la selección de un diseño
de IGU puede guiarse con métricas tales como CR, pero
el árbitro final debería ser la respuesta del usuario basada
en prototipos de IGU. Nielsen y Levy [NIE94] informan
que «existe una gran posibilidad de éxito si se elige
una interfaz basándose solamente en la opinión del usuario.
El rendimiento medio de tareas de usuario y su satisfacción
con la IGU están altamente relacionadas.»
is,s_MÉTarCAs_BEL._CbD1G.O_FU= . 'C
La teoría de Halstead de la ciencia del software [HAL77]
es «probablemente la mejor conocida y más minuciosamente
estudiada ... medidas compuestas de la complejidad
(software)» [CURSO]. La ciencia del software
propone las primeras «leyes» analíticas para el software
de computadora'.
La ciencia del software asigna leyes cuantitativas al
desarrollo del software de computadora, usando un conjunto
de medidas primitivas que pueden obtenerse una vez
que se ha generado o estimado el código después de completar
el diseño. Estas medidas se listan a continuación.
n,: el número de operadores diferentes que aparecen en el
n2: el número de operandos diferentes que aparecen en el
N,: el número total de veces que aparece el operador
N,: el número total de veces que aparece el operando
programa
programa
los operodores incluyen todos las consmcciones del flujo de
control, condiciones y operociones matemóticas. los operondos
ogrupan todos las variables y constantes del programo.
Halstead usa las medidas primitivas para desarrollar
expresiones para la longitud global del programa;
volumen mínimo potencial para un algoritmo; el volumen
real (número 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 características
tales como esfuerzo de desarrollo, tiempo de desarrollo
e incluso el número esperado de fallos en el
software.
Halstead expone que la longitud N se puede estimar
como:
N = n, log2 nl + n2 log2 n2 (19.10)
y el volumen de programa se puede definir como:
v = N log2 (n1 + n2) (19.11)
Se debería tener en cuenta que V variará con el lenguaje
de programación y representa el volumen de información
(en bits) necesarios para especificar un
programa.
Teóricamente, debe existir un volumen mínimo para
un algoritmo. Halstead define una relación de volumen
L como la relación de volumen de la forma más compacta
de un programa con respecto al volumen real del
programa. Por tanto, L debe ser siempre menor de uno.
En términos de medidas primitivas, la relación de volumen
se puede expresar como
L = 2/nl x n2/N2 (19.12)
9 Se debería resaltar que las deyes)) de Halstead han generado una
sustancial controversia y que no todo el mundo está de acuerdo con
que la teoría subyacente sea correcta. Sin embargo, se han realizado
verificaciones experimentales de las averiguaciones de Halstead para
varios lenguajes de programación (por ejemplo, [FEL89]).
336
CAPfTULO 19 MÉTRICAS TÉCNICAS DEL SOFTWARE
El trabajo de Halstead se presta a la verificación experimental
y de hecho se ha desarrollado una gran labor
de investigación en la ciencia del software. Un estudio
de este trabajo estaría fuera del alcance de este libro,
pero puede decirse que se ha llegado a un buen acuerdo
entre lo previsto analíticamente y los resultados experimentales.
Para más información, vea [ZUS90],
[FEN91] y [ZUS97].
Aunque se ha escrito mucho sobre las métricas del software
para pruebas (por ejemplo, [HET93]), la mayoría
de las métricas propuestas se concentran en el proceso
de prueba, no en las características técnicas de las pruebas
mismas. En general, los responsables de las pruebas
deben fiarse de las métricas de análisis, diseño y
código para que les guíen en el diseño y ejecución de
los casos de prueba.
% CLAVE
los métricos de lo prueba desembocan en las siguientes
categorias:(l) métricas que ayudan o determinar
el número de pruebas requeridos en los distintos niveles
de la prueba; (2)métricas poro cubrir la pruebo
de un componente dado.
Las métricas basadas en la función (Sección 19.3.1)
pueden emplearse para predecir el esfuerzo global de
las pruebas. Se pueden juntar y correlacionar varias
características a nivel de proyecto (por ejemplo, esfuerzo
y tiempo para las pruebas, errores descubiertos,
número de casos de prueba producidos) de proyectos
anteriores con el número de PF producidos por un equipo
del proyecto. El equipo puede después predecir los
valores «esperados» de estas características del proyecto
actual.
La métrica bang puede proporcionar una indicación
del número de casos de prueba necesarios para examinar
las medidas primitivas tratadas en la sección 19.3.2.
El número de primitivas funcionales (PFu), elementos
de datos (DE), objetos (OB), relaciones (RE), estados
(ES) y transiciones (TR) pueden emplearse para predecir
el número y tipos de prueba del software de caja
negra y de caja blanca. Por ejemplo, el número de pruebas
asociadas con la interfaz hombre-máquina se puede
estimar examinando: (1) el número de transiciones
(TR) contenidas en la representación estado-transición
del IHM y evaluando las pruebas requeridas para ejecutar
cada transición, (2) el número de objetos de datos
(OB) que se mueven a través de la interfaz y (3) el número
de elementos de datos que se introducen o salen.
Las métricas del diseño arquitectónico proporcionan
información sobre la facilidad o dificultad asociada con
la prueba de integración (Capítulo 18) y la necesidad
de software especializado de prueba (por ejemplo, matrices
y controladores). La complejidad ciclomática (una
métrica de diseño de componentes) se encuentra en el
núcleo de las pruebas de caminos básicos, un método
de diseño de casos de prueba presentado en el Capítulo
17. Además, la complejidad ciclomática puede usarse
para elegir módulos como candidatos para pruebas
más profundas (Capítulo 18). Los módulos con gran
complejidad ciclomática tienen más probabilidad de tendencia
a errores que los módulos con menor complejidad
ciclomática.
Por esta razón, el analista debería invertir un esfuerzo
extra para descubrir errores en el módulo antes de integrarlo
en un sistema. Es esfuerzo de las pruebas también
se puede estimar usando métricas obtenidas de medidas
de Halstead (Sección 19.5). Usando la definición del volumen
de un programa, V, y nivel de programa, NP, el
esfuerzo de la ciencia del software, e, puede calcularse
como:
NP = 1 / [(n1/2) x ( Nz/n,)l ( 1 9.1 3a)
e=V/NP ( 19.13b)
El porcentaje del esfuerzo global de pruebas a asignar
a un módulo k se puede estimar usando la siguiente
relación:
porcentaje de esfuerzo de pruebas (k) =
e(k>/Ce(i) (19.14)
donde e(k) se calcula para el módulo k usando las
ecuaciones (19.13) y la suma en el denominador de
la ecuación (19.14) es la suma del esfuerzo de la ciencia
del software a lo largo de todos los módulos del
sistema.
A medida que se van haciendo las pruebas, tres medidas
diferentes proporcionan una indicación de la compleción
de las pruebas. Una medida de la amplitud de
las pruebas proporciona una indicación de cuantos
requisitos (del número total de ellos) se han probado.
Esto proporciona una indicación de la compleción del
plan de pruebas. La profundidad de las pruebas es una
medida del porcentaje de los caminos básicos independientes
probados en relación al número total de estos
caminos en el programa. Se puede calcular una estimación
razonablemente exacta del número de caminos básicos
sumando la complejidad ciclomática de todos los
módulos 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 categorías
de los fallos proporcionan una descripción de un error,
de manera que se puedan llevar a cabo análisis estadísticos
de errores.
337
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRdCTlCO
Todas las métricas del software presentadas en este capítulo
pueden usarse para el desarrollo de nuevo software
y para el mantenimiento del existente. Sin embargo,
se han propuesto métricas diseñadas explícitamente para
actividades de mantenimiento.
El estándar EEE 982.1-1988 [EE94] sugiere un índice
de madurez del software (IMS) que proporciona una
indicación de la estabilidad de un producto software (basada
en los cambios que ocurren con cada versión del producto).
Se determina la siguiente información:
M,= número de módulos en la versión actual
F, = número de módulos en la versión actual que se han
cambiado
F, =número de módulos en la versión actual que se han aña-
Fd =número de módulos de la versión anterior que se han
El índice de madurez del software se calcula de la
IMS = [ MT- (Fa +F, +Fd)] /MT
A medida que el IMS se aproxima a 1 ,O el producto
se empieza a estabilizar. EL IMS puede emplearse también
como métrica para la planificación de las actividades
de mantenimiento del software. El tiempo medio
para producir una versión de un producto software puede
correlacionarse con el IMS desarrollándose modelos
empíricos para el mantenimiento.
dido
borrado en la versión actual
siguiente manera:
(19.15)
Las métricas del software proporcionan una manera
cuantitativa de valorar la calidad de los atributos internos
del producto, permitiendo por tanto al ingeniero
valorar la calidad antes de construir el producto. Las
métricas proporcionan la visión interna necesaria para
crear modelos efectivos de análisis y diseño, un código
sólido y pruebas minuciosas.
Para que sea útil en el contexto del mundo real, una
métrica del software debe ser simple y calculable, persuasiva,
consistente y objetiva. Debería ser independiente
del lenguaje de programación y proporcionar
una realimentación eficaz para el desarrollador de softw
are.
Las métricas del modelo de análisis se concentran
en la función, los datos y el comportamiento (los tres
componentes del modelo de análisis). El punto de función
y la métrica bang proporcionan medidas cuantitativas
para evaluar el modelo de análisis. Las métricas
del diseño consideran aspectos de alto nivel, del nivel
de componentes y de diseño de interfaz. Las métricas
de diseño de alto nivel consideran los aspectos arquitectónicos
y estructurales del modelo de diseño. Las
métricas de diseño de nivel de componentes proporcionan
una indicación de la calidad del módulo estableciendo
medidas indirectas de la cohesión,
acoplamiento y complejidad. Las métricas de diseño de
interfaz proporcionan una indicación de la conveniencia
de la representación de una IGU.
La ciencia del software proporciona un intrigante
conjunto de métricas a nivel de código fuente. Usando
el número de operadores y operandos presentes en el
código, la ciencia del software proporciona una variedad
de métricas que pueden usarse para valorar la calidad
del programa.
Se han propuesto pocas métricas técnicas para un
empleo directo en las pruebas y mantenimiento del software.
Sin embargo, se pueden emplear muchas otras
métricas técnicas para guiar el proceso de las pruebas
y como mecanismo para valorar la facilidad de mantenimiento
de un programa de computadora.
[BAS84] Basili, y V.R. D.M. Weiss, «A Methodology for
Collecting Valid Software Engineering Data», IEEE Trans.
Software Engineering, vol. SE-10, 1984, pp. 728-738.
[BIE94] Bieman, J.M., y L.M. Ott, «Measuring Functional
Cohesionn, IEEE Trans. Sof?ware Engineering, vol. 20,
n." 8, Agosto 1994, pp. 308-320.
Software Engineering Measuremenb, IEEE Trans. Software
Engineering, vol 22, n." 1, Enero 1996, pp. 68-85.
[CAR90] Card, D., y N. R. L. Glass, Measuring Software
Design Qualit-y, Prentice-Hall, 1990.
[BRI%] Btkd, L.C., S. Mo~~syc V~.R,. Baili, d%~~rty-Based
[CAV78] Cavano, J.P., y J.A. McCall, «A Framework for the
Measurement of Software Quality», Proc. ACM Sofmare
Qualig Assurance Wokshop, Noviembre 1978, pp. 133-
139.
[CHA89] Charette, R.N., Software Engineering Risk Analysis
and Management, McGraw-Hillnntertext, 1989.
[CURSO] Curtis, W., «Management and Experimentation in
Software Engineering», Proc. IEEE, vol. 68, n." 9, Septiembre
1980.
[DAV93] Davis, A., et al., ddentifying and Measuring Quality
in a Software Requirements Specification», Proc. lSt
338
CAPfTULO 19 MÉTRICAS TÉCNICAS DEL SOFTWARE
Intl. Software Metrics Symposium, IEEE, Baltimore, MD,
May 1993, pp. 141-152.
[DEM81] DeMillo, R.A., y R.J. Lipton, «Software Project
Forecastingn, Software Metrics (A.J. Perlis, F.G. Sayward
y M. Shaw, ed.), MIT Press, 1981, pp. 77-89.
[DEM82] DeMarco, T., Controlling Software Projects, Yourdon
Press, 1982.
[DHA95] Dhama, H., «Quantitative Models of Cohesion and
Coupling in Software», Journal of Systems and SofnYare,
vol. 29, n.' 4, Abril 1995.
[EII91] Ejiogu, L., Software Engineering with Formal Metrics,
QED Publishing, 1991.
[FEL89] Felican, L., y G. Zalateu, «Validating Halstead's
Theory for Pascal Programs», IEEE Trans. Software Engineering,
vol. 15, n.' 2, Diciembre 1989, pp. 1630-1632.
[FEN91] Fenton, N., Software Metrics, Chapman & Hall,
1991.
[FEN94] Fenton, N., «Software Measurement: A Necessary
Scientific Basis», IEEE Trans. Software Engineering, vol.
20, n.' 3, Marzo 1994, pp. 199-206.
[GRA87] Grady, R. B., y D.L. Caswell, Software Metrics: Establishing
a Company-Wide Program, Prentice-Hall, 1987.
[HA771 Halstead, M., Elements of Software Science, N."th
Holland, 1977.
[HEN81] Henry, S., y D. Kafura, «Software Structure Metrics
Based on information Flow», IEEE Trans. Software Engineering,
vol. SE-7, n.O5, Septiembre 1981, pp. 510-518.
[HET93] Hetzel, B., Making Software Measurement Work,
QED Publishing, 1993.
[IEE94] Software Engineering Standards, 1994, IEEE, 1994.
[KYB84] Kyburg, H.E., Theory and Measurement, Cambndge
University Press, 1984.
[MCC76] McCabe, T.J., «A Software Complexity Measure»,
IEEE Trans. Software Engineering, vol. 2, Diciembre 1976,
[MCC77] McCall, J., P. Richards, y G. Walters, «Factors in
Software Quality», 3 vols., NTIS AD-A049-014,015,055,
Noviembre 1977.
[MCC89] McCabe, T.J., y C.W. Butler, «Design Complexity
Measurement and Testinp, CACM, vol. 32, n.' 12,
Diciembre 1989, pp. 1415-1425.
[MCC94] McCabe, T.J., y A.H. Watson, «Software Complexityn,
Crosstalk, vol. 7, n.' 12, Diciembre 1994, pp. 5-9.
[NIE94] Nielsen, J., y J. Levy, «Measuring Usability: Prefereme
vs. Performance», CACM, vol. 37, n.' 4, Abril 1994,
[ROC94] Roche, J.M., «Software Metrics and Measurement
Principies», Software Engineering Notes, ACM, vol. 19,
n.' 1, Enero 1994, pp. 76-85.
[SEA931 Sears, A., «Layout Appropriateness: A Metric for Evaluating
User Interface Widget Layout», IEEE Trans. Software
Engineering, vol. 19, n.' 7, Julio 1993, pp. 707-719.
[USA871 Management Qualiry Insight, AFCSP 800-14 (U.S.
Air Force), 20 Enero, 1987.
[ZUS90] Zuse, H., Software Complexity: Measures and Methods,
DeGruyter, Nueva York, 1990.
[ZUS97] Zuse, H., A Framework of Software Measurement,
DeGruyter, Nueva York, 1997.
pp. 308-320.
pp. 76-85.
19.1. La teoría de la medición es un tema avanzado que tiene
una gran influencia en las métricas del software. Mediante
[FEN91], [ZUS90] y [KYBS4] u otras fuentes, escriba una
pequeña redacción que recoja los principales principios de la
teoría de la medición. Proyecto individual: Prepare una conferencia
sobre el tema y expóngala en clase.
19.2. Los factores de calidad de McCall se desarrollaron
durante los años setenta. Casi todos los aspectos de la informática
han cambiado dramáticamente desde que se desarrollaron,
y sin embargo, los factores de McCall todavía se aplican
en el software moderno. ¿Puede sacar alguna conclusión basada
en este hecho?
19.3. Por qué no se puede desarrollar una única métrica que
lo abarque todo para la complejidad o calidad de un programa?
19.4. Revise el modelo de análisis que desarrolló como parte
del Problema 12.13. Mediante las directrices de la Sección
19.3.1., desarrolle una estimación del número de puntos función
asociados con SSRB.
19.5. Revise el modelo de análisis que desarrolló como parte
del Problema 12.13. Mediante las directrices de la Sección
19.3.2., desarrolle cuentas primitivas para la métrica bang. ¿El
sistema SSRB es de dominio de función o de datos?
19.6. Calcule el valor de la métrica bang usando las medidas
que desarrolló en el Problema 19.5.
19.7. Cree un modelo de diseño completo para un sistema
propuesto por su profesor. Calcule la complejidad estructural
y de datos usando las métricas descritas en la Sección 19.4.1.
Calcule también las métricas de Henry-Kafura y de morfología
para el modelo de diseño.
19.8. Un sistema de información grande tiene 1.140 módulos.
Hay 96 módulos que realizan funciones de control y coordinación,
y 490 cuya función depende de un proceso anterior.
El sistema procesa aproximadamente 220 objetos de datos con
una media de tres atributos por objeto de datos. Hay 140 elementos
de la base de datos Únicos y 90 segmentos de base de
datos diferentes. 600 módulos tienen un solo punto de entrada
y de salida. Calcule el ICDE del sistema.
19.9. Investigue el trabajo de Bieman y Ott [BiE94] y desarrolle
un ejemplo completo que ilustre el cálculo de su métrica de
cohesión. Asegúrese de indicar cómo se determinan las porciones
de datos, señales de datos y señales de unión y superunión.
339
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO
19.10. Seleccione cinco módulos existentes de un programa
de computadora. Mediante la métrica de Dhama descrita
en la Sección 19.4.2., calcule el valor de acoplamiento de
cada módulo.
19.1 1. Desarrolle una herramienta de software que calcule
la complejidad ciclomática de un módulo de lenguaje de programación.
Elija el lenguaje.
19.12. Desarrolle una herramienta de software que calcule
la conveniencia de la representación de una IGU. Esa herramienta
debería permitirle asignar el coste de transición entre
las entidades de la representación. (Nota: fíjese en que el tamaño
potencial del número de las altemativas de representación
crece mucho a medida que aumenta el número de posibles
posiciones de cuadrícula.)
19.13. Desarrolle una pequeña herramienta de software que
realice un análisis Halstead de un código fuente de un lenguaje
de programación a su elección.
19.14. Haga una investigación y escriba un documento sobre
la relación entre las métricas de la calidad del software de Halstead
y la de McCabe (con respecto a la cuenta de errores). ¿Son
convincentes los datos? Recomiende unas directrices para la
aplicación de estas métricas.
19.15. Investigue documentos recientes en busca de métricas
específicamente diseñadas para el diseño de casos de prueba.
Exponga los resultados en clase.
19.16. Un sistema heredado tiene 940 módulos. La última
versión requiere el cambio de 90 de estos módulos. Además,
se añaden 40 módulos nuevos y se quitaron 12 módulos antiguos.
Calcule el índice de madurez del software del sistema.
Sorprendentemente hay un gran número de libros dedicados
a las métricas del software, aunque la mayoría están enfocados
a métricas de proceso y proyecto excluyendo las métricas
técnicas. Zuse [ZUS97] ha escrito el más completo tratado
de métricas técnicas publicado hasta la fecha.
Los libros de Card y Glass [CAR90], Zuse [ZUS90], Fenton
[FEN91], Ejiogu [EJI91J, Moeller y Paulish (Métricas del
Software, Chapman & Hall, 1993) y Hetzel [HET93] son referencias
sobre las métricas técnicas en detalle. Además, merece
la pena examinar los siguientes libros:
Conte, S.D., H.E. Dunsmore, y V.Y. Shen, Software Engineering Metrics
and Models, Benjamin/Cummings, 1984.
Fenton, N.E., y S.L. Pfleeger, Software Metrics: A Rigorous and Practical
Approach, 2.d ed., PWS hblishing Co., 1998.
Grady, R.B. Practica1 Softwure Metrics for Project Mungement and Process
lmprovement, Prentice Hall, 1992.
Perlis, A., et al., Software Metrics: An Analysis and Evuluution,
MIT Press, 1981.
Sheppard, M., Sofhyare Engineering Metrics, McGraw-HiU, 1992.
La teoría de la medición del software la presentan Denvir,
Herman, y Whitty en una colección de documentos
(Proceedings of the International BCS-FACS Workshop:
Formal Aspects of Measurernent, Springer-Verlag, 1992).
Shepperd (Foundations of Software Measurement, Prentice
Hall, 1996) también tratan la teoría de la medición en
detalle.
Una relación de docenas de usos de las métricas del software
están presentadas en [IEE94]. En general, una discusión
de cada métrica ha sido reducida a lo esencial «las
primitivas» (medidas) requeridas para calcular las métricas
y las adecuadas relaciones a efectos de los cálculos. Un apéndice
del libro suministra más información y referencias sobre
el tema.