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 las 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 la 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 - 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 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 MTRICAS DEL PROYECTO

TO La medicin 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 de la 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

Se deberan 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 eficacia de un proceso ya existente (por ejemplo: el para- digma, las tareas de ingeniera del software, productos de trabajo 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 la efectividad de un proceso

de software?

55

INGENIERfA DEL SOFTWARE. UN 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 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 funcin2. El equipo revisa estos datos para detectar los indicadores que pueden mejorar el ren- dimiento del equipo.

l a s 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

C A P ~ T U L O 4 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:

Referenciu Web/ ' MPSE y otra informacin relacionada con la calidad est disponible 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. Se registra 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. Se computa 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. Se desarrollan 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 sohare 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 N G E N I E R ~ A DEL SOFTWARE. UN ENFOQUE PRCTICO

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 la 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 P R O C E S O DEL SOFTWARE Y MTRICAS DEL PROYECTO

.

son privadas para un individuo a menudo se combinan para desarrollar mtricas del proyecto que sean pbli- cas para un equipo de software. Las mtricas del pro- 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- 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 no se conoce el tamao o la complejidad de los proyec- tos, no se puede 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 que se haya producido. Si una organizacin de softwa- re mantiene registros sencillos, se puede crear una tabla de datos 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 que se desarrollaron 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) defectos4 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. Ya que 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.

los 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 una entrada 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?

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

00-Contenido.pdf01-Captulo.pdf02-Captulo.pdf03-Captulo.pdf04-Captulo.pdf05-Captulo.pdf06-Captulo.pdf07-Captulo.pdf08-Captulo.pdf09-Captulo.pdf10-Captulo.pdf11-Captulo.pdf12-Captulo.pdf13-Captulo.pdf14-Captulo.pdf15-Captulo.pdf16-Captulo.pdf17-Captulo.pdf18-Captulo.pdf19-Captulo.pdf20-Captulo.pdf21-Captulo.pdf22-Captulo.pdf23-Captulo.pdf24-Captulo.pdf25-Captulo.pdf26-Captulo.pdf27-Captulo.pdf28-Captulo.pdf29-Captulo.pdf30-Captulo.pdf31-Captulo.pdf32-Captulo.pdf33-Apndice.pdf