TEMA 2 MTRICAS DEL SOFTWARE

2.1.- Mtricas del software., 2.1.1.- Mtricas de tamao., 2.1.2.- Mtricas de estructuras de control., 2.1.3.- Mtricas compuestas., 2.1.4.- Mtricas de esfuerzo., 2.1.5.- Mtricas de calidad y fiabilidad., 2.1.6.- Mtricas de diseo., 2.1.7.- Otra mtricas del software., 2-1 2-3 2 - 12 2 - 15 2 - 17 2 - 19 2 - 25 2 - 27

2.1.- Mtricas del software. Toda magnitud fsica es susceptible de ser medida. Sin embargo, el software es una actividad fundamentalmente intelectual, no slo en su origen, sino que su resultado final tambin los es. El software no tiene de entidad fsica ms que el soporte que lo registra: el papel, material magntico, los circuitos de la memoria. Las medidas realizadas sobre estos soportes no lo son estrictamente del software, sino que se trata nicamente de referencias indirectas. De ah que muchas medidas del software incidan en aspectos abstractos, que resultan difciles de describir de forma clara. Cuando se miden las magnitudes del software se toman las referencias adecuadas sobre los soportes del software, generalmente el cdigo fuente, y de ah se obtienen cuantificaciones de conceptos tales como legibilidad o dificultad, junto con otras ms accesibles como son el propio tamao fsico del cdigo. Las mtricas del software responden a dos objetivos: valorar y estimar . Las magnitudes objeto de valoracin son tres: la calidad, fiabilidad y productividad. La estimacin parte de mediciones histricas para prever el esfuerzo y el tiempo que debe invertirse en un proyecto dado, y las caractersticas del resultado final. Cualquiera de estas tareas (valoracin y estimacin) resulta tremendamente compleja, a pesar de contar con las mtricas del software. Calidad y fiabilidad son conceptos importados de la ingeniera hardware, pero que en el software tienen un sentido muy distinto. La productividad es un concepto ampliamente desarrollado en otras reas industriales, pero la carencia de un sistema mtrico unificado, y la diversidad de factores que influyen en ella, hacen que tampoco sea posible obtener valoraciones fiables de esa magnitud en el mbito del software. La diversidad de mtricas del software es enorme. Son muchos los autores que han sugerido un sistema mtrico propio. De ah que sea difcil comparar (una de las tareas bsicas de la medicin) los trabajos efectuados hasta la fecha sin contar con un alto grado de incertidumbre e imprecisin. An cuando hay medidas que son generalmente aceptadas (las lneas de cdigo como mtrica de tamao, por ejemplo), no desaparecen los problemas por completo: matices de apreciacin (considerar o no los comentarios y las lneas en blanco) y sistemas de referencia de compatibilidad dudosa (cdigo generado en

2-1

distintos lenguajes) hacen difcil encontrar una referencia consolidada en la que basar las observaciones. A continuacin se enumeran algunas de las mtricas del software ms comunes ordenadas por el mbito del software a que se refiere. A cada una de ellas, podra aadirse una larga serie de variaciones segn los distintos autores, pero se pretende dar una visin de conjunto, ms que hacer una enumeracin exhaustiva. Hay muchas magnitudes que pueden ser medidas en el software: el tamao en lneas de cdigo, el coste monetario del desarrollo, el tiempo de desarrollo en das de trabajo, el tamao de la memoria precisada en bytes, e incluso el nmero de quejas del usuario antes de entregar el producto. Diferentes observadores del mismo producto, pueden obtener distintas medidas, incluso en una misma magnitud. Un tpico ejemplo de esta circunstancia son las lneas de cdigo. Un anlisis puede considerar el nmero total de lneas en el listado, incluyendo las lneas en blanco y las de comentarios. Otro podra ignorarlos dado que no afectan al programa. Otro ms no considerara como lneas contables aquellas copiadas de algn otro sistema (libreras, generadas automticamente, ...). La necesidad de una definicin unificada de las lneas de cdigo, o de cualquier otra medida es una exigencia comn de los ingenieros del software. Una posible clasificacin de las mtricas empleadas para valorar el software aparece en la figura 2.1 y establece dos categoras principales: mtricas del producto, y mtricas del proceso. Las primeras son las que tradicionalmente se han empleado en la medida del software, y pueden ser obtenidas automticamente tomando como entrada el cdigo fuente: tamao, estructuras de datos y lgica. Las mtricas del proceso por su parte dependen esencialmente del entorno de desarrollo. Un ejemplo de este tipo de mtricas es el tiempo empleado para desarrollar un elemento software que depende de distintos factores externos (dificultad del problema, capacidad del personal, metodologa empleada,...).

Tamao

2-2

DEL PRODUCTO

Estructura de datos Lgica .............. Tiempo de desarrollo Reusabilidad Productividad .................

MTRICAS DEL PROCESO

Fig. 2.1. Mtricas del software. Categoras.

Un problema asociado al empleo de mtricas del software es el de comparar medidas diferentes, aunque aparentemente se refieran a la misma magnitud. Slo la definicin precisa de las condiciones y los elementos que intervienen en una medida determinada permitirn que la comparacin de dos valores pueda realizarse con garantas y pueda servir de base a estudios ms completos y fiables. En las siguientes secciones se enumerarn algunas de las mtricas ms difundidas siguiendo la clasificacin mencionada anteriormente. 2.1.1.- Mtricas de tamao. Los programas se escriben en lenguajes muy distintos y con propsitos muy diferentes, usando tcnicas y mtodos dispares, pero con una caracterstica comn: tienen un tamao. Este tamao se determina habitualmente tomando como referencia el programa en cdigo fuente. Podran emplearse otras magnitudes para este propsito (la memoria que se necesita para almacenarlo), pero el tratamiento de un fichero fuente es relativamente sencillo, lo que facilita la sistematizacin y automatizacin del proceso de medida. El tamao es una medida empleada fundamentalmente por tres razones: es fcil de obtener una vez que el programa ha sido completado, es uno de los factores ms importantes en los mtodos de desarrollo, y la productividad se expresa tradicionalmente con el tamao del cdigo. La medida de tamao ms usada es la cantidad de lneas de cdigo que se representa como Ss, y se mide en LOC (Lines Of Code, lneas de cdigo). Para programas grandes es ms adecuado el uso de KLOC (miles de lneas de cdigo) representadas como S. A pesar de que la lnea de cdigo podra suponerse una

2-3

medida simple que puede obtenerse fcilmente no lo es tanto. Para muchos autores, las lneas de cdigo medidas no deben incluir comentarios o lneas en blanco, dado que su presencia o ausencia no afectar al funcionamiento del programa. Adems, incluir comentarios o lneas en blanco no supone el mismo nivel de dificultad que desarrollar una lnea de cdigo. La inclusin de estos elementos en la medida de productividad induce a muchos programadores a producirlos artificialmente con objeto de inflar los resultados dando lugar a elevadas tasas de productividad, generalmente estimada en LOC/PM (lneas de cdigo por Programmer Month, programadores o personas por mes). Por contra, comentarios y lneas en blanco aumentan la legibilidad del cdigo, por lo que facilitan la depuracin de errores y el mantenimiento, si bien es difcil cuantificar en qu grado. Por otra parte, el uso de lenguajes de alto nivel complica la definicin de lneas computables: una instruccin puede extenderse a travs de varias lneas, o dos o ms instrucciones pueden situarse en una nica lnea. Adems, hay elementos del programa que tienen un peso desigual en el resultado final: declaraciones de variables, tipo, constantes, cabeceras de funciones, directivas de preprocesador. Todo esto contribuye a complicar el uso de las lneas de cdigo como mtrica fiable, ante la falta de definiciones estrictas y nicas de esta medida. Una posible solucin a los problemas mencionados anteriormente viene de la mano de la medida de tamao como cuenta de los "tokens" del cdigo fuente. Un token es un elemento de lenguaje que tiene significado por s mismo. Los tokens de un programa son las instrucciones del lenguajes, los identificadores, constantes, operadores delimitadores de comentario y signos especiales del mismo. De esta forma se obtiene una medida ms realista de la cantidad de informacin contenida en el cdigo fuente. Ver para ello la subrutina FORTRAN de la figura adjunta y el anlisis y descomposicin en tokens de la misma en la figura siguiente.

2-4

Lnea
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 SUBROUTINE SORT (X,N) INTEGER X(100), N, I, J, SAVE IM1 THIS ROUTINE SORTS ARRAY X INTO ASCENDING ORDER. IF (N.LT.2) GO TO 200 DO 210 I=2,N IM1=I-1 DO 220 J=1, IM1 IF (X(I).GE.X(J)) GO TO 220 SAVE=X(I) X(I)=X(J) X(J)=SAVE CONTINUE CONTINUE RETURN END Fig. 2.2. Subrutina FORTRAN.

Nivel

C C

220 210 200

1 2 3 3 4 5 5 5 3 2 1

Operadores
SUBROUTINE () ' INTEGER IF .LT. GO TO DO = .GE. CONTINUE RETURN end-of-line n1=14

Ocurrencias
1 10 8 1 2 1 2 2 6 1 1 2 1 13 N1=51

Operandos
SORT X N 100 I J SAVE IM1 2 200 210 1 220

Ocurrencias
1 8 4 1 6 5 3 3 2 2 2 2 3

n2=13

N2=42

Fig. 2.3. Anlisis de tokens de la subrutina de la Fig. 2.2.

La Ciencia del Software de Halstead constituye un sistema mtrico muy original que considera el tamao del cdigo en tokens . Las mtricas bsicas de la Ciencia del Software son: n1 : nmero de operadores diferentes del lenguaje n2 : nmero de operandos diferentes del lenguaje

2-5

N1 : nmero total de operadores N2 : nmero total de operandos

Considerando operadores los smbolos o palabras clave que especifican una accin (instrucciones, signos matemticos, de puntuacin), y operandos los elementos que representan datos (variables, constantes, etiquetas). El tamao de un programa en trminos de tokens se expresa como: N = N1 + N2 Los conflictos entre medidas de tokens surgen a la hora de considerar como uno solo las instrucciones de entrada/salida, las declaraciones y las lneas que contienen etiquetas, o por el contrario computar todos los posibles tokens que puedan aparecer en estas circunstancias. Las reglas usadas para contar tokens dependen mucho del lenguaje en que est escrito un programa. Con frecuencia aparecen ambigedades a la hora de considerar elementos del cdigo en una de las dos categoras de tokens, e incluso al tratar de computarlos como elementos con significado. La Ciencia del Software define algunas otras mtricas adicionales. Por ejemplo el vocabulario se define como: n = n1 + n2 Otra medida basada en las anteriores es el volumen de programa: V = N . log2n La unidad de medida del volumen es el bit. El volumen mide de esta forma el espacio mnimo requerido en memoria para almacenar el programa (suponiendo que cada elemento del vocabulario va a estar representado por un nico nmero binario). Estudios realizados sobre mdulos en lenguajes de alto y bajo nivel han mostrado que Ss, N y V estn linealmente relacionados, y son todas ellas medidas vlidas del tamao de un programa (aparentemente Ss, N y V miden la misma caracterstica del software). N y V son medidas "robustas" de tamao: una variacin significativa de las reglas de clasificacin de operadores y operandos no afectan notablemente al tamao resultante. Algunos autores han sugerido unidades mayores que la lnea de cdigo para medir el tamao de un programa, especialmente cuando el cdigo es muy extenso.

2-6

Una de estas unidades es el mdulo. Para grandes programas, es ms fcil estimar el nmero de mdulos que contendrn, en lugar del tamao en lneas. Sin embargo, esta mtrica aporta una informacin reducida pues es difcil determinar cul es la equivalencia entre mdulos y lneas de cdigo. El tamao de un mdulo depende de su complejidad, de la forma de trabajo de cada programador, del lenguaje y de otros factores. De hecho, cuando se divide el cdigo en mdulos, se hace siguiendo consideraciones funcionales y no de tamao pues el mdulo es una unidad funcional (efecta una tarea determinada), pero no es un mltiplo que contenga una cantidad exacta de lneas de cdigo. Como consecuencia de lo anterior, se ha propuesto como medida del tamao de un programa el nmero de funciones que contiene. Una funcin es una coleccin de instrucciones que realizan una tarea determinada para lo que disponen de un conjunto particular de variables locales. El uso de funciones como mtricas se basa en el hecho de que un programador piensa en el cdigo en trminos de las funciones que debe realizar, y no de los mdulos o lneas que lo constituyen. Un mdulo puede contener una o ms funciones. La evaluacin del nmero de funciones de un programa es una tarea compleja, aunque supone una ayuda el que el programa est estructurado en mdulos. De hecho, los estudios que tratan sobre la estimacin de tamao siguiendo puntos de funcin muestran que la experiencia del evaluador es fundamental a la hora de identificar las funciones de un sistema, y de cuantificar su nmero. El nmero de lneas que contiene una funcin es normalmente pequeo. Una explicacin a este hecho est en las limitaciones de la mente humana que la impiden manipular una gran cantidad de informacin al mismo tiempo. Para algunos autores, el tamao ptimo de un mdulo est entre 50 y 200 LOC, y debe admitirse que cantidades mayores que impiden abarcar de una mirada la totalidad del texto del mdulo, dificultan la comprensin de lo escrito. Los programadores no desarrollan siempre software completamente nuevo. De hecho, buena parte del trabajo de un programador se refiere a la modificacin de cdigo ya existente. En las tareas de mantenimiento este hecho es evidente, pero en el desarrollo, la reusabilidad de cdigo es una prctica aconsejable que reduce el esfuerzo total. Actualmente, segn los casos y reas de aplicacin, entre un 50 y un 95% del trabajo de los programadores es modificacin de programas. Esto plantea

2-7

problemas a la hora de medir el cdigo: no se puede valorar de igual manera el cdigo reusado que el nuevo, y an en el nuevo se debe distinguir entre el que se desarrolla para adaptar el viejo (que exige ms trabajo), y el que es absolutamente nuevo y no depende del cdigo reusado ms que de otras secciones de cdigo nuevo. En muchos programas, el tamao tiene dos componentes: Sn que representa al cdigo nuevo, y Su que es el cdigo reusado. Cualquiera que sean las unidades en las que se mida el tamao, es necesario que un valor Se o tamao equivalente, que sea funcin de Sn y de Su. El tamao equivalente representa el que debera tener el cdigo si no hubiera sido construido con cdigo reusado, esto es, partiendo de cero. Boehm propone para su modelo COCOMO (que se ver ms adelante) la siguiente relacin: Se = Sn + a/100 Su donde a es un factor de ajuste que depende del porcentaje de modificacin que haya sufrido el diseo (DM) y el cdigo (CM), y del esfuerzo preciso para la integracin (IM): a = 0,4(DM)+0,3(CM)+O,3(IM) El valor mximo que puede tomar a es 100, y representa el caso en que la adaptacin del cdigo sea tan difcil como reescribirlo por completo. Una frmula similar es la propuesta por Bailey y Basili : Se = Sn + k Su y sugieren el valor k = 0,2 obtenido de la base de proyectos evaluados para su modelo. Sin embargo, fijar un valor para k a priori, no es realista, y no debe pasar de una primera aproximacin al problema. Thebaut modifica la frmula anterior aventurando que la relacin entre tamao equivalente y cdigo reusado no es lineal: Se = Sn + Suk donde k es un positivo menor o igual que 1. Usando bases de proyectos en la que tanto Sn como Su estaban disponibles, Thebaut obtuvo valores de k en torno a 6/7. En este caso:

2-8

Su6/7 > 0,25 En cualquier caso, no hay consenso acerca de lo que mide exactamente el tamao equivalente. Aunque las frmulas de este tipo son realmente tiles a la hora de establecer comparaciones entre sistemas distintos. Mtricas de estructuras de datos. Una de las razones fundamentales de la programacin es el proceso de datos. Parte de estos datos constituyen la entrada del sistema, parte tiene un uso exclusivamente interno y, por ltimo, una tercera parte constituye la salida del sistema. As pues, disponer de un conjunto de mtricas con el que medir la cantidad de datos usado en la entrada, la salida, e internamente resultar de utilidad para valorar el software. Este conjunto es el formado por las mtricas de estructuras de datos que atienden a la cantidad de datos, al uso que se les da, y a su aparicin en distintas partes del sistema. Un mtodo para determinar la cantidad de datos es contar las entradas de la tabla de referencias cruzadas asociada al cdigo. Esta tabla contiene fundamentalmente las variables del programa, aunque tambin puede incluir otros elementos como etiquetas, tipos, o el propio nombre del programa. En general, se puede considerar datos de un programa todos aquellos elementos no pertenecientes al lenguaje (instrucciones, signos, operadores, constantes de todo tipo) que aparecen a lo largo del cdigo. Una primera medida de cantidad de datos es VARS, que representa el nmero de variables de un programa. La mtrica n2 de Hasteald es vlida tambin para estimar la cantidad de datos: n2 = VARS + constantes nicas + etiquetas n2 representa la cuenta de operandos distintos, por lo que no resulta estrictamente una mtrica que contenga la cantidad total de datos. Con objeto de subsanar esta carencia, Hasteald propone N2, que representa el nmero total de ocurrencias de operandos. Otro aspecto importante a la hora de valorar la informacin (los datos) usada por un programa es estudiar la forma en que se emplea. Estas mtricas estn orientadas al uso de mdulos, y refieren informacin concerniente al uso de la

2-9

informacin. Pero la cantidad de variables y operandos no aporta informacin sobre la complejidad del programa o su construccin. El proceso de programacin, que depende casi en exclusiva del esfuerzo humano, debe contar con las limitaciones de la mente. Una de estas limitaciones se refiere a la cantidad de informacin diferente que puede tener una persona "en mente" al tiempo que realiza una tarea determinada. El concepto de variables vivas en una instruccin determinada representa esta limitacin. Las variables tienen un periodo de vida que empieza con su primer uso (no con la declaracin) y termina con la ltima mencin que se hace de una de ellas. El nmero de variables vivas en una instruccin determinada indica la cantidad de informacin que el programador debe tener presente al construir el cdigo. LV (variables vivas) indica la complejidad del cdigo en un punto determinado (al margen de la propia complejidad del algoritmo desarrollado). Una medida global referida a todo el cdigo sera el nmero medio de variables vivas por instruccin ( LV ) que puede servir como referencia en comparaciones entre distintos programas. Otra mtrica que estudia el uso que se hace de los datos es la envergadura (SP, span) que representa el nmero de instrucciones entre dos usos de una misma variable. Grandes envergaduras requieren del programador que retenga en memoria durante mucho tiempo la informacin referida a una variable sin darle uso. La envergadura adquiere sentido plenamente cuando se usa su valor medio (SP ) referido a las variables. Las dos mtricas anteriores se refieren habitualmente a mdulos. El paso a mtricas globales de todo el programa se obtiene fcilmente:

LV programa =

LV m
i i =1

donde LVi es la vida media de las variables del mdulo i-simo, y m es el nmero de mdulos.

SPprograma =

SP n
i i =1

donde n es el nmero de posibles envergaduras del programa. Las mtricas de datos mostradas hasta ahora se refieren exclusivamente (salvo las generalizaciones) al espacio de un mdulo. Sin embargo, los datos no estn siempre limitados a un rea determinada del cdigo: es una prctica habitual el uso de datos comunes a varios mdulos. La magnitud del flujo de informacin

2 - 10

entre los componentes de un sistema da informacin adicional sobre la complejidad del diseo y las relaciones entre mdulos. En teora, todos los mdulos estn interrelacionados, si no es as, no pertenecen al mismo programa. Pero el grado de relacin entre mdulos depende de la cantidad de datos que constituya el flujo de informacin entre ellos. Este flujo puede estar formado por parmetros, o variables globales. En este ltimo caso, la complejidad del programa es mayor y resulta ms difcil comprender su funcionamiento. En el otro extremo estn las variables locales cuya vida discurre en los lmites del mdulo, por lo que su evolucin es ms fcil de prever. Del estudio de Basili y Turner se extraen dos mtricas referidas a esta cuestiones. La primera es el par de uso local -global (P, R) que representa una instancia de un mdulo P que usa a la variable R (P lee o escribe el valor de R). El nmero total de pares entre los mdulos y las variables globales da una medida de la complejidad de la forma en que comparten los datos. La segunda mtrica aporta informacin sobre la forma en que los mdulos comparten informacin, y se representa por medio de tres valores: (P, R, Q) que indica que el dato R adquiere su valor en el mdulo P y se lee en Q. Para que exista (P, R, Q) deben existir los pares (P, R) y (Q, R). Otra medida que expresa la complejidad de los datos compartidos es la llamada fan-in (HENR81). Se supone que R puede ser tanto una variable global como un parmetro entre dos mdulos, y el fan-in de un mdulo Q es el nmero de mdulos P que cumplen alguna de las siguientes condiciones:

Existe una variable R que verifica (P, R, Q). Existe un mdulo T y unas variables R y S tales que (P, R, T) y (T, S, Q).

El fan-in de un mdulo es el nmero de mdulos que directamente o indirectamente le pasan alguna informacin. De forma similar, es posible definir el fan-out como el nmero de mdulos a los que directa o indirectamente pasa informacin un mdulo determinado. 2.1.2.- Mtricas de estructuras de control. La estructura lgica de un programa es el mecanismo que le permite realizar las distintas funciones para las que fue construido. La estructura lgica del

2 - 11

programa representa los algoritmos empleados en su diseo y procesa los datos (la expresin "Algoritmos + Estructuras de Datos = Programas" WIRT76 es una estupenda definicin de programa). La estructura de un algoritmo se representa perfectamente con las grficas denominadas diagramas de flujo. Son muchos los mtodos de medicin del software que se basan en estos diagramas. El flujo de control en un programa es habitualmente secuencial, aunque puede ser interrumpido en ciertas ocasiones:

En una decisin, se divide en dos nuevas lneas de flujo que responden a la evaluacin de una condicin determinada. Un salto hacia atrs devuelve el flujo de control a una instruccin que ya ha sido ejecutada. Normalmente son la base de los bucles. Una transferencia de control a una rutina o procedimiento externo, hace que el flujo discurra por un camino externo al programa.

La mtrica denominada cuenta de decisin (DE) mide la cantidad de veces que ocurren situaciones como las mencionadas en primer y segundo lugar. Esto es, cuenta el nmero de instrucciones de decisin y bucles condicionales. A la hora de contar decisiones debe tenerse en cuenta los casos en que estas son compuestas, en esta situaciones DE cuenta predicados ms que instrucciones en s, por lo que las situaciones en las que se usan los operadores AND y OR incrementan en ms de uno el valor de DE (algo similar ocurre con instrucciones del tipo CASE). Una mtrica ms sofisticada referida a esta misma cuestin es el nmero de complejidad ciclomtica (v(G)). Esta medida est orientada a valorar el nmero de caminos linealmente independientes de un programa, lo que est relacionado con la facilidad para probar y mantener el cdigo. Una aproximacin al valor del nmero ciclomtico se obtiene de la siguiente expresin: v(G) = e - n + p donde e es el nmero de lneas del diagrama de flujo, n es el nmero de nodos, y p el total de elementos interconectados (figura 6.10). Otra aproximacin sugiere que el nmero de elementos interconectados es siempre dos (inicio y final), por lo que : v(G)= e - n + 2

2 - 12

El nmero de complejidad ciclomtica puede asimilarse al nmero de lneas que constituiran el "esqueleto" de un diagrama cuyo flujo se ha simplificado al mximo. El diagrama ms simple, que es aquel que posee un slo camino, presenta un v(G) = 1. Un posible lmite de complejidad estara en torno a v(G) = 10, ms all de esta cifra, las tareas de prueba y mantenimiento resultan muy complicadas. Si t representa el nmero de predicados, se puede demostrar que e - n = t- 1 v(G) = e - n + 2 = t + 1 dado que t y DE son prcticamente la misma cosa: v(G) = DE + 1

e = 14 n = 12 v(G) = 14 - 12 + 2 = 4

e = 10 n=8 v(G) = 10 - 8 + 2 = 4

Fig. 2.4: Nmeros ciclomticos de dos diagramas de flujo.

Por otra parte, tambin se puede demostrar que la complejidad ciclomtica de un programa formado por varios mdulos, es igual a la suma de las distintas complejidades. Si m es el nmero de mdulos:

2 - 13

v( Gprog) =
y de aqu:

v( G i ) =
i =1 m

e n
i i =1 i =1

+ 2m

v( Gprog ) =

DE
i =1

+m

La entropa es otra medida relacionada con la complejidad y el anlisis de diagramas de flujo. La expresin general es:

Zn =

log
i =1

n-1

(pi X + q j ) ; X = 2

donde qi es la probabilidad de que el elemento de decisin i-simo (smbolo IFTHEN) est en serie con el anterior. Por su parte pi es igual a 1 menos la cantidad anterior. Zn est relacionada con MIN, el nmero de regiones delimitadas por un diagrama de flujo. En una sola lnea de flujo MIN vale 1, con un bucle o una decisin es 2, con varias decisiones anidadas su clculo se complica y la entropa da una expresin ms exacta que el clculo manual. La entropa ha querido ser la mtrica de unin entre complejidad y productividad. Actualmente varias herramientas de medida del software la emplean para valorar la complejidad frente a mtricas ms clsicas como el nmero de complejidad ciclomtica. Otras mtricas referidas a la estructura de un programa son el nmero mnimo de caminos Np y la accesibilidad del cdigo R. Obviamente, el nmero de posibles caminos en un cdigo que contenga bucles es infinito, sin embargo, Np no toma en consideracin aquellos caminos que se repiten ms de una vez. Por su parte, la accesibilidad del cdigo se obtiene dividiendo el nmero total de caminos entre el nmero de nodos. En relacin a otras unidades del software, siempre se verifica que Np v(G). El nivel de anidamiento (NL) es una mtrica de complejidad que afecta a lenguajes de alto nivel. Cada instruccin tiene un nivel de anidamiento determinado, y el nivel medio que define un programa ( N L ) se obtiene aplicando recursivamente el siguiente procedimiento:

La primera instruccin ejecutable recibe el nivel 1. Si la instruccin a est en el nivel n y la instruccin b la sigue secuencialmente, su nivel tambin ser n.

2 - 14

Si la instruccin a est en el nivel n y la instruccin b est en un bucle o pertenece a una condicin definida por a, el nivel de b ser n+1.

Una mtrica ms de complejidad relacionada con la construccin del software es la cuenta de transferencias incondicionales del control. Dado que el seguimiento de las acciones de un programa a la hora de la prueba y el mantenimiento debe hacerse manualmente, y que resulta difcil averiguar que es lo que hace un cdigo en el que abundan los saltos (representados por instrucciones GOTO), el nmero absoluto de stos es una medida de complejidad. El nmero medio de saltos por mdulo, o de instrucciones entre dos saltos sirve como referencias a la hora de comparar cdigo de orgenes diversos. 2.1.3.- Mtricas compuestas. Las medidas descritas hasta ahora miden una nica magnitud para darle sentido como una caracterstica del software. Sin embargo, ocurre con frecuencia que para describir una determinada cualidad del software es preciso componer (construir un par) de medidas simples. Una medida alternativa a la complejidad ciclomtica es la formada por el par (CYC-mid, CYD-max) donde:

CYC-min es el nmero total de instrucciones condicionales y bucles (incluyendo instrucciones CASE). CYC-mid es igual a CYC-min ms un nmero igual a 2 menos el nmero de selecciones de una instruccin CASE. CYC-max es igual a CYC-mid ms los operadores lgicos de una instruccin condicional (es equivalente a V(G).

Las medidas compuestas ms conocidas son las de la Ciencia del Software de Halstead. Este conjunto de mtricas dispone de las medidas simples (N1, N2, n1 y n2 ) ya mostradas y de otras compuestas basadas en stas. La longitud estimada de programa (^N) depende nicamente del nmero de operadores y operandos distintos ( N = N1 + N2 ). El valor calculado para este valor proviene de la siguiente expresin:

2 - 15

^N = n1 . log2 n1 + n2 . log2 n2 el volumen de un programa es definido por Halstead como: V = N . log2 n que se puede interpretar como el nmero de "comparaciones mentales" necesarias para escribir un programa de longitud N. Esta interpretacin sugiere que la mente humana sigue un proceso de bsqueda binaria para seleccionar un token de un vocabulario de tamao n. Un algoritmo puede ser interpretado por varios programas equivalentes. Entre otros programas, uno tiene el volumen mnimo, tambin llamado volumen potencial (V*). Halstead indica que la implementacin mnima de un algoritmo es una llamada a un procedimiento desarrollado previamente. La implementacin de este algoritmo requerir tan slo invocar el procedimiento y enviar y recibir los parmetros de entrada y salida. El volumen potencial se calcula como: V* = (2+n2* ) log2 (2 + n2*) El primer trmino entre parntesis, 2, representa los dos elementos mnimos de la llamada al procedimiento (el nombre y el signo que le separa de sus parmetros). Un programa de volumen V est implementado a un nivel del programa L que se expresa como: L = V* / V Al inverso del nivel de programa, Halstead le denomina dificultad D. Si el volumen V de una implementacin aumenta, el nivel de programa decrece y la dificultad se incrementa. Una frmula alternativa al clculo de nivel de programa se obtiene de: L = 2 / n1 . n2 / N2 Una hiptesis de la Ciencia del Software dice que el esfuerzo preciso para implementar un programa se incrementa cuando el tamao del programa crece. El esfuerzo segn Halstead se obtiene de: E = V / L = D . V = n1 N2 N (log2 n) /2 n2

2 - 16

La unidad empleada para el esfuerzo es el nmero de discriminaciones mentales elementales. Tomando como base que la mente humana es capaz de realizar un nmero mximo de discriminaciones por segundo (5 a 20, normalmente 18), se puede obtener el tiempo de programacin total como: T = E / Existen numerosos lenguajes de programacin. Comparar las caractersticas de unos y otros es una tarea compleja. Con objeto de obtener una referencia vlida entre lenguajes, Halstead propone como resultado de un estudio sobre una serie de lenguajes, la mtrica nivel de lenguaje : = L . V* = L V Algunos valores obtenidos por este mtodo son: Pascal Algol Fortran Ensamblador : 1.53 : 1.21 : 1.14 : 0.88

Sin embargo, se detecta, segn los estudios, variaciones en torno a 1, lo que da una idea de la fluctuacin de estas "constantes". 2.1.4.- Mtricas de esfuerzo. El desarrollo del software es una actividad humana que depende en gran medida del trabajo personal. A la hora de valorar un sistema software debe considerarse la cantidad de esfuerzo que debe invertir el equipo de desarrollo para culminar su construccin. El coste del desarrollo es prcticamente el del trabajo empleado, pues la parte asignada a materiales es de tan poca entidad que resulta despreciable frente a la mano de obra. El esfuerzo requerido para construir un sistema puede ser medido con muchas unidades. Desde las discriminaciones mentales de Halstead, hasta el nmero real de horas y minutos que invierte un programador, la variedad es enorme, sin embargo hay una medida que destaca por su universalidad: la personames o meses -hombre. Por otra parte, aunque el esfuerzo es muy importante, en realidad la ms importante mtrica del esfuerzo es el coste.

2 - 17

La importancia de la medida del esfuerzo y coste responde ms a necesidades de tipo administrativo y de gestin que estrictamente tcnicas. Pero por ello no deben menospreciarse: el aspecto econmico del software, que es el que subyace a la gestin, determina la viabilidad de los proyectos. El conocimiento del esfuerzo invertido ayuda a valorar la productividad y a preparar las medidas de correccin oportunas para mejorar el trabajo del equipo y, estimar las necesidades de futuros proyectos. La precisin de la medida viene determinada por el tipo de aplicacin. No puede medirse de igual manera el esfuerzo y coste invertido en un proyecto pequeo, unipersonal, que el precisado para llevar adelante un proyecto grande, desarrollado por un equipo de trabajo formado por muchas personas. Los proyectos pequeos son completados habitualmente por una sola persona en unos pocos das o semanas. Por ello, las unidades temporales ms adecuadas seran los minutos, horas, o como muchos, los das. As, el esfuerzo se mide en personas-da. A esta escala, el aprovechamiento de la jornada laboral resulta muy importante. Las posibles interrupciones a lo largo de un da de trabajo son innumerables: llamadas telefnicas, pequeos descansos, comentarios con otras personas, distracciones,... Y tienen un reflejo inmediato en el rendimiento personal. De ah que se opte por medir el tiempo de trabajo a "reloj parado", pasando por alto las interrupciones al trabajo. Otro elemento importante al trabajar a escala reducida es el tiempo de comprensin y aprendizaje que el programador requiere para comprender los requerimientos, el diseo, o cualquier documento previo a la codificacin. Aprender a manejar las herramientas y lenguajes, conocer los interfaces, la metodologa empleada, etc... supone retrasos importantes en proyectos unipersonales. Los proyectos habituales en la industria, en la investigacin, o en entornos acadmicos, envuelven a equipos de trabajo formados por varias personas (a veces muchos equipos y muchas personas) durante perodos largos de tiempo: meses y aos. De esta forma, las unidades ms adecuadas para medir el esfuerzo, son las personas-mes, y personas-ao. En estos proyectos hay que asignar recursos materiales y personales diferenciados a tareas que se realizaban conjuntamente en un proyecto unipersonal: diseo, prueba, documentacin,... Esta especializacin

2 - 18

obliga tambin a aislar las tareas administrativas, y grupos especiales de trabajo se encargan de coordinar, planificar, monitorizar, y gestionar el proyecto. La intensidad en el trabajo no es mantenida por largos periodos de tiempo. Las interrupciones de todo tipo son tan numerosas y habituales que no son un factor de ruptura importante. Los tiempos de aprendizaje son grandes y afectan a todo el equipo. En resumen, los elementos que determinaban claramente a un proyecto pequeo no tienen esa importancia en uno grande. La medida del trabajo realizado, que en proyectos pequeos puede llevarse a cabo ntegramente por observadores externos, precisa ahora de la colaboracin de los participantes. En muchas organizaciones, los componentes del equipo de desarrollo estn obligados a rellenar diariamente formularios en los que registrar su actividad diaria. Estos formularios contienen impresiones subjetivas de cada persona, y no suponen en muchos casos una referencia vlida para medir el esfuerzo invertido. Las valoraciones de esfuerzo resultan as poco exactas, y a pesar de la enorme importancia que se les atribuye, no pasan de constituir una referencia aproximada a los valores reales, difciles de someter a medida. 2.1.5.- Mtricas de calidad y fiabilidad. El estudio de la calidad y fiabilidad tiene una importancia cada vez mayor en el mundo de la Ingeniera del Software. No slo se trata de obtener sistemas desarrollados correctamente, de acuerdo a los requerimientos y a los estndares establecidos, sino que se pretende conseguir programas fciles de mantener y, lo que es ms importante, sistemas fiables en tareas crticas. A pesar de los avances en las tcnicas de generacin de cdigo, no se pueden producir programas totalmente libres de errores. De esta forma, entre las distintas fases del ciclo de desarrollo se van filtrando una serie de errores que obligan a emplear mucho esfuerzo en su deteccin y correccin. Los errores pueden producirse en cualquier fase del ciclo de vida, pero sus efectos son tanto mayores cuanto ms temprana sea su aparicin. Los errores en la planificacin tienen ms consecuencias de tipo econmico y de gestin que estrictamente tcnicas, sin embargo los de diseo pueden producir los mayores problemas al estar en la base del sistema software. Los errores de codificacin, con ser los ms conocidos, no son los ms importantes, a pesar de ello, son los

2 - 19

ms tratados pues es ms simple automatizar su deteccin. Los errores en las pruebas son muy importantes pues dan por vlido un cdigo que no lo es, y permiten que se entregue un sistema defectuoso. Los errores de mantenimiento pueden deberse a la ignorancia de fallos antiguos o a la introduccin de otros nuevos. Los procedimientos de deteccin de errores de fundamentan en dos procedimientos: las bateras de test sobre el sistema, y las revisiones tcnicas . Se puede afirmar que cada vez que se ejecuta un programa, se le est sometiendo a un test. Pero cuando se utiliza un programa no se est agotando el total de posibles situaciones en que puede encontrarse, sino que se trabaja con un conjunto de datos y estado "normales" o habituales. La prueba del software se encarga de someter un programa a una revisin de todos los estados posible por los que puede atravesar en algn momento de su vida til. Los tres objetivos que dirigen la prueba del software son:

La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene xito si descubre un error no detectado hasta entonces.

Sin embargo, la caracterstica ms destacable de la prueba del software es que la prueba no puede asegurar la ausencia de defectos: slo puede demostrar que existen defectos en el software. La afirmacin anterior da la verdadera dimensin del proceso de prueba: slo se puede demostrar que el software es errneo, y no que sea completamente correcto. Cuando un test falla (esto es, cuando no encuentra errores) no se est en condiciones de afirmar que el programa probado est libre de defectos, sino que tambin puede ocurrir que el test sea incompleto o est mal construido (en una palabra, que contenga errores). Esto implica que las medidas referidas al nmero de errores dependa enormemente del proceso de prueba que se haya seguido, pues dos bateras de test podran detectar distinto nmero de errores en un mismo programa. El proceso de prueba debe adaptarse al sistema software que vaya a ser validado. Para simplificar un poco el trabajo del equipo de garanta de calidad se dispone de cierto nmero de tcnicas que pueden emplearse dentro de una

2 - 20

estrategia de pruebas determinada. Unos elementos auxiliares de las tareas de prueba cuya importancia crece da a da son las herramientas automticas. Habitualmente integradas en otras dedicadas al diseo y la codificacin, se basan esencialmente en el uso de bateras de datos de entrada que comparan con listas de salidas correctas. Es de esperar que en el futuro, el progresivo perfeccionamiento de estas herramientas, haga que el proceso de prueba sea ms fiables, y requiera menos dedicacin por parte de los equipos de desarrollo. Pero no es una buena tctica esperar al cdigo para determinar su correccin. Como ya se ha dicho, los errores producidos tempranamente obligan a emplear muchos recursos en su reparacin. Con objeto de verificar la validez de un diseo se usan una serie de tcnicas conocidas como revisiones tcnicas . Las revisiones se basan en la verificacin manual (por grupos de expertos) de la validez de un diseo, un programa, o cualquier otro elemento. Dado que se trata de un proceso humano regido exclusivamente por consideraciones subjetivas, las distintas tcnicas se basan en estrategias que garanticen la imparcialidad de las decisiones, y que favorezcan la obtencin de resultados homogneos y mantenibles. Las revisiones se realizan siempre por parte de varias personas, y por esta razn precisan de reglas muy estrictas que eviten consideraciones personales y no tcnicas. Las revisiones y la prueba del software son procesos laboriosos que producen una gran cantidad de documentacin, pero que tienen como recompensa, la obtencin de resultados, si no libres completamente de errores, si al menos ms fiables y mantenibles. En general, la mayor parte de las mtricas dedicadas al estudio de la calidad y fiabilidad se basan en contar los errores o fallos. Errores que no tienen que ser necesariamente incorrecciones del cdigo, sino cualquier elemento que aparte los resultados finales de lo especificado en los requerimientos. Otras dos medidas importantes son el nmero de cambios realizados en el diseo del software, y el nmero de cambios realizados en un programa determinado. Los cambios en un programa responden a tres categoras: una o varias modificaciones en una instruccin simple, insercin (o borrado) de una o ms instrucciones entre dos ya existentes, y un cambio del primer tipo seguido de insercin de instrucciones. La insercin o borrado de comentarios, o lneas en blanco no suele considerarse cambio ya que no afecta a los resultados finales del programa.

2 - 21

La mtrica ms comn referida a los fallos de un programa es la densidad de fallos o errores: densidad de errores = nmero de errores / S siendo S el tamao del cdigo en nmero de lneas. Sin embargo, esta medida con ser una referencia importante, no da una idea de la magnitud de un error. Obviamente, no tiene la misma importancia un error en un programa de edicin de textos que en el sistema de navegacin de un avin, y dentro de un mismo sistema, subir o bajar un sueldo tendr ms repercusin que el redondeo de las cantidades finales. Algunos sistemas de prueba dan un valor en forma de "severidad" de un error, pero esta valoracin es en cualquier caso muy subjetiva. Otra caracterstica difcil de cuantificar de los errores es la dificultad de encontrarlos. Hay lenguajes, formas de programar y tipos de errores que complican la tarea de encontrar los problemas del cdigo. La depuracin y el mantenimiento absorben muchos recursos que podran reducirse si los errores fueran ms fcilmente localizables. En cuanto a la fiabilidad, hay que notar que aunque es un concepto prestado de la ingeniera hardware, no puede tratarse de igual manera en el software. Un componente hardware puede fallar de muchas maneras: por fatiga, sobrecarga, defectos de fabricacin, influencias externas,... Sin embargo, los programas slo puede fallar si estn mal hechos, si el diseo o la codificacin han sido defectuosos. Aunque un sistema crtico que emplee programas puede fallar por cualquiera de las causas hardware o software descritas anteriormente, slo se puede atribuir al software aquellos problemas causados por los defectos en su elaboracin. De esta forma, la fiabilidad es una medida integral de todo el proceso de desarrollo, pues precisa no slo que se haya asegurado en todo momento la calidad del sistema, sino que adems el proceso de prueba debe haber realizado una depuracin perfecta de los errores que pudiera contener. La fiabilidad emplea varias medidas, la primera de ellas es la probabilidad F de que aparezca un error en un tiempo determinado , donde > 0. La fiabilidad R es la probabilidad de que no ocurra un error en ese intervalo de tiempo: R() = 1 - F()

2 - 22

esto supone que se estudia la fiabilidad a lo largo de un espacio continuo de tiempo, sin embargo, es ms realista ajustarse al nmero de veces n que se ejecuta el programa: R(n) = 1 - dn /n donde dn es el nmero de fallo hallados en n ejecuciones. Si f() es la funcin de densidad de probabilidad: f() = dF( ) / d y f(t) es la probabilidad de que el software falle en el intervalo ( , + d ). La tasa de riesgo h() es la probabilidad de que el software falle en ( , + d ) si no ha fallado antes: h() = f() / ( 1 - F() ) de donde podemos obtener una nueva expresin para la fiabilidad del software: h() = f() / ( 1 - F() )= - d( ln (1 - F() ) ) / d = - d ln R( ) / d

ln R ( ) =

z
0

h (x)dx , y finalmente : R ( ) = e

z
0

h ( x ) dx

Otra medida de inters es el tiempo medio entre fallos (MTTF , Mean Time To Faillure) que se define como:

MTTF = 1 n

t
i=1

La expresin que relaciona el tiempo medio entre fallos y la fiabilidad de un programa es:

MTTF =

z
0

R( t )dt

La figura siguiente muestra tres figuras relacionadas con el estudio de la fiabilidad del software: en (a) se muestra el historial de errores en la vida de un programa; (b) muestra F( ), la probabilidad de que aparezca un error en un programa en un intervalo de tiempo determinado; por ltimo , en (c) se muestra f(), la funcin de densidad de probabilidad.
t1 l t2 l t3 l t4 l t5 l

2 - 23

Fig. 2.5(a). Distribucin de errores del soft. Histrico de errores

1 F( ) = P[t<= ]

Fig. 2.5(b). Distribucin de errores del soft. Funcin distribucin intervalo de errores

f( ) = P [t< ]

Fig. 2.5(c). Distribucin de errores del soft. Funcin de densidad de probabilidad de errores

2.1.6.- Mtricas de diseo. Como ya se ha visto por las distintas mtricas estudiadas, la complejidad de un programa crece con su tamao: los programas largos son ms difciles de escribir y comprender, contienen habitualmente ms errores, y su d epuracin resulta ms compleja. Con objeto de reducir esta complejidad, los diseadores de software han hecho un uso progresivo de tcnicas de modularizacin y diseo estructurado. Entre las diversas ventajas de las tcnicas de diseo se pueden destacar las siguientes:

2 - 24

Comprensibilidad: programadores y usuarios pueden comprender fcilmente la lgica del programa. Manejabilidad: los gestores pueden asignar fcilmente personal y recursos a los distintos mdulos representados por tareas. Eficiencia: el esfuerzo de implementacin puede reducirse. Reduccin de errores: los planes de prueba se simplifican notablemente. Reduccin del esfuerzo de mantenimiento: la divisin en mdulos favorece que las distintas funciones las lleven a cabo mdulos diferenciados.

Aunque estos beneficios tambin son discutidos y para ello se alega toda clase de inconvenientes, en general se admite que el paso a la modularidad es un gran salto adelante. Pero el problema que se plantea ahora se refiere a los mdulos en si: Cul es el tamao idneo, la complejidad mxima, la extensin adecuada de un mdulo? Algunas de las mtricas vistas hasta el momento tratan este problema. As algunos autores estiman que el tamao de un mdulo debe oscilar entre las 50-200 lneas de cdigo. Otros simplemente indican que un mdulo debe completar una funcin por s solo. La complejidad lmite de un mdulo se fija en algunos casos en un nmero de complejidad ciclomtica igual a 10. Otras discusiones se centran en la organizacin de los mdulos en el programa: estructuras en rbol, o lineales. Con objeto de obtener una valoracin de los mdulos y una disposicin que pueda emplearse como base para comparaciones, surgen las mtricas orientadas al diseo. Muchas de estas mtricas son generalizaciones de otras referidas a mbitos ms restringidos (nmeros de complejidad ciclomtica, mtricas de la ciencia del software,...) Uno de los estudios ms completos relativos a la cuestin de valorar los mdulos software es el llevado a cabo por Troy y Zweben en el que se relaciona una serie de mtricas bsicas con valores de calidad representados por la tasa de modificaciones en pruebas . En este estudio, un gran sistema fue dividido en mdulos usando varias convenciones de diseo. Cada mdulo se codific, prob y prepar para la

2 - 25

integracin. Se registraron los cambios realizados en cada mdulo. Cada implementacin de diseo se acompa de un grfico que representaba las interconexiones entre los mdulos. En total se obtuvieron veintiuna mtricas asociadas a cada grfico. Los principios que dirigen estas mtricas son:

Acoplamiento: Se mide como el nmero de interconexiones entre mdulos. El acoplamiento crece con el nmero de llamadas, o con la cantidad de datos compartidos. Se supone que un diseo con un acoplamiento alto puede contener ms errores. Se cuantifica como el nmero de conexiones por nodo del grfico de diseo. Cohesin: Valora las relaciones entre los elementos de un mdulo. En un diseo cohesivo, las funciones estn ubicadas en un solo mdulo. Los diseos con una cohesin baja contendrn ms errores. Las medidas que valoren la informacin compartida entre mdulos cuantificarn la cohesin. Complejidad: Un diseo debe ser lo ms simple posible. La complejidad crece con el nmero de construcciones de control, y el nmero de mdulos de un programa. Un diseo complejo contendr ms errores. La complejidad se evidencia en el nmero de elementos del grfico de diseo. Modularidad: El grado de modularidad afecta a la calidad del diseo. Es preferible un exceso a un defecto de modularidad, pues en este ltimo caso contendr ms errores. La cuantificacin de la modularidad se obtiene midiendo la cantidad de elementos del grfico. Tamao: Un diseo con grandes mdulos, o gran profundidad en su grfico contendr ms errores. De hecho, complejidad y tamao estn muy relacionados y las consecuencias de un exceso de cualquiera de los dos principios tiene los mismo resultados.

Las conclusiones finales del estudio sugieren que a pesar de la correlacin encontrada entre los factores estudiados y los errores encontrados, sigue habiendo una serie de factores no detectados que determinan a su vez la calidad de un diseo. De todas formas es posible afirmar que las interconexiones entre mdulos, y la complejidad de los diseos aumentan notablemente los errores, y disminuyen la calidad.

2 - 26

2.1.7.- Otra mtricas del software. Adems de las mencionadas, existen algunos otras mtricas que valoran ciertos aspectos del software. Las mtricas de reusabilidad tratan de medir el grado en que un elemento software puede ser empleado por otros programas, en otras palabras, su independencia. Debido a que es difcil valorar objetivamente esta independencia, la referencia ms comn es la independencia del hardware expresada en nmero de cambios en el cdigo al adaptar un programa a una nueva plataforma. Esta medida puede ampliarse al nmero de cambios realizados en el cdigo por lneas al adaptarlo a un nuevo sistema operativo, o a un nuevo sistema grfico. Las mtricas de portabilidad valoran aspectos muy similares. Las mtricas de mantenibilidad se enuncian como funcin de los valores de concisin, consistencia, instrumentacin, modularidad, autodocumentacin y simplicidad. Las mtricas de testeabilidad (o capacidad de probar el software) son funcin de la auditabilidad (capacidad de someter el software a auditora), la complejidad de software (ciclomtica, contando los GOTO y bucles, o segn los valores de la Ciencia del Software), instrumentacin, modularidad, autodocumentacin y simplicidad. Las de flexibilidad tienen como componentes a la complejidad, la concisin, la consistencia, la expandibilidad, la generalidad, la autodocumentacin, y la simplicidad. La interpretacin que se da de los componentes de cada una de estas mtricas es, no obstante, discutible e imprecisa, sin un mtodo definido para obtener una valoracin. Tambin se carece de expresiones que determinen el peso que cada componente tiene en la mtrica.

2 - 27