Vous êtes sur la page 1sur 9

INGENIERA DEL SOFTWARE

UN ENFOQUE PRCTICO
Quinta edicin
CAPTULO

4 PROCESO DE SOFTWARE
Y MTRICAS DE PROYECTOS

L
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-
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 las ;Quin lo hace? Las mtricas del soft- zando mtricas orientadas al tamao o
mtricas del producto son una medida ware son analizadas y evaluadas por a la funcin. El resultado se analiza y
cuantitativa que permite a la gente del los administradores del software. A se compara con promedios anteriores
software tener una visin profunda de menudo las medidas son reunidas por de proyectos similares realizados con
la eficacia del proceso del software y de los ingenieros del software. la organizacin. Se evalan las ten-
los proyectos que dirigen utilizando el ;Por qu es imporiante? Si no mides, dencias y se generan las conclusiones.
proceso como un marco de trabajo. Se slo podrs juzgar basndote en una Cul es el producto obtenido?Es un
renen los datos bsicos de calidad y evaluacin subjetiva. Mediante la medi- conjunto de mtricas del software que
productividad. Estos datos son entonces cin, se pueden sealar las tendencias proporcionan una visin profunda del
analizados, comparados con promedios (buenas o malas), realizar mejores esti- proceso y d e la comprensin del pro-
anteriores, y evaluados para determi- maciones, llevar a cabo una verdadera yecto.
nar las mejoras en la calidad y produc- mejora sobre el tiempo. Cmo puedo estar seguro de que lo
tividad. Las mtricas son tambin Cules son los pasos? Comenzar defi- he hecho correctamente? Aplican-
utilizadas para sealar reas con pro- niendo un conjunto limitado de medi- do un plan de medicin sencillo pero
blemas de manera que se puedan desa- das de procesos, proyectos y productos consistente, que nunca utilizaremos
rrollar los remedios y mejorar el proceso que sean fciles de recoger. Estas medi- para evaluar, premiar o castigar el ren-
del software. d a s son a menudo normalizadas utili- 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 - d e 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 [RAG95]. Un indicador proporciona una visin pro-
utilizan a menudo indistintamente, es importante des- funda que permite al gestor de proyectos o a los inge-
tacar las diferencias sutiles entre ellos. Como los tr- nieros de software ajustar el producto, el proyecto o
minos medida y medicin se pueden utilizar el proceso para que las cosas salgan mejor.
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. Por ejemplo, cuatro equipos de software estn tra-
Cuando, simplemente, se ha recopilado un solo bajando en un proyecto grande de software. Cada equi-
aspecto de los datos (por ejemplo: el nmero de erro- po debe conducir revisiones del diseo, pero puede
res descubiertos en la revisin de un mdulo), se ha seleccionar el tipo de revisin que realice. Sobre el
establecido una medida. La medicin aparece como examen de la mtrica, errores encontrados por per-
resultado de la recopilacin de uno o varios aspectos sona-hora consumidas, el gestor del proyecto notifi-
de los datos (por ejemplo: se investiga un nmero de ca que dos equipos que utilizan mtodos de revisin
revisiones de mdulos para recopilar medidas del ms formales presentan un 40 por 100 ms de erro-
nmero de errores encontrados durante cada revisin). res encontrados por persona-hora consumidas que
Una mtrica del software relata de alguna forma las otros equipos. Suponiendo que todos los parmetros
medidas individuales sobre algn aspecto (por ejem- son iguales, esto proporciona al gestor del proyecto
plo: el nmero medio de errores encontrados por revi- un indicador en el que los mtodos de revisin ms
sin o el nmero medio de errores encontrados por formales pueden proporcionar un ahorro mayor en
persona y hora en revisiones). inversin de tiempo que otras revisiones con un enfo-
Un ingeniero del software recopila medidas y desa- que menos formal. Esto puede sugerir que todos los
rrolla mtricas para obtener indicadores. Un indica- equipos utilicen el enfoque ms formal. La mtrica
dor es una mtrica o una combinacin de mtricas que proporciona al gestor una visin ms profunda. Y ade-
proporcionan una visin profunda del proceso del soft- ms le llevar a una toma de decisiones ms funda-
ware, del proyecto de software o del producto en s mentada.

Esto asume que se recopila otra medida, persona y horas gastadas


en cada revisin.
54
CAPfTULO 4 PROCESO DEL SOFTWARE Y MTRICAS DEL P R O Y E C T O

TO
La medicin es algo comn en el mundo de la ingenie- En algunos casos, se pueden utilizar las mismas
ra. Se mide el consumo de energa, el peso, las dimen- mtricas del software para determinar tanto el pro-
siones fsicas, la temperatura, el voltaje, la relacin yecto como los indicadores del proceso. En realidad,
seal-ruido.. . la lista es casi interminable. Por desgra- las medidas que recopila un equipo de proyecto y las
cia, la medicin es mucho menos comn en el mundo convierte en mtricas para utilizarse durante un pro-
de la ingeniera del software. Existen problemas para yecto tambin pueden transmitirse a los que tienen la
ponerse de acuerdo sobre qu medir y las medidas de responsabilidad de mejorar el proceso del software.
evaluacin de problemas recopilados. Por esta razn, se utilizan muchas de las mismas mtri-
cas tanto en el dominio del proceso como en el del
proyecto.
Referenciu We6/ 4.2.1. Mtricas del proceso y mejoras
Se puede descargar una guo completo
de mtricos del software desde: en el proceso del software
www.inv.nasa.gov/SWG/resources/ La nica forma racional de mejorar cualquier proceso
NASA-GB-001-94.pdf es medir atributos del proceso, desarrollar un juego de
Se deberan recopilar mtricas para que los indica- mtricas significativas segn estos atributos y entonces
dores del proceso y del producto puedan ser ciertos. Los utilizar las mtricas para proporcionar indicadores que
indicadores de proceso permiten a una organizacin de conducirn a una estrategia de mejora. Pero antes de
ingeniera del software tener una visin profunda de la estudiar las mtricas del software y su impacto en la
eficacia de un proceso ya existente (por ejemplo: el para- mejoras de los procesos del software es importante des-
digma, las tareas de ingeniera del software, productos tacar que el proceso es el nico factor de los controla-
de trabajo e hitos). Tambin permiten que los gestores bles al mejorar la calidad del software y su rendimiento
evalen lo que funciona y lo que no. Las mtricas del como organizacin [PAU94].
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. CLAVE
Los indicadores de proyecto permiten al gestor de l o habilidad y la motivacin del personal realizando
proyectos del software (1) evaluar el estado del proyecto el trobajo son los factores ms importantes que influyen
en curso; (2) seguir la pista de los riesgos potenciales: en lo colidod del software.
(3) detectar las reas de problemas antes de que se con-
viertan en crticas; (4) ajustar el flujo y las tareas del En la Figura 4.1, el proceso se sita en el centro de
trabajo, y ( 5 ) evaluar la habilidad del equipo del pro- un tringulo que conecta tres factores con una pro-
yecto en controlar la calidad de los productos de traba- funda influencia en la calidad del software y en el ren-
jo del software.
dimiento como organizacin. La destreza y la
motivacin del personal se muestran como el nico
Producto
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:
Caractersticas Condiciones 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).
de desarrollo

iComo puedo medir


FIGURA 4.1. Determinantes de la calidad del software
la efectividad de un proceso
y de la efectividad de organizacin
(adaptado segn PAU941i.
de software?

55
INGENIERfA DEL SOFTWARE. U N ENFOQUE P R C T I C O

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 las mtricas pblicas permiten a una organizacin
de la entrega del software, defectos detectados e infor- realizar cambios estratgicos que mejoran el proceso
mados a los usuarios finales, productos de trabajo entre- del software y cambios tcticos durante un proyecto
gados (productividad), esfuerzo humano y tiempo de software.
consumido, ajuste con la planificacin y otras medidas.
Las mtricas de proceso tambin se extraen midiendo
las caractersticas de tareas especficas de la ingeniera Las mtricas pblicas generalmente asimilan infor-
del software. Por ejemplo, se podra medir el tiempo y macin que originalmente era privada de particulares y
el esfuerzo de llevar a cabo las actividades de protec- equipos. Los ndices de defectos a nivel de proyecto (no
cin y las actividades genricas de ingeniera del soft- atribuidos absolutamente a un particular), esfuerzo, tiem-
ware del Captulo 2. po y datos afines se recopilan y se evalan en un inten-
Grady [GRA92] argumenta que existen unos usos to de detectar indicadores que puedan mejorar el
privados y pblicos para diferentes tipos de datos rendimiento del proceso organizativo.
de proceso. Como es natural que los ingenieros del Las mtricas del proceso del software pueden pro-
software pudieran sentirse sensibles ante la utiliza- porcionar beneficios significativos a medida que una
cin de mtricas recopiladas sobre una base particu- organizacin trabaja por mejorar su nivel global de
lar, estos datos deberan ser privados para el individuo madurez del proceso. Sin embargo, al igual que todas las
y servir slo como un indicador de ese individuo. mtricas, stas pueden usarse mal, originando ms pro-
Entre los ejemplos de mtricas privadas se incluyen: blemas de los que pueden solucionar. Grady [GRA92]
ndices de defectos (individualmente), ndices de sugiere una etiqueta de mtricas del software adecua-
defectos (por mdulo), errores encontrados durante el da para gestores al tiempo que instituyen un programa
desarrollo. de mtricas de proceso:
La filosofa de datos de proceso privados se ajus-
ta bien con el enfoque del proceso personal del soft- Utilice el sentido comn y una sensibilidad organi-
ware propuesto por Humphrey [HUM95]. Humphrey zativa al interpretar datos de mtricas.
describe el enfoque de la manera siguiente: Proporcione una retroalimentacin regular para par-
ticulares y equipos que hayan trabajado en la reco-
El proceso personal del software (PPS) es un conjunto
estructurado de descripciones de proceso, mediciones y mto-
pilacin de medidas y mtricas.
dos que pueden ayudar a que los ingenieros mejoren su rendi- No utilice mtricas para evaluar a particulares.
miento personal. Proporcionan las formas, guiones y estndares Trabaje con profesionales y equipos para establecer
que les ayudan a estimar y planificar su trabajo. Muestra cmo objetivos claros y mtricas que se vayan a utilizar
definir procesos y cmo medir su calidad y productividad. Un
principio PPS fundamental es que todo el mundo es diferente para alcanzarlos.
y que un mtodo que sea efectivo para un ingeniero puede que No utilice nunca mtricas que amenacen a particu-
no sea adecuado para otro. As pues, el PPS ayuda a que los lares o equipos.
ingenieros midan y sigan la pista de su trabajo para que pue-
dan encontrar los mtodos que sean mejores para ellos.
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.
Humphrey reconoce que la mejora del proceso del
software puede y debe empezar en el nivel individual. No se obsesione con una sola mtrica y excluya otras
Los datos privados de proceso pueden servir como refe- mtricas importantes.
rencia importante para mejorar el trabajo individual del
ingeniero del software.
Algunas mtricas de proceso son privadas para el Qu directrices deben
equipo del proyecto de software, pero pblicas para aplicarse cuando recogemos
todos los miembros del equipo. Entre los ejemplos se mtricas del software?
incluyen los defectos informados de funciones impor-
tantes del software (que un grupo de profesionales han A medida que una organizacin est ms a gusto con
desarrollado), errores encontrados durante revisiones la recopilacin y utiliza mtricas de proceso, la deriva-
tcnicas formales, y lneas de cdigo o puntos de fun- cin de indicadores simples abre el camino hacia un
cin por mdulo y funcin2. El equipo revisa estos datos enfoque ms riguroso llamado mejora estadstica de
para detectar los indicadores que pueden mejorar el ren- proceso del sofmare (MEPS). En esencia, MEPS utili-
dimiento del equipo. 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
C A P ~ T U L O4 PROCESO DEL SOFTWARE Y MTRICAS DEL PROYECTO

macin de errores y defectos3 encontrados al desarro-


llar y utilizar una aplicacin de sistema o producto. El
anlisis de fallos funciona de la misma manera: No puedes meioror tu enfoque para la ingeniera
del sohare a menos que comprendos donde ests
fuerte y donde ests dbil. Utilice los tcnicas MEPS
poro oumeniur esa comprensin.
Referenciu Web/ ' Siguiendo los pasos 1 y 2 anteriores, se puede desa-
MPSE y otra informacin relacionada con la calidad rrollar una simple distribucin de defectos (Fig. 4.2)
est disponible en la Sociedad Americana para la Calidad [GRA94]. Para el diagrama de tarta sealado en la figu-
en www.asq.org ra, se muestran ocho causas de defectos y sus ongenes
(indicados en sombreado). Grady sugiere 8i-desarrollo
1. Todos los errores y defectos se categorizan por ori- de un diagrama de espina [GRA92] para ayudar a diag-
gen (por ejemplo: defectos en la especificacin, en nosticar los datos presentados en el diagrama de fre-
la lgica, no acorde con los estndares). cuencias. En la Figura 4.3 la espina del diagrama (la lnea
central) representa el factor de calidad en consideracin
2. Se registra tanto el coste de corregir cada error como (en este caso, los defectos de especificacin que cuentan
el del defecto. con el 25 por 100 del total). Cada una de las varillas (lne-
3. El nmero de errores y de defectos de cada catego- as diagonales) conectadas a la espina central indican una
ra se cuentan y se ordenan en orden descendente. causa potencial del problema de calidad (por ejemplo:
4. Se computa el coste global de errores y defectos de requisitos perdidos, especificacin ambigua, requisitos
cada categora. incorrectos y requisitos cambiados). La notacin de la
5. Los datos resultantes se analizan para detectar las espina y de las varillas se aade entonces a cada una de
categoras que producen el coste ms alto para la las varillas principales del diagrama para centrarse sobre
organizacin. la causa destacada. La expansin se muestra slo para la
causa incorrecta en la Figura 4.3.
6. Se desarrollan planes para modificar el proceso con La coleccin de mtricas del proceso es el conduc-
el intento de eliminar (o reducir la frecuencia de apa- tor para la creacin del diagrama en espina. Un diagra-
riciones de) la clase de errores y defectos que sean ma en espina completo se puede analizar para extraer
ms costosos. los indicadores que permitan a una organizacin de soft-
ware modificar su proceso para reducir la frecuencia de
errores y defectos.
Lgica
20%
Perdido Ambiguo
Manejo de datos
interfaz software L / \ 10.9%
6.0%

lnterfaz
hardware
7.7%

especificacin
Comprobaci rn
de errores
10.9%
El cliente di
informacin
lnterfaz de usuario equivocada
11.7%
Origen de erroreddefectos Peticiones inadecuadas
Especificacin/requisitos
Diseo
Cdigo
Incorrecto Cambios
FIGURA 4.2. Causas de defectos y su origen para cuatro
proyectos de software iGRA941. 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 N G E N I E R ~ ADEL SOFTWARE. UN ENFOQUE PRCTICO

4.2.2. Mtricas del proyecto La utilizacin de mtricas para el proyecto tiene dos
Las mtricas del proceso de software se utilizan para aspectos fundamentales. En primer lugar, estas mtri-
propsitos estratgicos. Las medidas del proyecto de cas se utilizan para minimizar la planificacin de desa-
software son tcticas. Esto es, las mtricas de proyec- rrollo haciendo los ajustes necesarios que eviten retrasos
tos y los indicadores derivados de ellos los utilizan un y reduzcan problemas y riesgos potenciales. En segun-
gestor de proyectos y un equipo de software para adap- do lugar, las mtricas para el proyecto se utilizan para
tar el flujo del trabajo del proyecto y las actividades evaluar la calidad de los productos en el momento actual
tcnicas. y cuando sea necesario, modificando el enfoque tcni-
co que mejore la calidad.

Cmo debemos
las tcnicas de estimacin de proyectos se estudian
utilizar las mtricas
en el captulo 5.
durante el proyecto?

La primera aplicacin de mtricas de proyectos en A medida que mejora la calidad, se minimizan los
la mayora de los proyectos de software ocurre duran- defectos, y al tiempo que disminuye el nmero de defec-
te la estimacin. Las mtricas recopiladas de proyectos tos, la cantidad de trabajo que ha de rehacerse tambin
anteriores se utilizan como una base desde la que se rea- se reduce. Esto lleva a una reduccin del coste global
lizan las estimaciones del esfuerzo y del tiempo para el del proyecto.
actual trabajo del software. A medida que avanza un Otro modelo de mtricas del proyecto de software
proyecto, las medidas del esfuerzo y del tiempo consu- [HET93] sugiere que todos los proyectos deberan medir:
mido se comparan con las estimaciones originales (y la entradas: la dimensin de los recursos (p. ej.: perso-
planificacin de proyectos). El gestor de proyectos uti- nas, entomo) que se requieren para realizar el trabajo,
liza estos datos para supervisar y controlar el avance.
A medida que comienza el trabajo tcnico, otras salidas: medidas de las entregas o productos creados
mtricas de proyectos comienzan a tener significado. durante el proceso de ingeniera del software,
Se miden los ndices de produccin representados resultados: medidas que indican la efectividad de las
mediante pginas de documentacin, las horas de revi- entregas.
sin, los puntos de funcin y las lneas fuente entre- En realidad, este modelo se puede aplicar tanto al
gadas. Adems, se sigue la pista de los errores proceso como al proyecto. En el contexto del proyecto,
detectados durante todas las tareas de ingeniera del el modelo se puede aplicar recursivamente a medida
software. Cuando va evolucionando el software des- que aparece cada actividad estructural. Por consiguien-
de la especificacin al diseo, se recopilan las mtri- te las salidas de una actividad se convierten en las entra-
cas tcnicas (Captulos 19 al 24) para evaluar la das de la siguiente. Las mtricas de resultados se pueden
calidad del diseo y para proporcionar indicadores utilizar para proporcionar una indicacin de la utilidad
que influirn en el enfoque tomado para la generacin de los productos de trabajo cuando fluyen de una acti-
y prueba del cdigo. vidad (o tarea) a la siguiente.

Las mediciones del mundo fsico se pueden categorizar Cul es la diferencia


de dos maneras; medidas directas (por ejemplo: la lon- entre medidas directas
gitud de un tomillo) y medidas indirectas (por ejemplo: e indirectas?
la calidad de los tomillos producidos, medidos con-
tando los artculos defectuosos). Las mtricas del soft-
ware se pueden categorizar de forma similar. El coste y el esfuerzo requerido para construir el soft-
Entre las medidas directas del proceso de la inge- ware, el nmero de lneas de cdigo producidas, y otras
niera del software se incluyen el coste y el esfuerzo medidas directas son relativamente fciles de reunir,
aplicados. Entre las medidas directas del producto se mientras que los convenios especficos para la medicin
incluyen las lneas de cdigo (LDC) producidas, velo- se establecen ms adelante. Sin embargo, la calidad y
cidad de ejecucin, tamao de memoria, y los defectos funcionalidad del software, o su eficiencia o manteni-
informados durante un perodo de tiempo establecido. miento son ms difciles de evaluar y slo pueden ser
Entre las medidas indirectas se incluyen la funcionali- medidas indirectamente.
dad, calidad, complejidad, eficiencia, fiabilidad, facili- El dominio de las mtricas del software se dividen
dad de mantenimiento y muchas otras capacidades en mtricas de proceso, proyecto y producto. Tambin
tratadas en el Captulo 19. se acaba de destacar que las mtricas de producto que
5a
CAPfTULO 4 P R O C E S O DEL SOFTWARE Y MTRICAS DEL PROYECTO

son privadas para un individuo a menudo se combinan Qu datos deberamos


para desarrollar mtricas del proyecto que sean pbli- reunir para derivar mtricas
cas para un equipo de software. Las mtricas del pro- orientadas al tamao?
yecto se consolidan 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- FIGURA 4.4. Mtricas orientadas al tamao.
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- Para desarrollar mtricas que se puedan comparar
lizacin. El equipo B encontr1 84. Considerando que entre distintos proyectos, se seleccionan las lneas de
en el resto los equipos son iguales, qu equipo es ms cdigo como valor de normalizacin. Con los rudi-
efectivo en detectar errores durante el proceso'? Como mentarios datos contenidos en la tabla se pueden desa-
no se conoce el tamao o la complejidad de los proyec- rrollar para cada proyecto un conjunto de mtricas
tos, no se puede responder a esta pregunta. Sin embar- simples orientadas al tamao:
go, si se normalizan las medidas, es posible crear errores por KLDC (miles de lneas de cdigo)
mtricas de software que permitan comparar medidas defectos4 por KLDC
ms amplias de otras organizaciones. E por LDC
pginas de documentacin por KLDC
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
que se haya producido. Si una organizacin de softwa-
re mantiene registros sencillos, se puede crear una tabla Plontillo de coleccin de mtricos
de datos orientados al tamao, como la que muestra la
Figura 4.4. La tabla lista cada proyecto de desarrollo de Adems, se pueden calcular otras mtricas interesantes:
software de los ltimos aos y las medidas correspon- errores por persona-mes
dientes de cada proyecto. Refirindonos a la entrada de LDC por persona-mes
la tabla (Fig. 4.4) del proyecto alfa: se desarrollaron
12.100 lneas de cdigo (LDC) con 24 personas-mes y E por pgina de documentacin
con un coste de E168.000. Debe tenerse en cuenta que
el esfuerzo y el coste registrados en la tabla incluyen 4.3.2. Mtricas Orientadas a la Funcin
todas las actividades de ingeniera del software (anli- Las mtricas del software orientadas a la funcin utili-
sis, diseo, codificacin y prueba) y no slo la codifi- zan una medida de la funcionalidad entregada por la
cacin. Otra informacin sobre el proyecto alfa indica aplicacin como un valor de normalizacin. Ya que la
que se desarrollaron 365 pginas de documentacin, se funcionalidad>>no se puede medir directamente, se
registraron 134 errores antes de que el software se entre- debe derivar indirectamente mediante otras medidas
gara y se encontraron 29 errores despus de entregr- directas. Las mtricas orientadas a la funcin fueron
selo al cliente dentro del primer ao de utilizacin. propuestas por primera vez por Albretch [ALB79], quien
Tambin sabemos que trabajaron tres personas en el sugiri una medida llamada punto defuncin. Los pun-
desarrollo del proyecto alfa. 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 Factor de ponderacin


informacin del software y las evaluaciones de la com- Parmetros
plejidad del software.
de medicin
Nmero
Cuenta

cl
Simple Medio Complejo

=a
3
de entradas x 3 4 6

Referencia Web
de usuario
Nmero
de salidas
cl x 4 5 7 =a
Se puede obtener informacin completo sobre los puntos
de funcibn en: www.ifpug.org
de usuario
Nmero
de peticiones x 3 4 6 =a
Los puntos de funcin se calculan [IFP94] comple-
tando la tabla de la Figura 4.5. Se determinan cinco
de usuario

Nmero
de archivos X l 10 15 a
=
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 interfaces
externas
x 5 7 10 a
=

Cuenta total
Nmero de entradas de usuario. Se cuenta cada
entrada de usuario que proporciona diferentes datos
orientados a la aplicacin. Las entradas se deberan FIGURA 4.5. Clculo de puntos de funcin.
diferenciar de las peticiones, las cuales se cuentan de
forma separada. Para calcular puntos de funcin (PF), se utiliza la
relacin siguiente:
PF = cuenta-total x [0,65 + 0,Ol x 6(Fi )] (4.1)
en donde cuenta-total es la suma de todas las entradas
los puntos de funcin se derivan de medidas PF obtenidas de la figura 4.5.
directas del dominio de la informacin. Fi (i = 1 a 14) son valores de ajuste de la compkji-
dad segn las respuestas a las siguientes preguntas
Nmero de salidas de usuario. Se cuenta cada salida
[ART85]:
que proporciona al usuario informacin orientada a la
aplicacin. En este contexto la salida se refiere a infor- 1. Requiere el sistema copias de seguridad y de recu-
mes, pantallas, mensajes de error, etc. Los elementos peracin fiables?
de datos particulares dentro de un informe no se cuen- 2. Se requiere comunicacin de datos?
tan de forma separada. 3. Existen funciones de procesamiento distribuido?
Nmero de pcticiones de usuario. Una peticin se 4. Es crtico el rendimiento?
define como una entrada interactiva que produce la gene- 5. Se ejecutarh el sistema en un entorno operativo
racin de alguna respuesta del software inmediata en existente y fuertemente utilizado?
forma de salida inleractiva. Se cuenta cada peticin por 6. i,Requiere el sistema entrada de datos interactiva?
separado.
Nmero de archivos. Se cuenta cada archivo maes- 7. Requiere la entrada de datos interactiva que las
tro lgico (esto es, un grupo lgico de datos que puede transacciones de entrada se lleven a cabo sobre ml-
ser una parte de una gran base de datos o un archivo tiples pantallas u operaciones?
independiente). 8. Se actualizan los archivos maestros de forma
Nmero de interfaces externas. Se cuentan todas interactiva?
las interfaces legibles por la mquina (por ejemplo: 9. Son complejas las entradas, las salidas, los archi-
archivos de datos de cinta o disco) que se utilizan vos o las peticiones?
para transmitir informacin a otro sistema. 10. Es complejo el procesamiento interno?
Una vez que se han recopilado los datos anterio- 11. Se ha diseado el cdigo para ser reutilizable?
res, a la cuenta se asocia un valor de complejidad. 12. Estn incluidas en el diseo la conversin y la ins-
Las organizaciones que utilizan mtodos de puntos talacin'?
de funcin desarrollan criterios para determinar si 13. Se ha diseado el sistema para soportar mltiples
una entrada en particular es simple, media o com- instalaciones en diferentes organizaciones?
pleja. No obstante la determinacin de la compleji- 14. Se ha diseado la aplicacin para facilitar los cam-
dad es algo subjetiva. bios y para ser fcilmente utilizada por el usuario?

En realidad, la definicin 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