Metricas del producto para el Software

Sistemas de Información II – Año 2014

Medidas del producto para el Software
Walter C. Tejerina1
(1)Sistemas de Información II, Facultad de Ingeniería, Universidad Nacional de Jujuy
walterct87@gmail.com

RESUMEN: En los tiempos actuales, gracias a los avances de la Informática, el software se utiliza en casi
todos los campos de la actividad humana: la industria, el comercio, las finanzas, el gobierno, la salud, la
educación, las artes. Existe una creciente preocupación por lograr que los productos software cumplan
con ciertos criterios de calidad. Para ello, se avanza en la definición e implementación de estándares que
fijan los atributos deseables del software de calidad, a la vez que surgen modelos y metodologías para la
evaluación de la calidad. Para lograr este objetivo, los ingenieros de software deben emplear métodos
efectivos junto con herramientas modernas dentro del contexto de un proceso maduro de desarrollo del
software.

1



INTRODUCCION

Las métricas del software permiten medir de
forma cuantitativa la calidad de sus atributos
internos del producto, esto permite al ingeniero
evaluar la calidad antes de su construcción. Es
importante establecer ¿qué es la calidad del
software?, ¿Quién lo hace?, ¿Por qué es
importante?, ¿Cuáles son los pasos? Para
determinar la calidad, ¿Cuál es el producto
obtenido?, ¿Cómo estar seguro de hacerlo
correctamente?. Todas estas interrogantes se
determinarán a lo largo del desarrollo del presente
informe. Aspectos a considerar tales como hacer
una distinción entre medida, métrica e indicador,
qué factores de calidad se toman.
1.1 Calidad del software
Es el cumplimiento de los requisitos de
funcionalidad y desempeño 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.
La calidad del software es una compleja mezcla
de factores que variarán a través de diferentes
aplicaciones y según los clientes que las pidan
[1].
Con esta definición se destacan tres puntos
importantes:





Los requisitos del software son la base
de las medidas de calidad. La falta de
concordancia con estos requisitos es una
falta de calidad.
Los estándares especificados definen un
conjunto de criterios de desarrollo que
guían la ingeniería del software. Si no se
siguen los criterios, el resultado será,
casi seguramente, la falta de calidad.
A menudo se soslaya un conjunto de
requisitos implícitos. Si el software
cumple con sus requisitos explícitos pero
no con los implícitos, la calidad del
software estará en duda.

.
1.1.1 Factores de Calidad de McCall
Estos factores se dividen en dos grupos muy
importantes:



Los que se miden directamente.
Los que solo se miden indirectamente.

McCall, Richards y Walters propusieron unos
factores los cuales se concentran en tres aspectos
importantes de un producto de software: sus
características operativas, su capacidad para
experimentar cambios y su capacidad para
adaptarse a nuevos entornos. En la siguiente
figura se observan los factores que afectan la
calidad del software.


2

Figura 1. Factores de calidad de McCall
1.1.2
9126

Factores de calidad del estándar ISO

Se desarrolló un intento por identificar los
atributos de calidad para el software de
computadora. El estándar identifica 6 puntos:
 Funcionalidad
 Confiabilidad
 Facilidad de uso
 Eficiencia
 Facilidad de mantenimiento
 Portabilidad

MARCO CONCEPTUAL PARA
METRICAS DEL PRODUCTO

El peligro de tratar de encontrar medidas que
caractericen tantos atributos diferentes es que
inevitablemente las medidas tienen que satisfacer
objetivos que entran en conflicto entre sí. Esto se
opone a la teoría de que cada medición debe ser
representativa. Muchas personas argumentan que
la medición del producto realizada durante las
primeras etapas del proceso de software
proporciona a los ingenieros un mecanismo
consistente y objetivo para evaluar la calidad.
2.1 Principios de medición
Roche sugiere un proceso de medición al que
caracterizan cinco actividades:





1.2 Métricas, medición e indicadores
La medición es un elemento clave en cualquier
proceso de ingeniería. Las medidas se emplean
para comprender mejor los atributos de los
modelos que se crean y evaluar la calidad de los
productos de la ingeniería. Por las características
inherentes al software, sus medidas y métricas
son indirectas y, por lo tanto, expuestas al debate.
Una medida proporciona una indicación
cuantitativa de la extensión, cantidad, dimensión
capacidad o tamaño de algún atributo de un
producto o proceso [2].
Una métrica es una evaluación del grado en que
un sistema, componente o proceso posee un
atributo determinado (extensión, cantidad,
dimensiones, capacidad o tamaño).
Un ingeniero de software recopila medidas y
desarrolla métricas para obtener los indicadores.
Un indicador es una métrica o combinación de
métricas que proporcionan conocimientos. Estos
conocimientos le permiten al jefe de proyecto o a
los ingenieros de software ajustar el proceso, el
proyecto o el producto para que las cosas
mejoren.

LAS




Formulación. Derivación de medidas y
métricas
apropiadas
para
la
representación del software que se
considera.
Recolección. Mecanismo con que se
acumulan los datos necesarios para
derivar las métricas formuladas.
Análisis. Cálculo de las métricas y la
aplicación de herramientas matemáticas.
Interpretación. Evaluación de las
métricas en un esfuerzo por conocer
mejor la calidad de la representación.
Retroalimentación.
Recomendaciones
derivadas de la interpretación de las
métricas del producto transmitidas al
equipo del software.

Existen principios que son representativos de
muchos otros que podrían proponerse para
caracterizar y validar las métricas:





Una métrica debe tener propiedades
matemáticas deseables.
Cuando una métrica representa una
característica de software que aumenta
cuando se presentan rasgos positivos o
que disminuye al encontrar rasgos
indeseables, el valor de la métrica debe
aumentar o disminuir en el mismo
sentido.
Cada
métrica
debe
validarse
empíricamente en una amplia variedad
de contextos antes de publicarse o
aplicarse a la toma de decisiones.


2.2 Métricas del modelo de análisis
En esta fase se obtendrán los requisitos y se
establecerá el fundamento para el diseño. Y es
por eso que se desea una visión interna a la
calidad del modelo de análisis. Sin embargo hay
pocas métricas de análisis y especificación, se
sabe que es posible adaptar métricas obtenidas
para la aplicación de un proyecto, en donde las
métricas examinan el modelo de análisis con el
fin de predecir el tamaño del sistema resultante,
en donde resulte probable que el tamaño y la
complejidad del diseño estén directamente
relacionados. Es por eso que se verán en las
siguientes secciones las métricas de puntos de
función y de calidad de especificación [3].
2.2.1 Puntos de función
El Punto Función es “un método para medir el
tamaño y la complejidad software basándose en la
cantidad de funcionalidad”, o una herramienta
para “medir el tamaño funcional del software”.
Permite a los clientes disponer de un método
común para estimar el trabajo de sus proveedores.
Normalmente, además el método del cálculo del
punto función es conocido por el proveedor. Y en
cualquier caso se evitan las estimaciones “ad hoc”
para cada desarrollo / proveedor. Se consigue así
tener unas “tablas estándar” de estimación de los
trabajos, y métricas derivadas, como el número de
horas de desarrolladores por Puntos Función,
Número total de horas por Puntos Función, Coste
por Puntos Función, etc.
Pero una de las dificultades de implantar el punto
función es que hay muchos métodos, y
“familias”, para calcular los Puntos Función. Y
que algunos son más ligeros y otros enormemente
más pesados.
Con el objetivo de hacer más llevadera la tarea de
seleccionar un método para el cálculo del punto
función, dos de los métodos más prácticos y
ligeros para implantar la estimación con punto
función son los siguientes:
 FP Lite: Este método es una derivación
del método el IFPUG (International
Function Point Users Group), ya que el
método tradicional del IFPUG es
bastante complejo de implantar. El FP
Lite lo que hace es reducir y simplificar
las fases del IFPUG.
 Puntos Casos de Uso (Use Case Points):
Se basa en casos de uso. Y es de gran
aplicabilidad al mundo real. El método
es del 93, y de manera similar al FP Lite,
simplifica y reduce considerablemente
los pasos necesarios para estimar.

Ambos métodos permiten definir un conjunto de
tablas estándar, por las que todos los proveedores
deben guiarse a la hora de realizar una
estimación. El FP Lite trabaja con requisitos más
tradicionales, y el Puntos Casos de Uso con casos
de uso como entrada. Ambos son ligeros, y
existen experiencias reales de su implantación
[4].
2.2.2 Métricas de la calidad de la especificación
Propuesta por Pressman, mide la calidad del
análisis y de los requisitos capturados. A pesar de
medir factores cualitativos, propone métricas
como por ejemplo el número de requisitos donde
los revisores han interpretado lo mismo.
Al medir características de la especificación es
posible obtener un conocimiento cuantitativo de
la especificidad y el grado de avance proponen
una lista de características que pueden emplearse
para valorar la calidad del modelo de análisis y la
correspondiente especificación de requisitos:
especificidad
(ausencia
de
ambigüedad),
compleción, corrección, comprensión, capacidad
de verificación, consistencia interna y externa,
capacidad de logro, concisión, trazabilidad,
capacidad de modificación, exactitud y capacidad
de reutilización. Además, los autores apuntan que
las especificaciones de alta calidad deben estar
almacenadas electrónicamente, ser ejecutables o
al menos interpretables, anotadas por importancia
y estabilidad relativas, con su versión
correspondiente, organizadas, con referencias
cruzadas y especificadas al nivel correcto de
detalle.

2.3 Métricas del modelo de diseño
Las métricas de diseño para el software, como
otras métricas del software, no son perfectas.
Continúa el debate sobre la eficacia y cómo
deberían aplicarse. Muchos expertos argumentan
que se necesita más experimentación hasta que se
puedan emplear las métricas de diseño. Y sin
embargo, el diseño sin medición es una
alternativa inaceptable.
2.3.1 Métricas del diseño arquitectónico
Consideradas métricas de caja negra ya que
no requieren ningún conocimiento del
funcionamiento interno de un componente de
software en particular. Se centran en la
arquitectura del programa y la eficiencia de los
módulos. Son de caja negra en el sentido que no


requieren ningún conocimiento del trabajo interno
de un módulo en particular del sistema.
Card y Glass definen tres medidas de la
complejidad del diseño del software: complejidad
estructural, complejidad de datos y complejidad
del sistema.
La complejidad de datos D(i) proporciona una
indicación de la complejidad en la interfaz interna
de un módulo i.
La complejidad del sistema C(i) se define como
la suma de las complejidades estructural y de
datos.

2.3.2
Métricas del diseño a nivel de
componentes
Las métricas de diseño a nivel de
componentes se concentran en las características
internas de los componentes del software e
incluyen medidas de las “3Cs” -la cohesión,
acoplamiento y complejidad del módulo-.
Estas tres medidas pueden ayudar al desarrollador
de software a juzgar la calidad de un diseño a
nivel de los componentes.
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 [2].
2.3.2.1 Métricas de cohesión
Bieman y Ott definen una colección de
métricas que proporcionan una indicación de la
cohesión de un módulo. Las métricas se definen
con cinco conceptos y medidas:
Porción de datos: es un recorrido hacia atrás por
un módulo que busca valores de datos que afectan
el estado del módulo cuando comienza el
recorrido.
Muestras de datos: las variables detenidas para
un módulo se definen como muestras de datos
para el módulo.
Señales de unión: este conjunto de muestras de
datos cae en una o más porciones de datos.
Señales de superunión: estas muestras de daos
son comunes a todas las porciones de datos de un
módulo.
Capacidad de unión: la capacidad de unión
relativa de una señal de unión es directamente
proporcional al número de porciones de datos que
une.

Cohesión funcional fuerte: un procedimiento sin
señales de superunión tiene 0 (cero) cohesión
funcional fuerte, es decir que no hay muestras de
datos que contribuyen a todas las salidas.
Cohesión funcional débil: un procedimiento sin
señales de unión tiene 0 (cero) cohesión funcional
débil, es decir que no hay muestras de datos que
contribuyen a todas las salidas.
Adhesividad: un procedimiento sin señales de
unión tiene 0 (cero) adhesividad, es decir que no
hay muestras de datos que contribuyen a más de
una salida.
2.3.2.2 Métricas de acoplamiento

El acoplamiento de módulo proporciona
una indicación de la conectividad de un módulo
con otros módulos, datos globales y el entorno
exterior. Se ha propuesto una métrica para el
acoplamiento del módulo 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 módulo se definen en
términos de cada uno de los tres tipos de
acoplamiento apuntados anteriormente.
Para el acoplamiento de flujo de datos y de
control:
Di = número de parámetros de datos de entrada
Ci = número de parámetros de control de entrada
Do = número de parámetros de datos de salida
Co = número de parámetros de control de salida

Para el acoplamiento global:
Gd = número de variables globales usadas como datos
Gc = número de variables globales usadas como control

Para el acoplamiento de entorno:
W = número de módulos llamados (expansión)
R = número de módulos que llaman al módulo en
cuestión

Usando estas medidas, se define un indicador
de acoplamiento de módulo M de la siguiente
manera:
M=K/m

Donde
K

= L es una constante de proporcionalidad y

m = Di + a x Ci + Do + b x Co + Gd + c x Gc + W + R


Los valores de k, a, b y c deben derivarse
empíricamente. A medida que M aumenta, el
acoplamiento general del módulo disminuye.
Para que la métrica suba a medida que aumenta el
grado de acoplamiento se define una métrica
revisada:
C=1-M

2.3.3 Métricas del diseño orientado a objetos
Las métricas orientadas a objetos se centran
en métricas que se pueden aplicar a las
características de encapsulamiento, ocultamiento
de información, herencia y técnicas de
abstracción de objetos que hagan única a esa
clase.
Se proponen una familia de medidas para
desarrollos orientados a objetos:







Métodos ponderados por clase (MPC):
Tamaño y complejidad
Profundidad árbol de herencia (PAH):
Tamaño
Número de descendientes (NDD):
Tamaño, acoplamiento y cohesión
Acoplamiento entre clases (ACO):
Acoplamiento
Respuesta para una clase (RPC):
Comunicación y complejidad
Carencia de cohesión en los métodos
(CCM): Cohesión interna.

Estas métricas, en líneas generales, permiten
averiguar cuán bien están definidas las clases y el
sistema, lo cual tiene un impacto directo en la
mantenibilidad del mismo, tanto por la
comprensión de lo desarrollado como por la
dificultad de modificarlo con éxito.

2.3.4 Métricas orientadas a clases
La clase es la unidad fundamental de un
sistema orientado a objetos. Por tanto las medidas
y metricas de una clase individual seran
invaluables para un ingeniero de software que
debe valorar la calidad de diseño. La clase es el
predecesor de las subclases que heredan sus
atributos y operaciones
Se basa en la idea de que el número de métodos y
su complejidad es un indicador razonable de la
cantidad de esfuerzo necesaria para implementar
y comprobar una clase.
Mide la complejidad de una clase asignándole
una complejidad a cada método. Resulta ambigua

dado que no ofrece ninguna definición asociada a
la complejidad.

2.4 Métricas del modelo del código fuente
La teoría de Halstead de la ciencia del
software es «probablemente la mejor conocida y
más minuciosamente estudiada de las medidas
compuestas de la complejidad (software). 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.

Figura 2. Medidas de Diseño
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 = N1 + N2.

Es una simple medida del tamaño de un
programa. Cuanto más grande sea el tamaño de
N, mayor será la dificultad para comprender el
programa y mayor el esfuerzo para mantenerlo.
El volumen de programa se puede definir como
un “peso extra” al número de operadores y
operandos únicos.
Por ejemplo, si dos programas tienen la misma
longitud N pero uno tiene mayor número de
operadores y operandos únicos, que naturalmente


lo hacen más difícil de entender y mantener, este
tendrá un mayor volumen
Se calcula como

El índice de madurez del software se calcula de la
siguiente manera:

V = N x log2(n) donde n = n1 + n2

IMS = [Mt – (Fa + Fc + Fd)] / Mt]
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 la métrica de Halstead también se define el
esfuerzo, esta ofrece una medida del trabajo
requerido para desarrollar un programa.
Desde el punto de vista del mantenimiento, el
esfuerzo se puede interpretar como una medida
del trabajo requerido para comprender un
software ya desarrollado. Se calcula como

Donde:
Mt es el número de módulos en la versión actual
Fa es el número de módulos añadidos a la versión

actual
Fc es el número de módulos cambiados en la
versión actual
Fd es el número de módulos de la versión anterior
que se eliminaron en la actual
A medida que el IMS se acerca a 1,0 el producto
comienza a estabilizarse

3

CONCLUSION

E = V/L

Donde L (lenguaje) indica si se está utilizando un
lenguaje de alto o bajo nivel. Aumenta
proporcionalmente con el volumen, pero decrece
con la utilización de lenguajes de alto nivel.
Por ejemplo, una simple llamada a un
procedimiento podría tener un valor L de
1; en COBOL podría tener 0,1 y el ensamblador
podría tener un L de 0,01[5].

2.5 Métricas para mantenimiento
Todas las métricas del software 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 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:

Figura 3. Medidas para índice de madurez

A lo largo de nuestra investigación vimos
como
las
métricas
proporcionan
los
conocimientos necesarios para crear modelos
efectivos de análisis y diseño, un código sólido y
pruebas exhaustivas. Estas métricas se enfocan al
proceso de software en varios aspectos tales como
métricas del producto, para el modelo de análisis,
para el modelo de diseño, para el código fuente,
para pruebas y para mantenimiento, las cuales
permiten el control de calidad en cada uno de
estos procesos.
Otras como 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
proporciona 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.


4

BIBLIOGRAFIA

[1] Calidad en el Software. Mayela Delgado.
Marzo. Disponible en:
http://www.entornoempresarial.com/articulo/106/
calidad-en-el-software-i
Fecha: 13 de febrero de 2014
[2] Pressman, R. S. (2006) “Ingeniería de
Software. Un enfoque práctico”. MCGRAWHILL. México. 2006
[3] Métricas en el desarrollo del Software
Heidi González Doria.
Disponible en:
http://catarina.udlap.mx/u_dl_a/tales/documentos/
lis/gonzalez_d_h/capitulo4.pdf

[4]Dos métodos prácticos para implantar la
estimación con puntos de función. Javier Garzas.
Disponible en:
http://www.javiergarzas.com/2012/03/puntosfuncion.html

[5]Métricas del código fuente Ingeniería del
software II. Yajaira Pallares Echavez.
Disponible en:
http://ingsoftware3.blogspot.com.ar/2013/01/metricas-delcodigo-fuente.html

Metricas del producto para el Software

Más contenido relacionado

La actualidad más candente (20)

Destacado (12)

Similar a Metricas del producto para el Software (20)

Último (20)

Metricas del producto para el Software