INGENIERA DEL SOFTWARE

UN ENFOQUE PRCTICO
Quinta edicin
CAPTULO
PROCESO DE SOFTWARE
4 Y MTRICAS DE PROYECTOS
A medicin es fundamental para cualquier disciplina de ingeniera, y la ingeniera del soft-
ware no es una excepcin. La medicin nos permite tener una visin ms profunda propor-
L cionando un mecanismo para la evaluacin objetiva. Lord Kelvin en una ocasin dijo:
Cuando pueda medir lo que est diciendo y expresarlo con nmeros, ya conoce algo sobre
ello; cuando no pueda medir, cuando no pueda expresar lo que dice con nmeros, su conoci-
miento es precario y deficiente: puede ser el comienzo del conocimiento, pero en sus pensa-
mientos, apenas est avanzando hacia el escenario de la ciencia.
La comunidad de la ingeniera del software ha comenzado finalmente a tomarse en serio las
palabras de Lord Kelvin. Pero no sin frustraciones y s con gran controversia.
Las mtricas del software se refieren a un amplio elenco de mediciones para el software de
computadora. La medicin se puede aplicar al proceso del software con el intento de mejorar-
lo sobre una base continua. Se puede utilizar en el proyecto del software para ayudar en la esti-
macin, el control de calidad, la evaluacin de productividad y el control de proyectos.
Finalmente, el ingeniero de software puede utilizar la medicin para ayudar a evaluar la cali-
dad de los resultados de trabajos tcnicos y para ayudar en la toma de decisiones tctica a medi-
da que el proyecto evoluciona.
Qu es? El proceso del software y l as
mtricas del producto son una medida
cuantitativa que permite a la gente del
software tener una visin profunda de
la eficacia del proceso del software y de
los proyectos que dirigen utilizando el
proceso como un marco de trabajo. Se
renen los datos bsicos de calidad y
productividad. Estos datos son entonces
analizados, comparados con promedios
anteriores, y evaluados para determi-
nar las mejoras en la calidad y produc-
tividad. Las mtricas son tambin
utilizadas para sealar reas con pro-
blemas de manera que se puedan desa-
rrollar los remedios y mejorar el proceso
del software.
;Quin lo hace? Las mtricas del soft-
ware son analizadas y evaluadas por
los administradores del software. A
menudo las medidas son reunidas por
los ingenieros del software.
;Por qu es imporiante? Si no mides,
slo podrs juzgar basndote en una
evaluacin subjetiva. Mediante la medi-
cin, se pueden sealar las tendencias
(buenas o malas), realizar mejores esti-
maciones, llevar a cabo una verdadera
mejora sobre el tiempo.
Cules son los pasos? Comenzar defi-
niendo un conjunto limitado de medi-
das de procesos, proyectos y productos
que sean fciles de recoger. Estas medi-
das son a menudo normalizadas utili-
zando mtricas orientadas al tamao o
a la funcin. El resultado se analiza y
se compara con promedios anteriores
de proyectos similares realizados con
l a organizacin. Se evalan las ten-
dencias y se generan las conclusiones.
Cul es el producto obtenido? Es un
conjunto de mtricas del software que
proporcionan una visin profunda del
proceso y de la comprensin del pro-
yecto.
Cmo puedo estar seguro de que lo
he hecho correctamente? Aplican-
do un plan de medicin sencillo pero
consistente, que nunca utilizaremos
para evaluar, premiar o castigar el ren-
dimiento individual.
Dentro del contexto de la gestin de proyectos de software, en primer lugar existe una gran pre-
ocupacin por las mtricas de productividad y de calidad -medidas de salida (finalizacin) del
desarrollo del software, basadas en el esfuerzo y tiempo empleados, y medidas de la utilidad del
producto obtenid+.
Park, Goethert y Florac [PAR961 tratan en su gua de la medicin del software las razones por
las que medimos:
Hay cuatro razones para medir los procesos del software, los productos y los recursos:
caracterizar
evaluar
predecir
mejorar
53
INGENIERIA DEL SOFTWARE. UN ENFOQUE PRACTICO
Caracterizamos para comprender mejor los procesos, los productos, los recursos y los entomos y para establecer
las lneas base para las comparaciones con evaluaciones futuras.
Evaluamos para determinar el estado con respecto al diseo. Las medidas utilizadas son los sensores que nos per-
miten conocer cundo nuestros proyectos y nuestros procesos estn perdiendo la pista, de modo que podamos poner-
los bajo control. Tambin evaluamos para valorar la consecucin de los objetivos de calidad y para evaluar el impacto
de la tecnologa y las mejoras del proceso en los productos y procesos.
Predecimos para poder planificar. Realizar mediciones para la prediccin implica aumentar la comprensin de las
relaciones entre los procesos y los productos y la construccin de modelos de estas relaciones, por lo que los valores
que observamos para algunos atributos pueden ser utilizados para predecir otros. Hacemos esto porque queremos esta-
blecer objetivos alcanzables para el coste, planificacin, y calidad - de manera que se puedan aplicar los recursos apro-
piados-. Las medidas de prediccin tambin son la base para la extrapolacin de tendencias, con lo que la estimacin
para el coste, tiempo y calidad se puede actualizar basndose en la evidencia actual. Las proyecciones y las estima-
ciones basadas en datos histricos tambin nos ayudan a analizar riesgos y a realizar intercambios diseo/coste.
Medimos para mejorar cuando recogemos la informacin cuantitativa que nos ayuda a identificar obstculos, pro-
blemas de raz, ineficiencias y otras oportunidades para mejorar la calidad del producto y el rendimiento del proceso.
Aunque los trminos medida, medicin y mtricas se
utilizan a menudo indistintamente, es importante des-
tacar las diferencias sutiles entre ellos. Como los tr-
minos medida y medicin se pueden utilizar
como un nombre o como un verbo, las definiciones
de estos trminos se pueden confundir. Dentro del con-
texto de la ingeniera del software, una medida pro-
porciona una indicacin cuantitativa de la extensin,
cantidad, dimensiones, capacidad o tamao de algu-
nos atributos de un proceso o producto. La medicin
es el acto de determinar una medida. El ZEEE Stan-
dard Glossary of Software Engineering Terms [IEEE93]
define mtrica como una medida cuantitativa del gra-
do en que un sistema, componente o proceso posee
un atributo dado.
Cuando, simplemente, se ha recopilado un solo
aspecto de los datos (por ejemplo: el nmero de erro-
res descubiertos en la revisin de un mdulo), se ha
establecido una medida. La medicin aparece como
resultado de la recopilacin de uno o varios aspectos
de los datos (por ejemplo: se investiga un nmero de
revisiones de mdulos para recopilar medidas del
nmero de errores encontrados durante cada revisin).
Una mtrica del software relata de alguna forma las
medidas individuales sobre algn aspecto (por ejem-
plo: el nmero medio de errores encontrados por revi-
sin o el nmero medio de errores encontrados por
persona y hora en revisiones).
Un ingeniero del software recopila medidas y desa-
rrolla mtricas para obtener indicadores. Un indica-
dor es una mtrica o una combinacin de mtricas que
proporcionan una visin profunda del proceso del soft-
ware, del proyecto de software o del producto en s
[RAG95]. Un indicador proporciona una visin pro-
funda que permite al gestor de proyectos o a los inge-
nieros de software ajustar el producto, el proyecto o
el proceso para que las cosas salgan mejor.
Por ejemplo, cuatro equipos de software estn tra-
bajando en un proyecto grande de software. Cada equi-
po debe conducir revisiones del diseo, pero puede
seleccionar el tipo de revisin que realice. Sobre el
examen de la mtrica, errores encontrados por per-
sona-hora consumidas, el gestor del proyecto notifi-
ca que dos equipos que utilizan mtodos de revisin
ms formales presentan un 40 por 100 ms de erro-
res encontrados por persona-hora consumidas que
otros equipos. Suponiendo que todos los parmetros
son iguales, esto proporciona al gestor del proyecto
un indicador en el que los mtodos de revisin ms
formales pueden proporcionar un ahorro mayor en
inversin de tiempo que otras revisiones con un enfo-
que menos formal. Esto puede sugerir que todos los
equipos utilicen el enfoque ms formal. La mtrica
proporciona al gestor una visin ms profunda. Y ade-
ms le llevar a una toma de decisiones ms funda-
mentada.
Esto asume que se recopila otra medida, persona y horas gastadas
en cada revisin.
54
CAPfTULO 4 PROCESO DEL SOFTWARE Y MTRI CAS DEL PROY ECTO
TO
Lamedicin es algo comn en el mundo de la ingenie-
ra. Se mide el consumo de energa, el peso, las dimen-
siones fsicas, la temperatura, el voltaje, la relacin
seal-ruido.. . la lista es casi interminable. Por desgra-
cia, la medicin es mucho menos comn en el mundo
dela ingeniera del software. Existen problemas para
ponerse de acuerdo sobre qu medir y las medidas de
evaluacin de problemas recopilados.
Referenciu We6/
Se puede descargar una guo completo
de mtricos del software desde:
www.inv.nasa.gov/SWG/resources/
NASA-GB-001-94.pdf
Sedeberan recopilar mtricas para que los indica-
dores del proceso y del producto puedan ser ciertos. Los
indicadores de proceso permiten a una organizacin de
ingeniera del software tener una visin profunda de la
eficaciade un proceso ya existente (por ejemplo: el para-
digma, las tareas de ingeniera del software, productos
detrabajo e hitos). Tambin permiten que los gestores
evalen lo que funciona y lo que no. Las mtricas del
proceso se recopilan de todos los proyectos y durante
un largo perodo de tiempo. Su intento es proporcionar
indicadores que lleven a mejoras de los procesos de soft-
ware a largo plazo.
Los indicadores de proyecto permiten al gestor de
proyectos del software (1) evaluar el estado del proyecto
en curso; (2) seguir la pista de los riesgos potenciales:
(3) detectar las reas de problemas antes de que se con-
viertan en crticas; (4) ajustar el flujo y las tareas del
trabajo, y ( 5 ) evaluar la habilidad del equipo del pro-
yecto en controlar la calidad de los productos de traba-
jo del software.
Producto
Caractersticas Condiciones
de desarrollo
FIGURA 4.1. Determinantes de la calidad del software
y de la efectividad de organizacin
(adaptado segn PAU941i.
En algunos casos, se pueden utilizar las mismas
mtricas del software para determinar tanto el pro-
yecto como los indicadores del proceso. En realidad,
las medidas que recopila un equipo de proyecto y las
convierte en mtricas para utilizarse durante un pro-
yecto tambin pueden transmitirse a los que tienen la
responsabilidad de mejorar el proceso del software.
Por esta razn, se utilizan muchas de las mismas mtri-
cas tanto en el dominio del proceso como en el del
proyecto.
4.2.1. Mtricas del proceso y mejoras
en el proceso del software
La nica forma racional de mejorar cualquier proceso
es medir atributos del proceso, desarrollar un juego de
mtricas significativas segn estos atributos y entonces
utilizar las mtricas para proporcionar indicadores que
conducirn a una estrategia de mejora. Pero antes de
estudiar las mtricas del software y su impacto en la
mejoras de los procesos del software es importante des-
tacar que el proceso es el nico factor de los controla-
bles al mejorar la calidad del software y su rendimiento
como organizacin [PAU94].
CLAVE
l o habilidad y la motivacin del personal realizando
el trobajo son los factores ms importantes que influyen
en lo colidod del software.
En la Figura 4.1, el proceso se sita en el centro de
un tringulo que conecta tres factores con una pro-
funda influencia en la calidad del software y en el ren-
dimiento como organizacin. La destreza y la
motivacin del personal se muestran como el nico
factor realmente influyente en calidad y en el rendi-
miento [BOE81]. La complejidad del producto pue-
de tener un impacto sustancial sobre la calidad y el
rendimiento del equipo. La tecnologa (por ejemplo:
mtodos de la ingeniera del software) que utiliza el
proceso tambin tiene su impacto. Adems, el trin-
gulo de proceso existe dentro de un crculo de condi-
ciones de entornos que incluyen entornos de desarrollo
(por ejemplo: herramientas CASE), condiciones de
gestin (por ejemplo: fechas tope, reglas de empresa)
y caractersticas del cliente (por ejemplo: facilidad de
comunicacin).
iComo puedo medir
l a efectividad de un proceso
de software?
55
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRCTI CO
La eficacia de un proceso de software se mide indi-
rectamente. Esto es, se extrae un juego de mtricas segn
los resultados que provienen del proceso. Entre los resul-
tados se incluyen medidas de errores detectados antes
de la entrega del software, defectos detectados e infor-
mados a los usuarios finales, productos de trabajo entre-
gados (productividad), esfuerzo humano y tiempo
consumido, ajuste con la planificacin y otras medidas.
Las mtricas de proceso tambin se extraen midiendo
las caractersticas de tareas especficas de la ingeniera
del software. Por ejemplo, se podra medir el tiempo y
el esfuerzo de llevar a cabo las actividades de protec-
cin y las actividades genricas de ingeniera del soft-
ware del Captulo 2.
Grady [GRA92] argumenta que existen unos usos
privados y pblicos para diferentes tipos de datos
de proceso. Como es natural que los ingenieros del
software pudieran sentirse sensibles ante la utiliza-
cin de mtricas recopiladas sobre una base particu-
lar, estos datos deberan ser privados para el individuo
y servir slo como un indicador de ese individuo.
Entre los ejemplos de mtricas privadas se incluyen:
ndices de defectos (individualmente), ndices de
defectos (por mdulo), errores encontrados durante el
desarrollo.
La filosofa de datos de proceso privados se ajus-
ta bien con el enfoque del proceso personal del soft-
ware propuesto por Humphrey [HUM95]. Humphrey
describe el enfoque de la manera siguiente:
El proceso personal del software (PPS) es un conjunto
estructurado de descripciones de proceso, mediciones y mto-
dos que pueden ayudar a que los ingenieros mejoren su rendi-
miento personal. Proporcionan las formas, guiones y estndares
que les ayudan a estimar y planificar su trabajo. Muestra cmo
definir procesos y cmo medir su calidad y productividad. Un
principio PPS fundamental es que todo el mundo es diferente
y que un mtodo que sea efectivo para un ingeniero puede que
no sea adecuado para otro. As pues, el PPS ayuda a que los
ingenieros midan y sigan la pista de su trabajo para que pue-
dan encontrar los mtodos que sean mejores para ellos.
Humphrey reconoce que la mejora del proceso del
software puede y debe empezar en el nivel individual.
Los datos privados de proceso pueden servir como refe-
rencia importante para mejorar el trabajo individual del
ingeniero del software.
Algunas mtricas de proceso son privadas para el
equipo del proyecto de software, pero pblicas para
todos los miembros del equipo. Entre los ejemplos se
incluyen los defectos informados de funciones impor-
tantes del software (que un grupo de profesionales han
desarrollado), errores encontrados durante revisiones
tcnicas formales, y lneas de cdigo o puntos de fun-
cin por mdulo y funcin
2
. El equipo revisa estos datos
para detectar los indicadores que pueden mejorar el ren-
dimiento del equipo.
las mtricas pblicas permiten a una organizacin
realizar cambios estratgicos que mejoran el proceso
del software y cambios tcticos durante un proyecto
de software.
Las mtricas pblicas generalmente asimilan infor-
macin que originalmente era privada de particulares y
equipos. Los ndices de defectos a nivel de proyecto (no
atribuidos absolutamente a un particular), esfuerzo, tiem-
po y datos afines se recopilan y se evalan en un inten-
to de detectar indicadores que puedan mejorar el
rendimiento del proceso organizativo.
Las mtricas del proceso del software pueden pro-
porcionar beneficios significativos a medida que una
organizacin trabaja por mejorar su nivel global de
madurez del proceso. Sin embargo, al igual que todas las
mtricas, stas pueden usarse mal, originando ms pro-
blemas de los que pueden solucionar. Grady [GRA92]
sugiere una etiqueta de mtricas del software adecua-
da para gestores al tiempo que instituyen un programa
de mtricas de proceso:
Utilice el sentido comn y una sensibilidad organi-
zativa al interpretar datos de mtricas.
Proporcione una retroalimentacin regular para par-
ticulares y equipos que hayan trabajado en la reco-
pilacin de medidas y mtricas.
No utilice mtricas para evaluar a particulares.
Trabaje con profesionales y equipos para establecer
objetivos claros y mtricas que se vayan a utilizar
para alcanzarlos.
No utilice nunca mtricas que amenacen a particu-
lares o equipos.
Los datos de mtricas que indican un rea de proble-
mas no se deberan considerar negativos. Estos datos
son meramente un indicador de mejora de proceso.
No se obsesione con una sola mtrica y excluya otras
mtricas importantes.
Qu directrices deben
aplicarse cuando recogemos
mtricas del software?
A medida que una organizacin est ms a gusto con
la recopilacin y utiliza mtricas de proceso, la deriva-
cin de indicadores simples abre el camino hacia un
enfoque ms riguroso llamado mejora estadstica de
proceso del sofmare (MEPS). En esencia, MEPS utili-
za el anlisis de fallos del software para recopilar infor-
* Consulte las Secciones 4.3.1 y 4.3.2 para estudios ms detallados
sobre LDC (lneas de cdigo) y mtricas de puntos de funcin.
56
CAP~ TULO 4 PROCESO DEL SOFTWARE Y MTRI CAS DEL PROY ECTO
macin de errores y defectos
3
encontrados al desarro-
llar y utilizar una aplicacin de sistema o producto. El
anlisis de fallos funciona de la misma manera:
Referenciu Web/ '
MPSE y otra informacin relacionada con la calidad
estdisponible en la Sociedad Americana para la Calidad
en www.asq.org
1. Todos los errores y defectos se categorizan por ori-
gen (por ejemplo: defectos en la especificacin, en
la lgica, no acorde con los estndares).
2. Seregistra tanto el coste de corregir cada error como
el del defecto.
3. El nmero de errores y de defectos de cada catego-
ra se cuentan y se ordenan en orden descendente.
4. Secomputa el coste global de errores y defectos de
cada categora.
5. Los datos resultantes se analizan para detectar las
categoras que producen el coste ms alto para la
organizacin.
6. Sedesarrollan planes para modificar el proceso con
el intento de eliminar (o reducir la frecuencia de apa-
riciones de) la clase de errores y defectos que sean
ms costosos.
Lgica
20%
Manejo de datos
interfaz software L
/ \ 10.9%
6.0%
lnterfaz
hardware
7.7%
Comprobaci
de errores
10.9%
lnterfaz de usuario
11.7%
Origen de erroreddefectos
Especificacin/requisitos
Diseo
Cdigo
FIGURA 4.2. Causas de defectos y su origen para cuatro
proyectos de software iGRA941.
No puedes meioror tu enfoque para la ingeniera
del sohar e a menos que comprendos donde ests
fuerte y donde ests dbil. Utilice los tcnicas MEPS
poro oumeniur esa comprensin.
Siguiendo los pasos 1 y 2 anteriores, se puede desa-
rrollar una simple distribucin de defectos (Fig. 4.2)
[GRA94]. Para el diagrama de tarta sealado en la figu-
ra, se muestran ocho causas de defectos y sus ongenes
(indicados en sombreado). Grady sugiere 8i-desarrollo
de un diagrama de espina [GRA92] para ayudar a diag-
nosticar los datos presentados en el diagrama de fre-
cuencias. En la Figura 4.3 la espina del diagrama (la lnea
central) representa el factor de calidad en consideracin
(en este caso, los defectos de especificacin que cuentan
con el 25 por 100 del total). Cada una de las varillas (lne-
as diagonales) conectadas a la espina central indican una
causa potencial del problema de calidad (por ejemplo:
requisitos perdidos, especificacin ambigua, requisitos
incorrectos y requisitos cambiados). La notacin de la
espina y de las varillas se aade entonces a cada una de
las varillas principales del diagrama para centrarse sobre
la causa destacada. La expansin se muestra slo para la
causa incorrecta en la Figura 4.3.
La coleccin de mtricas del proceso es el conduc-
tor para la creacin del diagrama en espina. Un diagra-
ma en espina completo se puede analizar para extraer
los indicadores que permitan a una organizacin de soft-
ware modificar su proceso para reducir la frecuencia de
errores y defectos.
Perdido Ambiguo
especificacin
rn
El cliente di
informacin
equivocada
Peticiones inadecuadas
Incorrecto Cambios
FIGURA 4.3. Un diagrama de espina (Adaptado de [GRA921).
Como se trata en el Chptulo 8, un error es alguna fisura en un pro-
ducto de trabajo de ingeniera del software o en la entrega descu-
bierta por los ingenieros del software antes de que el software sea
entregado al usuario final.
Un defecto es una fisura descubierta despus de la entrega al usua-
no final.
57
I NGENI ER~A DEL SOFTWARE. UN ENFOQUE PRCTI CO
4.2.2. Mtricas del proyecto
Las mtricas del proceso de software se utilizan para
propsitos estratgicos. Las medidas del proyecto de
software son tcticas. Esto es, las mtricas de proyec-
tos y los indicadores derivados de ellos los utilizan un
gestor de proyectos y un equipo de software para adap-
tar el flujo del trabajo del proyecto y las actividades
tcnicas.
las tcnicas de estimacin de proyectos se estudian
en el captulo 5.
La primera aplicacin de mtricas de proyectos en
la mayora de los proyectos de software ocurre duran-
te la estimacin. Las mtricas recopiladas de proyectos
anteriores se utilizan como una base desde la que se rea-
lizan las estimaciones del esfuerzo y del tiempo para el
actual trabajo del software. A medida que avanza un
proyecto, las medidas del esfuerzo y del tiempo consu-
mido se comparan con las estimaciones originales (y la
planificacin de proyectos). El gestor de proyectos uti-
liza estos datos para supervisar y controlar el avance.
A medida que comienza el trabajo tcnico, otras
mtricas de proyectos comienzan a tener significado.
Se miden los ndices de produccin representados
mediante pginas de documentacin, las horas de revi-
sin, los puntos de funcin y las lneas fuente entre-
gadas. Adems, se sigue la pista de los errores
detectados durante todas las tareas de ingeniera del
software. Cuando va evolucionando el software des-
de la especificacin al diseo, se recopilan las mtri-
cas tcnicas (Captulos 19 al 24) para evaluar la
calidad del diseo y para proporcionar indicadores
que influirn en el enfoque tomado para la generacin
y prueba del cdigo.
La utilizacin de mtricas para el proyecto tiene dos
aspectos fundamentales. En primer lugar, estas mtri-
cas se utilizan para minimizar la planificacin de desa-
rrollo haciendo los ajustes necesarios que eviten retrasos
y reduzcan problemas y riesgos potenciales. En segun-
do lugar, las mtricas para el proyecto se utilizan para
evaluar la calidad de los productos en el momento actual
y cuando sea necesario, modificando el enfoque tcni-
co que mejore la calidad.
Cmo debemos
utilizar las mtricas
durante el proyecto?
A medida que mejora la calidad, se minimizan los
defectos, y al tiempo que disminuye el nmero de defec-
tos, la cantidad de trabajo que ha de rehacerse tambin
se reduce. Esto lleva a una reduccin del coste global
del proyecto.
Otro modelo de mtricas del proyecto de software
[HET93] sugiere que todos los proyectos deberan medir:
entradas: la dimensin de los recursos (p. ej.: perso-
nas, entomo) que se requieren para realizar el trabajo,
salidas: medidas de las entregas o productos creados
durante el proceso de ingeniera del software,
resultados: medidas que indican la efectividad de las
entregas.
En realidad, este modelo se puede aplicar tanto al
proceso como al proyecto. En el contexto del proyecto,
el modelo se puede aplicar recursivamente a medida
que aparece cada actividad estructural. Por consiguien-
te las salidas de una actividad se convierten en las entra-
das de la siguiente. Las mtricas de resultados se pueden
utilizar para proporcionar una indicacin de la utilidad
de los productos de trabajo cuando fluyen de una acti-
vidad (o tarea) a la siguiente.
Las mediciones del mundo fsico se pueden categorizar
de dos maneras; medidas directas (por ejemplo: la lon-
gitud de un tomillo) y medidas indirectas (por ejemplo:
la calidad de los tomillos producidos, medidos con-
tando los artculos defectuosos). Las mtricas del soft-
ware se pueden categorizar de forma similar.
Entre las medidas directas del proceso de la inge-
niera del software se incluyen el coste y el esfuerzo
aplicados. Entre las medidas directas del producto se
incluyen las lneas de cdigo (LDC) producidas, velo-
cidad de ejecucin, tamao de memoria, y los defectos
informados durante un perodo de tiempo establecido.
Entre las medidas indirectas se incluyen la funcionali-
dad, calidad, complejidad, eficiencia, fiabilidad, facili-
dad de mantenimiento y muchas otras capacidades
tratadas en el Captulo 19.
Cul es l a diferencia
entre medidas directas
e indirectas?
El coste y el esfuerzo requerido para construir el soft-
ware, el nmero de lneas de cdigo producidas, y otras
medidas directas son relativamente fciles de reunir,
mientras que los convenios especficos para la medicin
se establecen ms adelante. Sin embargo, la calidad y
funcionalidad del software, o su eficiencia o manteni-
miento son ms difciles de evaluar y slo pueden ser
medidas indirectamente.
El dominio de las mtricas del software se dividen
en mtricas de proceso, proyecto y producto. Tambin
se acaba de destacar que las mtricas de producto que
5a
CAPfTULO 4 PROCESO DEL SOFTWARE Y MTRI CAS DEL PROY ECTO
.
son privadas para un individuo a menudo se combinan
paradesarrollar mtricas del proyecto que sean pbli-
cas para un equipo de software. Las mtricas del pro-
yecto seconsolidan para crear mtricas de proceso que
sean pblicas para toda la organizacin del software.
Pero jcmo combina una organizacin mtricas que
provengan de particulares o proyectos?
. . .
. .
Puesto que muchos foctores influyen en el trabajo
del software, no utilice las mtricas poro comparor
personas o equipos.
Para ilustrarlo, se va a tener en consideracin un
ejemplo sencillo. Personas de dos equipos de proyecto
diferentes registran y categorizan todos los errores que
se encuentran durante el proceso del software. Las medi-
das de las personas se combinan entonces para desa-
rrollar medidas de equipo. El equipo A encontr 342
errores durante el proceso del software antes de su rea-
lizacin. El equipo B encontr1 84. Considerando que
en el resto los equipos son iguales, qu equipo es ms
efectivo en detectar errores durante el proceso'? Como
noseconoce el tamao o la complejidad de los proyec-
tos, no sepuede responder a esta pregunta. Sin embar-
go, si se normalizan las medidas, es posible crear
mtricas de software que permitan comparar medidas
ms amplias de otras organizaciones.
4.3.1. Mtricas Orientadas al Tamao
Las mtricas del software orientadas al tamao provie-
nen de la normalizacin de las medidas de calidad y/o
productividad considerando el tamao del software
quesehaya producido. Si una organizacin de softwa-
re mantiene registros sencillos, se puede crear una tabla
dedatos orientados al tamao, como la que muestra la
Figura 4.4. La tabla lista cada proyecto de desarrollo de
software de los ltimos aos y las medidas correspon-
dientes de cada proyecto. Refirindonos a la entrada de
la tabla (Fig. 4.4) del proyecto alfa: se desarrollaron
12.100 lneas de cdigo (LDC) con 24 personas-mes y
con un coste de E168.000. Debe tenerse en cuenta que
el esfuerzo y el coste registrados en la tabla incluyen
todas las actividades de ingeniera del software (anli-
sis, diseo, codificacin y prueba) y no slo la codifi-
cacin. Otra informacin sobre el proyecto alfa indica
quesedesarrollaron 365 pginas de documentacin, se
registraron 134 errores antes de que el software se entre-
gara y se encontraron 29 errores despus de entregr-
selo al cliente dentro del primer ao de utilizacin.
Tambin sabemos que trabajaron tres personas en el
desarrollo del proyecto alfa.
Qu datos deberamos
reunir para derivar mtricas
orientadas al tamao?
FIGURA 4.4. Mtricas orientadas al tamao.
Para desarrollar mtricas que se puedan comparar
entre distintos proyectos, se seleccionan las lneas de
cdigo como valor de normalizacin. Con los rudi-
mentarios datos contenidos en la tabla se pueden desa-
rrollar para cada proyecto un conjunto de mtricas
simples orientadas al tamao:
errores por KLDC (miles de lneas de cdigo)
defectos
4
por KLDC
E por LDC
pginas de documentacin por KLDC
Plontillo de coleccin de mtricos
Adems, se pueden calcular otras mtricas interesantes:
errores por persona-mes
LDC por persona-mes
E por pgina de documentacin
4.3.2. Mtricas Orientadas a la Funcin
Las mtricas del software orientadas a la funcin utili-
zan una medida de la funcionalidad entregada por la
aplicacin como un valor de normalizacin. Yaque la
funcionalidad>>no se puede medir directamente, se
debe derivar indirectamente mediante otras medidas
directas. Las mtricas orientadas a la funcin fueron
propuestas por primera vez por Albretch [ALB79], quien
sugiri una medida llamada punto defuncin. Los pun-
tos de funcin se derivan con una relacin emprica
Un defecto ocurre cuando las actividades de garanta de calidad (p.
ej.: revisiones tcnicas formales) fallan para descubrir un error en un
producto de trabajo generado durante el proceso del cottware.
59
INGENIERfA DEL SOFTWARE. UN ENFOQUE PRCTICO
segn las medidas contables (directas) del dominio de
informacin del software y las evaluaciones de la com-
plejidad del software.
Referencia 3 Web
Se puede obtener informacin completo sobre los puntos
de funcibn en: www.ifpug.org
Los puntos de funcin se calculan [IFP94] comple-
tando la tabla de la Figura 4.5. Se determinan cinco
caractersticas de dominios de informacin y se pro-
porcionan las cuentas en la posicin apropiada de la
tabla. Los valores de los dominios de informacin se
definen de la forma siguiente?
Nmero de entradas de usuario. Se cuenta cada
entrada de usuario que proporciona diferentes datos
orientados a la aplicacin. Las entradas se deberan
diferenciar de las peticiones, las cuales se cuentan de
forma separada.
l o s puntos de funcin se derivan de medidas
directas del dominio de la informacin.
Nmero de salidas de usuario. Se cuenta cada salida
que proporciona al usuario informacin orientada a la
aplicacin. En este contexto la salida se refiere a infor-
mes, pantallas, mensajes de error, etc. Los elementos
de datos particulares dentro de un informe no se cuen-
tan de forma separada.
Nmero de pcticiones de usuario. Una peticin se
define como unaentrada interactiva que produce la gene-
racin de alguna respuesta del software inmediata en
forma de salida inleractiva. Se cuenta cada peticin por
separado.
Nmero de archivos. Se cuenta cada archivo maes-
tro lgico (esto es, un grupo lgico de datos que puede
ser una parte de una gran base de datos o un archivo
independiente).
Nmero de interfaces externas. Se cuentan todas
las interfaces legibles por la mquina (por ejemplo:
archivos de datos de cinta o disco) que se utilizan
para transmitir informacin a otro sistema.
Una vez que se han recopilado los datos anterio-
res, a la cuenta se asocia un valor de complejidad.
Las organizaciones que utilizan mtodos de puntos
de funcin desarrollan criterios para determinar si
una entrada en particular es simple, media o com-
pleja. No obstante la determinacin de la compleji-
dad es algo subjetiva.
Parmetros
de medicin Cuenta
Nmero
de entradas
de usuario
Nmero
de salidas
de usuario
Nmero
de peticiones
de usuario
cl
cl
Nmero
de archivos
Nmero
de interfaces
externas
Factor de ponderacin
Simple Medio Complejo
x 3 4 6 =a
x 4 5 7 =a
x 3 4 6 =a
X l 10 15 = a
x 5 7 10 = a
Cuenta total
FIGURA 4.5. Clculo de puntos de funcin.
Para calcular puntos de funcin (PF), se utiliza la
(4.1)
relacin siguiente:
PF =cuenta-total x [0,65 +0,Ol x 6( Fi )]
en donde cuenta-total es la suma de todas las entradas
PF obtenidas de la figura 4.5.
Fi (i =1 a 14) son valores de ajuste de la compkji-
dad segn las respuestas a las siguientes preguntas
[ART85] :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Requiere el sistema copias de seguridad y de recu-
peracin fiables?
Se requiere comunicacin de datos?
Existen funciones de procesamiento distribuido?
Es crtico el rendimiento?
Se ejecutarh el sistema en un entorno operativo
existente y fuertemente utilizado?
i,Requiere el sistema entrada de datos interactiva?
Requiere la entrada de datos interactiva que las
transacciones de entrada se lleven a cabo sobre ml-
tiples pantallas u operaciones?
Se actualizan los archivos maestros de forma
interactiva?
Son complejas las entradas, las salidas, los archi-
vos o las peticiones?
Es complejo el procesamiento interno?
Se ha diseado el cdigo para ser reutilizable?
Estn incluidas en el diseo la conversin y la ins-
talacin'?
Se ha diseado el sistema para soportar mltiples
instalaciones en diferentes organizaciones?
Se ha diseado la aplicacin para facilitar los cam-
bios y para ser fcilmente utilizada por el usuario?
Enrealidad, ladefinicin de los valores del dominio de la informa-
cin y la forma en que se cuentan es un poco ms complejo. El lec-
tor interesado debera consultar [IFP94j para obtener ms detalles.
60