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 est ndares establecidos, sino que se pretenda conseguir programas f ciles de mantener y, lo que es m s importante, sistemas fiables en tareas crticas. ! pesar de los avances en las t"cnicas de generacin de cdigo, no se pueden producir programas totalmente libres de errores. #e esta forma, entre las distintas fases del ciclo de desarrollo se van filtrando una serie de errores que obligan a emplear muc$o esfuerzo en su deteccin y correccin. %os errores pueden producirse en cualquier fase del ciclo de vida, pero sus efectos son tanto mayores cuanto m s temprana sea su aparicin. %os errores en la planificacin tienen m s consecuencias de tipo econmico y de gestin que estrictamente t"cnicas, sin embargo los de dise&o pueden producir los mayores problemas al estar en la base del sistema software. %os errores de codificacin con ser los m s conocidos, no son los m s importantes, a pesar de ello, son los m s tratados pues es m s simple automatizar su deteccin. %os errores en las pruebas son muy importantes pues dan por v lido un cdigo que no lo es, y permiten que se entregue un sistema defectuoso. %os errores de mantenimiento pueden deberse a la ignorancia de fallos antiguos o a la introduccin de otros nuevos. %os procedimientos de deteccin de errores de fundamentan en dos procedimientos' las bateras de test sobre el sistema, y las revisiones t"cnicas. Se puede afirmar que cada vez que se e(ecuta un programa, se le est sometiendo a un test. )ero cuando se utiliza un programa no se est agotando el total de posibles situaciones en que puede encontrarse, sino que se traba(a con un con(unto de datos y estado *normales* o $abituales. %a prueba del software se encarga de someter un programa a una revisin de todos los estados posible por los que puede atravesar en alg+n momento de su vida +til. %os tres ob(etivos que dirigen la prueba del software son' %a prueba es un proceso de e(ecucin de un programa con la intencin de descubrir un error. ,n buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto $asta entonces. ,na prueba tiene "-ito si descubre un error no detectado $asta entonces.

Sin embargo, la caracterstica m s destacable de la prueba del software es que la prueba no puede asegurar la ausencia de defectos' slo puede demostrar que e-isten defectos en el software. %a 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. .uando un test falla /esto es, cuando no encuentra errores0 no se est en condiciones de afirmar que el programa probado est libre de defectos, sino que tambi"n puede ocurrir que el test sea incompleto o est mal construido /en una palabra, que contenga errores0. Esto implica que las medidas referidas al n+mero de errores dependa enormemente del proceso de prueba que se $aya seguido, pues dos bateras de test podran detectar distinto n+mero de errores en un mismo programa. El proceso de prueba debe adaptarse al sistema software que vaya a ser validado. )ara simplificar un poco el traba(o del equipo de garanta de calidad se dispone de cierto n+mero de t"cnicas que pueden emplearse dentro de una estrategia de pruebas determinada. ,nos elementos au-iliares de las tareas de prueba cuya importancia crece da a da son las $erramientas autom ticas. 1abitualmente integradas en otras dedicadas al dise&o 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 $erramientas, $aga que el proceso de prueba sea m s fiable, y requiera menos dedicacin por parte de los equipos de desarrollo. )ero no es una buena t ctica esperar al cdigo para determinar su correccin. .omo ya se $a dic$o, los errores producidos tempranamente obligan a emplear muc$os recursos en su reparacin. .on ob(eto de verificar la validez de un dise&o se usan una serie de t"cnicas conocidas como revisiones t"cnicas. %as revisiones se basan en la verificacin manual /por grupos de e-pertos0 de la validez de un dise&o, un programa, o cualquier otro elemento. #ado que se trata de un proceso $umano regido e-clusivamente por consideraciones sub(etivas, las distintas t"cnicas se basan en estrategias que garanticen la imparcialidad de las decisiones, y que favorezcan la obtencin de resultados $omog"neos y mantenibles. %as revisiones se realizan siempre por parte de varias personas, y por esta razn precisan de reglas muy estrictas que eviten consideraciones personales y no t"cnicas. %as 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 m s fiables y mantenibles. En general, la mayor parte de las m"tricas 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. 2tras dos medidas importantes son el n+mero de cambios realizados en el dise&o del software, y el n+mero de cambios realizados en un programa determinado. %os cambios en un programa responden a tres categoras' una o varias modificaciones en una instruccin simple, insercin /o borrado0 de una o m s instrucciones entre dos ya e-istentes, y un cambio del primer tipo seguido de insercin de instrucciones. %a insercin o borrado de comentarios, o lneas en blanco no suele considerarse cambio ya que no afecta a los resultados finales del programa. %a m"trica m s com+n referida a los fallos de un programa es la densidad de fallos o errores' #ensidad de errores 3 n+mero de errores 4 S Siendo S el tama&o del cdigo en n+mero de lneas. Sin embargo, esta medida con ser una referencia importante, no da una idea de la magnitud de un error. 2bviamente, no tiene la misma importancia un error en un programa de edicin de te-tos que en el sistema de navegacin de un avin, y dentro de un mismo sistema, subir o ba(ar un sueldo tendr m s repercusin que el redondeo de las cantidades finales. !lgunos sistemas de prueba dan un valor en forma de *severidad* de un error, pero esta valoracin es en cualquier caso muy sub(etiva. 2tra caracterstica difcil de cuantificar de los errores es la dificultad de encontrarlos. 1ay lengua(es, formas de programar y tipos de errores que complican la tarea de encontrar los problemas del cdigo. %a depuracin y el mantenimiento absorben muc$os recursos que podran reducirse si los errores fueran m s f cilmente localizables. En cuanto a la fiabilidad, $ay que notar que aunque es un concepto prestado de la ingeniera $ardware, no puede tratarse de igual manera en el software. ,n componente $ardware puede fallar de muc$as maneras' por fatiga, sobrecarga, defectos de fabricacin, influencias e-ternas,... Sin embargo, los programas slo pueden fallar si est n mal $ec$os, si el dise&o o la codificacin $an sido defectuosos. !unque un sistema crtico que emplee programas puede fallar por cualquiera de las causas $ardware o software descrito anteriormente, slo se puede atribuir al software aquellos problemas causados por los defectos en su elaboracin. #e esta forma, la fiabilidad es una medida integral de todo el proceso de desarrollo, pues precisa no slo que se $aya asegurado en todo momento la calidad del sistema, sino que adem s el proceso de prueba debe $aber realizado una depuracin perfecta de los errores que pudiera contener. %a fiabilidad emplea varias medidas, la primera de ellas es la probabilidad

5 de que aparezca un error en un tiempo determinado , donde 6 7. %a fiabilidad 8 es la probabilidad de que no ocurra un error en ese intervalo de tiempo' 8/0 3 9 : 5/0 Esto supone que se estudia la fiabilidad a lo largo de un espacio continuo de tiempo, sin embargo, es m s realista a(ustarse al n+mero de veces n que se e(ecuta el programa' 8/n0 3 9 : dn 4n #onde dn es el n+mero de fallos $allados en n e(ecuciones. Si f/0 es la funcin de densidad de probabilidad' f/0 3 d5/0 4 d y f/t0 es la probabilidad de que el software falle en el intervalo /, ; d 0. %a tasa de riesgo $/0 es la probabilidad de que el software falle en / , ; d 0 si no $a fallado antes' $/0 3 f/0 4 / 9 : 5/0 0 #e donde podemos obtener una nueva e-presin para la fiabilidad del software' $/0 3 f/0 4 / 9 : 5/0 03 : d/ ln /9 : 5/0 0 0 4 d 3 : d ln 8/0 4 d

2tra medida de inter"s es el tiempo medio entre fallos /<==5, <ean =ime =o 5aillure0 que se define como'

%a e-presin que relaciona el tiempo medio entre fallos y la fiabilidad de un programa es'

%a figura siguiente muestra tres figuras relacionadas con el estudio de la fiabilidad del software' en /a0 se muestra el $istorial de errores en la vida de un programa> /b0 muestra 5/0, la probabilidad de que aparezca un error en un programa en un

intervalo de tiempo determinado> por +ltimo , en /c0 se muestra f/ 0, la funcin de densidad de probabilidad.

Fig. 1(a). Distribucin de errores del software. Histrico de errores

Fig. 2 (b). Distribucin de errores del software. Funcin distribucin intervalo de errores

Fig. 2 (c). Distribucin de errores del software. Funcin de densidad de probabilidad de errores

?ibliografa
GONZLEZ DORIA, Heidi, Las Mtricas de Software y su Uso e !a Re"i# , $e !% ea& 'ase e (
http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/gonzalez_d_h/capitulo2.pdf

)URSOS*)OM, +u da,e tos de I "e ier%a de Software $e !% ea& 'ase e (

http://148.202.148.5/cursos/cc321/fundamentos/unidad2/tema2_1.html

DE )OSS, A!e-a dro, Mtricas de! Software, $e !% ea& 'ase e (

http:// .gdl!mexcomp.com/"ocuments/metricas#20de#20soft are.pdf

R* S* .ress,a * I "e ier%a de! software* U e fo/ue 0r1ctico* 23 Edici# * McGrawHi!! 456678 Re'ista de .rocesos y Mtricas de !as tec o!o"%as de !a i for,aci# 9o!u,e 5 :,ero 5, a;ri! <==>*