UNIV€RSIDAD AUTONOMA M€TROPOlITANA

UNIV€RSIDAD AUTONOMA M€TROPOlITANA -

c a s a m d m ’ Ciencias Básicas e Ingenieria UNIDAD IZTAPALAPA

i

J c c Medida y EvdludciÓn de la Culidad del Software ”

T E S I S

ING€NI€RO €N €l€ClRONICA IN COMPUTACION Que para Optar por el Título de

P r e S e n t a

/Regina Jacqueline Mauries Ruáz

México, D. F. 1994

UNNERSIDAD AUTONOMA METROPOLITANA

UNIDAD ETAPALAPA

Royedo T e r d

‘MEDIDA Y EVALUAUON DE LA CAUDAD DEL SOFTWARE I.

Realhado por: Roglna Jaoquellne Maurlor Ruk.

MEDIDA Y EVALUAUON

DELA CAUDAD DEL SOFIWARE.

Medida y Evaluacidn de la Calidad del Software

Agradecimientos

Dedica este t raba jo a mi5 padres Mario y Maria, por e l apoyo que me brindaran durante e l desarro l lo d e mis estudios.

Tambi&n agradezco l a cooperacidn d e mi esposo Luis Armando en la e tapa f inal d e mi carrera .

A l Ingeniero Miguel Angel Guzmdn Lbpez por sus val iosos conáejos y or ientacibn para e l d e s a r r o l l o d e es te t raba jo .

1 .

2 .

2.1 2.2

2.2.1

2.4.1 2 . 4 . 2

2.5

2 .5 .1 2 . 5 . 2 2.5.3 2.6


I N D I C E

CAPITULO PRIMERO

Introducci6n ......................................

CAPITULO SEGUNDO

Teoria de reconocimiento de patrones para el andlisis de datos para la Ingeniería del Software .......................................... Introduccibn ...................................... Requerimientos para un proceso efectivo de modelos ........................................... Limitaciones relacionadas a los datos de In- genrieria de Software ............................. Requisitos para contrarestar las carenclas ........ Teorias actuales para la modelacibn empirica ...... And1ir;is regresivo ................................ Los Arboles de clasificacibn ...................... Teoría de reconocimiento de patron para andllsis de datos ................................. Principios bdsicos ................................ Definicibn formal del proceso del OSR (Reduccidn Optimizada de Modelos) ................. Prediccibn, manejo de riesgo y evaluacibn de

Prediccibn ........................................ Manejo de riesgo .................................. Evaluacibn de calidad ............................. Res6men ...........................................

calidad dentro de la estructura del OSR ...........

8

10 10

11

11 12 13 13 14

15 15

16

17 17 18 18 19

4

Medida y Evaluacibn de l a Calidad del Software

4 . 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.3

4.4

S .

CAPITULO TERCERO

Clasificacidn ortoqonal de defectos. un concepto para mediciones dentro del proceso ....... Introduccibn ...................................... Modelos de defecto estadistico .................... Andlisis de causas ................................ La brecha ......................................... El puente ......................................... Clasificacibn ortoyonal de defectos (COD) ......... Condicibn necesaria. .............................. Condicibn suficiente .............................. Clasificacibn para Causa-Efecto ................... El atributo del defecto tipo ...................... Explotando el defecto tipo ........................ Resultados piloto ................................. Proceso de inferencia ............................. El atributo del detonante del defecto ............. Implementacibn de l a COD .......................... Resí.men ...........................................

CAPITULO CUARTO

Metodoloqia para la validacibn de la mbtrica del software ...................................... Introduccibn ...................................... Sistema bdsico .................................... El factor de calidad .............................. MBtrica de calidad ................................ MBtrica validada .................................. Funciones de calidad ............................... Criterio de validacibn ............................ Proceso de validacibn de la mdtrica ............... Mbtodos estadisticos no parametricos para validacibn de la mBtrica .......................... Resí.men ...........................................

CAPITULO QUINTO

Tgcnicas de modelacibn predictivas de la calidad del software desde las medidas del software .......................................... Introduccibn ...................................... findlisis de reyresi~n ............................. Minimos cuadrados relativos, una aproximaci6n

El criterio de error relativo ..................... al andlisis de reqresibn ..........................

S

77 ”

22

‘23

24 24 26 27 27 28 29 dl

34 34 35 35

“L LL

77 icl

-7

38 35 39 41 41 42 42 43 49

5 0 5 1

54 54 SS

56 56

Medida y Evaluacidn de la Calidad del Softblare

5.3

5.4

h . 6.1 6.2

6 . 3

6.4

6.4.1 6.4.2

6.4.3 6.4.4 6.5

7 . 7.1 7.2 7 .3

7.4

7.5 7.6

8 . 8.1 a.2 8 . 3 8.4

Prediccidn de cambios desde la compiejidad de los datos ......................................... 57 Resúmen ........................................... 59

CAP iTClLO SEXTO

Estudio empirico de la calidad del entorno para el desarrollo y evaluacibn del software ...... Tecnologia de evaluacidn para la calidad del 1ntroducci.n

entorno del software .............................. Evaluacidn de los entornos de desarrollo del software .......................................... Evaluacidn de resultados de los siete entor-

Definicidn de requerimientos de calidad nos

Seleccidn de la mbtrica y de la clasificacidn de nivel .......................................... Medicibn y clasificacibn .......................... Valoracidn de entornos ............................ Res..men ...........................................

......................................

............................................... ...........

CAPITULO SEPTiMO

Medida basada en la Entropia de la complejidad del Software .................................. Introduccidn ...................................... Teoria de informacidn ............................. Aplicacidn de la Teoria de informacldn al

Una mgtrica de la complejidad del software Software

basada en la entropia empirica del programa ...... Valoracidn del desenpeca de la Nueva Mgtrica ...... Resúmen ...........................................

..........................................

CAPITULO UCTAVO

Prediccibn de los cambios desde la complejidad de los datos ...................................... Introduccidn ...................................... Ajuste de c u r v a s .................................. Andlisis de los resultados ........................ Resúmen ...........................................

61 51

62

66

67 67

69 69 70 71

74 74 75

7.b

76 77 79

b

iqedida Evaluaciin úe 1.a Calidad del S o f t w r e

Pr6logo.

E n e! mundo moderno .se ha generalizado el uso d e l a s computadora5 por los benef ic ios que aportar; a 1 desarrol lo de diversas act ividades product i vas .

?Sra q1-1.e e s t o s equipos rlndan l o s benef i c ios ez.peradosi se requieren programas cada ' $ 2 ~ mds e t i c i e n t e s , que promuevan 1 % fac i l idad de operacihn, y 1.2 o:r3ctitud d e los datos e informaciin que desean los I-t5uar1o=.

Se hace pues necesar io , evaluar e i iunc~onaniento de 10.3 programas y es tab lecer m&todos qlue p e r m i t a n u n adecluado control (de calidad de los mismos.

S i n embargo, de u n t ieapo 3 la fecha se han llevsdo a csbo una s e r i e d e investigaciones y pruebas con di ferentes programas, qt-1.e intentan establecer normas pa ra una adecuada valoracibn de su b u m funcionamiento.

7


1. Introduccibn.

El manejo del software continúa siendo una Area importante y de rdpido crecimiento en la investigacidn y practica de la ingenieria del software. La medicidn habilita el andlisis sistemdtico, la comprensidn y el mejoramiento de los sistemas de software y de sus procesos. Los principios de medicibn, tgcnicas, y sistemas proporcionan una base sr5lida para muchos aspectos del desarrollo del software y de SLI evaluacidn desde su experimentacidn hasta una quia empirica de la sfntesis del software.

En el presente estudio se ha llevado a cabo la recopilacidn de una serie de investigaciones realizadas por The Institute of Electrical and Electronics Engineers, Inc . (IEEE). En los tres primeros capituloá se describen y validan diferentes tCcnicas para el andlisis basado en mediciones del software, utilizando patrones de reconocimiento, clasificacidn, visualizacidn y mr2todos de especificacibn.

- Teoria de reconocimiento de patrones para el andlisis de datos para la ingenieria del software.- Este estudio presenta una teoria de andlisis general de reconocimiento de patrones de datos llamada reduccidn optimizada de conjuntos. Se contrasta la teoria con andlisis regresivo y Arboles de clasificacibn.

- Clasificacidn ortogonal de defectos, un concepto para mediciones dentro del proceso.- Aquí se presenta una tkcnica de andlisis llamada Clasificacidn Ortogonal de Defectos que utiliza Cstos para proporcionar una retroalimentacibn en un proceso de desarrollo.

- Metodologia para validacidn de la mCtrica del software.- propone una metodologia de validacidn comprensiva de la mbtrica basada en seis criterios de validacidn, que apoyan la calidad de las funciones de evaluacidn, control y prediccibn.

El cuarto capitulo presenta una comparacidn analitica de las tbcnicas de modelado del software.

Capitulo 1 - 8

Medida y Evaluacibn de la Calidad del Software

- TPcnicas de Modelacibn Predictivas de la Calidad del Software desde las medidas tiel software.- Motiva el uso de dos tbcnicas de estimacibn llamadas minimos cuadrados relativos y error minimo relativo, compardndolas con los metodos tradicionales de evaluacibn.

El quinto capitulo evalúa el entorno del software, enfocdndose a un mejoramiento de la calidad del mismo y las repercusiones que tiene sobre el software.

- Estudio Empirico de la Calidad del Entorno para el Desarrollo y Evaluacibn del Software.- Analiza los entornos de desarrollo del software orientados-a-nuevos-paradigmas que han sido desarrollados en un proyecto de 5 años llamado FASET.

El sexto capitulo define una metrica ordinal sobre la teoria de informacibn y s u relacibn con la propensibn a error.

- Una Medida Basada en la Entropia de la Complejidad del Software.- Aqui se presenta una comparacibn axiomdtica de las propiedades de la rnCtrica asi como algunas validaciones emplricas.

- Prediccibn de los cambios desde la complejidad de los datos.- Una vez que se analizaron las diferentes tPcnicas y metodologias para el mejoramiento y medicitm de la calidad del software, se seleccionb la que era mds viable de acuerdo a las condiciones del sistema a evaluar. Esta metodologia ful la denominada TPcnicas de Modelacibn Predictivas de la Calidad del Software desde las Medidas del Software; aqui se hace un anAliais de los resultados obtenidos al emplear esta metodologia.

El drea de medicibn del software continúa creciendo, amplidndose y su presencia depende enteramente de ciclo de vida del software.

Capitulo 1 - 9

Medida y Evaluacibn de la Calidad del Software.

2. Teorfa de Reconocimiento de Patrones para el Analisis de datos para la Ingenieria del Software.

2 . 1 . Introduccibn.

El manejo de un desarrollo de software a gran escala requiere el uso de modelos cuantitativos para proporcionar un conocimiento y respaldo de control basados en datos histttricos de proyectos similares.

Basili ha introducido un paradigma de medicibn basado en la orientacibn para el mejoramiento del desarrollo del software, llamado "paradigma de mejoramiento" C 11, C 2 1 . Este paradigma proporciona una visir5n experimental de las actividades del soft!dare enfocadas al aprendizaje y mejoramiento, infiriendo la necesidad de reconocimientos cuantitativos para los siguientes cLsos :

- Construir modelos predictivos del proceso de software, producto, y otras formas de experiencia (por ej. esfuerzo, programa y confiabilidad) basdndose en caracteristicas comunes.

- Reconocimiento y cuantificacittn de los factores de influencia (por ej. habilidad del personal, restricciones de almacenamiento) en varias partidas de inter& (por ej. entorno de productividad, estimacibn de esfuerzo) con el prop6sito de entender y controlar el desarrollo.

- Evaluar los procesos y productos de software desde diferentes perspectivas, (por ej. productividad, tasa de falla) compardndolos con proyectos de caracteristicas similares.

Las tecnicas cldsicas para andlisis de datos tienen limitaciones cuando se usan en datos de ingenieria del software. En este estudio se presenta una nueva tecnica basada tanto en aprendizaje de mdquina como en principios y estadisticas, para resolver algunas de estas limitaciones.

Este estudio estd organizado como sigue:

Capitulo 2-10


- La seccibn I 1 trata acerca de las necesidades y restricciones para la construccidn de modelos efectivos para el entorno de desarrollo del software.

- La seccibn 1 1 1 analiza algunas de las mds comunes teorías para la construccibn de modelos.

- La seccibn IV presenta una nueva tbcnica para el andlisis de datos de ingenieria de software, llamada Reduccidn Optimizada de Modelos (0%).

- La seccibn V explica cbmo esta teoria puede ser utilizada no s610 para prediccibn sino tarnbiCn para andlisis de riesgo y evaluacidn de calidad.

2 . 2 Requerimientos para un Proceso Efectivo de Modelos.

En el texto que sigue, se hace referencia a la variable a ser evaluada como "variable dependiente" (por ej. productividad y tasa de falla) y las variables que explican el fenbmeno como "variables independientes" (por ej. capacidad del personal, tamaño de la base de datos).

2 . 2 . 1 Limitaciones relacionadas a los datos de ingenieria de software.

Cí: Es dificil hacer wposiciones acerca de las rElaciones funcionales entre variables y su probable distribucibn en sus rangos.

C2 : En el campo de la ingenieria de software, uno áe enfrenta a menudo con juegos de datos que contienen variables explicativas continuas y discretas (por ej. lineas de cbdigo, experiencia de equipo, dominio de la aplicacibn).

C3: Debido a la falta de precisibn en el proceso de recoleccibn de datos, y a eventos no esperados (por ej. requerimientos inestables) en el proceso de desarrollo, ocurren valores de variable dependiente extremados/explicativos y atipicos. En la ingeniería de software, es común que una gran cantidad de factores puedan afectar las variables dependientes. Por lo tanto, la informacibn que puede ayudar para validar y entender los vectores atipicos no estd siempre disponible. TambiBn, el hecho de que se trabaja con un gran nitmero de variables explicativas hace dificil distinguir entre los vectores que son atipicos y los que representan las principales tendencias

Capitulo 2-11


de los datos.

C4: La interdependencia de las variables explicativas puede afectar la comprensibn de modeles, pero no siempre su exactitud (ej, modelos regresivos C31). Por otro lado, pueden existir interdependencia5 muy complejas, por ejemplo, la complejidad estructural de un software puede ser un factor muy importante de productividad si el programador es experto en el Ambit0 de la aplicacibn y en el lenguaje. Sin embargo, la complejidad tiene un impacto en la productividad si el programador es experimentado. Entonces, el impacto de la complejidad en la productividad depende de la variable ordinal explicativa de la experiencia de programacih.

C5 : Una variable independiente puede ser un factor de mucha fuerza en una parte especifica de su dominio de rango/valor, un fenbmeno conocido en estadistica como "Heteroscedasticidad".

Cb: La informacibn perdida es un problema común en la medicibn del software. Hay varias causas para esto: presupuesto limitado para recoleccibn de datos, esta recoleccibn es tardada, recolectar algunos de los datos es tkcnicamente imposible o no deseable, y la falta de entendimiento del problema debido a la novedad en el campo de la medicibn del software y la amplia variedad de los entornos de desarrollo.

2 . 2 . 2 Requisitos para contrarestar las carencias.

De acuerdo a las carencias mencionadas, se definen los requisitos para un andlisis efectivo de datos o procedimientos empíricos de modelado:

- R1: El procedimiento de andlisis de datos debe evitar suposiciones acerca de la relacibn entre las variables y la probable distribucibn de densidad en los rangos variables dependientes e independientes.

- R 2 : El proceso de modelacibn necesita captar el impacto y ser efectivo en la integracibn de todas las variables explicativas independientemente de su tipo. Tambien los modelos construidos necesitan proveer una forma consistente de interpretar los efectos de cada variable en la variable dependiente.

- R3: E5 preferible utilizar tkcnicas de modelacibn que sean importantes. Por ejemplo, un pequeño número de vectores de datos no cambiarian dramdticamente las caracteristicas del modelo.

Capitulo 2-12


- R4: Se necesita una tlcnica de modelacibn que tome en cuenta las interdependencias entre las variables explicativas. La tecnica de modelacibn debe dirigirse a este asunto proporcionando el contexto dentro del cual cada pardmetro del modelo muestre ser una parte de la informacibn relevante y significativa.

- R5: La heteroscedasticidad debe ser dirigida determinando en qu4 parte de su rango/valor una variable independiente afecta fuertemente la variable dependiente de inter&.

- Rb: La informacibn perdida obviamente reduce la habilidad para predecir y aprender. Es necesario comprender mejor si la falta de una parte de los datos es un obstdculo para la evaluacibn. Esto significa que se necesita un modelo que no solo genere predicciones, sino que provea algim dato acerca de la confiabilidad de cada prediccibn en lo individual, mds que una confiabilidad global del modelo entero.

2 . 3 Teorias Actuales para la Modelacibn Empírica.

Dos teorias principales se han empleado en la ingeniería de software para formar modelos estocdsticos multivariados: analisis de regresibn multivariado y Arboles de clasificacibn.

2.3 .1 Analisis regresivo.

El andlisis regresivo puede ser muy efxtivo para predecir (regresi6n de minimos cuadrados) o clasificar (regresibn logistical cuando algunas condiciones de prerrequisito se cumplen:

1) Las variables explicativas son independientes.

2 ) La forma funcional de la ecuacibn de regresibn ectd bien aproximada.

3 ) La mayoria de las variables explicativas son continuas (intervalos, tasa de nivel).

4 ) El t4rmino de error es constante en el espacio definido por la variable dependiente y las variables explicativas (ej. homoscedasticidad [SI).

Estas condiciones se cumplen raramente en los conjuntos de datos de ingeniería de software, haciendo el uso de estos modelos algo dificil (en terminos de prediccibn e interpretacibn). Sin

Capitulo 2-13

Medida y Evaluacidn de la Calidad del Software.

embargo, el andlisis regresivo es ampliamente conocido y hay numerosas herramientas disponibles para respaldar esta tlcnica y facilitar la interpretacibn de los modelos.

- Las las variabl convierte constante Entonces, integrados

- Se

tkcnicas regresivas usan variables falsas para manejar es discontinuas. Cada valor posible de la variable se en un pardmetro cuyo valor asignado es 1 ( u otra arriba de cero) cuando es cierto y O cuando no. el nttmero de pardmetros que pueden ser potencialmente en el modelo pueden incrementarse muy rdpidamente.

ha mostrado que lo "falso" puede afectar fuertemente el proceso de modelado de regresibn, y la correspondiente ecuacidn. La identificacidn y exclusibn de estos puntos de datos influenciales es un proceso complicado en un espacio de muestra n-dimensional (por ej. el contexto multivariado).

- Un modelo lineal de regresibn debe generar un coeficiente Único para cada variable explicativa (ecuaciones md-, complejas incluyendo combinaciones de pardmetros muestran ser difíciles de usar en la prdctica). Debido a la dependencia del modelo de complejidad-productividad en la experiencia del programador, un coeficiente no puede representar suficientemente la influencia de la complejidad en la productividad. Tambidn , el uso de formas funcionales mds complejas seria dificil, ya que normalmente se tiene un pobre entendimiento del fenbmeno que se estd estudiando.

- IJn modelo del nivel del valor correcto de adecuacitm como el coeficiente de determinacidn en el andlisis de mínimos cuadrados de regresibn no es adecuado para manejar informacibn parcial porque falla en medir la confiabilidad individual de cada prediccidn. Por lo tanto, en este contexto parece dificil para el andlisis de regresidn manejar informacibn parcial, ya que no puede diferenciar casos en donde la informacidn disponible es suficiente para obtener estimaciones precisas.

- El andlisis regresivo puede ser muy efectivo cuando el usuario trata con un reducido número de variables independientes explicativas. Sin embargo, en los conjuntos de datos de la ingeniería de software este no es el caso normalmente. Por lo tanto, el proceso de creacidn del modelo se torna inestable. TambiCn la interpretacibn de esos modelos basadas en las ecuaciones de regresidn y las matrices de correlaci6n son complicadas en la prdctica.

2.5.2 Los Arboles de Clasificacibn.

Esta tkcnica genera Arboles de particibn basados en datos


histdricos que describen experiencias pasadas de interk. Producen modelos de clasificacibn interpretable5 que ayudan a los ingenieros de software a remediar acciones basadas en modelos cuantitativos.

Los Arboles importante sobre siguientes ventajas

- Manejan var aceptable.

de clasif icacidn representan una mejora las t&cnicas de regresibn basdndose en las

iables discontinuas de una forma bastante

- El proceso de modelacibn puede ser automatizado efectiva- mente.

- La estructura del drbol es muy intuitiva y fAcil de interpretar para representar resultados de andlisis de datos.

- Las interdependencia5 entre las variables explicativas se toman en consideracibn hasta cierto punto, por ejemplo, cada particibn se forma en un cierto contexto definido por el conjunto en el que la particibn se lleva a cabo.

Sin embargo, se necesita considerar algunos aspectos:

- Rangos continuos de variable se necesitan dividir en intervalos. Esto se puede hacer usando t&nicas de andlisis de llaves o euristiras para optimizar la homogeneidad del intervalo.

- Una estructura de drbol puede f o r z a r a que el proceso de modelarich ignore algunas variables que pudieran ser útiles para algunas predicciones.

2.4 Teoria de reconocimiento de patrbn para andlisis de datos.

En base a lo explicado anteriormente, el objetivo ha sido combinar la expresividad de los Arboles de clasificacidn con el rigor de las bases estadisticas, por lo que se ha desarrollado la teoria llamada 0%. HAS que generar un drbol de particidn, la OSR establece un juego de patrones de relevancia para el objeto que se va a predecir, o para el juego de datos completo.

2.4.1 Principios bdsicos.

Se puede suponer que se quiere evaluar una caracteristica particular de un objeto (por ej. la densidad de falla de un

Capitulo 2-15


componente), nos referimos a esta caracteristica como la variable dependiente ( Y ) . El objeto se representa por un juego de variables explicativas que describen el componente de software (llamado X's). Estas variables pueden ser continuas o discontinuas. Por ejemplo un componente de software puede ser descrito por dos X's, su complejidad ciclomdtica (continua) y el tipo de su funcidn (discontinua). TambiCn se puede asumir que se tiene un conjunto de datos histbricos conteniendo vectores de patrdn que incluyen la previamente citada X's mds un valor real de Y asociado. Se llamard a la porcibn de X's del vector de patrbn, vector de medicidn.

El objetivo del algoritmo OSR es determinar cuales subconjuntos de experiencias (vectores de patrdn) de los datos histdricos proporcionan la mejor caracterizacidn del objeto a evaluar.

Esto es, tratar de determinar cudles subconjuntos de un conjunto de datos tienen las mejores probabilidades de distribucibn en el rango Y. Una buena probabilidad de distribucibn en el dominio del valor de Y es la que concentra un gran número de vectores de patrdn ya sea en una pequeña parte del rango ( Y es continua) o un pequeño número de categorias de variables dependientes ( Y es discontinua). Una de l a s funciones de evaluacidn de distribucibn de probabilidad mas comúnmente utilizada es la teoria entropia H.

Cada subconjunto que presenta distribuciones dptimas se nombra como subconjunto bptimo y estd caracterizado por condiciones o predicados que son verdaderos para todos los vectores de patrdn del subconjunto.

2 . 4 . 2 Definicidn formal del proceso del OSR.

Se implement6 un algoritmo ambicioso utilizando la funcidn Opt que puede ser descrito como un algoritmo recursivo de 3 pasos :

- Paso 1.- Si la variable dependiente es continua, su rango es dividido en un juego de clases de acuerdo a dos factores principales: la exactitud del modelo requerido y el tamaño del conjunto de datos. Entonces, los rangos y categorias de las variables explicativas se dividen y clasifican en clases baslndose en las tknicas de creacibn significativa de las mismas.

- Paso 2.- Seleccionar todos los vectores de patrbn en el conjunto de valores que tengan un valor para la variable

Capitulo 2-16


explicativa X i pertenecientes a CLASEsk, donde x i para el objeto a ser evaluado pertenece a la misma clase, y el subconjunto caracterizado por el predicado Xi C CLASEik concede el valor significativo estadístico minimo para H. Varios subconjuntos concediendo entropías minimas similares pueden ser extraidos rdpidamente.

- Paso 3.- El paso 2 se repite recursivamente en cada subconjunto PSS, y en cada subconjunto sucesivo hasta que un criterio de terminacibn predefinido se alcanza.

El algoritmo OSR puede ser especificado formalmente como una funcidn recursiva de dos pardmetros, donde PVS representa el conjunto de datos histbricos y mv el vector que describe el objeto a ser evaluado:

OSR(PVS,mv)=

I U (OSR(PSS,mv)) si Opt(PVS,mv) = 0

de otra forma I

El proceso total de extraccidn puede ser representado por una jerarquia. Para tomar decisiones efectivas se debe evaluar la exactitud de los patrones especificados.

2.5 Prediccidn, manejo de riesgo y evaluacidn de calidad dentro de la estructura del OSR

La prediccibn, evaluacidn de calidad y el riesgo se basan en una teoria cuantitativa similar, a pesar de que tienen diferentes propbsitos.

2.5.1 Predimih.

Para predecir, interesa estimar el valor de una variable dependiente en base a las hojas de la jerarquia (subconjuntos extraidos). La variable dependiente es una caracteristica de objeto medible conocida o exactamente evaluada al tiempo que se necesita. Por ejemplo uno puede desear predecir el rango de error esperado para un proyecto particular basado en otras caracteristicas (variables independientes) que pueden ser medidas, y subjetivamente evaluadas con una exactitud razonable, o calculadas a travCs de otros modelos. La teoria de prediccibn varia en base a si la variable dependiente es continua o discontinua.

Capf tulo 2-17


Si la variable dependiente se define en un rango discontinuo, la prediccidn se convierte en un problema de clasificacibn.

2.5 .2 Manejo de riesgo.

Las organizaciones de desarrollo de software se interesan en la evaluacidn de riesgos asociados can el manejo y las decisiones tkcnicas para mejorar el proceso de desarrollo. El riesgo asociado con una accidn puede ser descrito en tres dimensiones:

- DI.- Los diferentes resultados posibles. - D2.- La perdida potencial asociada a ellos. - D3.- La probabilidad de ocurrencia para cada resultado.

Para ligar adecuadamente la descripcidn del riesgo y el OSR las siguientes asociaciones deben ser establecidas:

- Los resultados y las clases de variables dependientes. - PCrdida potencial y distancia en el rango de variable dependiente entre el significado de clase y el valor pla- neado.

- Posibilidad de ocurrencia y probabilidad condicional para cada clase de variable dependiente.

Un modelo de andlisis de riesgo debe ser definido como una funcidn que combine diversos pardmetros y constantes de desviacidn esperados en variables dependientes.

2 . 5 . 3 Evaluacidn de Calidad.

Para cualquier modelo de calidad, se necesita una base para hacer comparaciones. Por ejemplo, considerese que las perspectivas de inter& de calidad son la productividad y la tasa de error y que la OSR concede patrones claros para ambas variables en el conjunto disponible. Estos patrones representan las distribuciones esperadas en el entorno actual de desarrollo para el proyecto en estudio.

La relacidn entre el factor real de calidad para al5On proyecto y el valor esperado basado en los patrones de reconocimiento proporciona una base para la evaluaci6n de calidad. Por ejemplo, supdngase que la productividad actual de un proyecto cae muy por debajo del valor esperado basado en los patrones de prediccidn, esto implica que la calidad del proyecto con respecto a su productividad es baja. Usando el patr6n como

Capitulo 2-18


base de comparacidn podemos preguntarnos de ddnde viene la diferencia, algunas causas deben ser investigadas: datos incompletos o inadecuados, algunas nuevas variables que afectan el proceso de desarrollo o de calidad. La calidad de un factor especifico puede ser definida como la distancia entre el valor de calidad real y el estimado basado en los patrones de reconocimiento.

Calidad-desviaci6n = AQ - S P(Cilrnedici6n_vectord) x ui m

i=l

con el valor real AQ para el factor de calidad.

Se puede ver globalmente la calidad como una funcibn subjetiva inherente de desviaciones en varios rangos de factor de calidad. Estas desviaciones pueden ser combinadas para proporcionar una evaluacidn global de calidad especifica para un usuario.

2.6 Resdmen.

El OSR fue desarrollado para puntualizar aspectos relacionados con la construccidn de modelos estocdsticos multivariados para una mejor planeacibn, control y evaluaci6n del proceso de desarrollo del software. El procedimiento exhibe las siguientes caracteristicas positivas:

- No hace suposicione5 con respecto a las funciones de densie3d de probabilidad en los rangos de variable dependiente e independiente. No intenta acomodar los datos en distribuciones predefinidas, en cambio utiliza los datos para aproximar la distribucibn real (patrones). Tampoco se necesita suponer relacidn matemdtica entre las variables dependiente e independiente.

- Maneja variables independientes continuas y discontinuas de una forma consistente.

- Todos los vectores de patrdn tienen el mismo peso cuando se calcula una entropia de subconjunto. Por lo cual, ningún vector o pequeño conjunto de ellos puede tener un impacto importante en la estructura de patrones generada.

- Durante el proceso de reduccidn optimizada de conjunto, cada variable independiente se evalúa en el contexto definido por los predicados seleccionados previamente. Entonces, hasta cierto punto, las interdependencia5 entre las variables explicativas son tomadas en cuenta para construir los patrones.

Capf tulo 2-19


- Ya que una estructura de drbol no estd impuesta, no se supone que hay homoscedasticidad cuando 5e extraen lo5 patrones, por ejemplo, una variable independiente puede ser un predictor significativo solamente en ciertas partes del dominio de su rango/valor.

- Permite una estimacibn de precisibn de cada prediccibn para poder contestar la pregunta: LES la prediccibn utilizable?. Cuando las variables independientes de relevancia no estdn disponibles al momento de la prediccibn, OSR aún permite elaborar una; sin embargo, OSR proporcionar& una alerta si la prediccibn que se espera es pobre.

Cap< tulo 2-20

Medida y Evaluacih de la Calidad del Software.

Referencias.

C 1 1 V. Basili, “Quantitative evaluation of software methodology“, in Proc. First Pan Pacific Computer Conf., Julio 1985.

C21 V. Basili and H. Rombach, “The TAME project: Toward improvement oriented software environments“, IEEE Trans. Software Eng., vol. SE-14, Junio 1988.

E31 W.R. Dillon, Multivariate Analysis: Methods and applications. New ‘fork: Wiley, 1984.

Capitulo 2-21


3. Clasificacidn Ortogonal de Defectos, un Concepto para Mediciones dentro del Proceso.

3.1 Introducci6n.

En años recientes se ha enfatizado la necesidad de calidad en el software por los siguientes motivos:

- Es un proceso lento y detiene los avances en los sistemas de cdmputo.

- Su costo es una parte importante en el costo total del sistema.

- Muchas fallas en 105 sistemas de cdmputo se deben a pro- b lemas de software.

Los mbtodos de medicibn para la calidad son complejos y muchas veces fuera del alcance del desarrollador.

Para obtener un mltodo razonable de medicidn se debe analizar las propiedades fundamentales de esa medicibn, derivdndose los principios para andlisis y los modelos.

Para mediciones en-proceso y andlisis en perspectiva se examinardn los dos extremos del espectro: modelos de defecto estadístico y andlisis cualitativo de causas.

3.1.1 Modelos de defecto estadistico.

Su objetivo es predeclr la confiabilidad del producto y mide la cantidad de defectos remanentes en campo, la tasa de falla del producto, y la tasa de deteccibn de defectos a corto plazo.

Estos son buenos indicadores pero normalmente ocurren al final del desarrollo cuando ya su valor es minimo.

Capitulo 3 - 22


Lo ideal es que el desarrollador se retroalimente con estas mediciones durante el proceso.

3.1.2 Andlisis de causas.

Su objetivo es identificar la raiz del defecto e iniciar acciones para eliminarlo. Se analiza un defecto a la vez cualitativamente, para lo cual se recomienda una descripcibn del proceso.

Este proceso mejora la calidad del software pero requiere recursos importantes;, la revisibn cualitativa deberd emplearse en conjuncibn con un andlisis cuantitativo como el de prevencibn de defectos para un mejor resultado.

3.1.3 La brecha.

Entre los dos extremos del espectro mencionados existe una brecha considerable. Esta se caracteriza por la falta de buenos mCtodos que signifiquen algo para el desarrollador y que puedan explotar 105 mCtodos de ingeniería.

Los modelos matemdticos se aproximan a la deteccibn de defectos mediante el proceso estadistico, cuando se calibran bien muestran ser mds o menos adecuados aunque no proveen informacibn en los tiempos que el F:-oceso de desarrollo requiere.

Por otro lado, el mecanismo de andlisis de causas es cualitativo, requiere mucho esfuerzo y provee informacibn de cada defecto en lo individual y no proporciona abstracciones que puedan ser usadas para el control global del proceso.

Muchos intentos se han hecho para medir la ingenieria del software, pero no se ha podido hacer de Cste un proceso controlable, principalmente porque no ha existido un adecuado control de relacidn entre las entradas y salidas o causas y efectos del proceso.

Capitulo 3 - 23


3.1.4 El puente.

La clasificacibn ortocjonal de defectos, presenta una tecnica puente entre los modelos de defecto y el andlisis causal.

Su objetivo es proveer un paradigma-de-medicidn en-proceso para extraer informacidn "clave" de los defectos, y habilitar la medicidn de las relaciones causa-efecto.

La eleccibn de un juego de clases ortogonales, mapeadas en el espacio del desarrollo o verificacibn, ayuda a los desarrolladores proporcionando retroalimentacidn de la base de sus esfuerzos de desarrollo del software.

Estos datos y sus propiedades proveen un trabajo estructurado para metodos de andlisis que explotan los m&todos tradicionales de ingenieria de proceso y retroalimentacih.

La COD (Clasificacibn Ortogonal de Defectos) se habilita si se siguen ciertos criterios fundamentales.

La seccidn I1 de este estudio trata del concepto de ortogonalidad en COD y la necesidad de condiciones suficientes para un esquema de clasificacidn que proporcione retroalimentacidn. La seccidn I 1 1 se dedica a los defectos tipo, y su uso para proveer retroalimentacibn en el proceso de desarrollo. La seccibn IV trata de los percutores de defectos que proveen retroalimentacibn en el proceso de verificacidn igual que los defectos tipo lo hacen en el proceso de desarrollo. La seccidn V evalDa los costos involucrados en la implementacibn de la COD y su relacibn con el andlisis causal.

La disponibilidad de herramientas de rastreo de defectos bien diseñadas y de programas piloto para verificar y desarrollar la tdcnica son de importancia critica para el dxito de la implementacibn de la COD.

3 .2 Clasificacibn ortoqonal de defectos.

Sin un buen sentido de causa y efecto es dificil desarrollar metodos que proporcionen buena retroalimentacidn al desarrollador.

Un reciente estudio esplora la existencia de l a s relaciones entre la semdntica de los defectos y su resultado en el proceso de desarrollo del software C 1 1 . La seleccidn de la semdntica de los defectos fuC intencional dado que se convirtib en un vehículo para proveer una medida de las variables de estado para un

Capitulo 3 - 24


proceso de desarrollo. El estudio mostrb que cuando los defectos se categorizan en un juego de defectos tipo representando la semdntica del punto fijo, era posible relacionar los cambios en los contornos de la curva de crecimiento de confiabilidad hacia los defectos de un tipo especifico. Los defectos tipo podian ser asociados con actividades en los diferentes niveles del desarrollo. Entonces los defectos de un tipo especifico se debían a una causa en el proceso y el contorno de la curva creciente de confiabilidad representaba un efecto en el proceso. En el estudio los subgrupos que tenian una proporcidn mayor de defectos de inicializacibn propiciaban curvas muy pronunciadas, confirmando la teoria de que los errores al principio del curso (inicializacibn) escondian otros defectos propiciando que la curva se pronunciara E21. Se reconocid subsecuentemente que una clasificacibn semdntica podia ser explotada para proveer retroalimentacibn en-proceso.

La COD significa escencialmente que se puede categorizar un defecto en clases que colectivamente apuntan a la parte del proceso que necesita atencibn, como en un punto caracterizador en un sistema cartesiano de ejes ortogonales por sus x, y, z coordenadas. Aunque en el proceso de desarrollo de software las zctividades se dividen ampliamente en diseño, c6digo y verificacidn, cada organizacidn puede tener 5us variaciones. Los niveles del proceso pueden ser llevados a cabo por diferentes personas y organizaciones, por lo tanto para que la clasificacibn sea ampliamente aplicable el esquema de la misma debe ser consistente entre los diferentes niveles. Idealmente, la clasificacidn debe ser independiente de los puntos especificos de un producto u organizacibn.

Un buen sistema de medicibn que permita aprender de la experiencia y provea medios de comunicarla entre proyectos debe tener cuando menos tres requisitos:

- Ortogonalidad. - Consistencia a traves de las fases. - Uniformidad a traves de los productos.

Una de las principales fallas de la clasificaci6n de defectos es el error humano, pero si el nilmero de clases de defectos es pequeño hay una buena oportunidad de que la mente humana lo pueda resolver. Teniendo un conjunto pequeño de dbnde escoger hace que la clasificacibn 5ea mds f d c i l y menos propensa a errores.

Capitulo 3 - 25


3.2 .1 Condicidn Necesaria.

Existe una clasificaci6n semdntica de defectos de un producto, para que las clases de defectos puedan ser relacionadas al proceso que puede explicar el progreso del producto a traves de este proceso.

Si el objetivo es explicar el progreso del producto a trave% de su proceso la simple pregunta de "LDbnde estdn los problemas del producto?" que se hace al programador es una solucibn degenerativa del problema.

El objetivo mencionado puede ser alcanzado capturando 10s detalles de un defecto establecido en una clasificaci6n semdntica que es posteriormente relacionada al proceso. Un ejemplo de esa clasificacibn semdntica es el defecto tipo, que captura el significado del establecido. Ya que los defectos tipo no indican directamente ddnde estd el problema, se necesita mapear el proceso. Este mapeo proporciona la relacidn entre los defectos tipo y el proceso que permite contestar la pregunta mencionada arriba. La clasificacibn semdntica proporciona mediciones en los procesos que permiten valorar el progreso de un producto a travCs del proceso.

La clasificaci6n semdntica es mds o menos acertada ya que estd ligada al trabajo terminado. Esta clasificacidn es invariable al proceso y al producto pero requiere un mapeo hacia los niveles de proceso. Este mapeo es un nivel indirecto que liga una clase semdntica a un nivel de proceso especifico.

La clasificacidn basada en opinidn tiene algunas fallas como el de ser muy especifica a un proceso y entonces m mapear entre diferentes procesos; ademds no puede funcionar donde el proceso no estd bien definido o estd siendo sujeto a cambios para compensar problemas. Claramente la clasificacibn semdntica tiene ventajas como la de ser capaz de medir el progreso de un producto, lo que hace que el mapeo de clases semdnticas sea factible. Escencialmente, un juego de esa5 clases semdnticas debe existir para mapear el proceso. La clasificacidn puede tener siempre algún grado de subjetividad, sin embargo la ortogonalidad reduce el error humano en la clasificacidn proporcionando clases que son distintas y mutuamente excluyentes.

Capitulo 3 - 26


5.2.2 Condiciones Suficientes.

Las condiciones suficientes se basan en un juego de elementos que construyen un atributo, como el defecto tipo.Basado en las condiciones necesarias, los elementos necesitan ser ortoqonales y asociados al proceso en que las medidas son inferidas. Las condiciones suficientes aseguran que el ndmero de clases sea adecuado para hacer la inferencia necesaria. En condiciones dptimas, las clases deben expander el espacio de todas las posibilidades que describen. Estas, entonces, forman un conjunto de expansidn con la capacidad de describir todo en ese espacio por medio de estas categorias. Si no forman un conjunto de expansidn entonces hay algunos puntos en el espacio que investigar o que no fueron descritos con los datos existentes. Asegurdndose de que la condicidn suficiente ha sido satisfecha, implica que se sabe y se puede describir precisamente el espacio en el que se quieren proyectar los datos.

Dada la naturaleza experimental del trabajo es difícil garantizar la suficiencia, por lo que son necesarias las siguientes tareas:

a) Obtener las mediciones correctas. b) Validar las inferencia5 de las mediciones con referencia

a las experiencias compartidas. c) Mejorar el sistema de rnedicidn en tanto vamos aprendiendo

mds de las experiencias piloto E31.

3.2.3 Clasificacidn para Causa-Efecto.

Obtener los datos correctos que proporcionen la historia completa para relacionar los atributos causales con efecto proporciona una mina de oro de informacidn de la cual aprender. La Fig. 1 muestra tres grupos mayores de datos importantes de tener. Un grupo es el de los atributos de causa, el segundo grupa estd indicado para medir los efectos. Tradicionalmente han existido diferentes formas para medir los efectos. Una medida comanmente utilizada en IBM es la severidad, la severidad de un defecto se mide usualmente en una escala de 1 a 4 , otra clasificacidn es la CUPRIMD C41, que significa capacidad, utilidad, desempeño, confiabilidad, instalabilidad, mantenimiento y documentacidn. Otras medidas incluyen la confiabilidad, el crecimiento, la densidad del defecto, etc. El tercer grupo esta dedicado a identificar sub-poblaciones de inter&. Estas son típicamente atributos que distinguen proyectos, personas, procesos, herramientas, etc.

Capitulo 3 - 27


3.3 El Atributo de Defecto Tipo.

Un programador haciendo una correccidn normalmente escoge el tipo de defecto. La seleccidn del defecto tipo implica la eventual correccibn. Estos tipos son simples, ya que deben ser obvios para el programador, en cada caso se hace una distincibn entre alqo faltante o incorrecto. Un error de funcibn es uno que afecta significativamente la capacidad, las interfaces con el usuario final, las interfaces del producto, las interfaces con la arquitectura del hardware o la estructura global de los datos, y requiere un cambio formal del diseño. Contrariamente un error de asignacidn indica unas cuantas líneas del cbdigo, como los bloques de control de inicializacidn o la estructura de datos. La interface corresponde a errores interactuando con otros componentes, mddulos, manejadores de drive atraves de macros, instrucciones de llamadas, bloques de control o listas de pardmetros. El chequeo apunta a la lbgica del programa que ha fallado hacia los datos validados adecuadamente y los valores antes de ser usados. Los errores de tiempo y serializacibn son aquellos que son corregidos mejorando el manejo de los recursos compartidos y de tiempo real.

Los errores de construccidn/empaquetado/mezcla son los que ocurren en los sistemas de libreria, manejo de cambios o control de versiones. Los de documentacibn pueden afectar tanto a publicaciones como a notas de mantenimiento. Los de algoritmo incluyen eficiencia o corrrccidn de problemas que afectan la tarea y pueden ser arreglados reimplementando un algoritmo o la estructura de datos local, sin necesidad de requerir un cambio de diseño.

La eleccidn de los tipos de defecto ha evolucionado a travbs del tiempo de los cinco tipos originales que refinamos trabajando con la IBM para llegar a ocho. Este incremento ha ocurrido en dimensiones relacionadas con el cambio habido de la prueba de un concepto a un entorno de produccidn. Por ejemplo, algunos de los nuevos tipos estdn relacionados a la mecdnica de un desarrollo grande ( construccidn / empaquetado / mezcla ) , concurrencia (serializacidn) que no existia anteriormente. Los defectos tipo son seleccionados para que sean lo suficientemente generales para aplicarse a cualquier desarrollo de software independientemente del producto. Su granularidad es tal, que se aplica a cualquier fase del proceso de desarrollo y puede ser asociado con algunas fases especificas del proceso. Los defectos tipo deben tambien expander el espacio de esas fases para satisfacer la condicibn suficiente. La Fig. 1 muestra los defectos tipo y asocia una fase del proceso de desarrollo con cada uno de estos tipos.

Capitulo 3 - 28


/""""""""""""""""" \

I Tipo de Defecto Extraviado: 4 oIncorrecto : )~""""""""""""""""~l

I Funcidn I Interface I Verificacibn I

: Asignaci6n Seleccionar: : Tiempo/Serializacibn uno I

: Const/Empaq/Mezcla I

: Documentac i6n Algoritmo I

\""""""""""""""""" /

I

/""-"""""""""" \

f Proceso de Asociacibn : \"""""-""""""" /

"" >

Fig. L El tipo de defecto y proceso de

Di señ0 Bajo nivel de diseño LLD o c6digo Cbd i go Bajo nivel de diseño Libreria de herramientas Publicaciones Bajo nivel de diseño

asociaciones.

Si un defecto de funcibn de encuentra, ya sea en el chequeo de sistema o unidad, se mantiene apuntando a la fase de diseño de alto nivel con la que el defecto est4 asociado. Similarmente, un error de tiempo estarfa asociado con el diseño de bajo nivel. El conjunto de defectos tipo es suficientemente distinto para expanderse en el proceso de desarrollo. Dando este conjunto de defectos tipo hay varias oportunidades de proporcionar retroalimentacibn al desarrollador basada en los perfiles de distribucidn de los defectos.

3.3.1 Explotando el Defecto Tipo.

La Fig. 2 muestra un ejemplo que ilustra la explotacibn ortogonal de los defectos tipo. Cuatro defectos son .ltilizados para este ejemplo: funcibn, asignaci6n1 interface, y tiempo. En cada fase de desarrollo se muestra una distribuci6n de los defectos, normalizada por el nctmero de defectos en esa fase. Dando un proceso de desarrollo se puede describir el comportamiento esperado. Por ejemplo, en la mayoria de los procesos de desarrollo donde un diseño es conducido antes de la codificacidn y el chequeo, los defectos de funcibn pueden ser encontrados al principio en el proceso e idealmente muy pocos en el chequeo del sistema. Entonces, las barras correspondientes a los defectos de funcidn disminuirdn a travbs del proceso. Por o t r o lado, es comprensible que mds defectos de tiempo y serializacibn sean encontrados durante la verificacibn del sistema. Los defectos de asignacidn y de interface pueden tener perfiles que muestran picos en la verificaci6n de la unidad y en la integracibn respectivamente.

Escencialmente, la distribuci6n de los defectos cambia con el tiempo, y provee un indicador de dbnde se encuentra el desarrollo.

Capftulo 3 - 29

Medida y Evaluacidn d e l a C a l i d a d d e l S o f t w a r e

Capitulo 3 - 30


El cambio de distribuclbn del defecto tipo, proporciona, entonces una medida del avance del producto a travBs del proceso. Al mismo tiempo, provee un medio para validar si el desarrollo es ldgico en el mismo lugar donde esta fisicamente. Por ejemplo, cuando se encuentra en la verificacidn de sistema el perfil de distribucidn se verd como 5 1 estuviera en la verificaci6n de unidad o de integracidn, entonces la distribucidn indica que el producto esta prematuramente en la verificacidn de sistema. El perfil de las distribuciones proporciona las seGales del proceso, cuando una desviacidn en el proceso es identificada por una desviacidn en la curva de distribucidn, el defecto tipo tambi&n apunta a la parte del proceso que es probablemente responsable.

3.3.2 Resultados Piloto.

El USO de un defecto tipo se ilustra mejor por una de las verificaciones piloto que se toman. Un componente de software se escogid sabiendo que tenía una historia de desarrollo dificil. Hacia el final del desarroilo, se torn6 evidente que varios cambios de proceso se habian realizado al principio del ciclo. El ejercicio aqui es para mostrar cdmo una distribucidn de defecto tipo hubiera señalizado el problema y recomendado una correccibn plausible. La Fig. 3 muestra la curva de crecimiento de confiabilidad del componente. Esta estd dividida en 4 períodos, los llltimos tres siendo de aproximadamente de b meses cada uno. En el llltimo periodo el nclmero de defectos casi se duplica y corresponde aproximadamente a la fase de verificacibn del sistema. Para el propbsito de estudio se dibujaron las lineas demarcando periodos de intervalos de b meses y se dibujaron muestras para clasificacih. La granularidad del andlisis est& entonces limitada a &.tos intervalos predeterminados de muestreo. En la prdctica no habria este efecto de muestreo ni conclusiones de andlisis podrian hacerse a intervalos mds cortos.

La parte inferior de la F i g . 3 muestra la distribuci6n de la funcidn de defecto tipo. Cada barra en la distribucidn corresponde a la fraccidn de defectos de ese tipo, en ese pertodo. El punto de partida en el proceso se reconoce claramente por la distribucibn de la funcidn de defectos tipo. Ndtese que el incremento de la funcidn tipo en el periodo 3 puede deberse a que este periodo corresponde a la fase de verificacibn de funcibn, donde los defectos de funcibn puede esperarse que se incrementen. Sin embargo, por el período final los defectos de funci6n se incrementaron a casi la mitad del total indicando que el chequeo final de integridad del software estd siendo impedido por las fallas de funcionamiento. Esta tendencia provocar& una alerta ya que es una desviacidn significativa de un comportamiento esperado. Dado que los defectos de funcibn fueron la causa de la

Capitulo 3 - 31

FIedida y Evaluacibn de la Calidad del Software

desviacidn, tambih sugieren una apropiada revisibn o inspeccibn mds que un chequeo intensivo.

Toma tiempo calibrar el cambio de distribucibn dentro de un proceso particular de desarrollo, pero hasta que la calibracibn se completa los andlisis de tendencias pueden ser usados para inferir si un proceso estd progresando en la direccibn adecuada.

. . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. .

. . .

. . . . . . . . . .

<.'

....................................... ,.m'

. . . . . . . . . . . . . . . . . . . . . . . . c. . . . . . . . . . .

,..I

. . . . . . . . . . . . . . . *.. . . . . . . . . . . . . . . . . . . . . . .

. ...................................... ,.m'

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

,..I

. . . . . . . . . . . . . . . *.. . . . . . . . . . . . . . . . . . . . J

"- "" _--

""

"

"" "--

"

D L 1 I I I

o m0 400 800 800 loo0 iBUd00

Capitulo 3 - 32


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

Capitulo 3 - 33


3.3.3 Proceso de Inferencia.

Tomando un andlisis de tendencias mds profundo para ilustrar el potencial de automatizacibn que es posible con la COD, la Fiy. 4 muestra una tabla de asociacibn principal y tiene mds detalles que la Fig. 2 . Las columnas son los diferentes defectos tipo y las lineas los niveles de proceso de verificacidn, los puntos identifican las principales asociaciones. Por ejemplo, la funcidn de defecto tipo se asocia con el diseño y se espera que sea detectada tanto en la inspeccidn de alto nivel como en la prueba de verificacidn de funcibn. Las asociaciones principales muestran ddnde los defectos de funcibn tipo se incrementan. Mediante la construccidn, se pueden esperar esperar grandes Areas antes y despues de los niveles de asociacibn principal. Esta tabla describe los perfiles de la distribucidn de los defectos tipo explrcitamente. A partir de estos perfiles se refleja un potencial de las Areas problema.

\Tipo \Defecto

\ Fctncidn Verificacidn Tiempo Algoritmo

Di señ0 LLD Cdd igo HLD Insp LLD Insp Insp Cddigo Unidad prueba Funcidn prueba Sistema prueba

I

: * 8

I

I

: * I

*

* t

* *

* * * *

* \""""""""""""""""""""""""- /

Fig. 4 Tabla de asociacidn principal.

3.4 El Atributo del Detonante del Defecto.

Un detonante de defecto es una condicidn que permite que un defecto emerja C51. Por ejemplo, cuando un producto se embarca se asume que todas las funciones y operaciones han sido verificadas. Sin embargo, en el campo, una serie de circunstancias pueden provocar que el defecto emerja y que de otra forma no hubiera ocurrido en el entorno de verificacidn. Puede ser que el defecto ocurra cuando el software se corre en una nueva plataforma de hardware . Entonces, aunque el defecto tipo es el mismo puede tomar diferentes detonantes que pueden

Capitulo 3 - 34


trabajar como catalizador para que el defecto surja. En campo, el detonante puede ser potencialmente identificado por alguien con experiencia en problemas de diagnosis. Entonces los detonantes a diferencia de los defectos tipo son identificados al principio del ciclo de vida de un defecto.

El concepto de detonante proporciona conocimiento no directamente del desarrollo del proceso, sino de la verificacibn. Idealmente la distribucibn de detonantes de defectos para el campo debe ser similar a la que se utiliza durante la verificacibn. Si hay una discrepancia entre las dos distribuciones, 5e identifican agujeros potenciales en el sistema . Este chequeo es particularmente litil cuando se embarca un producto con prisas y antes de que se lance al pitblico en general. La diferencia en la distribucibn de detonantes entre el producto embarcado con prisas y las pruebas de campo se pueden utilizar para mejorar los planes de verificacibn .

3.5 Implementacibn de la COD.

El impacto de costo de un ingeniero de software durante el proceso de desarrollo es minimo. Tfpicamente se considera una medida de una docena de teclazos por defecto para llenar uno o dos paneles. El tiempo de incremento es insignificante cuando entra uno a un sistema de rastreo de defectos; hemos medido de menos de un minuto hasta cuatro, dependiendo del rastreo. Hay un costo inicial que involucra educacibn, camblos de herramienta y cambios de proceso para iniciar la COD. Actualmente algunas pruebas que se han hecho se han llevado un total de 3 horas, lo que incluye sesiones de laboratorio para proveer una estructura que pudiera ser trabajada. Pero el proceso tambidn necesita 5er definido con los posibles clientes y responsables de las diferentes actividades. Dependiendo del grado de desarrollo de un laboratorio de andlisis se pueden implementar equipos de trabajo en el caso de pocos proyectos u nombrar un responsable cuando se emplee todo el laboratorio.

3.6 Resdmen.

Este estudio se enfoca a un punto clave para proceso de desarrollo del software con retroa desarrollador. Sin esta retroalimentacibn el valor es cuestionable.

la medicibn del limentacibn al de la medicibn

La retroalimentacibn ha sido uno de los grandes problemas que se han afrontado, y no sin razbn. En un extremo del espectro la investigacibn en el modelo de defectos se ha enfocado en la

Canitulo 3 - 35


prediccidn de la confiabilidad dando un tratamiento homoglneo a los defectos. En el otro extremo del espectro, el andlisis causal provee retroalimentacibn cualitativa del proceso. A la mitad no se han desarrollado mecanismos sistemdticos para la retroalimentacidn debido a la falta de relaciones fundamentales causa-efecto que se pueden extraer del proceso. Este articulo estd construido en algunos trabajos fundamentales que han demostrado la existencia de una relacidn entre los tipos de defecto encontrados y sus efectos en el proceso de desarrollo. Los puntos sobresalientes de este estudio son:

- Clasificacidn Ortoyonal de Defectos.- proporciona una capacidad bdsica para extraer señales de los defectos e inferir la salud del proceso de desarrollo. La clasificacibn estd basada en qub es lo que se conoce del defecto como por ejemplo su tipo o su detonante y no en una opinidn como ddnde fue introducido el defecto. La eleccidn de las categorias en un atributo deben satisfacer las necesidades y condiciones suficientes para que apunten a la parte del proceso que requiere atencibn.

- El diseño del atributo del tipo de defecto.- Que mide el progreso de un producto a traves de su proceso. El tipo de defecto identifica lo que se ha corregido y puede ser asociado con los diferentes niveles del proceso. Entonces, un conjunto de defectos de diferentes niveles en el proceso, clasificados de acuerdo a un conjunto de atributos ortogonales deben soportar la marca de este nivel en su distribucibn. Mds aún, los cambios en la distribucibn pueden medir el progreso del producto a traves de su proceso. El punto de partida de la distribucidn proporciona señales de alerta apuntando al nivel del proceso que requiere atencidn. Entonces, el tipo de defecto provee retroalirnentacibn en el proceso de desarrollo.

- El diseño de un atributo de detonacidn del defecto para proporcionar una medida de efectividad en un nivel de ver1ficacidn.- Los detonantes de defecto capturan la circunstancia que permiti6 al mismo emerger. La informacidn del detonante mide aspectos de terminacidn a un nivel de verificacidn. Este nivel puede ser el cddigo de verificacibn o inspeccidn y revisidn de un diseño. Estos datos pueden proveer eventualmente retroalimentacidn en el proceso de verificacibn. Tomados en conjunto con el tipo de defecto, el producto de dste y su detonante proporcionan informacidn que puede evaluar la efectividad del proceso.

- La experiencia obtenida con la COD, indica que puede proporcionar una rdpida retroalimentacidn a los desarrolladores. Actualmente datos de dos niveles se utilizan para andlisis de

Capítulo 3 - 36


tendencias que proporcionan retroalimentacidn. Se ha visto que con la evolucidn de las pruebas piloto, las medidas se pueden calibrar. El USO de la COD puede iniciarse tan temprano como se cuente con diseño de alto nivel e informacidn acerca de los datos de una seleccidn de pruebas piloto que la utilicen.

- La COD como concepto general de medicidn en-proceso. Aunque este reporte ha enfocado su aplicacidn en el desarrollo de software, es posible que similares avances se apliquen en otras Areas. Estas ideas estin siendo exploradas en la IBM en desarrollo de hardblare, informacidn y problemas orientados s1n defecto.

Referencias.

E11 R . Chilarege, W. L. Kao and R.G. Condit, “Defect type and its impact on the growth curve“, in Proc. 13th Int. Conf. Software Engineering, 1991.

121 M. Ohba, “Software reliability analysis models”, IBM J. Research and development, vol. 28, pp. 428-443, 1984.

C31 R. Chilarege and D.P. Siewiorek, “Experimental evaluation of computer systems reliability”, IEEE Trans. reliability, pp. 403- 408, vol. 39, Oct, 1990.

C41 R. A. Radice and R . W. Philips, Software Engineering: An industrial Approach Englewood Cliffs, NJ: Prentice Hall, 1988.

C51 I . Bhandari, M. Y . Wong, R. Chilarege, B. Ray and D. Choi, “An inference structure por process feedback: Technique and implementation”, IBM Research, RC 17869, 1992.

Capi.tulo 3 - 37

Medida y Evaluacibn de la Caiidad del Software

4. Metodologia para la validacibn de la mltrica del software.

4.1 Introduccibn

Se piensa que la mCtrica del software debe ser abordada como parte de una disciplina de ingenieria. Si la metrica es de gran utilidad, la validacibn debe ser efectuada en tCrminos de las funciones de la calidad (valoracibn, control y prediccidn) que la metrica puede respaldar.

A continuacidn se propone e ilustra una metodología de validacidn, cuya adopcidn se piensa que puede proveer una base racional para usar la metrica. Esta es una metodologfa comprensiva de la mCtrica que se construye en el trabajo de otros: estos han sido anilisis de validacidn realizados en m6tricas especificas o sistemas mCtricos con el prophsito de satisfacer objetivos de investigacibn especificos. Dentro de estas validaciones estdn las siguientes:

1 ) Puntos de funcibn como prediccibn de horas de trabajo a traves de diferentes puntos de desarrollo y conjunto de datos. E l l

2 ) Conflabilidad en la mCtrica de los datos reportada por los programadores. C31

3) Operador de conteo Haletead para programas en Pascal.tlO1

4) Arboles de clasificacibn basados en la mCtrica. Clbl

5) Evaluacidn de la metrica contra propiedades de complejidad sintactica. C171

las La teorfa de validacldn que aqui se presenta, tiene siguientes características:

1cas 1 ) La metodologia es general y no especifica a mltr particulares u objetlvos de investigacidn.

Capitulo 4 - 38


2 ) Estd desarrollada desde el punto de vista del usuario de la metrica (antes que el del investigador) quien tiene requerimientos para evaluar, controlar y predecir la cal idad.

La metrica consiste de seis criterios definidos matematica- mente, y son:

a) Asociaci6n. b) Consistencia. c) Poder de discriminacibn. dl Seguimiento. e) Prediccibn. f ) Repeticirh.

Se reconoce que una mbtrica dada puede tener usos Imúltiples (por ejemplo: valor, control y calidad predicha) y que puede ser vdlida para un uso y no vdlida para otro. Se define un proceso de validacidn matrica que integra factores de calidad, mktrica y funciones.

En la seccibn I 1 se establece una estructura que conjunta los conceptos y definiciones del factor de calidad, mktrica de calidad, metrica validada, funcibn de calidad, criterio de validacibn y proceso de validacidn mktrica. En esta secci6n se muestra cdmo el criterio de validacidn apoya a las funciones de calidad.

En la seccibn 111 se indica el porqug los mCtodos de estadistica no paramktricos son aplicables y compatibles con el criterio de validaci6n.

4.2 Sistema Basico.

Las bases de esta metodologia mktrica consiste en los siguientes elementos, (ver Fig. 1 ) :

A ) El Factor de Calidad. B) La mktrica de calidad. C ) La mktrica validada. D) Las funciones de calidad. E) El criterio de validacibn. F) El proceso de validacidn de la m8trica.

En la Fig. 1 se utiliza la notacidn (proyecto, tiempo, medicidn) para designar el tiempo de proyecto, (ej. la fase del ciclo de vida), y el tipo de medicidn (factor de calidad, mbtrica

Capitulo 4 - 39


de calidad). Se utiliza V para designar el proyecto en el cual una metrica es validada y una A para designar el proyecto en el que se aplica la m@trica.

\ I Validacibn (V) Proyecto 1 (P1) Linea de Tiempo

I 1. Grupo M 2. Grupo F 8 3 . M validada con F i

I I

, I I

I I

0

I"""""""""""""""""""""""~"""""""~~

I I

""""""_ > I

: VCPI, T1, M I VCP1, TZ, F l I ,

I FASE T1 FASE TZ ,

I

I

I

: Aplicacibn ( A ) Proyecto 2 (PZ) Linea de Tiempo I

: 4. Grupo M' 6. Grupo F ' : 5. Aplicacidn de M' a: 7. Revalidacibn de I i valuacidn, control, prediccidn M, "con F, F ' I )"""""""""""""""""""""""""""""""I

8 """"""_ > : ACP2, T1, M'] ACP2, T2, F ' 1

\""""""""""""""""""""""""""""""" / F ig . 1 Proceso de validacidn de la metrica.

Este diagrama se interpreta como sigue:

- Los eventos y el tiempo de avance del proyecto de validacibn esta definido por las lineas y flechas horizontales superiores. Esta linea de tiempo consiste del proyecto 1 con metrica M agrupada en la fase T1 (paso 1 ) ; La agrupacibn de factor F en la fase TZ (paso 2 ) ; y validacibn de M con respecto a F en la fase T2 (paso 3 ) .

- Los eventos y tiempo de avance del proyecto de aplicacidn son definidos por las lineas y flechas horizontales inferiores. Este proyecto es posterior en tiempo cronolbqico que el de validacibn, pero tiene las mismas fases T1 y T2. Esta línea de tiempo consiste del proyecto 2 con agrupacidn mltrica M' en la fase T1 (paso 4 ) ; aplicacibn de M' para evaluar, controlar y predecir la calidad en la fase Ti (paso 5 ) ; agrupamiento del factor F ' en la fase T 2 (paso 6 ) y revalidacibn de N y M' con respecto a F y F' en la fase T2 (paso 7 ) .

Capitulo 4 - 40


- La metrica M' es la misma que la de M, pero en general tiene diferentes valores, ya que estd agrupada en un proyecto distinto. Las mismas afirmaciones se aplican a F y F ' .

4.2.1 El Factor de Calidad.

Un factor de calidad F (mencionado de aqui en adelante como "Factor" 6 "F") es un atributo del software que contribuye a su calidad. C131, donde la calidad del software se define como el grado en el que el mismo posee una combinacibn deseada de atributos C141.

Por ejemplo, la confiabilidad (un atributo que contribuye a la calidad) es un factor. Un factor puede tener valores como el conteo de errores Fl....Fm en un conjunto de componentes del software (por ejemplo, un elemento de un sistema de software, como un mddulo, unidad, dato, o documento C131). Definimos F como un tipo de mBtrica que provee una medicidn directa de la calidad del software C61. Esto significa que F es un indicador intrínseco de la calidad como es percibida por el usuario, como los errores en el software que resultan en fallas de operacidn.

Se denota F como un factor V y F' como un factor en A . F y F' se muestran agrupadas en los puntos 2 y b respectivamente en la Fig. 1.

4.2.2 MBtrica de Calidad.

Una m6trica de calidad M (mencionada de aqui en adelante como "m8trica" o "M") es una funcidn (ej. la complejidad ciclomdtica M = e-n+2p) cuyas entradas son datos de software (medidas elementales del software, tales como ndmero de contornos e y número de nodos n en una grdfica dirigida), y cuya salida es un solo valor numbrico M que se puede interpretar como el grado en el cual el software posee un atributo dado (complejidad ciclomdtica) que puede afectar su calidad (ej. la confiabilidad) C151. Por ejemplo, si hay dos componentes 1 y 2 con M, = 3 y Hz = 10, esto puede indicar que la confiabilidad de i es mas grande que la de 2. Si este es el caso depende si M es una mBtrica vdlida. Se define M como una Medida de Calidad Indirecta C2lC6l. Esto significa que M puede usarse como substituto de F cuando no se dispone de esta, como en la fase de diseño. M se muestra como un conjunto en el punto 1 de la Fig. 1.

Es importante reconocer que en general puede haber relaciones muchos a muchos entre F y M .

Capitulo 4 - 41


4.2.3 MQtrica Validada.

Una mQtrica validada es aquella cuyos valores han mostrado estar estadisticamente asociados con los valores del factor correspondientes (ej. MI...Nn se han asociado e5tadisticament.e con Fl....Fn para un conjunto de componentes l...n) C131. Una prueba de validacibn de M con respecto a F se muestra en el punto 3 de la Fig. 1. Se denota N' como una metrica validada. Ya que M es validada con respecto a F, es necesariamente el caso en el que F es vdlido.

Por lo tanto decimos que F es vdlido por definicibn como un resultado de la amplia aceptacibn o uso histbrico (ej. error de conteo). Ya que F es una medida directa de la calidad, se prefiere sobre M, siempre que sea posible medir F con suficiente anticipacibn en el ciclo de vida para permitir que sea evaluado, controlado y predicho. Sin embargo usualmente este no es el caso, surge la necesidad de validacidn. Se puede notar que la necesidad de encontrar y corregir errores crece rdpidamente con el ciclo de vida, ventaja que aproxima al inicio l o s indicadores de la calidad del software. Se pueden formular las siguientes politicas con respecto a la medida del software: cuando es factible medir y aplicar F entonces se utiliza; de otra manera se debe intentar validar M con respecto a F, si esto da resultado, se emplea M'.

4.2.4 Funciones de Calidad.

Las funciones de calidad son actividades conducidas por organizaciones de software con el propbsito de alcanzar los objetivos en la calidad de un proyecto.

Los objetivos del proceso y el producto estdn incluidos. Las funciones que son pertinentes en esta metodologfa de metrica son: Evaluacidn, Control y Prediccibn.

1 ) Evaluacibn de la Calidad: La evaluacibn de la calidad es la evaluacibn de la calidad relativa de los Componentes del software. "La Calidad Relativa es la calidad de un componente dado comparada con la calidad de otros componentes en el conjunto" (ej. si M' es la complejidad ciclomdtica, la calidad del componente 1, con M ' = 3 puede 5er mejor que la de otro componente 2 , con M ' = l r J ) . Las metricas validadas son usadas para hacer esta comparacih. El propdsito de la evaluacibn es propocionar a los jefes de software bases racionales para asignar prioridades de mejoramiento de la calidad, para reubicar los recursos humanos y computacionales, para asegurar las funciones de calidad . Por ejemplo, lar; prioridades y recursos deben ser asignados en base a valores relativos o rangos de M' (ej. los

,


mdximos recursos deberdn ser asignados a los componentes con los valores mds altos o bajos de M'). M' se muestra agrupada en el punto 4 de la Fig.1, y usada para evaluacidn en el punto 5 ) .

2 ) Control de Calidad: Es la evaluacidn de los componentes de software contra valores criticos predeterminados de la mltrica (es decir, el valor de M' que se usa para identificar el software con calidad inaceptable) C131 y la identificacidn de los componentes que caen fuera de los limites de calidad. Se denota M= como el valor critico de M'. La mktrica validada se emplea para identificar componentes con calidad inaceptable. El propdsito del control es permitir que los jefes identifiquen el software con esta calidad con la suficiente anticipacitin en el proceso de desarrollo y tomar una accidn correctiva. El control implica el monitoreo de la calidad de un componente durante su ciclo de vida.

3 ) Prediccidn de la Calidad: Es un prondstico del valor de F en el tiempo T2 basado sobre los valores M'%, M'z...,M', para los componentes 1 , 2 , ..., n en el 'iempo T 1 , donde el tiempo T 1 podrfa ser el tiempo de ejecucidn de la computadora, el tiempo de trabajo o el tiempo de calendario. La matrica validada (ej. tamaño y complejidad) se emplea durante la fase de diseño para hacer predicciones de prueba o factores en la fase operacional (ej. conteo de errores). El propdsito de la prediccitin es proporcionar a los jefes un prondstico de la calidad del software operacional, y señalar los componentes para una inspeccibn detallada cuyos valores del factor predicho son mds grandes que ( o mds pequeños que1 los valores esperados (determinados desde el andlisis de requerimientos). M' se muestra como una coleccibn en el punto 4 en la Fig. 1 y usada como prediccidn en el punto 5.

4.2.5 Criterio de Validaci6n.

El criterio de validacidn proporciona la racionalizacidn para la matrica de validacidn. Son las relaciones cuantitativas especificas que son hipot&ticas entre el factor y la mktrica.

Este criterio se basa en el pricipio de validacidn, el cual define la relacibn cuantitativa entre factores y metricas que deben existir eara que el criterio de validacibn sea aplicado.

El criterio de validacidn se basa en el principio de validez, mismo que define la relacidn general cuantitativa entre factores y mltricas que deben existir para que este criterio sea aplicado.

Capitulo 4 - 43


1) Definiciones:

( 1 ) RCMI: Relacidn R sobre el vector M para VCP1, T í , MI ( 2 ) RCFI: Relacidn R sobre el vector F para VCP1, T2, F1 (3) RCM'I: Relacibn R sobre el vector M' para ACP2, T1 , M'] (4) REF']: Relacidn R sobre el vector F' para ACPZ, TZ, F'I

donde R podria ser, por ejemplo, una relacibn de orden tal como: Magnitud CM, <: Mz.. :< M,] y la magnitud CFx < F=. ..<Fml involucrando n valores (puntos de datos) para M y F.

2) Principio de Validacibn:

Si REMI i--> RCFl

es validado estadisticamente con un nivel de confianza x y, para cierto criterio de validacibn, con valor y,,

entonces CRCMI <:--y' RCFl> --:I CRCM'I --> RCF'I>? (5 f

en otras palabras, hay un mapeo N X--> F, validado sobre el proyecto 1, implica un mapeo M' --> F' sobre el proyecto 2? Suponemos que (5) es verdadera en el punto 5 de la Fig. 1. Una vez que F' es agrupada en el punto 6 , revalidamos (o invalidamos) (5) por repeticibn de la prueba de validacidn usando ademds M y M', validadas con respecto a F y F' agregadas en el punto 7 .

Se observa que una metrica puede ser validada con respecto a cierto criterio de validez, e invdlida para otro criterio. Cada criterio de validacidn apoya una o mds evaluaciones de las funciones de calidad, control y prediccidn. El criterio de validacidn (asociacibn, consistencia, poder de discriminacibn, seguimiento, predictibilidad y repetibilidad) son aplicados en el punto 3 de la Fig. 1. Los criterios en particular que son usados dependen de las funciones de calidad (una o mds)que se sustentan.

El procedimiento de validacidn requiere que el valor yi sea seleccionado para cierto criterio de validacidn, (el juicio debe ser ejercido en valores seleccionados para dar un balance entre ccn extremo de causa M, el cual tiene un alto grado de asociacidn con F, para que la validacidn falle, y el otro extremo de aceptar una M de validacibn cuestionable para pasar la validacih).

3 ) Asociacibn.- La variacidn en F explicada por la variacidn en M, estd dada por R' (coeficiente de determinacio,), donde es el coeficiente de correlacidn lineal, y debe exceder un umbral especifico, b

Rz > y x , con x dada.

Capitulo 4 - 44


Este criterio evalda si hay una asociacidn lineal suficiente entre F y M para asegurar el uso de M como una medida indirecta de F. Este criterio apoya la funcidn de evaluacibn de calidad como sigue.

Si los elementos del vector M, correspondientes a los componentes 1,2, ..., n son ordenados por magnitud, Lee puede inferir una ordenacidn lineal de F con respecto a M para el propdsito de evaluar las diferencias en la calidad de los componentes? en otras palabras, lo siguiente es vdlido?

MagnitudCMiOl=.. . :<M,. .<M,l <-->.

MagnitudCFliF2. .<Fí. . .* ;F,l ( 7 )

y (Mí+% - M,) !F~+I - F,. . .<:Fm) para i=1,2,. . . ,n-1 Por ejemplo, si R=0.9 y x = 0.05, entonces S iX de la

variacidn en F (contador de error) se explica por la variacidn en M (complejidad), con un nivel de confidencia aceptable. S1 esta relacidn es demostrada con un ejemplo representativo de componentes, y si y,, ha sido establecido como 0.7 , se puede concluir que M estd asociada con F y puede ser usada para comparar las magnitudes de la complejidad, que difiere en calidad (por ej. la diferencia en la magnitud de complejidad entre el componente 1 y el 2 ( 1 0 - S) es proporcional a sus diferencias en calidad en la tabla 1 ) . El valor resultante de M ' podria se usado para evaluar las diferencias en la calidad de los componentes del proyecto de aplicaci6n.

Proyecto de Validacibn /""""""""""""""""""""""-"""""""" \

: Componente M M F F I

I (magnitud) (rango) (magnitud) (magnitud) (rango) I

\"-""""""""""""""""""""""""""""" / Tabla 1.

4) Consistencia.- El grado del coeficiente de correlaci6n r entre F y M debe exceder un umbral específico, o

Capitulo 4 - 45

5 ) Poder Discriminative.- El valor crit debe ser capaz de discriminar, para un F, elementos (componentes 1 , 2 , . .. i,. ..n) de un siguiente manera:

M* > M, <:--;> F, > F,

Este criterio evalúa si M, tiene


r > ye, con x dada. Este criterio valora si hay consistencia suficiente entre

los rangos de F y de M para garantizar el uso de M como una medida indirecta de F C91. Este criterio apoya la evaluaci6n de la funcibn de calidad como sigue.

Si la relacidn áe demuestra sobre un ejemplo representativo de componentes, y si y, ha sido establecido como 0.7, podriamos; concluir que M es consistente con F y se puede usar para comparar los rangos de complejidad obtenidos desde diferentes componentes para evaluar el grado en el que ellos difieren en la calidad relativa (ej. la calidad del componente 2 es menor que (complejidad mayor) la del componente 1 en la tabla I ) .

La M ' resultante podria ser usada para evaluar la calidad relativa de los componentes sobre el proyecto de aplicacibn.

ico de una mktrica M, especificado, entre vector F C171 de la

Y

(10)

suficiente poder discriminativo para garantizar su uso como una medida indirecta de F,. Este criterio apoya la funcidn de control de calidad como sigue.

Dada M,, como se ilustra en la tabla 1 1 , particiona F para una F, especificada como se define en (10)? Por ejemplo, 105 datos de la tabla I son empleados en la tabla 11, con M, = 10 y F, = 2 . Vemos que el poder discriminativo no es perfecto en la tabla I 1 (es decir, O z I < > O ) . Si &te se emplea para señalar componentes con mas de 2 errores (F > F,I para una inspection detallada y si M', = 10 (complejidad) es validada, se podría usar sobre el proyecto de aplicacibn para controlar la calidad (esto es, discrimina entre componentes entre aceptables e inaceptables), como se muestra en la Fig. 4. El propbsito de la Fig. 4 es identificar el curso de la calidad (ej. un caso persistente de componentes que estdn en la zona inaceptable).

Ya que raramente hay un discriminador perfecto M, para F, (por ej. O,z=Ozx=O en la tsbla I I ) , se emplea un mltodo estadistico apropiado(por ejemplo, la tabla de contingencias

Capitulo 4 - 46

,


cuadrada C77C81C121) y los ejemplos de componentes representativos para medir el grado en el que (10) sostiene.

Proyecto de Validacibn. /""""""""""""""""""""""""""""""- \

t M, = 10 I M (= M, M > M, t F,=2 ,

I I

I I

""""""""""$-""""""""""""""""""""", t F <= F, : O 1 1 = 1 o,, o

I F ? F, : O 2 1 = 1 O22 = 2 \""""""""""""""-""""""""""""""""

Tabla 11. OIj = contador de observaciones en la celda i,j O l l , Oaa: clasificaciones correctas. O l a , O;?%: clasificaciones incorrectas.

I I

8 I I I

/

6) Seguimiento.- M debe cambiar de acuerdo a F para un componente sigue:

con x dada.

Este criterio evalúa SI M es capaz de seguir los cambios en F (ej. como un resultado de los cambios de diseño) en grado suficiente para garantizar el uso de M como una medida indirecta de F. Este criterio se apoya en la funcidn del control de calidad como sigue:

Si M es validada, entonces un vector M'*(Tj) formado por los valores M'I(Tl), M'l(Tz), ...,M'(Tj),...,M'fi(Tm) de componentes i, medidos en los intervalos T,, T2, ..., T,,,..,T,,, podria ser usado Para tener un seguimiento de la calidad sobre el proyecto de ap 1 icac idn.

Capitulo 4 - 47


I

I M'I M' i M'I "I

I M'I "I $""""""""""""""""""""-

TI T, T3 Te T,

Fig. 2 Aplicacidn de la metrica al control de calidad (seguimiento) para componentes i en los intervalos de tiempo 1 , 2 , ..., m.

7 ) Predictibi1idad.- Una funcidn de M, f(M), donde Pl es medida en el tiempo T1, debe predecir F, medida en el tiempo T2, con una exactitud y , o

:FIT, - Fpf2: ;"""""-~ 2 < yp I F-TZ I

donde FIT= e5 el valor real, y Fe,, es el valor predicho.

Este criterio 5e ilustra graficamente en la Fiy. 3, donde se contrasta la prediccidn perfecta con la imperfecta, donde ffM), formulada en T1, serd igual a Fa en T2 (predictibilidad perfecta), o e5 igual a F,+ o F,- (predictibilidad imperfecta).

I /"""""""" I > Fp+ Predictibilidad imperfecta

t \"""""""" > F,- Predictibilidad imperfecta F : f ( M ) ; ______----__---- > F. Predictibilidad perfecta

\""""""""""""""""

T1 T2 Tiempo del proyecto de aplicacibn --------- >

Fig. 3 Aplicacidn de la metrica a la prediccidn de calidad (predictibilidad) para un componente.

Este criterio valora si f ( M ) puede predecir F con la esactitud requerida. Este criterio apoya la funcibn de prediccidn de la calidad como sigue:

:Fa 'T2 - Fp 'TZ i ; - "_ """_" ; <: B, (141 Fa'T2

Capitulo 4 - 48

,


8) Repetibi1idad.- El rango de &cito de validacibn de M para un criterio de validacidn dado i debe satisfacer:

N*,/N, >

donde numero de validaciones de M para el criterio i, y Ni es el número total de pruebas para el criterio i.

Este criterio evalúa si M puede ser validado sobre un porcentaje suficiente de pruebas para tener confianza de que sera un indicador confiable de calidad a la larga. Se emplean "pruebas" porque la validacibn se podria llevar a cabo con respecto a proyectos, aplicaciones, componentes, o alguna otra entidad apropiada.

4.2.6 Proceso de Validacidn de la MBtrica.

Dado que debe ser un proyecto de validacibn V y un proyecto de aplicacidn A, como se muestra en la Fig. 1 , este requerimiento muestra los que se llama el "problema fundamental de la validacidn m&trica". Este problema surge porque puede haber un tiempo importante de rezago, diferencias del producto y proceso, y diferencias en los objetivos y entornos CSI entre las siguientes fases del proceso de validacibn (v&ase Fig. 11

1) VCP1, T1, M1 y VCP1, T2, F l 2 ) VCP1, T 2 , F l y A C E , T 1 , M'] 3 ) ACP2, Ti, M'] y ACP2, T 2 , F ' I .

Con respecto a la fase 1 el producto o proceso puede haber cambiado tanto entre Ti y T2, que M agrupada en T 1 , no permaneceria siendo representativa de F. Si este es el caso, M deberia ser agrupada nuevamente en T2 para validarse contra F. La ventaja de agrupar M en T1 es que seria mas fdcil y menos costoso que en 12, por que M puede ser agrupada como un resultado de compilacidn, diseño e inspeccibn de cbdigo.

Las mismas consideraciones se aplican con respecto a la fase 3 ) excepto que ahora la preocupacibn es si M' agrupada en Ti debe ser usada para la revalidacitn en T 2 . S i n embargo, ndtese que es obligatorio que M' sea agrupada en T1 para tener una pronta indicacidn de posibles problemas de calidad (lo que es un concepto clave para esta metadologia).

Con respecto a la fase 2 1 , se puede obtener un clerto grado 3z estabilidad en el proceso de validacibn si se emplea el siguiente procedimiento:

Capitulo 4 - 49


a) Seleccionar V y A para que sean lo mds similares posible con respecto a los entornos de aplicacidn y desarrollo.

Con respecto a las fases 1-3 consideradas en conjunto, podemos onbtener un grado de estabilidad en el proceso de validacidn si bste se emplea con los siguientes procesos adicionales:

b) Seleccionar la misma fase de ciclo de vida para T1 en V y A.

c) Seleccionar la misma fase de ciclo de vida para T 2 en V y A.

Se reconoce que puede no ser posible implementar estos procedimientos, si este es el caso, esto indicaria que hay un alto riesgo de que N validada en el punto 3 F i g . 1 no permaneciera valida en el punto 5 .

4.3 MItodos estadisticos no paramdtricos para validacidn de la m4trica.

Los mBtodos estadisticos no param4tricos son usados para apoyar la validacidn de la mltrica, porque estos mltodos tienen ventajas importantes sobre los mbtodos param4tricos. Realmente, podrla no ser' factible validar la mltrica en muchas situaciones sin su uso . Esto lleva a la conclusidn de que los m4todos no paramr2tricos son menos rigurosos que los parambtricos. Los mltodos no parametricos permiten desarrollar drdenes de relacibn muy útiles referentes a la calidad relativa de los componentes. Las ventajas de los mltodos no paramltricos son:

- Debido a lo silencioso de la mltrica de los datos, el hecho de que las suposiciones son menos restrictivas es una gran ventaja.

- La no suposicidn es necesaria con respecto a la distribucidn (ej. los datos no tienen que ser normalmente distribuidos).

- Se puede emplear una escala nominal (esto es, el componente A tiene una gran calidad, el componente B es de menor calidad) C111. El criterio de validacidn de poder discriminativo se basa en esta propiedad de medida. Similarmente se puede emplear la escala nominal para indicar asi un cambio incremental en el seguimiento de la m4trica (silno) un cambio incremental en un factor. El criterio de validacidn de seguimiento SE? basa en esta propiedad de medici6n.

Cacitulo 4 - 50


- Se puede emplear la escala ordinal (esto es, el componente A es de mds calidad que el componente B) y ordenar las estadisticas como rangos. El criterio de validacibn de consistencia se basa en esta propiedad de medicibn.

A pesar de las ventajas de los metodos no parametricos, ciertos criterios de validacibn ayudan a usar metodos parametricos. Esto se muestra en la tabla 3 "Asociacibn", la cual mide la diferencia en la calidad de 105 componentes, usa el intervalo de la escala. La "Predictibilidad" usa el intervalo de la escala para predecir el valor del factor y la escala del radio para medir la esactitud de la prediccibn. Finalmente, la "Repetibilidad" usa la escala del radio para medir el &xito de la validaci6n.

Criterio Escala Matodo Propiedad de la medici6n

.................................

Asoc iac idm Intervalo Param&rico Diferencia

Consistencia Ordinal No pardmetrico Alto/Mas Bajo

Poder Nomi na 1 No paramgtrico Hlto/Bajo Discriminativo

Seguimiento Nominal No parametric0 Incremento

Predictibilidad Intervalo, Parambtrico % Exactitud Rad io

Repetibilidad Radio Paramhtrico % Exit0 ...................................

Tabla 111. Propiedades del criterio de validacibn.

4.4 Resúmen.

En este estudio se ha descrito una metodologia para validar la metrica, que consta de seis criterios de validacibn, los cuales apoyan la valuacibn de las funciones de calidad , control y prediccibn. Seis criterios fueron definidos e ilustrados: asociacidn, consistencia, poder discriminativo, seguimiento, predictibilidad, y repetibilidad. Estos criterios son importantes porque proporcionan una metrica de validacibn racional en la

Capitulo 4 - 51


prictica esta racionalizacidn carece de seleccibn y aplicaci6n de mbtricas. Con la mltrica validada se tienen bases para llevar a cabo desiciones y tomar acciones para proporcionar software de calidad. Se ha mostrado que los factores de calidad,, mltricas y funciones se pueden integrar con nuestro proceso de validacibn de la mltrica. Por otro lado tambiCn se ha mostrado que 105 metodos estadisticos no paramltricos juegan un papel importante en la evaluacidn si la mCtrica satisface los criterios de validaci6n.

El criterio de poder discriminativo permite al usuario de la mltrica controlar la produccibn de software altamente confiable proporcionando umbrales de calidad aceptable.

Referencias.

C 1 1 A.J. Albrecht and J. E. Gaffney, Jr., "Software function, source lines of code, and development error prediction: a software science validation", IEEE Trans. Software Eng., vol. SE- 9 pp. 639-648, NOV. 1983.

C21 A.L. Baker et al., "A philosophy for software measurements", J. Syst. Software, vol. 12 No. 3 , pp.277-281, Jul. 1990.

C31 V.R. Basili, R.W. Selby Jr. and T.Y. Phillips, "Metric analysis and data validation across fortran projects", IEEE Trans. Software Eng., vol. SE-9 pp. 652-663, Nov. 1983.

C41 V.R. Basili and D.H. Hutchkens, "An empirical study of syntactic complexity family", IEEE Trans. Software Eng., vol. SE-9 pp. 664-672, NOV. 1983.

C51 V.R. Basili and H.D. Rombach, "The TAME project: toward improvement-oriented software environments", IEEE Trans. Software Eng., vol. 14, pp. 759-773, Jun. 1988.

C61 M.E. Bush and NE. Fenton, "Software Measurement: a conceptual framework", J.Syst. Software, vol. 12, No. 3, pp. 223-231, Jul. 1990.

C71 D.N. Card, G.T. Page, and FE. McGarry, "Criteria for software

Capitulo 4 - 52


modularization" in Proc. 8th Int. Conf. on Software Eng., Ag. 1985 pp. 372-377.

C81 W.J. Conover, Practical Nonparametricsn Statistics.New York: Willey, 1971.

C91 S.D. Conte, H. E. Dunsmore, and V.Y. Shen, Software Engineering Metrics and Models. Menlo Park, CA:Benjamin/Cummings, 1986.

C101 L. Felician and Z. Zalateu, "Validating Halstead's theory for Pascal programs", IEEE Trans. Software Eng. vol. 15, pp. 1630-1632, Dic. 1989.

Clll N.E. Fenton and A. Melton, "Deriving structurally based software metrics", J. Syst. Software, vol. 12, No. 3, pp.177-187, Jul. 1990.

E1 2 1 J.D. Gibbons, Nonparametric Statistical Inference, Neur York: McGraw Hill, 1971.

C131 IEEE Standard for a Software Quality Metrics Methodology (draft), No. P-l06/D21, Abr. 1, 1990.

C141 IEEE Standard Glossary of Software Engineering Terminology ANSI/IEEE Std. 729-1983.

E 1 5 1 IEEE Glossary of Software Engineering Terminology (draft), No. P729/61(3.12/DB, Mar. 30, 1990.

C161 A.A. Porter and R.W. Selby, "Empirically guided software development using metric-based classification trees", IEEE Software, vol. 7, No. 2, pp. 46-54, Mar. 1990.

C171 E.J. Weyuker, "Evaluating software complexity measures", IEEE Trans. Software Eng. vol. 14 pp. 1357-1365, Sept. 1988. No. P-l06/D31, Abr. 1, 1990.

Capftulo 4 - 53


5. TCcnicas de Modelacibn Predictivas de l a Calidad del Software desde las Medidas del Software.

5.1 Introduccibn

El objetivo de la construccidn de modelos de la calidad del software es usar las medidas que se puedan obtener con relativa anticipacidn en el ciclo de vida del desarrollo del software, para obtener estimaciones iniciales razonables de la calidad en el desarrollo de un sistema.

El objetivo de este capitulo es el andlisis de cuatro procedimlento5 de estlmacibn estadistlca que pueden contribuir al desarrollo de modelos predictivos vlables para usar en la determinacidn de la calidad del software. Estos modelos estdn asociados con la mCtrica de la complejidad del mismo como medidas numericas de las diferencias intrinsecas entre los mddulos del software. Un aspecto importante bajo consideracidn es la relacidn lineal entre diferentes mCtricas cuando son aplicadas a l control de calidad, anAlisis y prediccibn.

La informacidn derivada de estas relaciones puede contribuir al desarrollo y manejo de sistemas complejos especialmente en el caso en el que las mCtricas complejas estdn asociadas con cambios en el programa. En esta direccidn los recursos del proyecto pueden ser eficientemente aplicados a mddulos del proqrama y se pueden concentrar en aquellos que requieren modificacibn.

Muchos desarrolladores han encontrado mddulos de software que son muy complejos en tCrminos de ciclomdtica o complejidad de control que generan problemas durante los procesos de verificacidn y validacibn. Sin embargo el uso de la mktrica del software en el proceso regresivo de modelado est& siendo cuestionado debido a que la mayoria de estas mCtricas carecen de capacidades predictivas asi como de fundamentos tebricos desde el punto de vista estadistico.

Aquí se hace un estudio de cuatro tCcnicas de estimacibn para usar en el desarrollo de modelos de regresibn

Capitulo 5 - S4


específicamente en el uso de mBtricas de la complejidad del software como indicadores del software propenso-a-cambio. El proceso de modelacidn de regresidn lineal bdsico implica ajustar una ecuacidn lineal a los datos que aparecen al caer abruptamente a lo largo de una linea recta, hay muchas lineas que podrian de manera conveniente ser dibujadas a travbs de los datos. El criterio especifico que determina la línea adecuada se selecciona generalmente de tal forma que minimice una funcidn de perdida asociada. La complejidad del software y la calidad de los datos no concuerdan bien con las suposiciones que se deben alcanzar en el uso de las funciones de pbrdida cuadrdtica tradicionales.

Cuando la tbcnica de minimos cuadrados se usa para ajustar estos datos a un modelo lineal, los valores extremos de la variable dependiente, las fallas del programa, tienen un efecto desproporcionado sobre el ajuste de este modelo. El objetivo entonces, es introducir y explorar los potenciales de otros procedimientos de estimacidn para las datos de la ingenieria de software que tengan estas propiedades.

5.2 Clndlisis de Reqresibn.

En la utilizacidn de mbtrica del software para predecir algunas medidas de la calidad, tales como fallas de un programa, un modelo de regresidn lineal e5 comúnmente empleado. En este modelo la metrica de complejidad aparecerd como variable independiente y la variable dependiente serdn las fallas del programa. Este modelo estd formado por la seleccidn de el mejor subconjunto de un conjunto de variables independientes para explicar tanta variacidn como sea posible de la variable dependiente.

Los coeficientes para las variables independientes son producidos por Minimos Cuadrados(LS), Minimos Cuadrados Relativos (RLS), Valor Absoluto Minimo ( L A V ) , y Error Relativo Minima (MRE) .

Capitulo 5 - 55


5.2.1 Minimos Cuadrados Relativos, una aproximacibn al Andlisis de Reqresi6n.

Este mtltodo involucra la minimizacibn de la suma de los errores cuadrados relativos a los valores observados de la variable dependiente . Ndtese que el procedimrento RLS puede ser formalmente reducido a un modelo de regresibn regular LS siguiendo los siguientes pasos:

N ( y í - Y * í ) N Y A í t

min S r ---------T , = min S 1 1 - ----- 1 i = l Y* i=l Y í

donde Y A í = be + blxl + btxz +...+ bkXk.

considerando que YAí* = 1 y YAí' = YAí/Yí.

calcular

2

2.

Siguiendo substituciones, uno puede

i= l

pl rd Para ecua

izac al cual sigue un proceso de minim implementar fdcilmente.

i6n LS y que se puede

5.2 .2 El Criterio de Error Relativo.

El promedio del error relativo absoluto es una "funcibn de ida" para determinar la calidad de la ecuacidn de prediccibn. medir el error relativo promedio se define la siguiente

cibn:

ARE es dtil como medida de desempeño del modelo asociado con mdtricas de complejidad para identificar el software propenso a error Ell. En el presente trabajo ARE es tambidn utilizado como una medida de pron6stico de calidad entre varias tknicas de estimacibn. De esta manera, 5e mantiene la uniformidad entre las diferentes medidas de calidad de ajuste y exactitud de pron6stico de los mdtodos de estimacibn.

Capitulo 5 - 56


TambiCn se puede derivar el Minimo Error Relativo (MRE) de los pardmetros del modelo resolviendo:

considerando que y í * = 1 y yAí9 = YAi/Yi.

Siguiendo substituciones, se puede calcular

Lo cual e5 equivalente a estimar los pardmetros de un modelo usando el criterio de Valor bbsoluto Minimo. La regresibn MRE can ser considerada como una versibn "pesada" del mCtodo LAV con pesos iguales a los valores reciprocos observados.

5.3 Prediccidn de cambios desde la complejidad de los datos.

Las variables independientes usadas en la modelacibn son un conjunto de la m4trica de complejidad. Esta mCtrica puede ser obtenida inmediatamente despuCs de que un m6dulo de un programa ha sido codificado. Una descTipcibn de la m4trica especifica del software en este estudio es como sigue:

- Instrucciones del cbdigo de mdquina.- cuenta 105 bytes del número de instrucciones a nivel mdquina generados por cada mddulo del programa.

- Lineas de cddigo.- Cuenta las lineas de programa sin comentarios ni blancos.

- Llamadas a mbdu1os.- Enumeracibn del número de llamadas a mddulos externos en cada mbdulo.

- Datos.- número de datos estdticos accesados por un mddulo de programa.

- Pardmetros.- El número de pardmetros formales en cada mddulo, en la lista de pardmetros formal de cada mbdulo de programa.

Capitulo 5 - 57


- nl.- Conteo de los operadores Halstead, una enurneracia, de los dnicos tokens en un programa que producirdn alguna acci6n c21.

- nz.- Conteo de los operadores Halstead, una enumeracion de los dnicos token que envían o reciben datos.

- NI.- Operadores totales en un mOdLtl0, un contador del nllmero total de ocurrencias de operador en un proqrama.

- N = . - Operadores totales en un mddulo, un conteo del número total de ocurrencias de token operando en un prouFama.

- V(G).- Complejidad Ciclomdtica de McCabe, un ajuste de la diferencia entre el número de lados y nodos de la representacidn grdfica del control de flujo del mddulo del proqrama mks 2 .

- 1Cambios.- i4imero de ocurrencias de cambios hechos a un mddulo despcrCs de que se ilbica bajo un control formal de contlguraclm.

Pa ra evaluar la adaptacidn de un modelo de reqresidn a estos datos hay dos criterios distintos d 2 evaluacidn que deben ser considerados. Primero, el modelo de regresidn debe de representar adecuadamente la dispersidn lineal de los datos. Este es el criterio de adaptacidn de calidad. Segundo, el modelo debe hacer predicclones futuras significativas, @Sta es la predicc~dn de calidad del modelo.


5.4 Resdmen.

E? objetivo de este estudio no es presentar un modelo definitivo de prediccidn para las medidas de calidad de un programa, pero mds bien trata de explorar y evaluar varias tCcnicas de estimacidn para la creacibn de modelos lineales de calidad del softumre. Los resultados del andlisis de los m&todos de regresidn y estimacidn sugieren que 105 minimos cuadrados relativos y e l proceso de error relativo minimo poseen buenas propiedades desde el punto de vista de calidad del modelado de capacidades predictivas y de adaptacidn. No exhiben sensibilidad a las perturbaciones de datos en los valores extremos de la mktrica de calidad. En adicidn, se muestra que los 4 procedimientos de estimacibn tienen fuerte consistencia en la estimacidn de pardmetros para modelo5 lineales con variables independientes aleatorias.

La regresibn lineal múltiple con minimos cuadrados de estimacidn se utiliza por 5er conveniente. Podemos dividir nuestros datos en un paquete estadistico y obtener un modelo al final del andlisis. Si 105 resultados son tenues, podemos cuestionar la relacidn entre la mgtrica de complejidad y de calidad. Desde el punto de vista de manejo de proyecto nos interesa el uso de los datos para desarrollar modelos que proporcionen una prediccidn razonable para el desarrollo futuro del software. Este es un proceso critico de dos pasos. La calidad del proceso de estimacidn debe ser examinada tanto como la calidad de la relacidn entre l a s variables dependientes e independientes. Para datos que son normalmente distribuidos la tCcnica de estimacidn de mfnimos cuadrados es superior a la MRE.

Capitulo 5 - 59


Referencias.

C 1 7 V. Shen, T. Yu . S. Thebaut and L. Paulsen, “Identifying error-prone software-An empirical study”, IEEE Trans. Software Eng., vol. SE-11,Abr. 1985.

C21 M. H. Halstead, Elements of software Science, Nelv York: Elsevier, 1977.

C3’1 J. Munson and T. Khoshgotfaar, “Regression modeling of software quality: Empirical investigation”, Inf. Soft. Technol., vol. 32, pp. 106-114, Mar. 1990.


6 . Estudio Empirico de la calidad del entorno para el desarrollo y evaluacidn del software.

b.1 Introduccidn

Dado que las herramientas de ingenieria de software son en SI software, la tecnologfa para la evaluacidn del software se puede aplicar a la evaluacidn de herramientas o entornos de software. Boehm C21 y MacCall et al. C31 propusieron modelos de calidad. Y Murine C41 desarrolld pardmetros de calidad del software basados en el modelo de MacCall. Azuma et. al. CSI,C61 desarrolld SQMAT (Tecnologia de medida y seguridad de la calidad del 5oftware) como un software cuantitativo de la tecnología de la valoracidn de la calidad. En el camoo de la tecnologia de evaluacidn para desarrollo de software, Peters C71 tratd de evaluar y comparar las metodologias de diseño de software, y Basili C81, C91 ha evaluado la metodologia de la ingeniería de software.

El objetivo principal de este proyecto fue mejorir la productividad y la confiabilidad estableciendo tecnologías bdsicas para entornos de desarrollo de software orientado-a- nuevo-paradigma basado en tbcnicas de especificacidn formal. De acuerdo a este objetivo, siete entornos de desarrollo de software han sido desarrollados por equipos independientes:

1.- Herramienta de especificacidn algebraica. 2.- Herramienta de especificacidn declarativa. 3 . - Herramienta de especificacidn orientada-a-lenguaje-

4.- Herramienta de especificacidn diagramdtica. 5.- Herramienta de especificacidn orientada-a-estado-

6.- Herramienta de especificacidn basada-en-modelo. 7 . - Herramienta de especificacidn orientada-a-funcibn.

natura l.

transicidn.

Como parte de este proyecto, se desarrolld una tecnologia de evaluacidn para entornos de desarrollo de software basada en el modelo del proceso de evaluacidn de la calidad del software

Capitulo 6 - 61


definida en ISOIIEC 9126.

Primero, la tecnología de evaluacibn fue aplicada de una forma puramente experimental a las siete herramientas prototipo para su evaluacidn preliminar a la mitad de la fase de desarrollo, y entonces fue revisada en base a los resultados. En segundo tCrmino, Csta fuC aplicada a los siete entornos completos para su evaluacidn en la fase final del desarrollo.

La seccidn I 1 describe el concepto del modelo del proceso de evaluacidn de la calidad del software y la tecnologia de evaluacidn revisada para los entornos de desarrollo del software. La seccidn I11 introduce el proyecto FASET al cual fue aplicado la tecnologia de evaluacidn. La seccidn IV presenta ios res;ultados de la evaluacibn en la fase final del desarrollo. Finalmente en la seccibn V. el resúmen.

6.2 Tecnologia de evaluacibn para la calidad del entorno del Software.

Los principios bdsicos y la metodoloyia de la tecnología de evaluacibn estdn basados en el estudio de ISOIIEC JTCl DIS7126 e INSTACISTDIWGS (Centro JaponPs de Investigacibn y estandarizacidn de tecnología de informacidn nacional/ Grupo de Trabajo de Evaluacidn de la Calidad del Software) C101.

La idea bdsica de evaluacidn de calidad del software usada como base de la tecnologia de evaluación del entorno del software se describe primrro. En segundo lugar, se delinean los detalles de la tecnologia de evaluaci6n.

Se han propuesto y empleado muchas caracteristicas para la evaluacibn de la calidad, pero no hay un solo conjunto ampliamente usado de caracteristicas definidas porque un conjunto seleccionado especificamente para una evaluación depende del punto de vista del evaluador. De acuerdo a la experiencia, 5e sugiere que el número de caracteristicas de calidad 5e mantengan entre 3 y 8 por razones prdcticas y de conocimiento. Es necesario que cada característica de calidad sea redefinida en subcaracterísticas y estructuradas jerdrquicamente. La m&trica 5e usa para medir estas caracteristicas. La mktrica consiste de una escala y un mPtodo de medicidn. Una o mas metricas se seleccionan y definen para cada subcaracteristica. Algunas subcaracteristicas son fdciles de medir cuantitativamente, mientras otras no 10 son: cuando ktas subcaracteristicas deben ser medidas (diffciles) áe utiliza la metrica subjetiva. Sin embargo se requiere que todos los esfuerzos se enfoquen al desarrollo de mCtricas cuantitativas. Generalmente, l a s m&tricas difieren par áu

Capitulo 6 - 62


Eeccsidadcr Istablccidns o

ISO/IHC 9126 6

otra Id. T6caica

? k d i d o

I

IVd" ción

Capitulo 6 - 63


naturaleza, dependiendo de la fase del ciclo de vida o tipo de software, pero es importante que esas m&tricas se estandaricen para cada fase o softuare.

El proceso principal de evaluacidn de la calidad toma los siguientes pasos:

- Definicidn de los requerimientos de calidad. - Preparacibn (seleccibn de la mhtrica, definici6n del nivel

- Medicidn e intervalo. - Evaluacibn.

de intervalo, definicidn del criterio de evaluacibnj.

La estructura del modelo para el proceso de evaluacibn de la calidad del software se muest:a en la Fig. 1.

1) Definicibn de requerimientos de calidad.- En primer lugar, l a s caracteristicas de calidad fundamentales para evaluar el objetivo del entorno de software son definidas. En segundo lugar, se definen dentro de subcaracteristicas de calidad. Entonces, el nivel requerido de calidad y la importancia relativa para cada subcaracteristica de calidad se clasifican. La importancia de cada caracteristica difiere dependiendo del objetivo del entorno del software. Por esta razdn, para satisfacer las necesidades del usuario es muy importante aclarar no sdlo los requerimientos funcionales, sino tambien la importancia de las caracteristicas de calidad.

2 ) Seleczibn de la mPtrica v definicibn del nivel de clasificaci6n.-Para medir cada subcaracteristica, se seleccionan y definen metricas. Entonces, el criterio de clasificacibn para cada una se determina y se define.

S ) Medicidn y clasificaci6n.- El entorno para el desarrollo del software que se va a evaluar es probado, y las subcaracteristicas de calidad para el entorno son medidas clasificando cada mktrica de acuerdo a un criterio.

4 ) Evaluaci6n.- Los datos medidos son agrupados y anotados. Cada anotacibn de subcaracteristica alcanzada se calcula y representa en un diagrama circular con sus pesos. Entonces, el entorno de software se evalúa totalmente en base a la informacibn.

Las principales caracterfsticas de esta tecnologia de evaluacidn son las siguientes:

Capitulo 6 - 64

Medida y Evaluaci6n de la Calidad del Software

- Dos clases de caracteristicas de calidad.- Fiunque una herramienta es un apoyo de implementacibn para una metodologia, se considera "el entorno del desarrollo del software" en un amplio sentido, incluyendo una metodología en este estudio dado que el objetivo del entorno de FASET ha sido desarrollada recientemente asi como metodologias o lenguajes que se requieren para ser evaluados junto can las herramientas en si. Por lo tanto, la estructura de calidad tiene dos clases de caracteristicas de calidad en esta tecnologia de evaluacibn. Una es para evaluar las tbcnicas de ingenieria de software y especificacibn de lenguajes de descripcibn; la otra es para evaluar las herramientas en si. Como las anteriores caracteristicas, se seleccionaron aquellas escenciales para la evaluacidn de las tbcnicas de la ingenieria de software, así como lenguajes específicos que se incluyen en el entorno.

Carno la estructura de calidad estd claramente dividida en dos clases, el usuario puede evaluar la tecnica de ingenieria del software (metodologia) y la calidad de una herramienta en forma discriminada. En consecuencia es fdcil evaluar los entornos de software aplicando esta tecnologia. El usuario puede obtener informacibn de los pros y contras de los entornos de software, y encontrar fdcilmente motivos de inconveniencia. Por ejemplo, cuando el usuario encuentra una herramienta dificil de usar, el motivo puede ser aclarado flcilmente checando las resultados de evaluacidn de los dos tipos de caracteristicas de calidad representados en una grdfica circular. Este metodo de evaluacibn y su aplicacibn no se limitan sblo a la calidad, sino que incluyen atributos adicionales como la manejabilidad, reutilizacidn, etc.

Representar la evaluacibn de resultados eficientemente es tan importante como la estructura de calidad descrita anteriormente, considerando que las caracteristicas de entorno del software tienen diferente nivel de requerimientos o pesos dependiendo en los entornos del objetivo, los resultados de la evaluacidn deben ser expresados de una forma sencilla para áer entendidos de un vistazo. Estudiamos dos tipos de modelos de representacibn grdfica que son practicables para espresar la importancia relativa de caracteristicas y valores alcanzados.

De los dos modelas de representacibn se ha seleccionado uno de ellos porque representa de una manera mas sencilla la importancia relativa y el valor alcanzado de una forma clara e inmediata.

En este modelo se emplean diez subcaracteristicas de calidad (ej. comprensibn, habilidad para el manejo, operabilidad) de un


entorno de objetivo que son expresadas en diez partes divididas. Para cada subcaracteri~tica, se representa un peso por su dngulo, y una puntuacibn alcanzada se representa por su radlo. (El nivel requerido áe considera como el mdximo del radio). El radio establece una escala de cuatro grados que corresponde a los cuatro grados de nivel de evaluacibn.

Por lo tanto, el resultado medido de una cierta caracteristica puede ser fdcilmente basado en la siguiente idea: si un peso que es igual o mayor al promedio se asigna para una subcaracteristica especifica, y si el resultado alcanzado no es menor de 3/4 del radio (bueno o excelente en los cuatro niveles de valuacibn) entonces la subcaracterística se considera aceptable. Cuando el peso de una subcaracteristica es menor al promedio, se puede considerar aceptable aún si el resultado alcanzado es menor a tres pero no inferior a 2/4 del radio (marginal) porque k t a subcaracteristica no es muy importante para el entorno. Entonces, cada caracteristica puede ser Juzgada fdcilmente y serd de gran utilidad para la evaluacidn total del entorno del software.

6 . 3 Evaluacibn de los entornos de desarrollo del software.

Esta seccidn establece un bossuejo del proyecto FASET (Teoria Formal para la Tecnología del Entorno del Software) y los entornos de desarrollo del softuare que han sido desarrollados y evaluados en el proyecto. El proyecto pretende desarrollar tecn3logias bdsicas para crear entornos de desarrollo de software orientados a nuevos paradigmas que controlan cada fase del ciclo de vida desde la definicidn de requerimientos a 13 generacibn de programaá basados en metodos de especificacibn formal. Tambien pretende diseminar la importancia de 1 0 5 mPtodos de especificacibn formal a proyectos de produccibn reales de software. Entonces siete entornos de apoyo al desarrollo del software se han instaurado para cubrir un amplio rango de Areas de aplicacibn.

Los entornos desarrollados en el proyecto FASET se basan en el paradigma de automatizacibn de software propuesto originalmen- te por Blazer et. al. C111.

En este paradigma el software es desarrollado a traves de dos fases: desarrollo de especificaciones alcanzables, y su traduccidn. Este paradigma establece gnfasis especial en el mejoramiento de la confiabilidad ejecutando la verificacibn en el nivel de especificacibn y el mejoramiento de la eficiencia en el desarrollo, mediante la reutilizacidn de especificaciones

Capitulo 6 - 66


validadas y traduccibn semi-automatics.

Los siete entornos de apoyo de desarrollo de software se integran verticalmente. Cada entorno combina todas las fases del ciclo del vida de la definicibn de requerimientos a la generacibn fuente de programas. Estos habilitan la generacibn semi- automdtica de programas fuente derivadas de especificaciones formales que son desarrollados tomando en cuenta las condiciones de diseño y los requisitos del usuario, a travCs de refinamientos de etapas y conversibn.

6.4 Evaluacibn de resultados de las siete entornos.

Los siete entornos de desarrollo de software se han desarrollado por equipos independientes en el proyecto FCISET. Aunque los siete entornos tienen los paradigmas comunes descritos en la seccidn 111, sus metodologías, lenquaJes de especificacibn y Areas de aplicacibn de objetivo, generacidn de lenguajes de programacibn fuentes, y 105 entornos de aperacibn varian de una herramienta a otra. Por lo tanto se ha tratado de evaluar los siete entornos desde un punto de vista comun en la fase media del desarrollo. Para este propbsito se ha desarrollado la tecnoloqia de evaluacibn del entorno del software. Esta fue experimentalmen- te aplicada a la evaluacibn preliminar de los siete entornos C121 despuk se mejor6 la tecnoloqia de evaluacibn y se aplicb a los siete entornos en la fase final del proyecto FASET para conocer el grado de aplicabilidad a las Areas de objetivo.

En esta seccibn se presenta el proceso de evaluacibn y los resultados.

6.4.1. Definicidn de requerimientos de calidad.

De acuerdo al proceso de evaluacibn de calidad descrito en la seccibn 11, se seleccionaron caracteristicas de calidad y se refinaron en subcaracteristicas. Para cada subcaracteristica, se supone el mds alto valor de cuatro grados de niveles de valuacibn como el requerimiento ideal de calidad en este estudio. Entonces, siete equipos de desarrollo y uno de coordinacibn determinaron los pesos relativos para cada subcaracteristica.

En primer lugar, algunas caracteristicas de calidad adecuadas para la evaluacidn del objetivo del entorno del software se seleccionaron. Como se describe en la secci6n 11, el entorno del software tiene dos objetos distintos de evaluacibn: metodología y lenguaje, y la herramienta de software en si. En consecuencia, las caracteristicas de calidad fueron divididas en dos clases: una para evaluar las metodologia y lenguaje de las

Capitulo 6 - 67

Medida y Evaluación de la Calldad del Software

herramientas y una para evaluacibn de la herramienta del software misma.

Para metodologia y lenguaje, se eligieron dos caracteristicas fundamentales. Para permitir la utilización de los nuevos entornos orientados a paradigma y que sus lenguajes y metodologias fueran aprendidos lo mds fdcilmente posible, los lenguajes deben incluir la mayor parte de funciones y la descripción de especificación debe ser operada en una forma simple por cualquier usuario. En concordancia, el aprendizaje y la funcionalidad fueron seleccionados y definidos como sigue:

- Aprendizaje a un conjunto de atributos que conducen a un esfuerzo necesario para el entendimiento y dominio del lenguaje y metodologia.

- Funcionalidad = a un conjunto de atributos que conducen a la capacidad o esfuerzo para describir y modificar datos y funciones.

Hay seis caracteristicas en el modelo ISO/IEC 9126, llamadas funcionalidad, confiabilidad, utiiidad, eficiencia, mantenibilidad, y portabilidad. Sin embargo sólo dos caracteristicas se aplicaron en la evaluación, considerando las condiciones t+cnicas actuales del proyecto; y son: la funcionalidad y la utilidad.

- Funcionalidad = conjunto de atributos que conducen a la existencia de funciones especificadas.

- Utilidad = conjunto de atributos que conducen al esfuerzo requerido para la utilizacibn de la herramienta.

En segundo lugar cada cracteristica de calidad se reiinb a subcaracteristicas. Dentro del proceso de tecnologia de aprendizaje el aprendizaje se refinó en el entendimiento y en ei dominio. L i funclonalldad para el lenguade, e-, una de las caracteristicas mds importantes para evaluar el entorno de desarrollo del software; se refini en especificabilidad, descriptibilidad, modificabilidad y reutilizacibn.

Capitulo b - 68


6.4 .2 Seleccidn de la mktrica y de la clasificacibn de nivel.

Para medir estas subcaracteristicas, dos mdtricas cualitativas se seleccionaron para cada una. Entonces, dos mbtricas cuantitativas llamadas horas de entrenamiento para la metodologia del entendimiento y lenguaje y lfneas descriptivas para la descripcibn fueron añadidas.

Por dltimo, cada criterio de clasificacibn mCtrica fuC definido y se aplicaron cuatro niveles de clasificaci6n al criterio, ellos son:

1 ) Rechazo. 2 ) Marginal 3 ) Bueno 4) Excelente

6.4.3 Medici6n y clasificacibn.

Se condujeron experimentos de desc-ipcibn y especificacibn utilizando las siguientes herramientas en la fase final de desarrollo: la herramienta de especificacibn algebraica, la de especificaclbn declarativa, la de especificacibn natural orientada al lenguaje, la de especificacibn diagramAtica y la de especificacibn orientada al estado de transicibn.

Para efectos de experimentacidn se aplicaron algunos problemas prdcticos especifico5 para cada herramienta; algunos ejemplos son:

- Para la herramienta de especificacibn a1gebraica.- la especificacibn de un juego sencillo, o una base de datos de libreria.

- Para la herramienta de especiiicaci6n declarativa.- un mCtodo de aprendizaje de categorfas, una descripcibn de libreria de base de datos.

- La herramienta de especificacibn orientada al estado de transicidn.- programaá de archivo transferidos por un protocolo de x-modem.

Capitulo 6 - 69

Medida y Evaluacidn de la Calidad del Softciare

6.4.4 Valoracidn de entornos.

Cuando se evalúa una sola herramienta o l a s cualidades de varias que tienen el mismo propdsito se comparan, el peso debe ser exactamente asignado para cada mCtrica de cada subcaracterística, y el nivel medido, el requerido y la puntuacidn alcanzada se calculan usando l a s siguientes fbrmulas:

n

j=1 nivel de medicibn = S P,W,

n

j=1 nivel requerido = S RJWJ

Donde P, es igual al punto valuado, R, es igual al punto requerido, W, es igual al peso para una mbtrica, n es igual al número de mbtricas dentro de una subcaracteristica. En este estudio, se seleccionaron dos mPtricas de igual importancia para medir cada subcaracteristica en la fase de seleccidn mbtrica. Se decidid que las dos metricas cualitativas se distribuyeran a cada subcaracteristica que tuviera un peso equivalente. Dado que se supuso el valor mds alto de los cuatro niveles como el requerimiento de calidad ideal, entonces se modificaron y simplificaron las fdrmulas anteriores como sigue:

1

2 nivel de medicibn = -- (PI + P 2 ) ,

1 nivel requerido = -- (4 + 4)

3 h

Capitulo 6 - 70


En esta evaluacibn cada subcaracteristica se midid mediante dos metricas (horas de entrenamiento y lineas de descripcibn exclusivas), y cuatro niveles de grado de valuacibn.

4 . 5 Resúmen.

Se han introducido los modelos para la evaluacibn de la calidad del software y la tecnologia de evaluacibn del entorno del mismo que fue desarrollada como una parte del proyecto FASET. Los resultados de la evaluacidn clarifican que las características de calidad del modelo jerdrquico, la evaluacibn de calidad del modelo de proceso y la representacibn grffica son adecuados para la evaluacidn del entorno del software.

Actualmente muchos entornos de software han sido desarrollados. Cada herramienta y tecnica apoya alyim tipo de meJoramiento en la calidad con respecto cuando menos a una caracteristica. Sin embargo, desde el punto de vista del usuario toda-, las características de calidad requieren utilizar un entorno especifico que represente claramente los atributos descritos en este estudio.

Capitulo b - 71


Cll Eva1 Use,

c21 qua 1

c 2 1

REFERENCIAS

ISWIEC 9126 Information Technology- Software Product uation-Quality Characteristics and Guidelines for their ISO, 1991.

B.M. Boehm et al., "Quantitative evaluation of software ity", in Proc. 2nd ICSE 1976, pp. 596-605.

J. A. McCall et al.,"Factors in software quality", RADC TR- 77369, 1977.

C41 G.E. Murine et al.,"Applying software quality metrics", presented at ASQC Quality Congress.

C51 M. Azuma and T. Sunazuka, "Software quality measurement anti assurance technology (SQMAT)", The Quality pp. 79-84, 1986.

E61 T. Sunazuka, M, Azuma, and Yamagishi, "Software quality assesment technology" in Proc. 8th ICSE, 1985, pp. 142-148.

C71 I. J. Peters et al.,"Comparing Software design Metodologies", Datamation, 1978.

C81 V. R. tiasili,"quantitative evaluation of software engineering methodology", in Proc. 1st Pan Pacific Compt. Conf. Melbourne, Australia, Sept. 1985.

C91 ,"Can we measure softcrare technology; Lessons learned from 8 years of trying", in Proc. 10th Annu. Software Eng. Workshop, NASA Goddard Space Flight Center, Greenbelt, MD, Dec. 1985.

l101 Proc. let Int. Workshop Software Quality Improvement, Join System Development Corp., 1989.

E111 R. Balzer, T. E. Cheatham, and C, Green, "Software Technology in the 199C)'s: Using a new Paradigm", Computer, vol. 16, NO. 1 1 , PP. 39-45, 1983.

C121 M. Azuma, T. Miyoshi, and Y. Togashi, "Evaluating software development environment quality", in Proc. IEEE COMPSAC ' 89 , Orlando, FL, Sept. 1989, pp. 501-508.

E131 Annu. Rep., JSA/INSTAC/STD, Japanese Standards Ass., Mar. 1989.

C141 FASET project Tch. Rep. 3 , Joint System development Corp.,

Capitulo 6 - 72


1989,

C151 R. Balzer, T.E. Cheatham, and C. Green, I' Software technology in the 1990's: Using a new paradigm", Computer, vol. 16, NO. 11, pp.39-45, 1983.

E l61 M. Azuma, T. Miyoshi, and Y. Toqashi, "Evaiuating software development environment quality", Proc. IEEE COMPSAC'89, Orlando FL. Sept. 1989, pp. 501-508.

Capitulo 6 - 73


7. Medida Basada en la Entropia de la Complejidad del Software.

7.1 Introduccibn

La mPtrica de complejidad pretende asociar un nitmero con un programa, basado en el grado de presencia (o ausencia) de ciertas caracteristicas del software, en base a la hipdtesis de que un cddigo complejo (esto es, cddigo con alto grado de "malas características") serd dificil de mantener y poco confiable debido a un nimero desproporcionado de errores de programacibn.

Uno de las objetivos de la investigacidn en este campo es formular un mPtrica de complejidad que permlta a los programadores y sus manejadores predecir con exactitud el nitmero de errores en un programa. Si esta mbtrica pudiera ser aplicada al principio de la fase de prueba del softblare, se obtendría un chequeo mas efectivo de los recursos de distribucibn . Adicionalmente esta informacibn podría ayudar a los desarrolladores a decidir cudndo se ha completado la prueba, y a decidir cudndo el producto est& listo. Si consideramos que la minimizacibn de errores es un aspecto importante de programacidn, la mPtrica de complejidad puede servir como herramienta de retroalimentacibn a los programadores cuando escriben cbdigo así como servir como parte importante de las inspecciones del mismo.

En este estudio se propone que la Complejidad de un Programa es Inversamente proporcional al contenido promedio de informacibn de sus operadores. A q u i se describe un extenso estudio empírico en el cual el contenido de informacidn de los programas es relacionado a la frecuencia de error con resultados favorables. A partir de estos resultados se propone una medida ordinal de la complejidad del software basaoa en el contenido de informacibn de los programas.

Capitulo 7 - 74

Medida y Evaluacih de la Calidad del Software

7.2 Teoria de Informaci6n.

Una cadena de simbolos dibujada desde un alfabeto de simbolos s1,...sq se puede llamar mensaje. El campo de la teoria de informacidn trata con la medida de la cantidad de informacidn contenida en un mensaje CSI. La informacidn en este contexto, encuentra algo que no se conoce aún. En otras palabras, la informacidn es la cantidad de "sorpresa" expresada por cada simbolo en el mensaje.

Es decir, cuando ocurre un simbolo no esperado, la sorpresa, y mis aún, la informacidn, es mayor que un simbolo que esperdbamos ocurriera.

La cantidad de informacidn expresada por un 5610 simbolo S,

en un mensaje es inversamente relacionado a su probabilidad de ocurrencia. La probabilidad de este simbolo es p(s,) = p,. Esto se ha formalizado de manera que la cantidad de informacibn I i , en unidades abstractas llamadas bits, expresada por un 5010 símbolo S, con probabilidad de ocurrencia pi es:

1% = - log,p,

La informacidn es añadida, esto es, la cantidad de informacidn expresada por dos simbolos es la suma de su contenido de informacidn individual. Entonces, un alfabeto completo de simbolos padria proporcionar un promedio

de bits de informaci6n por simbolo. Esta cantidad es llamada Entropia de la fuente de Informacibn o lenguaje de Entropia. En el resto de este capitulo, el tCrmino bits se referird a la unidad de informacidn, y no a la definicidn normalmente encontrada en la literatura de computaci6n.

Es posible demostrar que la cantidad maxima de informacidn por simbolo es proporcionada por un alfabeto cuyos simbolos ocurren con igual probabilidad. El promedio de informacidn expresada por cada simbolo en tal alfabeto es logzq, para un alfabeto con q simbolos, cada uno con igual probabilidad de ocurrencia.

La minima cantidad de informacibn es expresada por un alfabeto en el que un simbolo ocurre con una probabilidad 1 , y todos los otros ocurren con una probabilidad de O . Este alfabeto

Capitulo 7 - 75

Medida y Evaluac ibn de l a Calidad del Software

t i ene una entropia d e lenguaje de 0.

7 . 3 Aplicacidn de la Teoria d e Informacidn a l software.

La versibn aqui presentada de es ta mCtrica s e basa en una d i s t r i b u c i b n empirica d e operadores dentro de un programa. Como se ha def inido en [ ? I , u n sfmbolo e s p e c i a l , una palabra reservada o una llamada a una funci6n se consideran operadores. Este estudio se l imi ta a operadores porque 5e ha encontrado que tienen c i e r t a d i s t r i b u c i b n de probabllidad naturalC91.

La probabilidad p i del 1-Csimo operador con ocurrencia mda frecuente es igual a l porcentaje de las ocurrencias tota les a l a s que contribuye, esto es

P I = f l / N 1

donde N, e s número t o t a l de operadores (no únicos) usados en e l programa, y f i e s e l número de ocurrencias del i-Csimo operador mds frecuentemente ocurrido. Entonces, l a cantidad promedio de informacibn aportada por cada operador en u n programa es :

"1

H z - S p I lOQ,Pi 1 - 1

Se hace re ferenc ia a H como l a Entropía Empirica del Programa.

7 .4 Una Metrica de l a Complejidad del Software basada en la Entropfa Emplrica d e l Programa.

La hipdtesis bdsica es que u n programa con un a l t o promedio de contenido de informacibn podria ser menos complejo que o t r o programa con un ba jo promedio. La medida d e Clas i f icacibn del Contenido de Informacibn Promedio (AICC) s e c a l c u l a de acuerdo a los siguientes pardmetros:

NI e s e l nkmero t o t a l de los operadores usados sn e l programa. f 1 '.:= i < n l e s e l número de veces q u e e l i-8simo operador aparece en el texto fuente. Entonces usando e s t a informaci6n s e l l e v a a cabo e l s iguiente cd lculo

n i f i f i

1 - 1 N I N1 AICC = - S "" log2 ----

Capitulo 7 - 76


El resultado de este cdlculo es redondeado a la dbcima mds cercana para establecer el mbdulo de medida AICC. Esta es una medida ordinal de la Complejidad del Software. Por ordinal se entiende que la mbtrica intenta ordenar los programas en relación a su complejidad, pero no se concluye que se pueda definir como la "distancia" entre dos medidas.

Esto implica por ejemplo, que los operadores de suma y resta de los valores de AICC no son significativos. Tampoco se puede utilizar un medio aritmCtico para representar la tendencia central de un grupo de mbdulos mcitricos AICC, aunque podemos usar una media.

Naturalmente, considerando la mbtrica como una medida ordinal, tambibn se estd restringiendo, porque se intenta solamente establecer un rango de los programas basados en su complejidad, no se puede inferir cudnto mds complejo es un programa compardndolo con otro, aunque la m@trica nos indique cud1 es el mds complejo. Desde luego esta sigue siendo informacibn útil, esta medida proporciona una quia si se desea identificar el 10% mds complejo de los mbdulos (tal vez no se tienen suficientes fuentes para aplicar inspecciones detalladas a cada mddulof, o tal vez deseamos comparar dos implementaciones distintas de la misma función (tal vez se tiene la opcibn de usar una o dos implementaciones de libreria). Al mismo tiempo una medida ordinal es mds fdcil de construir y de validar que una medida a intervalos o por proporciones de escala.

7.5 Valoracibn del Desempeño de la Nueva Mbtrica.

En el intento de relacionar una métrica dada con la Complejidad del Software, se debe establecer una mcitrica para la complejidad. Esta métrica intenta medir indirectamente una variable basada en algunas otras variables. La métrica elegida fue la del Lapso de Error. El Lapso de Error es simplemente el promedio del número de takers por error de cbdigo. En este caso "entre mds grande es mejor" ya que los valores grandes del Lapso de Error reflejan menos frecuencia de ocurrencia de error. Esto se calcula como

N ES _________________

Número de errores

Se ha pensado que esta es una medida razonable de la complejidad del software, ya que muchos investigadores concuerdan que altos niveles de complejidad pueden resultar en un número incrementado de errores de cbdigo en el mismo. Se ha decidido

Capitulo 7 - 77


i usar el lapso de error como oposicibn errores, pues la investigacibn tambibn grandes tienden a tener mis errores.

al nclmero absoluto de ndica que los sistemas

Desde el punto de vista de la investigacidn llevada a cabo, el hecho de que la MQtrica AICC est2 positivamente correlacionada con el errar promedio de Lapso de error es sorprendente. Esto implica que en tanto se incremente el contenido de la informacibn promedio, el lapso promedio entre los errores se hace mis grande (la densidad de error disminuye).

Sin embargo, los datos que han sido examinados en dos proyectos sugieren que un promedio mds grande de contenido de informacidn por sfmbolo se relaciona a mddulos con lapsos de error "aumentados", implicando software menos complejo. La llave para la distincibn es el hecho de que se ha utilizado contenidos de informacidn promedio por simbolo, eliminando entonces el impacto del tamaño del programa. Muchas otras tecnicas aplican el total de la informacibn del programa, viendose afectadas por su tamaño.

Capitulo 7 - 78

Medida y Evaluacidn d e la Calidad del Software

7 . b Resllmen.

En este estudio, se ha d e s c r i t o una nueva m4trica d e complejidad del software basada en e l contenido d e informacidn promedio de cada operador en un cddigo fuente de programa. Se ha observado que esta m4trica exhibe una buena correlac idn con l o s Lapsos d e Error d e una gran coleccibn d e software industrial .

Se deberdn l l e v a r a cabo t raba jos adic ionales en e l campo empfrico antes d e que esta m4trica sea validada adecuadamente, los datos con que se cuenta a la fecha sugieren que e l contenido d e informacidn basado en l a s t k n i c a s de medicitm d e l software es prometedor.

Referencias.

C 1 1 E. B e r l i n g e r , " A n information theory based complexity measure", i n Proc. 1980 Nat. Computer Conf., pp.773-779.

C215. Davis and R. LeBlanc, "A study of the a p p l i c a b i l i t y o f complexity measures", IEEE Trans. Software Eng., vol. 14, pp. 1366-1372, Sept. 1988.

C31 M. Halstead, Elements of Software Science, Amsterdam, T h e Netherlands: Elsevier Science, 1976.

C41 S . Zweben and M. Halstead, "The f recuency dis tr ibut ion of operators in PL/I programs", IEEE Trans. Software Eng., vol. SE- 5, pp, 91-95, Mar. 1979.

Capitulo 7 - 79


B. Prediccibn de los cambios desde la complejidad de los datos.

8.1 Introducci61-1.

El principal objetivo del presente andlisis estadistico, es poder efectuar predicciones en base a un modelo matemdtiro. En este caso se desea poder hacer predicciones significativas a futuro acerca de los cambios en el software.

Se ha seleccionado la estimacidn MRE (minim0 error relativo), de acuerdo con los resultados obtenidos en una amplia ~nvestiyaclbn realizada por Kitchenham y Pickard E l l , en la que se puede observar que la estimacldn MRE así como la estimacidn RtS son l a s mejores, ya que 13 funcidn de perdida ARE asociada a cada una de dichas estimaciones es minima.

TambiPn se calcula el coeficiente de determinacidn Rz en la investigacidn antes mencionada, y cuyo valor es representativo de la calidad de ajuste del modelo. Por lo que se supuso para los sistemas analizados, se tiene la mejor calidad de ajuste con respecto a los metodos LS (Minlmos Cuadrados), y LAV iMinlmo Valor Absoluto).

En este capitulo se aplican entonces los resultados obtenidos en dicha investigacidn llevada a cabo en un Slstema de Imdgenes Medicas para evaluar la calidad de los sistemas seleccionados.


8 . 2 Ajuste de Curvas.

A continuacidn se examinan las asociaciones cuantitativas entre un número de variables, lo que en terminologia estadistica se conoce como andlisis de regresibn.

De manera especifica se examina una t4cnica que permite ajustar una ecuacibn lineal al conjunto de datos dado, con el propdsito de obtener una ecuacibn empirica de prediccibn razonablemente precisa y que proporciona un modelo tebrico que no estd disoonible.

Se cuenta con un conjunto de mediciones y % , y z , . . . y n de una variable respuesta Y (cambios del programa), las cuales se observaron en los diferentes conteos de operadores dentro del programa ( x x , x2,. . . , x m ) , que representan los valores de las k variables de prediccibn.

En este caso la variable respuesta es el número de cambios y la variable de prediccidn es el número de operadores en el programa. Se requiere determinar una ecuacidn de regresibn para el número de operadores, como una funcibn de los cambios promedio en el programa.

La figura 1 muestra la grdfica del número de cambios en el programa contra el número de operadores, resultado del andlisis de un sistema de liquidaciones.

U pesar de la dispersidn observada en esta grdfica, se puede ver una tendencia lineal. Se supuso un modelo de la forma:

y, = a + bx, + e,, i = 1,z ..., n (1)

donde y i es la i-Csima observ-acibn de la variable respuesta (número de cambios en el programa), la cual corresponde al i- &imo valor x, de la variable de prediccibn (número total de operadores en el programa). Se puede ver que e, es el error aleatorio no observable asociado con y í ; a y b son pardmetros desconocidos que representan la interseccidn y la pendiente, respectivamente. e, es la distancia vertical de la observacibn a la línea de regresibn.

El metodo de minimos cuadrados considera la desviacibn de la observacidn y í de su valor medio y determina los valores de a y b Que minimizan l a suma de los cuadrados de estas desviaciones.

Capitulo 8 - 81


La i-Csima desviacibn o error es

y la suma de los cuadrados de los errores es

n n S eíz = S (y i - a + b x i ) =

i=l i=1

Los estimadores de minimos cuadrados a y b se obtienen diferenciando e igualando a cero la ecuacibn anterior, de lo cual se ob t iene :

Dados los estimadores a y b para la interseccibn y la pendiente respectivamente, la recta de reyresibn estimada para el modelo es:

donde Y A i es el estimador para la media de la observación y i , la cual corresponde al valor x i de la variable de prediccibn.

Con base en la ecuacidn nlimero 2, la diferencia entre la realiracidn y i y el valor estimado Y A i e s un estimador del correspondiente error. Este estimador se conoce como i-esimo residual ei = y i - y A i .

Capitulo 8 - 82

En 2 1 a n d l i s i s se elmpies e l Minino Error Relativo, p~-~.es los resultados obtenidos en una lnvestigaclin l levada a cabo en u n Sistema de imdgenes il@dicas (MIS) indica q ~ ! e e s t e &todo presentaba una función de psrdida a x ~ i a d a (AGE) minima iv@ase el capi tu lo nlimera 4) respecto a o t r o s metodos C l l .

Se hicieron mediciones en 5 s i s te tms de .software ya terminados, en los cuales se realizaron recientemente sz610 algunas modificaciones y de los cu; les se obtuvo sblo algana informacibn a! respec to , es dec l r , los d a t o s empleados son en su mayaria aproximados d e acuerdo a observaciones hechas por los mismos programadores. Cabe mencionar que estos s is temas se desarrollaran en el lenguaje de programación llamado ' C ' . Lor. v a l o r e s obtenidos en l a s inediciones hechas a cada sistema se encuentran resumidos en l a s t a b l a s No. 1 a la r40. 5 , asi como sur. gr?:lcas asocladas respectlvamente. . . .

8.3 Andlisis de los resultados.

p; b-lnerc: E l mode!:o de r e q r e s ~ c n debe representar adecuadamente l a dlspersldn 1;neal de l o s dat:os. Esta es l a ca l ldad de l c r i te r io de a j u s t e .

Segi-indo: El modelo (debe hacer predicciows f1-1.turas s i g n i f i c a t i v a s . E s t a es la ral idad predictivz del mcdelo.

E l mbtodo MRE, como se menclona a l pr incipio del capi tulo , es el ne.jor estimador en tPrmlnos de la me.jor l inea que se a j lus ta a l o s =lstemas analizados en la invescigacion, para u n par de var iab les representando !a :n+trica de cumpleJidad en rada sistema,

A l in tentar In terpre tar los res~~. l tados dz la regresil jn l i n e a l se t i e n e que los valoras .son l o s estimadores p a r a 13s m d i a s de !as distribution,% j e probasilidad de! ni'tmern de cambios o errores corresponoizntes al n6mero t o t a l ,de operadores :S i .

E l ndmero de operadores en e1 conjunto de d a t o s para el sistema 1 varian de 370 a 383, por l o q:ue suaiauiera que sea l a validez qiie t i e n e ia ecuacidn estimada de regresión y ^ para predecir e1 ndmzro de c m b i o s se mantiene, para todos los valores

C7

o Y L 1 -I

" =a 3.

, c o ID PJ +- UI a r o c. n 111 'U

U'I m

c+ Y m 3

IU - t t Y m

3 m U Y.

U (u

h .: m VJ

c w n c. í+ J


Tabla No. 1 Calculos bdsicos para obtener l o s estimadores de aininos cuadradas a y b con base en l o s datos obtenidos del Sisteaa No. 1.

N1 Cambios

370.00 5 371.00 6 374.00 5 374.00 6 375 .o0 7 378 .00 7 3 0 .o0 9 381 .M 8 385.00 9 369.00 10

3777 72

XiYi

1850 2226 1870 2 4 4 2625 2646 3420 3048 3465 3890

27204

2 Xi'

136900 137641 139876 139876 140625 142884 144400 145161 148225 151321

1426909

L

yi' Predicción ME MRE I

25 5.1472776 -0.029456 0.0294555 36 5.4138649 0.0976892 0.0976892 25 6.2136269 -0.242725 0.2427254 36 6.2136269 -0.035604 0.0356045 49 6,4892142 0.0742551 0.0742551

81 7.8131508 0. 1318721 0.1318721 64 8.0797382 -0.009967 0.0099673 81 9.1460875 -0.016232 0.0162319

1rW 10.212437 -0.021244 0.0212437

546 72 -0.091408 0.6990413

49 7 . 2 7 ~ 7 6 2 - 0 . 0 3 ~ 7 0 . 0 3 9 ~ 6 6

n- 10

Coeficientes para la ecuación nomal de regresión y'i= a + bxi

b= a=

0.2&5873 -93.49003

Capitulo 8 - 85


m

O

m

Capi tu lo 8 - 86

Medida y Evaluacidn de l a Calidad del Software


Sistema No. 2 (Liquidaciones) .- Al intentar interpretar los resultados de la reyresidn

lineal se tiene que los valores y ^ % son los estimadores para las medias de las distribuciones de probabilidad del número de cambios o errores correspondientes al número total de operadores :i i .

El número de operadores en el conjunto de datos para el sistema 2 varían de 815 a 847, por lo que cualquiera que sea la validez que tiene la ecuacidn estimada de regresidn y ^ para predecir el nimero de cambios se mantiene, para todos los valores que se encuentren entre 815 y 847.

Si se desea hacer predicciones de los cambios para valores mds alld del intervalo de los valores de x para los cuales se obtuvo la ecuacidn estimada de regresidn, si los valores de ;; se encuentran muy cercanos a dicho intervalo, la prediccicjn tiene cierta validez.

Por otro lado, si se interpreta la pendiente de la grdfica de regresidn para la tabla No. 2 , se ve que el número de cambios para cada medicidn de la complejidad igual a una unidad de número de cambios promedio en el programa es de 0.1.

Si ;< = 842 el nimero de cambros o errores en el sistema estimados es de y * = 4.24 cambios. Por lo que el valor correspondiente observado es de 4, el residual es e= :4 - 4.24:: 0.24, es decir, 0.24 es la distan,ia vertical que existe entre la observacidn 4 y el punto sobre la recta de regresidn estimada para x = 842.

Capitulo e - ee

Medida y E v a l u a c i b n d e l a C a l i d a d d e l S o f t w a r e

Tabla No. 2 Calculos hasicos para obtener los estimadores de m í n i m cuadrados a y b con base en los datos &tenidos del Sistema No. 2.

Valores estimados considerados para graficar la predicción lineal.

N1 Canbios

e15.00 2 82.00 1 831.1)1> e a . 00 4 842. C4 3 846.00 4

856.00 5 861 .00 6 867.00 6

'I

850.00 6

8426 39

XiYi Xi'2

1630 664225 822 675684

1662 690561 3344 693896 2526 708964 3384 715716 51M 722500 4280 732733 5166 741321 5202 751689

33116 7102292

y i * 2 Predicción ME M E I

4 1.1382M 0.4308678 0.430Ei678 1 1 ,8387046 4.83e705 o . m m 4 2 .73~706 -0.36~5 0.396353

16 3.239585 0.1901038 0.1901038 9 3.8399623 -0.279981 0.2799874

15 4.2402138 4.060053 0.0600535 36 4.6404653 0.2265891 0.2265891 25 5.2408426 -0.048169 0.0481685 36 5.7411571 0.0431405 0.0431405 36 ~.NI~S-G - 0 . 0 5 6 9 ~ 0.0569224

183 39 -9.762771 2.5441728

n= 10

Coeficientes para la ecuación noraal de regresión: y'= a + bx

b= a-

0. 1000629 -80.4139

C a p i t u l o 8 - 69

Medida y Evaluaci6n de l a Ca l idad del Software

0

O

m

O

m

Medida y EvaluacirSn de la Calidad d e l Sof tware

Capitulo 8 - 91

Medida y Evaluacibn de la Calidad del Softcrare

Sistema No. 3 (Descarga).-

Al intentar interpretar los resultados de la regresibn lineal se tiene que los valores y A i son los estimadores para las medias de las distribuciones de probabilidad del número de cambios o errores correspondientes al número total de operadores xi,

El número de operadores en el conjunto de datos para el sistema 3 varian de 723 a 747, por lo que cualquiera que sea la validez que tiene la ecuacibn estimada de reqresibn y^ para predecir 21 nl'lmero de cambios 5e mantiene, para todos los valores que se encuentren entre 723 y 747.

Si se desea hacer predicciones de los cambios para valores mds alld del intervalo de los valores de :: para los cuales se obtuvo la ecuacidn estimada de regresibn, si los valores de x se encuentran muy cercanos a dicho intervalo, la predicci6n tiene cierta validez.

Por otro lado, al interpretar la pendiente de la grAfica de reqresidn para la tabla No. 3, se ve que el nitmero de cambios para cada medicibn de la complejidad igual a una unidad de nlimero de cambios promedio en el programa es de 0.2.

Si :;=738, el número de cambios o errores en el sistema estimados es de y - = 4.71 cambios. Por lo que el valor correspondiente cbservado es de 3 , el residual es e= 13 - 4.71 : = 1.71, es decir, 1.71 es la distancia vertical que existe entre la observacibn 3 y el punto sobre la recta de reqresibn estimada para x = 738.

Capitulo 8 - 92

Medida y Evaluacibn de la Calidad d e l Software

Tabla No. 3 Mlculos bisicos para obtener l o s estimadores de nfnirnas cuadrados a y b con base en los datos obtenidos del Sistema No. 3.

ValorE estimados considerados para graficar la predicc ión l inea l .

723.00 728.00 3 732. 00 2 751 .o0 5 73.00 4

741 .o0 5 743.00 a 745 .OO á 747.00 7

/A/ 1 45

-

738. 00 ., .I

”

1446 2184 1464 S 6 5 2948 2214 3705 5944 4470 5 2 9

3 2 8 9

522729 529984 5 9 @ 4 543169 543163 544644 549081 552049 555025 558009

5433683

4 1.2528426 0.3755787 0.45’35787 9 2.4043168 0.1965611 0.1985611

25 4.4769705 0.1046059 0.1046059 16 4.4769705 -0.119243 0.1192426 9 4.7072654 -0.569088 0.5690885

25 5.3981499 -0.07963 0.07963 b4 5.8587396 0.2676575 0.376575 % 6.3193294 -0.05322 0.0532216 49 6.7799191 0.0314401 0.0314401

4 3.3254962 -0. 662748 o. b6274a1

24 1 45 -0.508087 2.4597741

n= 10

Cceficientes para la ecuacion nonsal y ^ = a + bx

b= a=

0.2302949 -165,2503

Capitulo 8 - 93


m

m

m

m

m

m

Capitulo 8 - 94

Medida y E v a l u a c i d n d e l a C a l i d a d d e l S o f t w a r e

Capítulo 8 - 9s


Sistema No. 4 (Mantenimiento de Congeladores).-

Al intentar interpretar los resultados de la regresidn lineal se tiene que los valores y * $ son los estimadores para las medias de las distribuciones de probabilidad del número de cambios o errores correspondientes al número total de operadores x,.

El número de operadores en el conjunto de datos para el sistema 4 v a r i a n de 71 a 103, por lo que cualquiera que sea la validez que tiene la ecuacibn estimada de regresidn y ^ para predecir el número de cambios se mantiene, para todos los valores que se encuentren entre 71 y 103.

Si se desea hacer predicciones de los cambios para vaiores mds alid del intervalo de ios valores de :c para los cuales se obtuvo ia ecuacidn estimada de regresion, si los valores de x se encuentran muy cercanos a dicho intervalo,la prediccibn tiene cierta validez.

Por otro lado, si se interpreta la pendiente de la grdfica de regresidn para la tabla No. 4, se ve que el número de cambios para cada medicibn de la complejidad igual a una unidad de número de cambios promedio en el programa es de 0 .1 .

Si :I = 97, el número de cambios o errores en el sistema estimados es de y - = 3.77 cambios. Por 10 que el Valor correspondiente observado es de 4, el residual es e= 14 - 3.97:= (2.03, es decir, 0.03 es la distancia vertical que existe entre la observacidn 4 y el punto sobre la recta de regresidn estimada para :c = 97.

M e d i d a y Evaluacidn d e l a C a l i d a d d e l Software

Tabla No. 4 CAiculos hasicos para obtener l o s estiaadores de mínimos cuadrados a y b con base en los datos obtenidos del Sistema No. 4.

Valores estimdos considerados para graiicar la predicción lineal.

N1 Carebios

71 .00 1 76.00 2 eo. 00 2 81 .O0 83 00 3 66.00 4 92.00 5 97.00 5 w.00 6

1 03.00 6

7 4

e67 37

XiYi

71 152 160 243 249 344 460 485 5E3 618

9 7 0

2 Xi’

5041 5776 Moo b561 6889 7396 8464 94G9 9604

1 0609

76149

n= 10

Coeficientes para la ecuación roma1

b= a=

0. 1553913 -10.63942

2 yi’ Predicción

1 1.1034 4 1.9303 4 2.5919 9 2.7573 9 3.0881

16 3.5842 25 4.5766 25 5.4035 36 5.5689 36 b.3959

165 37

WE 1 ME

(0.1991) 0.9316

Capitulo 8 - 97

,


m m

m

m m

6

Capitulo E - 98


Capitulo S - 99


Sistema No. 5 (Sel. Banco) .- 41 intentar interpretar los resultados de la regresidn

lineal se tiene que los valores y * * son los estimadores para las medias de las distribuciones de probabilidad del nomero de cambios o errores correspondientes al número total de operadores :í I .

El número de operadores en el conjunto de datos para el sistema 5 varian de 68 a 79, por lo que cualquiera que sea la validez que tiene la ecuacidn estimada de regresidn y - para predecir el número de cambios se mantiene, para todos los valores que se encuentren entre 68 y 79.

Si se desea hacer predicciones de los cambios para valores mas alld del intervalo de los valores de x para los cuales se obtuvo la ecuacidn estimada de regresidn, si los valores de x se encuentran muy cercanos a dicho intervalo,la prediccidn tiene cierta validez.

Por otro lado, si se interpreta la pendiente de la grdfica

para cada medicibn de la complejidad igual a una unidad de número de regresidn para la tabla No. S, se ve que el ndmero de cambios

de cambios promedio en el programa es de 0.1;.

Si :i = 73 , el número de cambios o errores en el sistema estimados es de y * = 1.86 cambios. Por lo que el valor correspondiente observado es de 3, el residual e5 e= : 3 - 1.861= 1.14, es decir, 1.14 es la distancia vertical que existe entre la observacidn 3 y el punto sobre la recta de reqresidn estimada para :.: = 73.


Tabla No. 5 Calculos basicos para obtener los estimadores de níniwos cuadrados a y b con base en los datos obtenidos del Sistwa No. 5.

Valores estimados considerados para graficar la predicción lineal.

N1 Canbios

65.00 1 70.00 1 71.00 A 7

72.00 2 73.00 74.00 76.00 3 77.00 4 78.00 4 79.00 5

- J -, .I

735 28

n= 10

Xi Y i

65 70 142 144 219 m 228 308 312 395

2105

2 Xi'

4225 490) 504 1 5 184 5329 547b

5929 6084 6241

5nb

54185

Coeficientes para la ecuación mraal

b- 0.2892308 a= -18.45846

L

yi' Predicción MRE I NRE I

1 1 4 4 9 9 9

lb 16 25

0,3415 l. 7877 2.0769 2.3662 2.6554 2.9446 3.5231 3.8123 4.1015 4.3908

0.6585

(0.03853 (O. 1831) 0.1149 0.0185 (0.1744) 0.0469 (0.0254) O. 1218

(0.7877) (0.6585) (0.7877) 0.0285

(0 . 1831 3 (0.11493 0.0185 (0.1744) (0.0469) (0.0254) (0.1218)

65 0.915385 78 4.1015385

Caeitulo 8 - 101

,


m o m

Caoitulo 8 - 102

Medida y Evaluaciin de l a Ca1id;d del Software

8 . 4 Resúmen.

S i se hace una revlsidn general del an2l is is de los s istemas mecidos. se pueden observar algunos caso5 específicos en l a s que el residuo e s inclusive mayor qi;e l. Dado qcke el residuo representa l a eantidad en l a que u n valor estimado f a l l a para predecir la mdia de la obzervaciin aleataria Correspondiente, entre mis grandes .son las magnitudes de los res iduos, mayor tender.4 a ser e l e f e c t o de 1 ; componente a l e a t a r i a , es d e c i r , del ndmero ,32 csmbios en e l madelo.

Medida y Evaluacidn de l a Calidad del Software

Referencias.

111 R . K . Lind and K. Vairavan, " A n experimental investigation of software metrics and their relationship to software development effort", IEEE Trans. Software Eng., vol. 15, pp. 649-651, Nay. 1989,


Bibliografía.

Lionel C. Briand, Victor R. Basili, Fellow, IEEE. and William M. Thomas, Member, IEEE, "A Pattern Recognition Aproach for Software Engineering Data Hnalisys", IEEE Trans. Softtuare Engineering, Vol. 18, No. 11, Nov. 1992.

Ram Chilarege, Senior Member, IEEE, Inderpal S. Bhandari, Member, IEEE, Jarir K. Chaar, Member, Michael J. Halliday, Diana S. Muebus, Bonnie K. Ray, and Man-Yuen Wong, "Orthogonal Defect Classification-A Concept for In-Process Measurements", IEEE Trans. Software Enqineering, Vol. 18, No. 11, Nov. 1992.

Norman F. Schneidewind, Senior Member. IEEE, "Methodology for validating Softcrare Metrics", IEEE Trans. Software Engineering, Vol. 18, No. S , May. 1992.

Taghi M. Khoshgoftaar, IEEE, John C. Munson, Member, IEEE, Bibhuti B. Bhattacharya, and Gary D. Richardson, "Predictive Modeling Techniques of Software Quality from Software Measures", IEEE Trans. Software Engineering, Vol. 18, No. 11, Nov. 1992.

Takechige Miyoshi and Motoei Azuma, Member, IEEE, "An Empirical Study of Evaluating Software Development Environment Quality", IEEE, Trans. Softblare Engineering, Vol. 19, No. 5, May. 1993.

Warren Harrison, "AN Entropy-Based Measure of Software Complexity", IEEE Trans. Software Engineering, Vol. 18, No.ll , Nov. 1992.

Sergio Cdrdenas-Garcia and Marvin V. Zelkowitz, Senior Member, IEEE, "A Management Tool for Evaluation of Software Designs", IEEE Trans. Software Engineering, Vol. 17, No. 9, Sept. 1992.

David J. Smith and Kenneth B. Wood, "Engineering Quality Software", 2a. ed., Elsevier Applied Science, 1989, 2B3pp.

Walpole R.E., R. H. Myers, "Probabilidad y Estadistica para Ingenieros", Sa. ed., Interamericana, M&:íico, 1988, 733 pp.

Gerge C. Canavos, "Probabilida y Estadistica, Aplicaciones y Mbtodos", McGraw Hill, M@:íico, 1988, 651 pp.

i

UNIV€RSIDAD AUTONOMA M€TROPOlITANA

Documents

Transcript of UNIV€RSIDAD AUTONOMA M€TROPOlITANA