FACULTAD DE INGENIER IA UNIVERSIDAD DE LA REPUBLICA An

FACULTAD DE INGENIERIAUNIVERSIDAD DE LA

REPUBLICA

Analisis de Taxonomıasde Defectos

Proyecto de Grado

Marıa Fernanda Grazioli [email protected]

TutorDiego Vallespir

[email protected]

Montevideo, UruguayDiciembre, 2009

Resumen

Los defectos juegan un papel importante en el desarrollo de software. Por unlado, porque cuando son detectados los mismos deben ser corregidos para queel software desarrollado sea de mejor calidad. Por otro lado, porque los defectoscontienen informacion que puede ser analizada con el fin de obtener mejoras ybeneficios. Por ejemplo, conocer la calidad de los distintos procesos de desarrolloy los productos, realizar seguimiento del progreso de un proyecto, controlar ymejorar los proceso de desarrollo, entre otros. Existen distintas taxonomıas quepermiten clasificar defectos de software.

En una organizacion el desarrollo de sistemas de software se realiza en equi-po. Un equipo esta compuesto por un conjunto de individuos, y todos juntosejecutan un proceso de desarrollo a nivel organizacional para lograr cumplir conel desarrollo segun los objetivos planteados. En particular, durante la fase deimplementacion, cada individuo lleva a cabo su proceso de desarrollo indivi-dual, que paralelamente se esta ejecutando con el proceso de desarrollo de laorganizacion. Lamentablemente, las taxonomıas de defectos existentes fuerondesarrolladas considerando unicamente el desarrollo a nivel organizacional.

En este trabajo se presenta un analisis profundo y comparativo de distintastaxonomıas de defectos: HP, Kaner, Binder, IEEE, ODC y Beizer. Para ellocreamos un marco de comparacion teorico original que permite la evaluacion ycomparacion de cualquier taxonomıa. Los resultados muestran que cada taxono-mıa considera distintas caracteristicas de un defecto. Algunas de ellas son mascompletas que otras desde el punto de vista de atributos. Sin embargo, aquellasmenos completas tienen un conjunto mas amplio de valores para los mismos.El analisis tambien muestra que hay diferencias en las propiedades entre lastaxonomıas.

Ademas, se estudia el estado de la practica de las taxonomıas. Los resul-tados obtenidos en distintos reportes reflejan que con un adecuado uso de unataxonomıa se pueden identificar los errores sistematicos, reducir los defectos,identificar areas de mejora potencial, reducir los costos del proyecto y evaluartecnicas de verificacion entre otros.

Los reportes de uso de taxonomıas y un analisis que realizamos sobre unexperimento formal muestran que clasificar defectos mediante una taxonomıa esuna tarea difıcil. La etapa de aprendizaje es extensa. La calidad de los resultadosdepende fuertemente de como se aplique la taxonomıa elegida, por lo que nolograr un buen dominio de la misma afecta significativamente la correctitud delos resultados de los analisis posteriores.

Por ultimo, en este trabajo desarrollamos una taxonomıa para ser aplicadadurante el proceso de desarrollo individual, en particular durante la verificacionunitaria.

iii

iv

Indice general

1. Introduccion 11.1. Motivacion y Objetivos . . . . . . . . . . . . . . . . . . . . . . . 11.2. Trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . 4

2. Meta Taxonomıa 52.1. Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3. Propiedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4. Incorporacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5. Clasificacion de esquemas . . . . . . . . . . . . . . . . . . . . . . 92.6. Discusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Taxonomıas 113.1. Taxonomıa de Hewlett-Packard . . . . . . . . . . . . . . . . . . . 11

3.1.1. Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.2. Tipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.3. Modo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2. Taxonomıa de Kaner, Falk y Nguyen . . . . . . . . . . . . . . . . 143.2.1. Defectos de Interfaz de Usuario . . . . . . . . . . . . . . . 143.2.2. Manejo de Errores . . . . . . . . . . . . . . . . . . . . . . 143.2.3. Defectos Relacionados a Fronteras . . . . . . . . . . . . . 153.2.4. Defectos en Calculos . . . . . . . . . . . . . . . . . . . . . 153.2.5. Estado Inicial y Siguientes . . . . . . . . . . . . . . . . . . 153.2.6. Defectos de Control de Flujo . . . . . . . . . . . . . . . . 153.2.7. Defectos de Manejo o Interpretacion de Datos . . . . . . . 163.2.8. Condiciones de Carrera . . . . . . . . . . . . . . . . . . . 163.2.9. Condiciones de Carga . . . . . . . . . . . . . . . . . . . . 163.2.10. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.11. Control de Version y Fuentes . . . . . . . . . . . . . . . . 173.2.12. Documentacion . . . . . . . . . . . . . . . . . . . . . . . . 173.2.13. Defectos de Testing . . . . . . . . . . . . . . . . . . . . . 17

3.3. Taxonomıa de Robert Binder . . . . . . . . . . . . . . . . . . . . 173.3.1. Taxonomıa de Defectos a Nivel de Metodo . . . . . . . . . 183.3.2. Taxonomıa de Defectos a Nivel de Clase . . . . . . . . . . 203.3.3. Taxonomıa de Defectos a Nivel de Cluster . . . . . . . . . 22

3.4. IEEE Classification . . . . . . . . . . . . . . . . . . . . . . . . . . 24

v

vi INDICE GENERAL

3.4.1. Reconocimiento . . . . . . . . . . . . . . . . . . . . . . . . 243.4.2. Investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 253.4.3. Accion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4.4. Disposicion . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.5. Orthogonal Defect Classification . . . . . . . . . . . . . . . . . . 263.5.1. Actividad . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5.2. Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.5.3. Impacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5.5. Fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5.6. Edad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5.7. Tipo de Defecto . . . . . . . . . . . . . . . . . . . . . . . 323.5.8. Calificador de Defecto . . . . . . . . . . . . . . . . . . . . 32

3.6. Taxonomıa de Boris Beizer . . . . . . . . . . . . . . . . . . . . . 333.6.1. 1xxx - Requerimientos y Caracterısticas . . . . . . . . . . 333.6.2. 2xxx - Funcionalidad . . . . . . . . . . . . . . . . . . . . . 353.6.3. 3xxx - Defectos Estructurales . . . . . . . . . . . . . . . . 373.6.4. 4xxx - Datos . . . . . . . . . . . . . . . . . . . . . . . . . 383.6.5. 5xxx - Implementacion y Codificacion . . . . . . . . . . . 403.6.6. 6xxx - Integracion . . . . . . . . . . . . . . . . . . . . . . 413.6.7. 7xxx - Sistema y Arquitectura de Software . . . . . . . . 433.6.8. 8xxx - Definicion de Pruebas y Ejecucion . . . . . . . . . 443.6.9. 9xxx - Otros . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.7. Mapeo de Taxonomıas por Freimut . . . . . . . . . . . . . . . . . 46

4. Comparacion Teorica 494.1. Marco Teorico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2. Comparacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5. Usos de Taxonomıas 595.1. Formas de Analisis e Interpretacion de Resultados . . . . . . . . 59

5.1.1. Mecanismos Generales de Analisis . . . . . . . . . . . . . 595.1.2. Interpretacion de Resultados . . . . . . . . . . . . . . . . 60

5.2. Tipos de Uso de las Taxonomıas . . . . . . . . . . . . . . . . . . 615.2.1. Prevencion de Defectos . . . . . . . . . . . . . . . . . . . 615.2.2. Control de Pruebas e Inspecciones . . . . . . . . . . . . . 635.2.3. Plan de Pruebas . . . . . . . . . . . . . . . . . . . . . . . 635.2.4. Reduccion de Defectos de Campo . . . . . . . . . . . . . . 645.2.5. Evaluar y Mejorar Cambios del Proceso . . . . . . . . . . 655.2.6. Soporte de Root Cause Analysis . . . . . . . . . . . . . . 665.2.7. Desarrollo, Extensiones y Mejoras de Taxonomıas . . . . . 665.2.8. Experimentos Formales . . . . . . . . . . . . . . . . . . . 69

5.3. Analisis de Experimento Formal . . . . . . . . . . . . . . . . . . 715.3.1. Programa 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 725.3.2. Programa 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 735.3.3. Analisis de Resultados del Experimento . . . . . . . . . . 73

5.4. Recomendaciones de uso . . . . . . . . . . . . . . . . . . . . . . . 755.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

INDICE GENERAL vii

6. Desarrollo Individual y Organizacional 796.1. Analisis de Atributos . . . . . . . . . . . . . . . . . . . . . . . . . 806.2. Taxonomıa para Desarrollo Individual . . . . . . . . . . . . . . . 85

7. Conclusiones y Trabajos a Futuro 897.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.2. Trabajos a Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Bibliografıa 93

viii INDICE GENERAL

Indice de figuras

3.1. Taxonomıa de Hewlett-Packard . . . . . . . . . . . . . . . . . . . 123.2. Jerarquıa del atributo Tipo en IEEE . . . . . . . . . . . . . . . . 253.3. Orthogonal Defect Classification . . . . . . . . . . . . . . . . . . 273.4. 1xxx - Requerimientos y Caracterısticas - Taxonomıa de Beizer . 333.5. 2xxx - Funcionalidad - Taxonomıa de Beizer . . . . . . . . . . . . 363.6. 3xxx - Defectos Estructurales - Taxonomıa de Beizer . . . . . . . 373.7. 4xxx - Datos - Taxonomıa de Beizer . . . . . . . . . . . . . . . . 393.8. 5xxx - Implementacion y Codificacion - Taxonomıa de Beizer . . 403.9. 6xxx - Integracion - Taxonomıa de Beizer . . . . . . . . . . . . . 423.10. 7xxx - Sistema y Arquitectura de Software - Taxonomıa de Beizer 433.11. 8xxx - Definicion de Pruebas y Ejecucion - Taxonomıa de Beizer 45

5.1. ODC Ejemplo de Distribuciones Esperadas . . . . . . . . . . . . 605.2. Extension de la taxonomıa de HP enfocada a la verificacion . . . 68

ix

x INDICE DE FIGURAS

Indice de cuadros

3.1. Mapeo entre atributos de la meta taxonomıa y de taxonomıas,presentado por Freimut . . . . . . . . . . . . . . . . . . . . . . . 47

4.1. Comparacion de taxonomıas HP, Kaner y Binder contra el marcoteorico, vista Atributos . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2. Comparacion de taxonomıas IEEE, ODC y Beizer contra el marcoteorico, vista Atributos . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3. Comparacion de taxonomıas HP, Kaner y Binder contra el marcoteorico, vista Propiedades . . . . . . . . . . . . . . . . . . . . . . 55

4.4. Comparacion de taxonomıas IEEE, ODC y Beizer contra el marcoteorico, vista Propiedades . . . . . . . . . . . . . . . . . . . . . . 56

5.1. Programa 1. Clasificacion con ODC . . . . . . . . . . . . . . . . . 725.2. Programa 1. Clasificacion con Beizer . . . . . . . . . . . . . . . . 725.3. Programa 2. Clasificacion con ODC, parte 1 . . . . . . . . . . . . 735.4. Programa 2. Clasificacion con ODC, parte 2 . . . . . . . . . . . . 735.5. Programa 2. Clasificacion con Beizer, parte 1 . . . . . . . . . . . 745.6. Programa 2. Clasificacion con Beizer, parte 2 . . . . . . . . . . . 745.7. Tipos de Uso de Taxonomıas por Reporte . . . . . . . . . . . . . 765.8. Resultados de Uso de Taxonomıas por Reporte . . . . . . . . . . 77

6.1. Clasificacion de Atributos en la escala, segun el Proceso de Desa-rrollo Individual y Organizacional . . . . . . . . . . . . . . . . . . 85

xi

xii INDICE DE CUADROS

Capıtulo 1

Introduccion

Los defectos juegan un papel importante en el desarrollo de software. Por unlado, porque cuando son detectados los mismos deben ser corregidos para queel software desarrollado sea de mejor calidad. Por otro lado, porque los defectoscontienen informacion que puede ser analizada con el fin de obtener mejoras ybeneficios. Por ejemplo, conocer la calidad de los distintos procesos de desarrolloy los productos, realizar seguimiento del progreso de un proyecto, controlar ymejorar los proceso de desarrollo, entre otros.

Es por esto que la informacion de los defectos debe ser recolectada y regis-trada. Existen varias propuestas de taxonomıas de defectos, unas mas completasque otras, unas jerarquicas y otras no. Algunas de estas taxonomıas son usadasen la industria mientras que otras no debido a su excesiva complejidad y otrosproblemas. Sin embargo, no existe un consenso acerca de cual taxonomıa es lamas adecuada para caracterizar la naturaleza de los defectos.

Tanto a nivel industrial como academico, es importante conocer como de-finir una taxonomıa segun los objetivos y necesidades del proyecto. Para elloes indispensable conocer los componentes, atributos, estructuras y propiedadesque puede tener una taxonomıa.

Otro aspecto importante es conocer los distintos analisis que se pueden rea-lizar con la informacion recolectada y cuales son los beneficios que se puedenadquirir. Conocer como se aplican dichos analisis y la informacion que se utilizaen cada uno de los mismos permite elegir o construir una taxonomıa adecuadaa las necesidades.

1.1. Motivacion y Objetivos

Hay distintas razones para utilizar taxonomıas de defectos. En el desarro-llo de software las mismas pueden ser usadas para conocer que caracterısticastienen los defectos que se introducen generalmente en una organizacion, en unproyecto o a nivel individual, mejorando tanto la actividad de verificacion comoel proceso de desarrollo de software. Las taxonomıas de defectos tambien hansido utilizadas de distintas formas en la Ingenierıa de Software Empırica (ESE).

Conocer las caracterısticas de los defectos que son normalmente inyectadospermite buscarlos de una manera particular. Por lo tanto, la actividad de ve-rificacion puede consumir menos tiempo y ser mas efectiva. Por ejemplo, si el

1

2 CAPITULO 1. INTRODUCCION

90 % de los defectos se encuentran en la especificacion de requerimientos, esposible verificar con mayor dedicacion dicha especificacion y reducir el tiempoutilizado en verificar otros productos de software. En otras palabras, orientar laverificacion teniendo en cuenta el conocimiento de los defectos que se inyectannormalmente.

La clasificacion de defectos da una idea de las fases, actividades, disciplinas,etc. del proceso de desarrollo donde la mayorıa de los defectos son inyectados.Con esta informacion, el proceso de desarrollo de software puede ser mejorado,logrando la reduccion de la cantidad de defectos inyectados durante el desarrollo.

Ademas, en ESE las taxonomıas de defectos han sido utilizadas para estu-diar la efectividad que tienen distintas tecnicas de verificacion en distintos tiposde defectos. Si se conoce esto, puede ser posible optimizar la combinacion dediferentes tecnicas de verificacion para maximizar el numero de defectos en-contrados. En la industria, las taxonomıas de defectos han sido utilizadas paraprevencion de defectos, control de pruebas e inspecciones, planificar pruebas,reduccion de defectos, evaluacion y mejora de cambios del proceso de desarrollo,entre otros.

Actualmente, el grupo de Ingenierıa de Software se encuentra trabajandoen el estudio de la efectividad y el costo de tecnicas de verificacion unitaria[VH09, VMBH09, VAL+09]. En este contexto resulta de gran interes mostrarlos resultados de efectividad y costo de las tecnicas discriminando segun el tipode defecto. Es a partir de este estudio que surge el interes de analizar los posiblesatributos y propiedades que debe tener una taxonomıa para un proceso de desa-rrollo individual, considerando que durante dicho proceso se aplican tecnicas deverificacion unitaria.

No solo estos motivos, sino otros que no se exponen aquı, muestran la im-portancia de las taxonomıas de defectos en el desarrollo de software y en ESE.Lamentablemente, no existe una taxonomıa utilizada universalmente, ni en desa-rrollo de software ni en ESE. Esta situacion causa muchos problemas, por ejem-plo, es muy difıcil o incluso imposible comparar resultados entre investigadores.

A continuacion se presentan los objetivos de este trabajo.

Conocer, analizar y documentar el estado del arte de las taxonomıas dedefectos de software

Estudiar y documentar el estado de la practica de taxonomıas

Conocer y documentar los problemas que ocurren al clasificar en distintastaxonomıas

Brindar lineamientos para la construccion de una taxonomıa de defectosde software especıfica para el proceso de desarrollo individual

1.2. Trabajo realizado

En este trabajo estudiamos un conjunto de taxonomıas existentes que se apli-can en la industria o en la academia. Las mismas son la taxonomıa de Hewlett-Packard [Gra92], la taxonomıa de Kaner, Falk y Nguyen [KFN99], la taxonomıade Binder [Bin99], la taxonomıa propuesta por IEEE Standard Classificationfor Software Anomalies [IEE93], la taxonomıa propuesta por IBM [Chi96] y lataxonomıa de Beizer [Bei90].

1.3. PUBLICACIONES 3

Freimut [Fre01] presenta una meta taxonomıa que extendemos y mejoramosmediante la creacion de un marco de comparacion teorico original que permitela evaluacion y comparacion de cualquier taxonomıa de defectos de software.El marco esta compuesto por dos vistas: Atributos y Propiedades. La primervista es util para evaluar las caracterısticas de los defectos que son consideradasen una taxonomıa dada. La segunda vista es util para evaluar las propiedadesdeseables que cada taxonomıa deberıa tener. Se evaluan y comparan las seis ta-xonomıas nombradas anteriormente contra el marco, presentando los resultadosy conclusiones extraıdas.

Estudiamos y reportamos el estado de la practica en lo que refiere a taxo-nomıas de defectos de software. Esto incluye los logros y beneficios obtenidosal aplicar una taxonomıa de defectos en conjunto con un analisis de resulta-dos. Tambien se presentan experimentos formales que utilizan clasificaciones dedefectos, ademas de extensiones y mejoras de taxonomıas.

Durante 2008 y principios de 2009 se realiza en la Facultad de Ingenierıaun experimento formal para conocer el costo y rendimiento de 5 tecnicas deverificacion unitaria. En dicho experimento participan 17 estudiantes ejecutandotecnicas de verificacion sobre distintos programas. Todos deben recolectar datossobre tiempos de ejecucion de las tecnicas, registrar los defectos encontrados yclasificar cada defecto en la taxonomıa de Beizer y en la taxonomıa de IBM.En este trabajo se analizan los resultados de clasificacion realizada en dichoexperimento formal.

En una organizacion el desarrollo de sistemas de software se realiza en equi-po. Un equipo esta compuesto por un conjunto de individuos, y todos juntosejecutan un proceso de desarrollo a nivel organizacional para lograr cumplir conel desarrollo segun los objetivos planteados. En particular, durante la fase deimplementacion, cada individuo lleva a cabo su proceso de desarrollo individual,que paralelamente se esta ejecutando con el proceso de desarrollo de la orga-nizacion. Uno de los objetivos de este trabajo es la creacion de una taxonomıaespecıfica para el proceso desarrollo personal. Para ello se realiza un analisis deposibles atributos y propiedades que debe tener una taxonomıa a ser utilizadaen dicho contexto y se brindan lineamientos para la construccion de la misma.

1.3. Publicaciones

Como parte de este trabajo se publican los siguientes artıculos:

Diego Vallespir, Fernanda Grazioli, Juliana Herbert. A framework to eva-luate defect taxonomies en Proceedings del XV Congreso Argentino deCiencias de la Computacion, Workshop de Ingenierıa de Software, pp.643–652, ISBN 978-897-24068-4-1, San Salvador de Jujuy, Argentina, Oc-tubre, 2009.

Fernanda Grazioli y Diego Vallespir. Marco teorico para evaluar taxono-mıas de defectos. Reporte tecnico RT 09-17, Instituto de Computacion,Facultad de Ingenierıa - Universidad de la Republica, 2009.

Se tiene pensado redactar un artıculo que contemple el estado de la practicaactual de las taxonomıas y que incluya las dificultades que surgen durante laaplicacion de las mismas. La redaccion se realizara en ingles, buscando publicaren una conferencia internacional.

4 CAPITULO 1. INTRODUCCION

1.4. Estructura del documento

Este documento se estructura en 6 capıtulos ademas del actual. El capıtu-lo “Meta Taxonomıa” introduce el concepto de meta taxonomıa y presenta lapropuesta de Freimut.

El capıtulo “Taxonomıas” presenta las taxonomıas relevadas. Ademas se pre-senta un mapeo realizado por Freimut entre los atributos de la meta taxonomıay algunas de ellas.

El marco de comparacion y la comparacion propiamente dicha de todas lastaxonomıas se presenta en el capıtulo “Comparacion Teorica”.

Los distintos tipos de uso de las taxonomıas se presentan en el capıtulo“Usosde Taxonomıas”.

En el capıtulo “Taxonomıas para Desarrollo Individual y Organizacional”se realiza un analisis de atributos segun el proceso de desarrollo individual yorganizacional. Se brindan lineamientos para construir una taxonomıa especıficapara un proceso de desarrollo individual a partir de los resultados del analisisde atributos.

Por ultimo, el capıtulo “Conclusiones y Trabajos a Futuro” presenta las con-clusiones acerca de este trabajo y las tareas que quedaron por realizar y queserıa de interes abordarlas en futuros trabajos.

Capıtulo 2

Meta Taxonomıa

Una meta taxonomıa define elementos que pueden componer una taxonomıa,permitiendo la construccion de una taxonomıa especıfica a partir de ella. Enparticular, la meta taxonomıa de Freimut define atributos y propiedades. Losatributos permiten registrar las caracterısticas de los defectos. Las propiedadesdescriben propiedades deseables de una taxonomıa. Una de las propiedades masrelevantes es la propia estructura de la taxonomıa.

En la literatura solo encontramos la propuesta de meta taxonomıa de Freimut[Fre01], este capıtulo esta basado en dicha propuesta.

En la seccion 2.1 se define el concepto de atributo y se presentan los atributoscandidatos a ser registrados de un defecto. El concepto de estructura se defineen la seccion 2.2, junto a la descripcion de las posibles estructuras que puedetener una taxonomıa. Se presenta el concepto de propiedad y se describen laspropiedades deseables de una taxonomıa en la seccion 2.3. En la seccion 2.4 sepuede observar una guıa de como incorporar una taxonomıa a un proceso. En laseccion 2.5 se presenta una posible clasificacion de taxonomıas. Finalmente enla seccion 2.6 se presenta una breve crıtica al planteo propuesto por Freimut.

2.1. Atributos

Un atributo define un aspecto de un defecto. Una taxonomıa esta compuestapor atributos. Cada atributo tiene un conjunto de valores posibles. Cada valorrepresenta una caracterıstica de un defecto que debe ser registrada al momentode la clasificacion del mismo. Los atributos que componen una taxonomıa debenser atributos que sean relevantes para un analisis posterior. A continuacion selistan los atributos propuestos por Freimut.

Ubicacion Se refiere al lugar en el que se encuentra el defecto. El nivel de deta-lle en la especificacion de esta caracteristica puede variar, ya sea indicandosolamente la entidad de alto nivel del sistema en la que el defecto se ubica(Requerimientos, Diseno, Codigo, Documentacion) o indicando ademas elnombre del producto en el que se encuentra.

Tiempo Se refiere a indicar la fase del proyecto en la que se produce la inyec-cion, deteccion y/o correccion del defecto.

5

6 CAPITULO 2. META TAXONOMIA

Sıntoma Se refiere a lo que se observa cuando se provoca la falla. Tambienpuede ser una descripcion de la actividad que provoca la falla.

Resultado final Se refiere a describir la falla causada por el defecto. Este atri-buto suele contener valores como performance, usabilidad, etc.

Mecanismo Se refiere a como se inyecta, detecta y/o corrige el defecto. Esdecir, indicar la actividad que se estaba realizando durante la inyecciondel defecto, la actividad que logra detectarlo o los pasos realizados paracorregir el mismo.

Causa (Error) Se refiere al error humano que causa la inyeccion del defecto.Los valores que puede tomar este atributo son: educacion, comunicacion,mal uso de herramientas, etc. Otro enfoque que se le puede dar a esteatributo, es capturar distintos tipos de causas, como por ejemplo: causashumanas (falta de conocimiento, problemas de comunicacion), causas delproyecto (falta de tiempo, errores de gestion), entre otras.

Gravedad Se refiere a que tan grave es el defecto o la falla.

Costo Se refiere al tiempo o esfuerzo dedicado a encontrar o corregir un defecto.Generalmente, esta informacion se refiere a un nivel que representa dichocosto (mediante una escala, como puede ser: alto, medio, bajo), pero puedecapturar el valor en las unidades de tiempo correspondientes.

En las definiciones propuestas por Freimut, la diferencia entre el atributoSıntoma y Resultado final no es clara. Nuestra interpretacion es la siguiente.Sıntoma se refiere a lo que se observa, tal vez sin saber que es lo que realmenteesta pasando cuando la falla ocurre. Por otro lado, resultado final se refiere alo que esta pasando realmente cuando la falla ocurre. Por ejemplo, un sıntomade una falla puede ser un mensaje de error. Una vez que el defecto (que causadicha falla) es detectado, se puede saber el alcance real de los efectos de la falla(resultado final). Por ejemplo, la base de datos esta corrupta y un mensaje deerror se despliega (el mismo mensaje que en el atributo sıntoma).

2.2. Estructura

El concepto de estructura refiere a la relacion existente entre los componentesde una taxonomıa. Se pueden definir varios tipos de estructuras, segun la relacionexistente entre los atributos definidos en una taxonomıa o segun la relacionexistente entre los valores posibles que puede tomar un atributo.

Una posible estructura es la jerarquica. Esto significa que existe una relacionde jerarquıa entre los valores posibles que puede tomar un atributo. Por ejemplo,un atributo correspondiente al tipo de defecto se puede dividir en varios subtiposy ası sucesivamente. Expresado de forma generica, los valores de un atributo enun nivel, son refinados por valores de atributo del siguiente nivel de la jerarquıa.Un ejemplo de taxonomıa que posee esta estructura es la taxonomıa de Beizer[Bei90].

Existe tambien la estructura arborescente. En dicha estructura basada enarboles, los atributos no son independientes entre sı. Es decir, la eleccion de un

2.3. PROPIEDADES 7

valor en un atributo, influye en los valores posibles de los siguientes atributos aclasificar.

Otra estructura posible es la ortogonal. En esta estructura los atributos sonortogonales, es decir, los valores de cada atributo son asignados independien-temente de los demas atributos que componen la taxonomıa. Un ejemplo detaxonomıa ortogonal es la taxonomıa propuesta por IBM (ODC) [Chi96].

La estructura semi-ortogonal es aquella en la que existe una relacion desemi-ortogonalidad entre los atributos de una taxonomıa. Esto implica que entrealgunos atributos no exista una dependencia, pero entre otros, la eleccion de unvalor en un atributo influye en los valores posibles de otro atributo. Un ejemplode taxonomıa semi-ortogonal es la taxonomıa propuesta por HP [Gra92].

Finalmente, una taxonomıa puede tener una estructura simple. En este caso,la taxonomıa consiste en un unico atributo donde no existen relaciones de ninguntipo entre los valores posibles que puede tomar.

2.3. Propiedades

Las propiedades son cualidades y restricciones que poseen los atributos quecomponen una taxonomıa. Al momento de clasificar utilizando una taxonomıa,si la misma no esta correctamente definida, pueden surgir problemas para lograrque la informacion registrada durante la clasificacion sea correcta, confiable yde buena calidad. Todos estos factores afectan negativamente los analisis fu-turos a realizar sobre la informacion registrada, ya que sus resultados serıancuestionables, dando lugar a dudas la validez de los mismos.

A continuacion se listan algunos ejemplos de problemas que pueden surgir altener una taxonomıa incorrectamente definida: el conjunto de posibles valoresque puede tomar un atributo es incompleto, o ambiguo, la definicion de losatributos es confusa o incompleta, no existen ejemplos de como clasificar undefecto, entre otros. Para evitar estos problemas, es deseable que las taxonomıascumplan con las propiedades que se describen a continuacion.

Valores de atributo mutuo-excluyentes Al momento de elegir un valor deun atributo, solo un valor debe ser apropiado. No puede suceder que dos omas valores de un mismo atributo apliquen correctamente para un defecto,ya que esto resultarıa en datos no confiables, inconsistentes.

Atributos ortogonales Como se explica anteriormente, la ortogonalidad re-fiere a que los valores de cada atributo puedan ser asignados independien-temente de los demas atributos. De esta manera, se asegura que caracte-rısticas diferentes de un defecto sean capturadas en atributos diferentes.

Completitud en valores de atributos El conjunto de valores debe ser com-pleto para que, de esta forma, todos los defectos tengan un valor apropiadoa ser asignado para cada atributo. Si el conjunto no es completo, un usua-rio al momento de clasificar un defecto bajo un atributo puede decidir noasignar un valor para dicho atributo o elegir el valor posible mas cercano,lo cual resulta en informacion incompleta o inconsistente. Para prevenireste problema, es posible incluir en el conjunto de valores posibles de unatributo un valor llamado “Otro” y ası, de ser necesario, en el futuro sepuede ampliar la taxonomıa con el valor adecuado faltante.


Menor cantidad posible de valores de atributos El conjunto de valoresposibles para un atributo debe ser lo mas pequeno posible. Es importanteque si una taxonomıa va a ser utilizada frecuentemente por desarrolla-dores, sea lo mas facil posible de aplicar y que no requiera demasiadotiempo en clasificar un defecto. El tener un conjunto pequeno de valores,no solo hace mas simple el proceso de clasificacion, sino que lo hace me-nos propenso a errores humanos. Por otro lado, si la taxonomıa a aplicaresta disenada para un futuro analisis profundo, es posible que se necesiteun conjunto con una mayor cantidad de valores posibles para lograr unaprecision adecuada en los resultados.

Descripcion de valores de atributos Es fundamental que cada uno de losvalores posibles que puede tomar un atributo este claramente definido ydetallado con ejemplos de defectos que clasifican con cada valor. El obje-tivo de esta propiedad es evitar las posibles confusiones y malas interpre-taciones, ya que las mismas pueden resultar en datos inconsistentes y noconfiables.

Las cinco propiedades explicadas anteriormente, son propiedades deseablesque deberıa tener una taxonomıa. Para lograr un mejor uso de una taxonomıa,hay una propiedad adicional que se puede agregar a la lista anterior: consistenciaen la aplicacion. Esta propiedad se refiere a mantener una consistencia en lastaxonomıas utilizadas durante distintas etapas de un proceso y en distintosproductos o proyectos. Esta propiedad plantea el uso de una misma taxonomıaen todas las etapas de desarrollo. De esta forma se evita que un mismo usuariotenga que clasificar con mas de una taxonomıa, pudiendo confundirse al aplicarlas mismas. El hecho de utilizar una misma taxonomıa en distintos proyectos eslo que permite realizar analisis comparativos y ademas de brindar la posibilidadde descubrir patrones de defectos independientes del proyecto o proceso.

2.4. Incorporacion

Al momento de incorporar una taxonomıa en una empresa, se puede optarpor utilizar una taxonomıa ya existente y de ser necesaria adaptarla a un contex-to, o desarrollar un nuevo esquema basado en las necesidades y objetivos de laempresa. A continuacion se describen ideas de como encarar estos dos caminosposibles.

Para una empresa que simplemente quiere tener una idea de los tipos dedefectos encontrados o que no quiere invertir en desarrollar un esquema propio,utilizar una taxonomıa existente es su mejor opcion. Los esquemas que son gene-ralmente utilizados y/o adaptados segun las necesidades son ODC y el Standardde la IEEE.

Sin embargo, cuando se decide crear una nueva taxonomıa, hay que definir losatributos a incluir y sus valores apropiados, segun el analisis que posteriormentese desea realizar con esos datos y las metas que se quieran cumplir.

En [IEE95] se presenta una guıa de pasos para organizaciones que deseanreutilizar el esquema propuesto por la IEEE, adaptandolo a su realidad e incor-porarlo a la organizacion. Estos mismos pasos pueden servir como guıa para eldesarrollo de una nueva taxonomıa de clasificacion de defectos.

2.5. CLASIFICACION DE ESQUEMAS 9

- Elegir los atributos de manera que cumplan las propiedades del standard,basandose en el objetivo del analisis para realizar la eleccion.

- Para cada atributo, determinar su conjunto de valores posibles. Se reco-mienda comenzar con un conjunto base, y probar clasificar el atributo encuestion para una muestra de defectos. De esta manera se chequea que losvalores del conjunto base tengan sentido, si no existe mas de una opcionvalida para un mismo defecto y la completitud del conjunto. El conjuntode valores va a ir creciendo de ser necesario.

- Documentar los atributos, describiendo claramente cada uno de ellos uti-lizando el vocabulario tıpico de la empresa, de forma que los usuarios queutilicen la taxonomıa comprendan claramente y sin ambiguedades. En estesentido tambien se debe documentar cada valor posible que puede tomarun atributo.

- Especificar cuando y como dicha informacion va a ser recolectada, es decir,explicar el sistema de registro y seguimiento de defectos.

- Planificar los analisis que se desean realizar y en que momento se debenejecutar los mismos.

- Brindar capacitacion adecuada para todos los usuarios del esquema.

En todos los pasos es bueno ir recordando y verificando el cumplimiento delas propiedades deseadas de una taxonomıa.

2.5. Clasificacion de esquemas

En [Wag08] se presenta una clasificacion de lo que el autor llama defectclassification systems. Estos sistemas se dividen en tres categorıas: Taxonomıasde defectos, root cause analysis y clasificacion de defectos.

Las taxonomıas de defectos son categorizaciones de defectos, mayormente encodigo, que estan basadas en los detalles de la implementacion de su solucion.Por ejemplo, declaracion de un tipo incorrecto, alcance de variable incorrecto,o mal manejo de interrupciones. Un ejemplo bien claro de una taxonomıa dedefectos es la taxonomıa de Beizer.

Una propuesta mas detallada es root cause analysis donde no solo se analizanlos defectos por sı solos, sino tambien su causa. Por ejemplo, errores cometidospor el equipo de desarrollo. El objetivo es identificar la raız de estas causas yeliminarlas para prevenir defectos en el futuro. En general, root cause analy-sis es visto como un enfoque que requiere bastante elaboracion y su relacioncosto/beneficio no esta clara. Algunas propuestas de root cause analysis se pre-sentan en [MJHS90] y [LPS00].

Las clasificaciones de defectos tienen como meta reducir los costos y man-tener los beneficios de root cause analysis. Clasifican un defecto en multiplesdimensiones. Ejemplos de clasificaciones de defectos son las taxonomıas pro-puestas por IBM, HP y la propuesta de la IEEE.

En este trabajo, utilizamos el termino taxonomıa para todos los defect clas-sification systems.


2.6. Discusion

En esta seccion planteamos algunas crıticas a la propuesta de Freimut sobrelos atributos a incorporar en una taxonomıa.

Al leer su propuesta, encontramos cierta dificultad en su interpretacion. Susdefiniciones no son claras, resultan ambiguas en algunos casos, lo que nos indujoa la confusion en varias oportunidades.

Notamos que un mismo atributo describe distintos aspectos de un defecto.Por ejemplo, el atributo Sıntoma abarca la descripcion de una falla y la actividadque provoca la falla.

Bajo el atributo Mecanismo, se incluyen actividades de inyeccion, detecciony correccion de defectos. Sin embargo, cuando propone un ejemplo, plantea queuna actividad de deteccion son las pruebas unitarias. Esto lleva a una contra-diccion, ya que la prueba unitaria es en realidad una actividad que produceuna falla, no detecta un defecto. Y aquı surge la ambiguedad y confusion entreSıntoma y Mecanismo. Nosotros entendemos que una actividad de deteccion se-rıa aquella que permite ubicar el defecto en un producto, por ejemplo aplicartecnicas de Debugging, lo cual es distinto de una actividad que provoca la fallapor primera vez, como puede ser la ejecucion de un caso de prueba.

Capıtulo 3

Taxonomıas

Este capıtulo tiene como objetivo presentar un amplio conjunto de taxono-mıas particulares, algunas utilizadas en la industria y otras solo academicamen-te, de manera observar distintos enfoques de un mismo concepto.

Para que este trabajo quede autocontenido se explican las taxonomıas concierta profundidad. En caso que el lector conozca alguna taxonomıa puede sal-tearse la lectura de la seccion correspondiente a dicha taxonomıa.

En la seccion 3.1 se presenta la taxonomıa propuesta por Hewlett-Packard.La taxonomıa propuesta por Kaner, Falk y Nguyen se presenta en la seccion 3.2.La taxonomıa presentada por Binder se explica en la seccion 3.3. En la sec-cion 3.4 se detalla el IEEE Standard Classification for Software Anomalies. Lataxonomıa propuesta por IBM, Orthogonal Defect Classification, se presenta enla seccion 3.5. En la seccion 3.6 se describe la taxonomıa presentada por BorisBeizer. Finalmente en la seccion 3.7 se presenta un mapeo realizado por Freimutentre los atributos presentados en el capıtulo 2 y algunas taxonomıas.

3.1. Taxonomıa de Hewlett-Packard

La taxonomıa propuesta por Hewlett-Packard [Gra92] se desarrolla en 1986con el objetivo de mejorar el proceso de desarrollo a traves de la reduccionde defectos en el tiempo. Esta disenada para ayudar a una organizacion en elestudio de las tendencias de defectos en productos ya culminados y utilizar esainformacion para la prevencion de defectos en futuros proyectos.

La taxonomıa puede verse claramente en la figura 3.1. La misma posee unaestructura semi-ortogonal, y esta compuesta por tres atributos a clasificar. Acontinuacion se presenta cada uno de ellos.

3.1.1. Origen

Se refiere a la actividad del proceso donde se inyecta el defecto. Los valoresposibles para el atributo Origen son los siguientes:

Especificaciones/Requerimientos Se refiere a las tareas relacionadas con ladeterminacion de las necesidades y de las condiciones a satisfacer para elsoftware en cuestion.

11

12 CAPITULO 3. TAXONOMIAS

Figura 3.1: Taxonomıa de Hewlett-Packard

Diseno Se refiere a la actividad que determina y especifica el funcionamientodel software en forma general, sin entrar en detalles de implementacion.

Codigo Se refiere a la tarea de implementacion, codificacion.

Entorno/Soporte Son las actividades relacionadas al entorno de desarrollo ysoporte tecnico a los usuarios.

Documentacion Es todo lo concerniente a la documentacion del desarrollo delsoftware y de la gestion del proyecto en cuestion.

Otros Se refiere a cualquier otra actividad involucrada en el desarrollo.

3.1.2. Tipo

Se refiere al area que es responsable por el defecto (sus valores dependen delorigen seleccionado previamente). Los valores posibles para el atributo Tipo sonlos siguientes:

Requerimientos/Especificaciones Un defecto de este tipo produce que elproducto no cumpla con las caracterısticas deseadas.

Funcionalidad Un defecto de este tipo afecta la funcionalidad del producto.

Interfaz de HW Son defectos relacionados con la interfaz de hardware, es de-cir, problemas a nivel de los dispositivos utilizados para ingresar, procesary entregar los datos.

Interfaz de SW Son defectos relacionados con la interfaz de software destina-da a entregar informacion acerca de los procesos y herramientas de control.

3.1. TAXONOMIA DE HEWLETT-PACKARD 13

Interfaz de Usuario Son defectos relacionados con la interfaz que se encargade la interaccion usuario-maquina.

Descripcion Funcional Son defectos en la descripcion de los requerimientosfuncionales o diseno funcional del sistema.

Comunicacion (Inter-)Procesos Se refiere a defectos causados por proble-mas de comunicacion entre procesos.

Definicion de Datos Son defectos relacionados con la definicion de estructurade datos.

Diseno Modular Se refiere a defectos relacionados a la modularizacion delsistema.

Descripcion Logica Son defectos relacionados al formalismo logico de la des-cripcion de un diseno o codigo.

Chequeo de Errores Se refiere a la omision o incorrectitud al chequear erro-res.

Standards Se refiere al cumplimiento de standards de diseno.

Logica Son defectos relacionados a la logica de la implementacion.

Computacional Se refiere a defectos relacionados a errores computacionales.

Manejo de Datos Se refiere a defectos relacionados con el manejo de datos.

Interfaz/Implementacion Modular Son defectos relacionados con la imple-mentacion de modulos o interfaces.

Standards Se refiere al cumplimiento de standards de implementacion.

Prueba de HW Son defectos relacionados con pruebas de hardware.

Prueba de SW Son defectos relacionados con pruebas de software.

Integracion de SW Se refiere a defectos en la integracion de software.

Herramientas de Desarrollo Son defectos relacionados con las herramientasde desarrollo utilizadas en el proyecto.

3.1.3. Modo

Se refiere a la causa que lleva al defecto. Los valores posibles para el atributoModo son los siguientes:

Omiso Significa que hay que agregar algo para corregir el defecto.

Confuso Significa que algo no esta claro.

Erroneo Significa que el defecto se debe a un error en algo realizado.

Cambiado Se refiere a que el defecto se introdujo al cambiar otra parte paracorregir otro defecto.

Eficiente Se refiere a que se puede mejorar haciendolo de otra manera maseficiente.


3.2. Taxonomıa de Kaner, Falk y Nguyen

En el libro Testing Computer Software [KFN99], los autores Kaner, Falk yNguyen presentan una taxonomıa compuesta por un unico atributo que es eltipo de defecto. El conjunto de valores posibles para dicho atributo esta forma-do por 13 grandes categorıas y donde cada categorıa contiene un conjunto desubcategorıas asociadas. Es decir, es una taxonomıa con una estructura jerar-quıca de dos niveles. Los valores no estan totalmente descriptos en el libro, yaque existen valores para los cuales no se explica su intencion. Por lo tanto, acontinuacion se describe cada una de las categorıas y subcategorıas asociadas,realizando una interpretacion de las mismas.

3.2.1. Defectos de Interfaz de Usuario

Son defectos relacionados a la interfaz encargada de la interaccion entreusuarios y computadoras. Las subcategorıas de esta categorıa son:

Funcionalidad La funcionalidad es poco manejable, difıcil, confusa o imposiblede realizar con la interfaz propuesta.

Comunicacion La informacion que provee la interfaz no es suficiente, es con-fusa o no es exacta.

Estructura de Comandos Se refiere a que los comandos son confusos o quees facil perderse dentro del programa.

Comandos Faltantes Se refiere a lo que esta faltando o a si el programa fuerzaal usuario a actuar en una manera antinatural.

Performance Se refiere mayormente a la sensacion de velocidad del softwareen el sentido de interaccion con el usuario.

Salida Se refiere a las salidas impresas en pantalla, si tienen sentido o si losgraficos son claros.

3.2.2. Manejo de Errores

Esta categorıa se refiere a defectos en el manejo de errores del sistema. Lassubcategorıas de esta categorıa son:

Prevencion de Errores Se refiere a los defectos que surgen al anticipar laposibilidad de errores y proteger al sistema de ellos.

Deteccion de Errores Se refiere a defectos al anunciar condiciones de erroreso al hacer frente a los errores detectados.

Recuperacion de Errores Se refiere a defectos relacionados con rutinas derecuperacion de errores que se ejecutan para volver al sistema a un estadoconocido y estable.

3.2. TAXONOMIA DE KANER, FALK Y NGUYEN 15

3.2.3. Defectos Relacionados a Fronteras

Se refiere a defectos relacionados con fronteras de dominios o condicioneslımite. Las subcategorıas de esta categorıa son:

Fronteras numericas Se refiere a defectos en las fronteras del dominio de unvalor numerico.

Frontera en condiciones Se refiere defectos a las fronteras de una condicionlogica.

3.2.4. Defectos en Calculos

Esta categorıa abarca los defectos relacionados con formulas, operaciones,precision de resultados y errores computacionales. Las subcategorıas de estacategorıa son:

Constantes no actualizadas Se refiere a la utilizacion de un valor constanteque no se corresponde con el valor valido en la actualidad.

Orden incorrecto de operadores Se refiere a la mal interpretacion de for-mulas o colocacion erronea de operadores en la expresion.

Overflow y underflow Surgen cuando alguna operacion aritmetica produceun resultado fuera del rango representable.

Errores computacionales Se refiere a defectos al aplicar formulas a datos queno son aplicables, perdida de precision debido al redondeo o truncamiento.

3.2.5. Estado Inicial y Siguientes

Esta categorıa abarca los defectos de inicializacion y actualizacion de varia-bles. Las subcategorıas de esta categorıa son:

Inicializacion de variable Se refiere a defectos que se relacionan con la ini-cializacion de una variable.

Inic. de variable de control de un bucle Se refiere a defectos que se rela-cionan con la inicializacion de una variable de control en un bucle (variableque participa en la condicion del bucle).

Reinicializacion Se refiere a defectos relacionados con asignaciones de valoresa variables.

3.2.6. Defectos de Control de Flujo

Esta categorıa se refiere a los defectos en el orden en el que se ejecutan lasinstrucciones. Las subcategorıas de esta categorıa son:

Running Amok El programa ejecuta de manera incontrolable, sin parar.

Finalizacion inesperada El programa finaliza su ejecucion inesperadamente.

Bucles Se refiere a errores de control de flujo relacionados con bucles.

if-then-else Se refiere a errores de control de flujo relacionados con sentenciasdel tipo if-then-else.


3.2.7. Defectos de Manejo o Interpretacion de Datos

Esta categorıa se refiere a los defectos en el manejo y/o interpretacion dedatos intercambiados entre modulos o entre programas. Las subcategorıas deesta categorıa son:

Tipos de datos Se utiliza un dato como si fuese de un tipo, pero en realidades de otro tipo.

Lista de parametros Se refiere a defectos introducidos por la invocacion in-correcta de un metodo, ya sea por utilizar parametros fuera de orden opor la omision de alguno de ellos.

Copias de datos desactualizados El valor de la copia del dato utilizado nose corresponde con el valor actual real del dato.

Valor erroneo de una tabla Se consulta un valor equivocado en una tabla.

Mascara incorrecta En el manejo de bits, la mascara aplicada no es la co-rrecta.

3.2.8. Condiciones de Carrera

Se llama carrera a una competencia entre dos eventos A y B, donde cualquie-ra de los dos pueden ser los siguientes en ser ejecutados. Si A ocurre primero,el programa funciona correctamente. Si B ocurre antes que A, el programa falladebido a que se esperaba que A ocurriese antes que B. El programador no sepercato que B podrıa “ganar la carrera”, y B gana solo en condiciones especiales.Las subcategorıas de esta categorıa son:

Asumir orden de eventos Se asume que un evento siempre termina antesque otro, cuando eso no es necesariamente ası.

Asumir rango de entrada Se asume que una entrada no va a ocurrir en unintervalo especıfico.

Ejecucion temprana Las tareas comienzan su ejecucion antes que se cumplansus tareas previas.

3.2.9. Condiciones de Carga

Esta categorıa se refiere a los defectos por sobrecarga. Las subcategorıas deesta categorıa son:

Falta de recursos Los recursos requeridos no estan disponibles.

Liberacion de memoria No se libera la memoria que ya no se esta utilizando.

3.2.10. Hardware

Esta categorıa abarca los defectos involucrados con el hardware, como elenvıo incorrecto de datos a los dispositivos o el intentar utilizar recursos nodisponibles. Las subcategorıas de esta categorıa son:

3.3. TAXONOMIA DE ROBERT BINDER 17

Dispositivo no esta disponible No se puede acceder al dispositivo deseadoo el mismo esta ocupado.

Fin de archivo inesperado El dispositivo o el programa recibe datos incom-pletos o en mal formato.

3.2.11. Control de Version y Fuentes

Esta categorıa abarca los defectos causados por un mal manejo de versionesy codigo fuente. Las subcategorıas de esta categorıa son:

Reaparicion de defectos Viejos defectos ya corregidos vuelven a aparecer porvolver a una version anterior.

Falta de correspondencia El codigo fuente no se corresponde con el binario.

3.2.12. Documentacion

Aquı clasifica cualquier defecto relacionado con la documentacion, ya sea delarea de Requerimientos, Diseno, Implementacion o Soporte. En la taxonomıano se detallan las subcategorıas correspondientes.

3.2.13. Defectos de Testing

Se refiere a defectos en el area de verificacion, como defectos al planificar,disenar y/o implementar casos de pruebas o errores cometidos en los reportesde defectos. En la taxonomıa no se detallan las subcategorıas correspondientes.

3.3. Taxonomıa de Robert Binder

Robert Binder, en su libro Testing Object-Oriented Systems Models, Pat-terns, and Tools [Bin99], muestra que en la programacion orientada a objetosgran parte de los defectos se deben a problemas en la aplicacion de los concep-tos de herencia, polimorfismo, secuencia de mensajes y transicion de estados.Los defectos surgen mayormente al aplicar dichos conceptos porque los mismosse usan con frecuencia en la programacion orientada a objetos, ya que formanla base de este paradigma. Ademas, estos conceptos son muy distintos a losconceptos basicos de la programacion procedural.

A continuacion se presenta una interpretacion de la taxonomıa propuesta porBinder para el paradigma orientado a objetos a nivel de Metodo, Clase y Clus-ter. La taxonomıa esta compuesta por dos atributos que llamaremos “Origen”y “Tipo”, y presenta una estructura de arbol ya que los valores posibles parael atributo Tipo dependen del valor elegido para el atributo Origen. Ademases jerarquica, pues el atributo tipo posee un conjunto de valores posibles queconforman una jerarquıa de dos niveles. El autor aclara que aun se debe traba-jar sobre la taxonomıa, ya que la misma no esta completa y tampoco cumplecon el IEEE Standard Classification for Software Anomalies. Se presenta unainterpretacion de la taxonomıa, ya que en el libro no se describe ni se explica elconjunto de valores propuestos. En el caso en que no se haya interpretado algunvalor, se pone “No se interpreta lo planteado por el autor”.


3.3.1. Taxonomıa de Defectos a Nivel de Metodo

La misma presenta los tipos de defecto posibles a nivel de metodo. El atributoOrigen puede tomar los valores: Requerimientos, Diseno e Implementacion.

A continuacion se describen los posibles tipos de defecto para el Origen“Requerimientos”.

Omision de requerimiento Los requerimientos no fueron relevados comple-tamente.

Transformacion incorrecta u omisa Hay una mala interpretacion del re-querimiento planteado por el cliente o falta interpretar el mismo.

A continuacion se describen los posibles tipos de defecto para el Origen“Diseno”.

Abstraccion

Baja cohesion Los metodos de una misma clase realizan tareas variadaso que no tienen demasiada relacion.

Conflicto de resposabilidades Las responsabilidades se superponen oentran en conflicto con metodos locales o de superclases.

Refinamiento

Feature override missing No se interpreta lo planteado por el autor.

Feature delete missing No se interpreta lo planteado por el autor.

Encapsulado

Uso excesivo de mecanismos friend/protected Se refiere que al mo-mento de determinar las visibilidades, se utiliza demasiado las pro-piedades friend/protected, cuando podrıan ser public/private.

Naked access No se interpreta lo planteado por el autor.

Modularidad

Metodo excesivamente largo Se refiere a la longitud en lıneas de co-digo y en tareas que realiza del metodo.

Metodo sin codigo El metodo esta vacio, no tiene contenido.

Atributos excesivamente largos Se refiere a la longitud de los atribu-tos.

Responsabilidades

Algoritmo incorrecto El algoritmo no realiza lo que debe hacer.

Algoritmo ineficiente El algoritmo no es eficiente, problemas de per-formance.

Violacion de invariante Algo que no debe cambiar se modifica.

Excepcion no lanzada No se lanza una excepcion cuando debe ser lan-zada.

Excepcion no atrapada No se atrapa una excepcion cuando debe seratrapada.


A continuacion se describen los posibles tipos de defecto para el “Origen”Implementacion.

General

Mensaje sin correspondiente Un mensaje es enviado a un objeto queno contiene el metodo correspondiente.

Codigo inalcanzable Hay codigo que jamas se va a ejecutar.

Violacion de contrato No se cumple con el contrato del metodo, ya seacon la precondicion, poscondicion o invariante.

Mensaje enviado a un servidor de objetos equivocado El mensa-je que se envıa no era para el servidor de objetos al cual se envio.

Parametros de mensaje Los parametros del mensaje son incorrectos ose omite alguno de ellos.

Prioridad de mensaje La prioridad del mensaje no es la correcta.

Mensaje no implementados en el servidor El mensaje no fue imple-mentado en el servidor correspondiente.

Error de sintaxis Se refiere a cualquier error sintactico del metodo.

Algoritmo

Algoritmo ineficiente El algoritmo no esta implementado de la mane-ra mas eficiente, pudiendo introducir problemas de performance orecursos.

Salida incorrecta La salida del metodo no es la esperada.

Precision La precision es incorrecta, incluye error de redondeo o trunca-miento.

Persistencia incorrecta Los objetos no son salvados correctamente.

Algoritmo no finaliza El metodo no termina nunca de ejecutar.

Excepciones

Excepcion faltante Falta implementar una excepcion.

Excepcion incorrecta La excepcion lanzada no es correcta.

Excepcion no atrapada Una excepcion no es atrapada cuando debeatraparse.

Catch incorrecto Una excepcion es atrapada cuando no debe atraparse.

Excepcion excede alcance Una excepcion se propaga fuera del alcancedeterminado.

Excepcion no se lanza Una excepcion no es lanzada cuando debe lan-zarse.

Estado incorrecto luego de una excepcion El sistema, luego de lan-zar una excepcion, queda en un estado que no es en el que debeestar.

Definicion y uso de instancias

Objeto faltante Se referencia a un objeto que no esta definido.


Objeto sin utilizar Se define un objeto que no es referenciado.

Inicializacion faltante, constructor incorrecto Falta inicializar unavariable o el constructor de la clase no esta correctamente implemen-tado.

Contrato de servidor violado No se respeta el contrato del servidor.

Unidades Se refiere al uso incorrecto de unidades, como por ejemploconfundir gramos con onzas.

Visibilidad/alcance incorrecto La visibilidad del metodo no es defini-da correctamente.

Serializacion incorrecta Se realiza una incorrecta serializacion, lo cualresulta en un estado corrupto.

3.3.2. Taxonomıa de Defectos a Nivel de Clase

La misma presenta los tipos de defecto posibles a nivel de clase. El atribu-to Origen puede tomar los valores: Requerimientos, Diseno, Implementacion yProceso.

A continuacion se describen los posibles tipos de defecto para el “Origen”Requerimientos.

Omision de requerimiento Los requerimientos no son relevados completa-mente.

Dominio no identificado de un objeto No se logra identificar correctamen-te el dominio del objeto.

Nivel de esfuerzo, lımites del sistema El nivel de esfuerzo es incorrecto olos lımites del sistema no estan bien definidos.

Nivel de abstraccion El nivel de abstraccion es incorrecto o inapropiado.

Diagrama de estados El diagrama de estados no esta correctamente definido.

Asociacion/Multiplicidad Omision de asociacion o con multiplicidad inco-rrecta.

A continuacion se describen los posibles tipos de defecto para el “Origen”Diseno.

Abstraccion

Asignacion de responsabilidades La asignacion de responsabilidadeses redundante, es decir, el mismo metodo aparece en varias subclasessin estar definido en una superclase en comun.

Diseno de objetos top-level y protocolo Estructura de clases pobre,protocolos no ortogonales, jerarquıa y herencia inconsistentes.

Asociacion Asociacion faltante o incorrecta.

Tipos de parametros Los tipos de parametros especificados para unaclase generica son incorrectos.

Bucles de herencia Por ejemplo, C es superclase de A, A es superclasede B y B es superclase de C.


Refinamiento

Incorrecta redefinicion de metodo en subclase Una subclase inco-rrectamente redefine un metodo de su superclase.

Caracterıstica incorrectamente heredada La caracterıstica es here-dada cuando no debe ser ası.

Especificacion incorrecta Faltan metodos o variables en la especifica-cion.

Ciclo en jerarquıa Existen ciclos en la jerarquıa.

Herencia multiple La herencia multiple es incorrectamente definida.

Ubicacion de clase La clase esta ubicada en un lugar no apropiado.

Encapsulado

Interfaz publica Se coloca una interfaz publica a una clase, pero no atraves los metodos de la clase.

Comunicacion inter-clase Comunicacion implıcita clase a clase.

Modularidad

Uso excesivo de mecanismos friend/protected Se refiere que al mo-mento de determinar las visibilidades, se utiliza demasiado las pro-piedades friend/protected, cuando pueden ser public/private.

Metodos public/private No se utilizan los metodos public/private.

Objeto no utilizado Un objeto esta definido pero no se referencia.

Numero excesivo de metodos La cantidad de metodos de la clase esdemasiado grande.

Demasiados atributos Se utiliza una cantidad muy grande de atribu-tos.

Modulo, clase, metodo o atributo no utilizado Algo que esta defi-nido pero que no se utiliza/referencia.

Modulo no contiene clases El modulo definido no contiene clases, estavacio.

Metodo no contiene codigo Existe un metodo que no contiene codigo,esta vacio.

Clase no contiene metodos La clase no contiene ningun metodo defi-nido.

Clase sin atributos La clase no tiene ningun atributo definido.

Modulo excesivamente largo El modulo definido es demasiado gran-de.

Resposabilidades

Diagrama de estados El diagrama de estados no esta correctamentedefinido.

Inconsistencia de contrato El contrato no es consistente consigo mis-mo o con el resto del sistema.

Concurrencia Hay una incorrecta especificacion sobre la concurrencia.


Violacion de invariante Algo que no debe cambiar se modifica.


Ubicacion Ubicacion del metodo incorrecta debido a sinonimos, errores denombrado.

Constructor/Destructor Incorrecta implementacion del constructor o des-tructor de la clase.

Parametros Parametros incorrectos usados en un clase generica.

Instanciacion Instanciacion de una clase abstracta.

Error de sintaxis Se refiere a cualquier error sintactico.

Asociacion Se refiere a una asociacion no implementada.

A continuacion se describe los posibles tipos de defecto para el “Origen”Proceso.

Documentacion La documentacion de la clase es inconsistente con su imple-mentacion.

Patrones/Standards No se aplican patrones de diseno o standards de codifi-cacion.

Version Uso incorrecto del control de versionado.

3.3.3. Taxonomıa de Defectos a Nivel de Cluster

Se llama cluster a un grupo relacionado de clases. La idea es no testearuna clase por separado, sino un conjunto de clases con el objetivo de probar unafuncionalidad mas grande. Los subsistemas son un tipo de clusters mas grandes,que se incluyen en este nivel.

El atributo Origen puede tomar los valores: Requerimientos, Diseno e Im-plementacion.

A continuacion se describen los posibles tipos de defecto para el “Origen”Requerimientos.

Omision de requerimiento Los requerimientos no son relevados completa-mente.

Nivel de abstraccion El nivel de abstraccion es incorrecto o inapropiado.

Diagrama de estados El diagrama de estados no esta correctamente definido.

Asociacion Omision de asociacion.

A continuacion se describen los posibles tipos de defecto para el “Origen”Diseno.

Encapsulado


Exportacion de estructura La implementacion de la estructura de da-tos se exporta incorrectamente.

Exportacion de caracterıstica La exportacion de una caracterıstica esrealizada incorrectamente.

Visibilidad de paquete Incorrecta visibilidad de paquete.

Metodos no locales La clase contiene metodos no locales.

Metodo no utilizado Hay metodos public que no son usados por otrosobjetos.

Mensaje/Objeto incoherente El mensaje no se corresponde con el ob-jeto al que debe ser enviado.

Interfaz con el entorno La interfaz con el entorno no esta correctamen-te definida.

Modularidad

Componente omiso Hay algun componente que falta en el cluster.

Componente inconsistente El componente no es consistente con la de-finicion.

Baja cohesion Hay una baja cohesion entre los componentes del cluster.


Prioridad La prioridad definida no es la correcta.

Serializacion La serializacion no esta implementada correctamente.

Mensaje a objeto inexistente Se envıa un mensaje a un objeto que fue des-truido previamente.

Recoleccion de basura El recolector de basura es inconsistente, no funcionaadecuadamente.

Mensaje equivocado a objeto correcto Se envıa un mensaje erroneo al ob-jeto deseado.

Excepcion correcta en objeto equivocado Se lanza una excepcion correc-ta, pero la misma no debe ser lanzada por ese objeto.

Excepcion equivocada en objeto correcto Se lanza una excepcion que nodebe lanzarse en el objeto correcto.

Pedido/Devolucion de recursos Se realiza un pedido o devolucion de recur-sos incorrectamente.

Concurrencia Se refiere a los problemas relacionados con la implementacionde la concurrencia.

Performance La performance no es la esperada.

Bloqueo mutuo El sistema queda inoperante en estado de bloqueo mutuodebido a problemas de concurrencia.


3.4. IEEE Standard Classification for SoftwareAnomalies

El IEEE Standard Classification for Software Anomalies [IEE93] esta pen-sado para organizaciones que quieren implementar o ampliar una taxonomıao para aquellas que deseen expandir y mejorar sus mecanismos de registro yseguimiento de defectos con metodologıas ya probadas y analizadas.

El standard propone una taxonomıa de atributos ortogonales cuya clasifica-cion se realiza en cuatro etapas: Reconocimiento, Investigacion, Accion y Dispo-sicion. En cada una de las etapas, se registra lo encontrado/investigado/decidido/realizado,se clasifican los atributos correspondientes y se identifica su impacto. Si bien susatributos son ortogonales, dentro de cada atributo existe una relacion jerarquicadentro del conjunto de valores posibles, por lo que la estructura de la taxonomıaes ortogonal y jerarquica.

A continuacion se describe cada una de las etapas, junto con los atributosobligatorios y opcionales a clasificar en cada una de ellas.

3.4.1. Reconocimiento

Esta etapa comienza cuando se genera una falla y por lo tanto un defectoes descubierto. Esta etapa de clasificacion puede ser efectuada por cualquierpersona involucrada en el desarrollo, testing, uso o mantenimiento de software,sin importar la etapa en la que se encuentra el producto en cuestion.

Los atributos a clasificar dentro de la etapa de Reconocimiento son los si-guientes:

Estado del Producto Se refiere a cual es la usabilidad del producto en esemomento (sin realizar ningun cambio). Este atributo es opcional.

Actividad del Proyecto Se refiere a lo que se estaba realizando cuando seprodujo la falla. Este atributo es obligatorio.

Fase del Proyecto Se refiere a la fase del ciclo de vida en la que se encuentrael proyecto. Este atributo es obligatorio.

Repetibilidad Se refiere a cuantas veces puede suceder la anomalıa. Este atri-buto es opcional.

Causa Sospechada Se refiere a lo que se piensa que es la causa del defecto.Los valores posibles dan un aspecto de ubicacion sospechada. Este atributoes opcional.

Sıntoma Se refiere a como se manifiesta la anomalıa. Este atributo es obliga-torio.

Los atributos relacionados al Impacto que se deben clasificar dentro de laetapa de Reconocimiento son los siguientes:

Valor para el Cliente Se refiere a que tan importante es corregir este defectopara el cliente. Este atributo es opcional.

Mision/Seguridad Se refiere a que tan mala es la anomalıa respecto a losobjetivos del proyecto o al bienestar humano. Este atributo es opcional.

3.4. IEEE CLASSIFICATION 25

9

8 3

4

2

3

3

1

4

4

2

5 6 10 5 12

Total: 72

Figura 3.2: Jerarquıa del atributo Tipo en IEEE

Gravedad Se refiere a que tan grave es la anomalıa, a nivel de desarrollo delproducto (no a nivel de cliente). Este atributo es obligatorio.

3.4.2. Investigacion

Es cuando el defecto ya fue ubicado, investigado y analizado lo suficientecomo para identificar su causa, proponer soluciones o indicar que el defecto norequiere accion.

Los atributos a clasificar dentro de la etapa de Investigacion son los siguien-tes:

Causa Actual Se refiere a la causa real del defecto. Los valores dan un aspectode ubicacion actual. Este atributo es obligatorio.

Fuente Se refiere a donde se origina el defecto. Este atributo es obligatorio.

Tipo Se refiere a que tipo de anomalıa es (problema logico, computacional, deinterfaz, de manejo de datos, de documentacion, de calidad, entre otros).Tambien puede referirse a que tipo de mejoras se necesitan. Este atributoes obligatorio. En la figura 3.2 se presenta un arbol con la jerarquıa de esteatributo, mostrando en cada nodo la cantidad de valores posibles en esenivel. No se presentan los nombres de cada valor por un tema de espaciofısico.

Los atributos relacionados al Impacto que se deben clasificar dentro de laetapa de Investigacion son los siguientes:

Prioridad Se refiere a que prioridad tiene el defecto para ser solucionado. Esteatributo es opcional.

Costo de Proyecto Se refiere a que efecto causa en el presupuesto del proyectoel hecho de solucionar el defecto. Este atributo es obligatorio.

Calidad/Confiabilidad del Proyecto Se refiere a que impacto causa en lacalidad o confiabilidad del producto el hecho de solucionar el defecto. Esteatributo es opcional.

Riesgo del Proyecto Se refiere al riesgo asociado a la implementacion de lasolucion del defecto.


Cronograma del Proyecto Se refiere a que efecto causa en el cronograma delproyecto el hecho de solucionar el defecto. Este atributo es obligatorio.

Sociedad Se refiere a que impacto causa en la sociedad el hecho de implementarla solucion. Este atributo es opcional.

3.4.3. Accion

Es cuando se establece un plan de accion, basado en los resultados de la etapade Investigacion, para solucionar el defecto y prevenir que el mismo ocurra enel futuro. El plan de accion debe incluir todas las actividades necesarias pararesolver el defecto inmediatamente. Tambien debe incluir actividades requeridaspara revisar los procesos, polıticas o cualquier otra condicion necesaria paraprevenir defectos similares.

Los atributos a clasificar dentro de la etapa de Accion son los siguientes:

Accion Correctiva Se refiere a que hacer para prevenir que la anomalıa ocurrade nuevo. Este atributo es opcional.

Resolucion Se refiere a la accion a realizar para corregir el defecto. Este atri-buto es obligatorio.

3.4.4. Disposicion

Es cuando se completan todas las acciones requeridas para solucionar eldefecto o cuando se culmina de identificar todas las acciones correctivas a largoplazo.

El atributo a clasificar dentro de la etapa de Disposicion es el siguiente:

Disposicion Se refiere a que sucede para dar por cerrado el proceso para estedefecto. Este atributo es obligatorio.

El valor posible para cada atributo es predeterminado, pero los mismos nose detallan aquı por cuestiones de espacio fısico.

3.5. Orthogonal Defect Classification

Previo al ano 1996, el analisis de defectos de software era generalmente efec-tuado mediante dos tipos de metodos: los Statistical Defect Models y los modelosRoot Cause Analysis.

Los Statistical Defect Models son puramente cuantitativos (como los meto-dos matematicos o estadısticos), abstractos, distantes del programador, de bajocosto y pueden ser automatizados. Estan restringidos a unos pocos dominios deaplicacion.

Por otro lado, los modelos Root Cause Analysis son modelos de analisis pu-ramente cualitativos (como los metodos utilizados en programas de prevencionde defectos), concretos, se basan en la perspectiva del programador, costososy necesitan muchos recursos humanos. Son utilizados en un amplio rango dedominios de aplicacion.

ODC, Orthogonal Defect Classification, es una taxonomıa de defectos desa-rrollada por IBM en 1996 [Chi96]. La misma brinda un puente entre los dos

3.5. ORTHOGONAL DEFECT CLASSIFICATION 27

Apertura

Defecto Clausura

ActividadTrigger

Impacto

Target

Tipo

Cali�cador

Fuente

Edad

Figura 3.3: Orthogonal Defect Classification

extremos, Statistical Defect Models y Root Cause Analysis, mediante el desa-rrollo de un sistema de medicion basado en semantica. Uno de los objetivos deODC es brindar al equipo de desarrollo una retroalimentacion constante duranteel transcurso del proyecto. Ademas, ODC es utilizada para mejorar el procesode desarrollo mediante la reduccion de la cantidad de defectos con el avance delproyecto.

ODC propone dos pasos de recoleccion de informacion en el proceso de cla-sificacion para diseno y codigo llamados Apertura y Clausura. El primer paso seejecuta cuando un defecto es descubierto y un nuevo reporte de defecto es incor-porado al sistema de registro y seguimiento de defectos. El otro paso se ejecutacuando el defecto es detectado, corregido y el reporte de defecto se encuentracerrado.

La taxonomıa con sus atributos puede verse claramente en la figura 3.3. Acontinuacıon se describe los atributos de la taxonomıa donde los mismos estanorganizados segun los dos pasos del proceso.

3.5.1. Actividad

Se refiere a la actividad que se estaba realizando cuando se produce la falla.En el caso de inspecciones, es la actividad que detecta el defecto directamente.Se mide en la fase de Apertura y los valores posibles son:

Inspeccion de Codigo Es una tecnica formal de revision de codigo cuyo ob-jetivo principal es detectar e identificar anomalıas en un producto de soft-ware. Consiste en el examen sistematizado por parte de pares del trabajoelaborado por una persona. Se buscan errores comunes, por lo cual se exa-


mina para detectar la presencia de errores mas que simular la ejecucion.Se utiliza una lista de errores a detectar, en la cual se incluyen los erroresde programacion clasica.

Inspeccion de Diseno Similar a la inspeccion de codigo, pero se realiza sobrelos documentos de diseno.

Prueba Unitaria La prueba unitaria es una forma de verificar una unidad desoftware de forma aislada. Una unidad puede ser un metodo, una clase o unconjunto pequeno de clases que forman un modulo. Las pruebas unitariasson generalmente realizadas por los desarrolladores de la unidad.

Prueba de Integracion Es aquella que se realiza una vez que se han aprobadolas pruebas unitarias. El objetivo es verificar la comunicacion entre dos omas componentes. Las pruebas de integracion se focalizan en los defectosde las interfaces, y se utiliza en la integracion de modulos, subsistemas osistemas. Generalmente las pruebas de integracion son realizadas por losdesarrolladores de los componentes.

Prueba de Sistema Las pruebas de sistema tienen como objetivo verificar elsistema software en su totalidad, para comprobar si el mismo cumple consus requerimientos. Abarca las pruebas funcionales, de usabilidad, de ren-dimiento, de seguridad, entre otras. Las pruebas pueden ser realizadas porlos desarrolladores del sistema o por un conjunto de verificadores expertosen el area con gran conocimiento de la especificacion del software a testear.

3.5.2. Trigger

Es la actividad que provoca la ocurrencia de una falla. En el caso de inspec-ciones, se refiere a como se detecta el defecto. Este atributo es utilizado paraproveer una medida de los aspectos de verificacion del proceso de desarrollo yse mide en la fase de Apertura.

Hay tres clases de triggers, segun las distintas actividades de verificacion queson comunmente empleadas en el desarrollo de software: Inspecciones, PruebasUnitarias/Funcionales, Pruebas de Sistema. La distincion entre las mismas surgepor como las mismas actuan para provocar fallas. Las Inspecciones son un proce-so pasivo, ya que no hay nada que ejecutar. Las Pruebas Unitarias o Funcionaleschequean activamente la implementacion mediante la ejecucion de codigo, im-pulsadas por triggers estructurales y de composicion. Las Pruebas de Sistemaemulan el uso en el entorno del cliente.

Los valores posibles para el atributo Trigger en Inspecciones son:

Compatibilidad con versiones Esta relacionado con la comprension de co-mo la version actual del producto funciona con versiones anteriores.

Compatibilidad Lateral Esta relacionado con como el producto debe traba-jar con otros productos con la misma configuracion de software.

Conformidad del diseno Esta relacionado con la completitud del diseno delproducto respecto a los requerimientos y objetivos del producto.


Concurrencia Esta relacionado con la comprension de las cuestiones de timingy serializacion relacionadas a la implementacion del producto. Por ejemplo,mecanismos de bloqueo, regiones compartidas y secciones crıticas.

Semantica Operacional Relacionado a la comprension del flujo de la logicarespecto a la implementacion de un diseno.

Consistencia/Completitud de Documento Esta relacionado con la com-pletitud de un diseno y asegurar la consistencia entre las distintas partesdel diseno propuesto y la implementacion.

Situaciones Raras Relacionado con implementaciones inusuales, idiosincra-sias o informacion especıfica de un dominio que no es comun.

Los valores posibles para el atributo Trigger en Pruebas Unitarias o Funcio-nales son:

Prueba de Cubrimiento Se refiere a la ejecucion de una funcion a traves devarias entradas para cubrir la mayor cantidad de casos posibles del dominiode parametros. Es un trigger de prueba de caja negra.

Prueba Secuencial Estos son casos de pruebas que apuntan a ejecutar mul-tiples secciones del codigo con diferentes secuencias. Tambien es de cajanegra.

Prueba de Interaccion Son pruebas que exploran interacciones mas compli-cadas que generalmente no son cubiertas por secuencias simples.

Prueba de Variacion Son pruebas que apuntan a ejecutar una unica funcionusando multiples entradas.

Cobertura de Camino Simple Son pruebas de caja blanca que apuntan aejecutar los distintos caminos del codigo.

Cobertura de Combinacion de Caminos Prueba de caja blanca que apun-ta a caminos de codigo mas completos.

Los valores posibles para el atributo Trigger en Pruebas de Sistema son:

Recuperacion/Manejo de Excepciones El defecto surge debido a un malmanejo de excepciones o no se ha ejecutado un proceso de recuperacion.

Arranque y Reinicio del Sistema Esto se refiere a un producto siendo ini-cializado o reiniciado. Estos procedimientos pueden estar muy ligado aaplicaciones, como la base de datos.

Volumen de trabajo Esto indica que el producto alcanzo la capacidad maxi-ma de alguno de los recursos.

Configuracion de Hardware y Software Estos triggers son aquellos que songenerados por cambios en el entorno, ya sea en hardware o software.

Modo Normal Esta categorıa significa que para capturar estos triggers, notuvo que suceder nada inusual. El producto falla cuando se suponıa quedebıa funcionar normalmente.


3.5.3. Impacto

Se refiere al impacto que tiene en el producto la provocacion de la falla. Semide en la fase de Apertura y los valores posibles son:

Instalabilidad Problemas en la capacidad del producto software para ser ins-talado en un ambiente previamente especificado.

Servicio El servicio brindado por el sistema no es el deseado por el cliente.

Standards El software no cumple completamente con algun standard plantea-do en los requerimientos.

Integridad/Seguridad Problemas en la capacidad del producto software paraproteger la informacion y los datos de modo que las personas o los sistemasno autorizados no puedan leerlos o modificarlos, y a las personas o lossistemas autorizados no se les niegue el acceso a ellos.

Migracion Se refiere a problemas al exportar/importar datos desde/hacia elsistema.

Confiabilidad Problemas en la capacidad del producto software para mantenersu nivel de desempeno cuando es utilizado bajo condiciones especıficas(durante un determinado perıodo de tiempo). Esto incluye problemas enla madurez, tolerancia a fallas y recuperabilidad del sistema.

Performance Se refiere a problemas de sobrecarga o estres.

Documentacion Se refiere a cualquier error en la documentacion, ya sea quela misma no se encuentra acorde a la implementacion o que la misma noeste completa.

Requerimientos No se cumplen todos los requerimientos especificados por elcliente.

Mantenimiento Problemas en la capacidad del producto software para ser mo-dificado. Las modificaciones pueden incluir correcciones, mejoras o adapta-ciones del software a cambios de ambiente y en requisitos o especificacionesfuncionales.

Usabilidad Se refiere a problemas en la capacidad de un software para ser com-prendido, aprendido, usado y ser atractivo para el usuario, en condicionesespecıficas de uso.

Accesibilidad Se refiere a problemas para acceder a distintas funcionalidadeso datos por parte de personas con algun tipo de discapacidad.

Capacidad Se refiere a problemas en la capacidad del sistema para realizaralguna funcionalidad.


3.5.4. Target

Se refiere a que entidad de alto nivel debe ser corregida, es decir, la ubicaciondel defecto. Se mide en la fase de Clausura y los valores posibles son:

Requerimientos Se corrigen los documentos de requerimientos y especifica-ciones de software.

Diseno Se corrigen los documentos de diseno y arquitectura.

Codigo La implementacion de codigo es lo que se corrige.

Build/Package/Merge Se deben corregir problemas en el proceso de build,en librerıas de sistema o en el manejo de control de versiones.

Informacion Se deben corregir los manuales de usuario, manuales de instala-cion, ayuda en linea o mensajes al usuario.

Interfaz de Usuario Se deben hacer cambios esteticos en la interfaz de usua-rio.

3.5.5. Fuente

Se refiere a quien desarrollo el target. Se mide en la fase de Clausura y losvalores posibles son:

En casa El defecto se encuentra en un area en la que trabajo un equipo dedesarrollo de la organizacion.

Librerıa El defecto se encuentra usando una librerıa. El problema puede habersido por usar mal la librerıa o un defecto de la librerıa en sı.

Externo El defecto se encuentra en una parte que proviene de un tercero.

Ported El defecto esta relacionado con el uso de algo que fue validado para unentorno distinto al utilizado.

3.5.6. Edad

Se refiere a cual es el historial del target. Se mide en la fase de Clausura ylos valores posibles son:

Base El defecto se encuentra en una parte del producto que no ha sido mo-dificada para el proyecto actual y no es parte de una librerıa standard.El defecto no es introducido en el proyecto actual, sino que es un defectolatente.

Nuevo El defecto se encuentra en una funcion que ha sido creada e introducidaen el proyecto actual.

Re-escrito El defecto fue introducido como resultado de rediseno y/o reim-plementacion de una funcion vieja, con motivo de mejorar su diseno ocalidad.

Re-corregido El defecto fue introducido al corregir un defecto anterior.


3.5.7. Tipo de Defecto

Se refiere a que debe ser corregido. Se mide en la fase de Clausura y losvalores posibles son:

Asignacion Un defecto de este tipo implica el cambio de unas pocas lıneas decodigo, como la inicializacion de un bloque de control o de estructuras dedatos.

Chequeo Se refiere a logica que ha fallado en la validacion de datos, chequeode valores antes de ser utilizados o condicion de iteraciones.

Algoritmo Son defectos de eficiencia o correctitud que pueden ser corregidosmediante la re-implementacion del algoritmo o mediante un cambio de laestructura de los datos locales, sin necesidad de un cambio en el diseno.

Funcion Un defecto de este tipo es aquel que afecta significativamente la ca-pacidad, las caracterısticas requeridas para el usuario final, la API, lasinterfaces con hardware o estructuras globales. Requiere un cambio for-mal en el diseno.

Timing/Serialization Son aquellos defectos que se corrigen mediante la me-jora en el manejo de recursos compartidos y de tiempo real.

Interfaz Corresponde a defectos en la interaccion con otros componentes, mo-dulos, controladores de dispositivos, llamados a funciones, bloques de con-trol o lista de parametros.

Build/Package/Merge Se refiere a defectos que ocurren debido a defectos enbibliotecas, control de cambios o control de version.

Documentacion Son defectos que pueden afectar a las publicaciones o lasnotas de mantenimiento.

3.5.8. Calificador de Defecto

Explica como se inyecta el defecto. Se mide en la fase de Clausura y losvalores posibles son:

Faltante El defecto es causado por algo que se omite. Por ejemplo, falta unasentencia de asignacion.

Incorrecto El defecto es causado por algo realizado incorrectamente. Por ejem-plo, el chequeo de datos realizado usa valores incorrectos.

Extrano El defecto se debe a algo que no es relevante o pertinente al documentoo al codigo en sı. Por ejemplo, en el documento de diseno hay una seccionque no es necesaria para el producto actual, por lo que deberıa ser quitada.

3.6. TAXONOMIA DE BORIS BEIZER 33

1xxx - Requerimientos y

Características

11xx - Requerimiento

incorrecto

112x - No deseado

111x - Incorrecto

113x - Innecesario

12xx - Lógica

121x - Ilógico

122x - No razonable

123x - Inalcanzable

124x - Inconsistente, incompatible

13xx - Completitud

131x - Incompleto

132x - Faltante,

no especi�cado

141x - No veri�cable

142x - No se puede

probar

152x - Presentación,

documentación

153x - Standards

133x - Duplicado,

superpuesto

134x - Demasiado

generalizado

137x - No compatible con

versión anterior

138x - Insu�cientemente

expandible

162x - Características

163x - Casos

164x - Cambios de

Dominio

165x - Mensajes de usuario y diagnósticos

166x - Interfaces

internas

168x - Performance y

timing

167x - Interfaces externas

14xx - Veri�cabilidad

15xx - Presentación

16xx - Cambios en

requerimientos

Figura 3.4: 1xxx - Requerimientos y Caracterısticas - Taxonomıa de Beizer

3.6. Taxonomıa de Boris Beizer

En el libro Software Testing Techniques, Second Edition [Bei90], Boris Beizerpresenta una taxonomıa jerarquica de tipos de defectos de software. Los defectosse clasifican por un numero de 4 dıgitos y a veces incluye subnumeracion usandoel punto “.”. Ademas la letra “x” se utiliza de forma de posibilitar la expansionde la taxonomıa. El ultimo dıgito de cada conjunto es el 9, que se utiliza cuandoel defecto no coincide con ninguna de las categorıas existentes o porque no existeuna descomposicion mas fina.

En cada subseccion se presenta una categorıa basica y las subcategorıascorrespondientes. Se puede profundizar en la taxonomıa y ver ejemplos de cadacategorıa en [VL08].

3.6.1. 1xxx - Requerimientos y Caracterısticas

Los defectos de este tipo son aquellos que se refieren a la especificacion derequerimientos y caracterısticas. En la figura 3.4 puede verse un resumen de lacategorıa 1xxx. A continuacion se detallan sus subcategorıas.

11xx - Requerimiento incorrecto El requerimiento o una parte del mismono es correcto.

111x - Incorrecto El requerimiento esta mal.

112x - No deseado El requerimiento esta correctamente definido, perono es deseable.

113x - Innecesario El requerimiento no es necesario.


12xx - Logica El requerimiento es ilogico o no es razonable.

121x - Ilogico Defecto ilogico, usualmente debido a una contradiccioninterna que puede ser expuesta por un analisis logico de casos.

122x - No razonable Logicamente correcto y consistente, pero no razo-nable con respecto al ambiente, presupuesto o limitaciones de tiempodel proyecto.

123x - Inalcanzable Requerimiento fundamentalmente imposible o queno puede ser alcanzado bajo las limitaciones existentes.

124x - Inconsistente, incompatible El requerimiento es inconsistentecon otros requerimientos o con el entorno.

13xx - Completitud El requerimiento esta especificado de manera ambigua,incompleta o demasiado especificado.

131x - Incompleto La especificacion es incompleta. Casos, caracterısti-cas, variaciones o atributos sin especificar y por lo tanto no imple-mentados.

132x - Faltante, no especificado El requerimiento entero esta sin es-pecificar.

133x - Duplicado, superpuesto El requerimiento se superpone parcialo totalmente con otro requerimiento ya implementado o especificado.

134x - Demasiado generalizado El requerimiento esta especificado deforma correcta y consistente pero demasiado generalizado para laaplicacion.

137x - No compatible con version anterior El requerimiento impli-ca que objetos creados o manipulados por versiones anteriores nopuedan ser procesados correctamente por esta version.

138x - Insuficientemente expandible El requerimiento no puede serexpandido adecuadamente.

14xx - Verificabilidad Defectos en la especificacion relacionados con la veri-ficacion de que los requerimientos estan correctamente implementados.

141x - No verificable El requerimiento, si se implementa, no puede serverificado por motivos de tiempo o presupuesto.

142x - No se puede probar No es posible disenar y/o ejecutar pruebaspara verificar el requerimiento.

15xx - Presentacion Defectos en la presentacion o documentacion de reque-rimientos. Los requerimientos se asumen correctos, pero la forma en queestan presentados no.

152x - Presentacion, documentacion Defecto en la presentacion ge-neral, documentacion o formato.

153x - Standards La presentacion viola los standards para requerimien-tos.


16xx - Cambios en requerimientos Los requerimientos han cambiado entreel momento en que se comenzo a implementar y el momento en que terminola verificacion.

162x - Caracterısticas Los cambios en los requerimientos se deben acambios en las caracterısticas.

163x - Casos Los cambios en los requerimientos se deben a cambios enlos casos de uso.

164x - Cambios de Dominio El dominio de los datos de entrada hasido moficado.

165x - Mensajes de usuario y diagnosticos Cambios en texto, con-tenido o condiciones en los mensajes al usuario como prompts, adver-tencias o mensajes de error.

166x - Interfaces internas Interfaces internas al sistema han sido cam-biadas.

167x - Interfaces externas Interfaces externas, como drivers de dispo-sitivos, han sido cambiadas.

168x - Performance y timing Cambios en los requerimientos de per-formance y/o timing.

3.6.2. 2xxx - Funcionalidad

Se refiere a defectos en la implementacion de caracterısticas o funcionalidadesdel software. En la figura 3.5 puede verse un resumen de la categorıa 2xxx. Acontinuacion se detallan sus subcategorıas.

21xx - Correctitud Defectos en la correctitud de la implementacion.

211x - Caracterıstica malentendida, equivocada Segun la especifi-cacion, la implementacion no es correcta. El defecto se debe a que lacaracterıstica no se entendio, o se entendio pero se implemento mal.

218x - Interacciones de la caracterıstica La caracterıstica esta im-plementada correctamente en sı misma, pero tiene interacciones in-correctas con otras caracterısticas, o la interaccion especificada o im-plicada se maneja de manera incorrecta.

22xx - Completitud de caracterısticas Defectos relacionados con la com-pletitud de las caracterısticas que estan implementados.

221x - Caracterıstica faltante Falta la implementacion de una carac-terıstica entera.

222x - Caracterıstica sin especificar Una caracterıstica no especifi-cada ha sido implementada.

223x - Caracterıstica duplicada, superpuesta La forma en que lacaracterıstica esta implementada, duplica o se superpone a carac-terısticas implementadas por otras partes del software.

23xx - Completitud de casos Defectos relacionados con la completitud delos casos de las caracterısticas.


2xxx - Funcionalidad

21xx - Correctitud

218x - Interacciones de la característica

211x - Característica malentendida,

equivocada

22xx - Completitud de

características

221x - Característica

faltante

222x - Característica sin especi�car

223x - Característica duplicada,

superpuesta

23xx - Completitud

de casos

231x - Caso faltante

232x - Caso extra

241x - Dominio malentendido,

equivocado

242x - Ubicación de límites

1233x - Caso duplicado,

superpuesto

234x - Datos de

salida extraños

243x - Clausura de

límites

244x - Intersección

de límites

24xx -Dominios

25xx - Mensajes de usuario y diagnósticos

26xx - Condiciones de excepción mal

manejadas

Figura 3.5: 2xxx - Funcionalidad - Taxonomıa de Beizer

231x - Caso faltante No se implementa un caso entero.

232x - Caso extra Son casos que no debieron ser manejados.

233x - Caso duplicado, superpuesto Manejo duplicado de casos o su-perposicion parcial con otros casos.

234x - Datos de salida extranos Hay salida de datos que no son re-queridos.

24xx - Dominios El procesamiento del caso o la caracterıstica depende deuna combinacion de valores de entrada. Un defecto de dominio existe siun procesamiento incorrecto es ejecutado para una combinacion de valoresde entrada. El procesamiento se asume correcto.

241x - Dominio malentendido, equivocado No entender el tamano,forma, lımites, o otras caracterısticas del domino de entrada espe-cificado para el caso o la caracterıstica. La mayorıa de los defectosrelacionados con el manejo de casos extremos son defectos de domi-nio.

242x - Ubicacion de lımites Los valores o expresiones que definen unlımite en el domino son erroneos.

243x - Clausura de lımites Puntos finales y lımites del dominio sonasociados incorrectamente con un domino adyacente.

244x - Interseccion de lımites Los lımites del dominio son definidospor una relacion entre variables de control del dominio. La imple-mentacion de la relacion es incorrecta.


3xxx - Defectos

Estructurales

31xx - Control de �ujo y secuenciación

312x - Lógica de control y predicados

311x - Estructura general

32xx - Procesamiento

321x - Algorítmico, fundamental

322x - Evaluación de

expresión

316x - Manejo de excepciones

incorrecto

323x - Inicialización

313x - Selección Case

314x - Bucles e

iteraciones

315x - Control de inicialización

o estado

326x - Tiempo de Ejecución

324x - Limpieza

325x - Precisión, exactitud

Figura 3.6: 3xxx - Defectos Estructurales - Taxonomıa de Beizer

25xx - Mensajes de usuario y diagnosticos Prompts, listados u otra for-ma de comunicacion con el usuario es incorrecta. El procesamiento seasume correcto. Defectos que caen dentro de esta subcategorıa son: Adver-tencia falsa, fracasar al advertir, mensaje incorrecto, ortografıa, formatos.

26xx - Condiciones de excepcion mal manejadas Condiciones de excep-cion como problemas de recursos o modos de falla, que requieren un ma-nejo especial, no son manejadas correctamente o se utilizan mecanismosincorrectos de manejo de excepciones.

3.6.3. 3xxx - Defectos Estructurales

Se refiere a defectos relacionados con la estructura de los componentes. Enla figura 3.6 puede verse un resumen de la categorıa 3xxx. A continuacion sedetallan sus subcategorıas.

31xx - Control de flujo y secuenciacion Defectos especıficamente relacio-nados con el flujo de control del programa.

311x - Estructura general Defectos generales relacionados con la es-tructura del componente. Entran en esta subcategorıa los defectospor camino inaccesible, codigo inalcanzable y codigo muerto.

312x - Logica de control y predicados El camino ejecutado a travesde un programa es dirigido por predicados de flujo de control. Estacategorıa trata defectos en la implementacion de estos predicados.


313x - Seleccion Case Defectos simples en la seleccion de casos, comoser expresion de seleccion de casos formulada de forma incorrecta,lista de switch-case, defecto en la asignacion de un switch-case.

314x - Bucles e iteraciones Defectos en el control de loops.

315x - Control de inicializacion o estado Defectos relacionados conla inicializacion del flujo de control del programa y con cambios deestado que afectan el flujo de control.

316x - Manejo de excepciones incorrecto Toda invocacion incorrec-ta de un manejador de excepciones de flujo de control, no previamentecategorizada.

32xx - Procesamiento Defectos relacionados con el procesamiento bajo lasuposicion de que el flujo de control es correcto.

321x - Algorıtmico, fundamental El algoritmo seleccionado es inade-cuado, pero utilizado correctamente.

322x - Evaluacion de expresion Defectos relacionados con la maneraen la que se evaluan las expresiones artimeticas, booleanas, de strings.

323x - Inicializacion Defectos en la inicializacion de variables, expresio-nes, funciones usadas en procesamiento (auxiliares). No se incluyenlos defectos de inicializacion asociados con declaraciones y sentenciasde datos (413x) ni inicializacion de loops (314x).

324x - Limpieza Manejo incorrecto de la limpieza de areas de datos,registros y estados asociados con el procesamiento.

325x - Precision, exactitud Precision insuficiente o excesiva, exacti-tud insuficiente y otros defectos relacionados al sistema de repre-sentacion de numeros usado.

326x - Tiempo de Ejecucion El tiempo de ejecucion es excesivo parael procesamiento de un componente.

3.6.4. 4xxx - Datos

Se refiere a defectos en la definicion, estructura o uso de datos. En la figura 3.7puede verse un resumen de la categorıa 4xxx. A continuacion se detallan sussubcategorıas.

41xx - Definicion de datos, estructura, declaracion Defectos en la defi-nicion, estructura e inicializacion de datos. Esta categorıa se aplica si elobjeto es declarado estaticamente en el codigo original o creado dinami-camente.

411x - Tipo El tipo de objeto de datos, en su declaracion, es incorrecto.

412x - Dimension Para arreglos y otros objetos que tienen una dimen-sion, como por ejemplo arreglos, registros y archivos. Un defecto enla dimension o en las dimensiones mınimas o maximas, o en declara-ciones de redimension.


4xxx - Datos

41xx - De�nición de datos, estructura,

declaración

412x - Dimensión

411x - Tipo

42xx - Acceso y manejo de datos

421x - Tipo

422x - Dimensión

416x - Recursos estáticos

o dinámicos

423x - Value413x -

Valores iniciales o por defecto

414x - Duplicados y alias

415x - Alcance

428x - Acceso


426x - Recursos

Figura 3.7: 4xxx - Datos - Taxonomıa de Beizer

413x - Valores iniciales o por defecto Defectos en los valores inicia-les asignados al objeto de datos, seleccion de valores por defecto in-correctos, o fallar al suministrar un valor por defecto en caso de sernecesario.

414x - Duplicados y alias Defectos relacionados a la duplicacion inco-rrecta o la falla al crear un objeto duplicado.

415x - Alcance El alcance, particion o componente al cual aplica el ob-jeto esta especificado de forma incorrecta.

416x - Recursos estaticos o dinamicos Relacionado con la declara-cion de recursos asignados estatica y dinamicamente.

42xx - Acceso y manejo de datos Relacionado con el acceso y la manipu-lacion de objetos de datos que se asumen correctamente definidos.

421x - Tipo Defectos relacionados con el tipo del objeto.

422x - Dimension Para dimensiones dinamicamente variables de un ob-jeto con dimension. Se refiere a un defecto en la dimension. Por ejem-plo redimension dinamica de arreglos, exceder longitud maxima deun archivo, remover uno mas que el numero mınimo de registros.

423x - Value Relacionado con el valor de los objetos de datos.

424x - Duplicados y alias Defectos en duplicacion y alias dinamico (entiempo de ejecucion) de objetos.

426x - Recursos Relacionado con recursos asignados dinamicamente ypools de recursos, en cualquier medio de memoria que exista: princi-pal, cache, disco, RAM.


5xxx - Implementación

y Codi�cación

51xx - Codi�cación y

Tipografía

512x - Instrucción malentendida

511x - Codi�cación apurada,

tipográ�co

52xx - Violación de standards

521x - Violación de estructuras

522x - De�nición de datos,

declaraciones

416x - Recursos estáticos

o dinámicos

523x - Acceso a datos

413x - Valores iniciales

o por defecto


415x - Alcance

528x - Comentarios

524x - Llamado e invocación

526x - Mnemotécnicos,

etiquetas

53xx - Documentación

531x - Incorrecto

532x - Inconsistente

533x - Incomprensible

534x - Incompleta

535x - Faltante

Figura 3.8: 5xxx - Implementacion y Codificacion - Taxonomıa de Beizer

428x - Acceso Relacionado con el acceso a los objetos, no la manipula-cion de los mismos. En este contexto, accesos incluyen: leer, escribir,modificar, (y en algunos casos) crear y destruir.

3.6.5. 5xxx - Implementacion y Codificacion

Se refiere a defectos en la implementacion de software y aplicacion de stan-dards. Los defectos que caen en esta categorıa son por ejemplo, datos sin de-clarar, rutinas sin declarar, codigo, problemas de inicializacion. La mayorıa deellos son capturados por un buen compilador. Tambien se incluyen defectos dedocumentacion como comentarios erroneos, ya que los mismos conducen a ac-ciones incorrectas en el mantenimiento, causando la inclusion de otros defectos.En la figura 3.8 puede verse un resumen de la categorıa 5xxx. A continuacionse detallan sus subcategorıas.

51xx - Codificacion y Tipografıa Defectos que pueden ser claramente atri-buidos a problemas de codificacion o tipografıa. La clasificacion para undefecto en esta categorıa es subjetiva.

511x - Codificacion apurada, tipografico Defectos que son razona-blemente atribuidos a errores de tipeo u otros defectos tipograficos.

512x - Instruccion malentendida Defectos que se deben a un malen-tendido de la operacion de una instruccion.

52xx - Violacion de standards Defectos que se refieren a violacion o malen-tendidos en la aplicacion de standards y convenciones. Se asume que elsoftware funciona correctamente.


521x - Violacion de estructuras Violaciones en las estructuras del flu-jo de control u organizacion del software.

522x - Definicion de datos, declaraciones La ubicacion de la decla-racion de objetos de datos no esta acorde a los standards.

523x - Acceso a datos Violacion en las convenciones de como los obje-tos de datos de distinto tipo son accedidos.

524x - Llamado e invocacion Defectos en la forma en que otros pro-cesos son llamados, invocados o en la forma de comunicacion con losmismos.

526x - Mnemotecnicos, etiquetas Violacion a las reglas de asignacionde nombres a objetos.

528x - Comentarios Violacion de las convenciones que gobiernan el uso,ubicacion, densidad y formato de los comentarios.

53xx - Documentacion Defectos en la documentacion asociados al codigo oal contenido de los comentarios incluidos en el codigo.

531x - Incorrecto Frase incorrecta en la documentacion.

532x - Inconsistente Frase en la documentacion es inconsistente consi-go misma o con otras frases.

533x - Incomprensible La documentacion no puede ser comprendidapor un lector calificado.

534x - Incompleta La documentacion es correcta, pero informacion im-portante no esta contemplada.

535x - Faltante Falta gran parte de la documentacion.

3.6.6. 6xxx - Integracion

Se refiere a defectos en la integracion de interfaces con componentes. Loscomponentes se asumen correctos. En la figura 3.9 puede verse un resumen dela categorıa 6xxx. A continuacion se detallan sus subcategorıas.

61xx - Interfaces internas Defectos que estan relacionados con las interfacesentre componentes que se comunican con el programa. Se asume que loscomponentes son correctos. En este contexto, la transferencia directa oindirecta de datos o informacion de control mediante objetos de memoriacomo tablas, recursos asignados dinamicamente, o archivos, constituyenuna interfaz interna.

611x - Invocacion de componente Defectos relacionados a la invoca-cion de componentes de software. En este sentido un componentepuede ser una subrutina, funcion, macro, programa, segmento de pro-grama, o cualquier otro componente de procesamiento.

612x - Parametro de interfaz en invocacion Defecto que esta rela-cionado con los parametros de la invocacion, su numero, orden, tipo,posicion o valores.


6xxx - Integración

61xx - Interfaces internas

612x - Parámetro de interfaz

en invocación

611x - Invocación de componente

62xx - Interfaces externas

y timing

621x - Interrupciones

622x - Dispositivos

y drivers

616x - Invocación duplicada

623x - Timing o rendimiento

de entrada/salida

613x - Retorno de invocación a

componente

614x - Inicialización,

estado

615x - Invocación en

lugar equivocado

Figura 3.9: 6xxx - Integracion - Taxonomıa de Beizer

613x - Retorno de invocacion a componente Defecto que esta rela-cionado a la interpretacion de los parametros proporcionados por elcomponente invocado, en retorno al componente invocador, o sobre elpase del control a algun otro componente. En este contexto, un regis-tro, una secuencia de retorno de una subrutina, o un archivo puedencalificar dentro de esta categorıa de defectos. Los defectos incluidosaquı no son defectos en el componente que creo los datos de retorno,sino en la manipulacion posterior y la interpretacion de los datos enel componente que los recibe.

614x - Inicializacion, estado Componente invocado no inicializado, oinicializado en un estado erroneo, o con datos incorrectos.

615x - Invocacion en lugar equivocado El lugar o estado en el que seinvoca a un componente en el componente invocador es incorrecto.

616x - Invocacion duplicada El componente no deberıa haber sido in-vocado o ha sido invocado mas a menudo que lo necesario.

62xx - Interfaces externas y timing Defectos relacionados con las interfa-ces externas, como dispositivos de entrada/salida y/o drivers u otro soft-ware que no opera bajo la misma estructura de control.

621x - Interrupciones Manejo o seteo incorrecto de interrupciones.622x - Dispositivos y drivers Se refiere a una interfaz incorrecta con

dispositivos o drivers, o a una interpretacion incorrecta de la infor-macion de estado retornada.

623x - Timing o rendimiento de entrada/salida Defectos en el ti-ming con dispositivos externos.


7xxx - Sistema y Arquitectura de

Software

71xx - Sistema Operativo

712x - Datos retornados, malinterpretación

de estado

711x - Invocación,

comando

714x - Espacio

72xx - Arquitectura de

software

721x - Bloqueos y semáforos

722x - Prioridad

723x - Transacción,

control de �ujo


725x - Llamados recursivos

726x - Reentrada

724x - Manejo de recursos y

control

73xx - Recuperación

741x - Rendimiento inadecuado

742x - Tiempo de

respuesta, retraso

743x - Cantidad de

usuarios

744x - Parásitos de performance

74xx - Performance

75xx - Diagnóstico

incorrecto77xx - Entorno

76xx - Particiones y

superposiciones

Figura 3.10: 7xxx - Sistema y Arquitectura de Software - Taxonomıa de Beizer

3.6.7. 7xxx - Sistema y Arquitectura de Software

Se refiere a defectos que no se pueden atribuir a un componente o interfa-ces entre componentes, pero afectan el sistema, la arquitectura de software ola arquitectura de hardware. En la figura 3.10 puede verse un resumen de lacategorıa 7xxx. A continuacion se detallan sus subcategorıas.

71xx - Sistema Operativo Defectos relacionados al uso de las funcionalida-des del sistema operativo. No son defectos en el sistema operativo en sı.

711x - Invocacion, comando Se envio un comando erroneo al sistemaoperativo o se invoco una funcionalidad incorrectamente.

712x - Datos retornados, malinterpretacion de estado Se ignorano malinterpretan los datos devueltos por el sistema operativo o lainformacion de estado.

714x - Espacio Recurso de memoria requerido no esta disponible o sepidio de manera incorrecta.

72xx - Arquitectura de software Problemas en la arquitectura no definidosanteriormente.

721x - Bloqueos y semaforos Defectos en el uso de mecanismos debloqueo y funcionalidades de comunicacion interprocesos. No son de-fectos en los mecanismos en sı.

722x - Prioridad Defectos relacionados a la prioridad de la tarea.

723x - Transaccion, control de flujo Defectos relacionados a la defi-nicion de flujos de control.


724x - Manejo de recursos y control Defectos relacionados al mane-jo de recursos compartidos.

725x - Llamados recursivos Defectos en el uso de invocaciones recur-sivas de componentes de software.

726x - Reentrada Defectos relacionados a la reentrada de componentesdel sistema.

73xx - Recuperacion Defectos relacionados a la recuperacion de objetos lue-go de una falla.

74xx - Performance Defectos relacionados al rendimiento, retrasos en el com-portamiento del software, asumiendo que todos los otros aspectos estancorrectos.

741x - Rendimiento inadecuado El sistema no tiene el rendimientoesperado.

742x - Tiempo de respuesta, retraso El tiempo de respuesta de loseventos no es el especificado, retraso en los eventos.

743x - Cantidad de usuarios El numero maximo especificado de usua-rios simultaneos o tareas simultaneas, no son coherentes con los re-trasos especificados en las transacciones.

744x - Parasitos de performance Defecto cuyo sıntoma principal esla degradacion de la performance.

75xx - Diagnostico incorrecto Diagnostico o mensaje de error incorrecto.La invocacion al manejador de excepciones fue incorrecta.

76xx - Particiones y superposiciones La memoria o memoria virtual estaincorrectamente particionada, superpone un area incorrecta o hay conflictode particiones.

77xx - Entorno Version equivocada de sistema operativo, generacion del sis-tema incorrecta u otro defecto en el entorno del host.

3.6.8. 8xxx - Definicion de Pruebas y Ejecucion

Se refiere a defectos en la definicion, diseno, ejecucion de pruebas y manejode datos usados durante las pruebas. En la figura 3.11 puede verse un resumende la categorıa 8xxx. A continuacion se detallan sus subcategorıas.

81xx - Diseno Defectos en el diseno de las pruebas.

811x - Requerimientos malentendidos Las pruebas no se correspon-den con los componentes porque el verificador que diseno la pruebano comprendio los requerimientos.

812x - Incorrecta predicion de salida La salida predecida de la prue-ba no se corresponde con la salida requerida.

813x - Incorrecta prediccion de camino La prediccion de salida dela prueba es correcta, pero se llega a la misma por un camino que sepredijo incorrectamente.


8xxx - De�nición de Pruebas y Ejecución

81xx - Diseño

812x - Incorrecta predición

de salida

811x - Requerimientos malentendidos

813x - Incorrecta predicción de camino

82xx - Ejecución


822x - Golpe de teclado

o comando

823x - Base de datos


825x - Acto de

veri�cación

824x - Con�guración


de prueba

815x - Prueba de estructura de

datos o valor


817x - Con�guración

818x - Método de veri�cación,

criterio

816x - Secuenciación

83xx - Documentación

de pruebas

84xx - Completitud de casos de prueba

Figura 3.11: 8xxx - Definicion de Pruebas y Ejecucion - Taxonomıa de Beizer

814x - Inicializacion de prueba Las condiciones iniciales que fueronespecificadas para la prueba son incorrectas.

815x - Prueba de estructura de datos o valor Los objetos de datosutilizados o sus valores estan incorrectos.

816x - Secuenciacion La secuencia en que las pruebas son ejecutadas,en relacion a otras pruebas o la inicializacion de la prueba, es inco-rrecta.

817x - Configuracion El hardware, la configuracion de software o en-torno especificado para la prueba es incorrecto.

818x - Metodo de verificacion, criterio El metodo por el cual la sa-lida va a ser verificada es incorrecto o imposible.

82xx - Ejecucion Defectos en la ejecucion de pruebas.

821x - Inicializacion El componente probado no fue inicializado al es-tado correcto o con los valores correctos.

822x - Golpe de teclado o comando Un simple golpe de teclado o bo-ton lanza error.

823x - Base de datos La base de datos usada en la prueba era inco-rrecta.

824x - Configuracion La configuracion o el entorno especificado parala prueba no fue usado durante la ejecucion.

825x - Acto de verificacion El acto que verifica la salida fue ejecutadoincorrectamente.


83xx - Documentacion de pruebas La documentacion de los casos de prue-ba o criterios de verificacion es incorrecta o confusa.

84xx - Completitud de casos de prueba Faltan casos de prueba para cu-brir el criterio especificado.

3.6.9. 9xxx - Otros

Se refiere a todo defecto que no clasifica en las categorıas anteriores.

3.7. Mapeo de Taxonomıas por Freimut

En el Cuadro 3.1 se presenta el mapeo realizado por Freimut entre los atri-butos presentados en la meta taxonomıa y los atributos existentes en las taxo-nomıas ODC, HP e IEEE.

Analizando los atributos de ODC, observamos que el atributo Edad se en-cuentra bajo el meta atributo Ubicacion. Nosotros no coincidimos con esto yaque, si bien la Edad se refiere a la historia del Target, un cambio en el valor delatributo Edad no implica un cambio en la ubicacion del defecto. Respecto alatributo Tipo, el mismo se encuentra bajo el meta atributo Mecanismo, lo cualno nos resulta adecuado ya que el Tipo no describe como el defecto fue corre-gido. Tampoco coincidimos con la categorizacion del atributo Actividad bajo elmeta atributo Mecanismo, ya que la Actividad es un atributo que se mide enla etapa de Apertura y se refiere a la actividad que provoco la falla, y eso esdistinto a la actividad que detecto el defecto.

Analizando los atributos de HP, observamos que el atributo Tipo se encuen-tra bajo el meta atributo Sıntoma. Nosotros no estamos de acuerdo en esto yaque el Tipo no describe lo que se observa cuando se provoca la falla y tampocodescribe la actividad que provoca la falla.

Analizando los atributos la taxonomıa presentada por la IEEE, observamoslo mismo que planteamos para el atributo Tipo de HP. Tampoco coincidimoscon la categorizacion del atributo Actividad del Proyecto bajo el meta atributoMecanismo, ya que la Actividad del Proyecto es un atributo que se mide en laetapa de Reconocimiento y se refiere a lo que se estaba realizando cuando seprovoca la falla, y eso es distinto a la actividad que detecta el defecto. Respectoa los atributos Causa sospechada y Causa actual, observamos que los mismosse encuentran bajo el meta atributo Causa (Error). Esta categorizacion no nosresulta adecuada, ya que el meta atributo Causa (Error) se refiere a erroreshumanos que llevaron a la introduccion del defecto, y los atributos de la IEEEtienen un enfoque de ubicacion. Finalmente se observa que existen atributosque no estan reflejados en el mapeo y deberıan estarlo, tal es el caso del atri-buto Gravedad que deberıa estar bajo el meta atributo Gravedad y el atributoCronograma del Proyecto que deberıa estar bajo el meta atributo Costo.

3.7. MAPEO DE TAXONOMIAS POR FREIMUT 47

Atributos ODC HP IEEEUbicacion Target, Edad Origen FuenteTiempo Fase del ProyectoSıntoma Trigger Tipo Tipo, Sıntoma, Estado del

ProductoResultado final Impacto Estado del Producto, Re-

petibilidadMecanismo Tipo, Activi-

dad, CalificadorModo Actividad del Proyecto,

Accion correctivaCausa (Error) Causa sospechada, Causa

actualGravedadCosto

Cuadro 3.1: Mapeo entre atributos de la meta taxonomıa y de taxonomıas,presentado por Freimut


Capıtulo 4

Comparacion Teorica

Los capıtulos anteriores se enfocan en la presentacion de las estructuras,componentes y propiedades de las taxonomıas de defectos de software, y enla descripcion de varias taxonomıas utilizadas tanto en la industria como enel ambito academico. El objetivo este capıtulo es presentar nuestro marco decomparacion teorico. Ademas, se realiza una evaluacion de las taxonomıas yavistas contra el marco presentado.

En la literatura solamente se encontro una comparacion realizada por Frei-mut [Fre01], la cual no profundiza demasiado. Sin embargo, usamos dicha com-paracion para crear un marco de comparacion teorico original que se presentaen la seccion 4.1. La comparacion propiamente dicha de todas las taxonomıaspresentadas en el capıtulo anterior, se presenta en la seccion 4.2.

4.1. Marco Teorico

Para poder comparar teoricamente las taxonomıas de una forma correctay coherente, primero es necesario definir un marco para cuantificar objetiva yhomogeneamente las caracterısticas, fortalezas y deficiencias de cada taxonomıa.El tener definido un marco no solo permite realizar un analisis comparativo delas taxonomıas vistas anteriormente, sino que sirve para comparar cualquiertaxonomıa de defectos de software.

La comparacion que realiza Freimut es interesante ya que la misma planteaobservar los atributos presentes en distintas taxonomıas incluyendo HP, IEEE yODC. De todas formas no resulta completa para alcanzar nuestra meta, ya queno solo se puede caracterizar una taxonomıa por sus atributos, sino tambien porsus propiedades. Ademas, su comparacion no incluye todas las taxonomıas pre-sentadas ni es totalmente coherente con sus definiciones, como puede observarseen la seccion 3.7.

Para poder cumplir con el objetivo de realizar un balance teorico completo ycorrecto, proponemos el desarrollo de un marco de comparacion. El mismo estacompuesto por dos vistas: Atributos y Propiedades.

La vista basada en Atributos toma como idea inicial la propuesta planteadapor Freimut, la cual modificamos mediante la incorporacion de atributos masespecıficos. El objetivo de esta vista es evaluar la capacidad de una taxonomıapara describir defectos. A continuacion se describe cada atributo del marco. El

49

50 CAPITULO 4. COMPARACION TEORICA

nombre original de aquellos atributos que derivan de la propuesta de Freimut,aparecen entre parentesis al final de la descripcion. Si el atributo no se deriva dela propuesta de Freimut, aparece la palabra “nuevo” al final de la descripcion.

Ubicacion sospechada Se refiere al lugar donde se sospecha que se encuentrael defecto. Este atributo se registra al momento en que se produce la falla.Puede referirse a la actividad responsable de construir el producto quecontiene el defecto, o a un producto propiamente dicho. (Ubicacion)

Ubicacion real Se refiere al lugar donde se encuentra el defecto realmente.Puede referirse a la actividad responsable de construir el producto quecontiene el defecto, o a un producto propiamente dicho. (Ubicacion)

Fase de provocacion de la falla Se refiere a la fase en la que se encuentra elproyecto en el momento en que se provoca la falla. (Tiempo)

Fase de inyeccion Se refiere a la fase en la que se encuentra el proyecto en elmomento en que se inyecta el defecto. (Tiempo)

Sıntoma Se refiere a que se observa, es decir, lo que puede verse cuando seprovoca la falla. (Sıntoma)

Tipo Se refiere al tipo de defecto que se detecta. (Nuevo)

Mecanismo de provocacion de falla Se refiere a como se provoca la falla,mediante que actividad. (Mecanismo)

Mecanismo de inyeccion Se refiere a como se inyecta el defecto. (Mecanismo)

Impacto de la falla Se refiere al impacto que produce la falla en el producto,al momento en que ocurre la falla. (Resultado final)

Impacto del defecto Se refiere al impacto que produce el defecto en el pro-ducto, luego de detectar el mismo. (Resultado final)

Causa (Error) Se refiere al error humano que causa la inyeccion del defecto.(Causa)

Fuente responsable Se refiere a donde se desarrolla el producto en el cualse inyecta el defecto. Es un atributo que representa, por ejemplo, si eldefecto se encuentra en un producto desarrollado en el proyecto actual, osi se encuentra en un producto desarrollado en casa pero no especialmentepara este proyecto o si el mismo se encuentra en un producto externo.(Nuevo)

Recorreccion Se refiere a si el defecto se introdujo al corregir un defecto an-terior. (Nuevo)

Probabilidad de ocurrencia Se refiere a la probabilidad estimada de ocu-rrencia de la falla. Este atributo se registra al momento en que se producela falla. (Nuevo)

Gravedad Se refiere a que tan grave es la falla que ocurre. (Gravedad)

Prioridad Se refiere a que tan rapido se debe corregir el defecto. (Nuevo)

4.1. MARCO TEORICO 51

Costo de deteccion Se refiere al tiempo que se consume en la deteccion deldefecto, luego de la provocacion de la falla. (Costo)

Costo estimado de correccion Se refiere al tiempo que se estima para sucorreccion, luego de la deteccion del defecto. (Costo)

Costo de correccion real Se refiere al tiempo que se consume en la correcciondel defecto. (Costo)

Ası como se incluyeron como atributos la fase de provocacion de la falla yla fase de inyeccion del defecto, pensamos incluir atributos que representen lafase de deteccion y la fase de correccion del detecto. Decidimos no incluir estosatributos en el marco, ya que no se considera que puedan aportar conocimientoutil para analizar. Consideramos que es una decision independiente del defectoel elegir en que fase detectar el defecto. Es decir, ya se sabe que surgio una falla,pero la decision de en que momento detectar el defecto, es una decision particularde cada proyecto. Analogo es el razonamiento para la fase de correccion deldefecto, luego de que el mismo es detectado.

La vista basada en Propiedades, se basa en las propiedades deseables pro-puestas por Freimut, incluyendo tambien propiedades que entendemos necesarioy util evaluar en las distintas taxonomıas. A continuacion se describen las nue-vas propiedades propuestas por nosotros y el posible conjunto de valores paracada una.

Calidad de la descripcion de valores de atributos Refiere a expresar quenivel de calidad tiene la descripcion de los valores de atributos. Resultainteresante conocer el nivel de calidad, ya que solo indicar la existencia ono de una descripcion no brinda un panorama de que tanto aporta dichadescripcion a la taxonomıa. Para esta propiedad no se definen valoresposibles, sino que para cada taxonomıa se debe expresar el nivel de calidadexistente.

Calidad de ejemplos de valores de atributos Se refiere a expresar que ni-vel de calidad tienen los ejemplos de los valores de atributos. Resultainteresante conocer el nivel de calidad de los ejemplos, ya que solo indicarla existencia o no de los mismos, no brinda un panorama de que tan cla-ro es el valor de un atributo y cuando dicho valor aplica correctamente.Los valores posibles para esta propiedad son “Buena”, “Mala” o “No con-tiene ejemplos”, segun la taxonomıa contenga ejemplos claros y concisos,ambiguos o no contenga ejemplos, respectivamente.

Clasificacion Se refiere a como se clasifica la taxonomıa segun [Wag08]. Losvalores posibles para esta propiedad son “Taxonomıa de defectos”, “Rootcause analysis” o “Clasificacion de defectos”.

Estructura Se refiere a cual es la estructura de la taxonomıa. Resulta intere-sante conocer la estructura de una taxonomıa para tener una vision clarade la relacion existente entre sus atributos. Los valores posibles para es-ta propiedad son “Jerarquica”, “Arbol”, “Ortogonal”, “Semi-Ortogonal” o“Simple”. Es deseable que la estructura sea ortogonal, ya que eso aseguraque aspectos diferentes de un defecto sean capturados en atributos dife-rentes.


Nivel de generalidad Se refiere a la capacidad de aplicacion de la taxonomıaa distintos proyectos o procesos de software. Resulta de interes conocer elnivel de generalidad para conocer cuando se puede utilizar la taxonomıa.Los valores posibles para esta propiedad son “Especıfica” (solo se puedeaplicar para un tipo software determinado), “Intermedia” (solo se puedeaplicar en una etapa del desarrollo de software) o “Generica” (aplicable encualquier momento del ciclo de vida del desarrollo).

Adaptabilidad Se refiere a la capacidad de expansion y modificacion de la ta-xonomıa acorde a las necesidades. Resulta de interes conocer la capacidadde adaptacion de una taxonomıa ya que es importante conocer si se puedemodificar o extender la taxonomıa existente para lograr un objetivo par-ticular o si es necesario crear algo totalmente nuevo para ello. Los valoresposibles para esta propiedad son “Adaptable”, “Medianamente adaptable”o “No adaptable”.

Tiempo de aprendizaje Se refiere al tiempo que se demora en aprender ausar una taxonomıa. Resulta de interes conocer el costo medio de apren-dizaje, ya que en el caso que el tiempo sea una limitante al momento dedecidirse por una taxonomıa u otra, es importante tener una estimacion decuanto tiempo implica su estudio. Los valores posibles para esta propiedadson“Alto”,“Medio”o“Bajo”, segun el tiempo que consuma su aprendizaje.

Tiempo de clasificacion Se refiere al tiempo que se demora en clasificar undefecto en una taxonomıa luego de saber usarla. Al igual que la propie-dad anterior, el interes surge porque el tiempo puede ser una limitante almomento de elegir la taxonomıa a incorporar en un proyecto. Los valoresposibles para esta propiedad son “Alto”, “Medio” o “Bajo”, segun el tiempoque consuma su aplicacion.

A continuacion se lista las propiedades propuestas por Freimut en la sec-cion 2.3 y el posible conjunto de valores para cada una.

Valores de atributo mutuo-excluyentes El cumplimiento de esta propie-dad implica que al momento de clasificar un atributo para un defecto, soloun valor es correcto. Los valores posibles para esta propiedad son “Sı” o“No”, segun la taxonomıa cumpla o no con dicha propiedad.

Completitud en valores de atributos El cumplimiento de esta propiedadimplica que al momento de clasificar un atributo para un defecto, siempreexista al menos un valor correcto. Los valores posibles para esta propiedadson “Sı”, “Aparente” o “No”, segun la taxonomıa cumpla, aparentementecumpla o no cumpla con dicha propiedad.

4.2. Comparacion

La forma en que la vista basada en atributos debe ser utilizada es la si-guiente: para cada atributo en la vista, buscar un atributo correspondiente enla taxonomıa que se esta evaluando. En los Cuadros 4.1 y 4.2, se evaluan lasseis taxonomıas contra el marco teorico, vista Atributos. En dichos Cuadros

4.2. COMPARACION 53

Atributos HP Kaner BinderUbicacion sospe-chadaUbicacion real Origen OrigenFase de provocacionde la fallaFase de inyeccionSıntomaTipo Tipo Tipo TipoMecanismo de pro-vocacion de la fallaMecanismo de in-yeccion

Modo Tipo (no siem-pre contempla-do)

Impacto de la fallaImpacto del defectoCausa (Error)Fuente responsableRecorrecionProbabilidad deocurrenciaGravedadPrioridadCosto de deteccionCosto estimado decorreccionCosto de correccionreal

Cuadro 4.1: Comparacion de taxonomıas HP, Kaner y Binder contra el marcoteorico, vista Atributos

se puede observar, para cada taxonomıa, que atributo se corresponde con queatributo del marco teorico.

Se observa que el unico atributo que se encuentra en todas las taxonomıases el tipo de defecto.

Binder, Kaner, Beizer y HP clasifican el defecto solamente cuando el mismoya fue detectado. ODC e IEEE clasifican al momento en que se provoca la fallay tambien luego de detectar el defecto. IEEE ademas clasifica al momento enque se corrige y al finalizar el registro y seguimiento del defecto.

Se puede observar que existen atributos planteados en el marco teorico queno estan contemplados en ninguna de las taxonomıas vistas. A continuacion selista cada uno y se detalla cual es el motivo de su inclusion en el marco teorico.

Fase de inyeccion Resulta interesante registrar la fase en que se inyecta el de-fecto, ya que dicho conocimiento puede utilizarse para prevenir la inyeccionde defectos similares en proyectos futuros.

Causa (Error) Resulta interesante registrar cual fue el error humano que pro-voca la inyeccion del defecto, ya que ser conscientes de ello puede ayudar


Atributos IEEE ODC BeizerUbicacion sospe-chada

Causa sospecha-da

Ubicacion real Fuente, Causaactual

Target

Fase de provocacionde la falla

Fase del Proyec-to

Fase de inyeccionSıntoma Sıntoma, Estado

del productoTipo Tipo Tipo TipoMecanismo de pro-vocacion de la falla

Actividad delproyecto

Trigger, Activi-dad

Mecanismo de in-yeccion

Calificador

Impacto de la falla Valor para elcliente, Misiony seguridad

Impacto

Impacto del defecto Costo del pro-yecto, Calidad yconfiabilidad delproyecto, Ries-go del Proyecto,Sociedad

Causa (Error)Fuente responsable Fuente, EdadRecorreccion EdadProbabilidad deocurrencia

Repetibilidad

Gravedad GravedadPrioridad PrioridadCosto de deteccionCosto estimado decorreccion

Cronograma delProyecto

Costo de correccionreal

Cuadro 4.2: Comparacion de taxonomıas IEEE, ODC y Beizer contra el marcoteorico, vista Atributos

en la prevencion de defectos en futuros proyectos. Algunos resultados deroot cause analysis dan posibles valores para este atributo. Por ejemploen [MJHS90], se plantea un atributo Causa con los valores Educacion,Supervision, Comunicacion, Herramientas y Transcripcion. En [LPS00] sepropone un atributo que captura distintos tipos de causas: Causas Hu-manas (falta de conocimiento, problemas de comunicacion), Causas delProyecto (falta de tiempo, error de gestion) o Causas de Revision (no sehizo inspeccion o fue incompleta, participacion inadecuada).

4.2. COMPARACION 55

Costo de deteccion Resulta interesante ya que se puede realizar un analisisde costos segun los tipos de defectos y ver si existe alguna relacion queluego permita estimar los cambios en el cronograma del proyecto. Ademas,conocer que tipos de defectos son costosos de detectar puede colaborar enla mejora del proceso grupal e individual, para evitar los defectos mascostosos.

Costo de correccion real Al igual que el costo de deteccion, resulta intere-sante su registro para un posterior analisis de costos, con el objetivo deestimar correctamente los cambios en el cronograma del proyecto. Tam-bien, conocer que tipos de defectos son costosos de corregir puede colaboraren la mejora de los procesos.

Tambien se puede observar que los atributos Resolucion, Accion Correcti-va y Disposicion de la taxonomıa propuestos por la IEEE, no se encuentrancontemplados en ningun atributo del marco. No se incorporan los significadosde Resolucion y Accion Correctiva, ya que para nosotros la resolucion y acciona tomar para prevenir un defecto no surge de un unico defecto, sino que sonacciones que se toman a partir de la informacion relevada de un conjunto de de-fectos. Tampoco se incorpora el significado de Disposicion ya que el mismo tienecomo objetivo indicar la etapa final del registro y seguimiento de un defecto. Noconsideramos que sea una caracterıstica a relevar de un defecto.

Propiedades HP Kaner BinderValores de atributomutuo-excluyentes

Si Si No

Completitud en va-lores de atributos

Aparente Aparente Aparente

Calidad de la des-cripcion de valoresde atributos

Buena: descrip-ciones claras, sinambiguedades

Mala: no todoslos valores estanexplicados

No se describenlos valores

Calidad de ejem-plos de valores deatributos

Buena No contieneejemplos

No contieneejemplos

Clasificacion Clasificacion dedefectos

Taxonomıa dedefectos

Clasificacion dedefectos

Estructura Semi-Ortogonal Jerarquica Arbol y Jerar-quica

Nivel de generali-dad

Generica Generica Especıfica

Adaptabilidad Adaptable Adaptable AdaptableTiempo de aprendi-zaje

Bajo Bajo Alto

Tiempo de clasifica-cion

Bajo Bajo Alto

Cuadro 4.3: Comparacion de taxonomıas HP, Kaner y Binder contra el marcoteorico, vista Propiedades

En los Cuadros 4.3 y 4.4, se presenta la comparacion de las seis taxonomıasvistas contra el marco teorico, vista Propiedades.


Propiedades IEEE ODC BeizerValores de atributomutuo-excluyentes

Si Si No

Completitud en va-lores de atributos

Aparente Aparente Si

Calidad de la des-cripcion de valoresde atributos



Mala: descrip-cion superficial,ambigua enalgunos casos

Calidad de ejem-plos de valores deatributos

Buena Buena Mala

Clasificacion Clasificacion dedefectos

Clasificacion dedefectos

Taxonomıa dedefectos

Estructura Ortogonal y Je-rarquica

Ortogonal Jerarquica

Nivel de generali-dad

Generica Generica Generica

Adaptabilidad Adaptable Adaptable AdaptableTiempo de aprendi-zaje

Alto Bajo Alto

Tiempo de clasifica-cion

Alto Bajo Alto

Cuadro 4.4: Comparacion de taxonomıas IEEE, ODC y Beizer contra el marcoteorico, vista Propiedades

Respecto a los valores para un atributo, las taxonomıas de HP, Kaner, IEEE yODC presentan la propiedad de conformar un conjunto mutuo-excluyente. Estosignifica que nunca dos o mas valores de un mismo atributo se correspondencon un mismo defecto. Sin embargo, en las taxonomıas de Binder y Beizer, elconjunto de valores para un atributo no presenta esa propiedad, lo que puedegenerar datos inconsistentes ya que se puede clasificar un mismo defecto dedistintas maneras.

Observando la estructura de las taxonomıas, observamos que ODC e IEEEson ortogonales. IEEE ademas es jerarquica al igual que las taxonomıas de Bei-zer, Binder y Kaner, pues en las cuatro taxonomıas el atributo tipo de defecto esrefinado en varios subniveles. La taxonomıa de Binder tambien es arborescente,ya que el valor del atributo Tipo depende del origen seleccionado previamen-te. La taxonomıa de HP es semi-ortogonal, ya que el valor del atributo Tipodepende del valor elegido para el atributo Origen, pero el atributo Modo esindependiente de los otros atributos.

La completitud en los valores de los atributos es una propiedad difıcil dedemostrar, ya que se deberıa tomar una muestra de defectos y clasificarlos encada taxonomıa para verificar que realmente todos los defectos pueden ser cla-sificados en los atributos correspondientes. Por eso es que la unica taxonomıaque realmente podemos afirmar que cumple con esta propiedad es Beizer, yaque para su unico atributo existe el valor “Otros”, donde allı clasifican los de-fectos que no se correspondıan con ninguno de los valores anteriores. Las demas

4.2. COMPARACION 57

taxonomıas aparentan cumplir con la completitud, pero no es posible afirmarlo.Respecto a la calidad de las descripciones y ejemplos de los valores de un

atributo, se aprecia una variacion de la misma en las distintas taxonomıas. Detodas formas, podemos decir que las taxonomıas de HP, IEEE y ODC presentanbuena calidad, ya que las mismas poseen descripciones completas, que no danlugar a confusion, ademas de incluir ejemplos concisos. Por otro lado, decimosque las taxonomıas de Kaner, Binder y Beizer tienen una mala calidad, ya queo no contienen descripciones ni ejemplos, o dichos atributos son superficiales,ambiguos o incompletos.

Respecto a los tiempos de aprendizaje, se agrupa con el valor “Bajo” aquellastaxonomıas que se consideran facilmente comprensibles, ya sea por la claridady completitud de su presentacion y/o por ser taxonomıas que comprenden unacantidad de atributos pequena. A las taxonomıas presentadas por Binder y Bei-zer, se les puso el valor “Alto” ya que si bien solo estan compuestas por ununico atributo, existen muchos valores posibles para ese atributo. Eso sumadoa descripciones vagas y una mala calidad de los ejemplos, resulta en un tiempode aprendizaje mucho mayor al del otro grupo. La taxonomıa presentada por laIEEE tambien se considera con tiempo de aprendizaje “Alto”, ya que contieneun conjunto muy amplio de atributos que deben ser estudiados y entendidos.

Analogo es el razonamiento propuesto para los tiempos de clasificacion. Aaquellas taxonomıas con descripciones sin ambiguedades, buenos ejemplos y/ocon pocos atributos a clasificar, se las agrupa con el valor“Bajo”. Las taxonomıascon mayor cantidad de atributos o aquellas que no estan claramente definidas niejemplificadas, donde el usuario generalmente demora su clasificacion por dudarentre dos o mas valores, se considera que tienen un tiempo de clasificacion“Alto”.

Clasificar un tiempo como “Alto”, “Medio” o “Bajo” no es la mejor formade hacerlo, ya que puede ser demasiado subjetiva y poco precisa. A futuro sepodrıan calcular los tiempos medios de aprendizaje y clasificacion para las di-versas taxonomıas, y poner dichos valores para poder realizar una comparacionmas exacta y representativa de la realidad.

Se observa que la cantidad de atributos, la calidad de las descripciones delos valores de atributos y la calidad de los ejemplos presentados en cada taxo-nomıa influyen significativamente en el tiempo de aprendizaje y clasificacion dela taxonomıa.


Capıtulo 5

Usos de Taxonomıas

En los capıtulos anteriores se presentan y analizan taxonomıas utilizadas enla industria y en la academia, evaluandolas mediante un marco de comparacionteorico original. En este capıtulo se presentan diversos usos de las taxonomıasencontrados en la literatura. Esto incluye usos de taxonomıas en experimentosy en la industria.

En la seccion 5.1, se presentan distintas formas generales de analisis de resul-tados de la clasificacion de defectos, ası como tambien mecanismos generales deinterpretacion de resultados. En la seccion 5.2 se presentan distintos tipos de usode las taxonomıas, incluyendo propuestas de mejoras y extensiones de taxono-mias existentes, ademas de experimentos formales vinculados a las taxonomıas.En la seccion 5.3 se presentan y analizan los resultados de un experimento formalrealizado por el grupo de Ingenierıa de Software del Instituto de Computacion.Algunas recomendaciones sobre la aplicacion de las taxonomıas reportadas endiversos estudios son presentadas en la seccion 5.4. Finalmente, en la seccion 5.5se presentan las conclusiones del capıtulo.

5.1. Formas de Analisis e Interpretacion de Re-sultados

El objetivo de esta seccion es presentar como la informacion obtenida a partirde la clasificacion de defectos puede ser analizada de distintas formas y comointerpretar los resultados de los posibles analisis.

5.1.1. Mecanismos Generales de Analisis

En la literatura se encuentran tres formas generales distintas de analizar lainformacion obtenida luego de la clasificacion de defectos. Uno de los metodos esmediante graficas, el otro es basandose en distribuciones esperadas y el ultimoes mediante un analisis estadıstico.

La construccion de graficas es un mecanismo sencillo de analisis que permitevisualizar facilmente los resultados. Es comun determinar la frecuencia relativay absoluta de los defectos segun su tipo. Para visualizar la distribucion de losdatos se pueden utilizar graficas de torta, histogramas o graficas de Pareto.

59

60 CAPITULO 5. USOS DE TAXONOMIAS

Un metodo para controlar las actividades de deteccion de fallas, como ins-pecciones o testing, es comparando las distribuciones obtenidas contra distri-buciones esperadas [CBC+92]. Las distribuciones esperadas derivan de datosrecolectados de varios proyectos historicamente y las mismas estan disponiblespublicamente para ser utilizadas. Un ejemplo de grafica con distribuciones es-peradas puede verse en la figura 5.1.

Por ejemplo, en ODC los defectos del tipo Funcion, son aquellos que requie-ren un cambio formal en el diseno. Es de esperar que la cantidad de defectosde este tipo baje a medida que avanza el proyecto. El comportamiento de unatributo con el paso del tiempo se llama “firma”. Basandose en una firma, lasdesviaciones respecto al comportamiento esperado pueden ser detectadas. Porejemplo, si la cantidad de defectos del tipo Funcion aumenta con el correr deltiempo, es necesario realizar una investigacion para visualizar si esta ocurriendoun problema.

%

40

30

20

10

Design Inspections Unit Test Integration Test System Test

Function

Assignment

Interface

Timing

Defect Types

Figura 5.1: ODC Ejemplo de Distribuciones Esperadas

Otro metodo para analizar los datos obtenidos luego de la clasificacion esmediante un analisis estadıstico propuesto por la IEEE en [IEE95]. En el stan-dard se muestra como aplicar chi-square tests para verificar estadısticamente silos valores de un atributo dado estan uniformemente distribuidos. Una segundaaplicacion es verificar estadısticamente si dos atributos son estadısticamente in-dependientes. No hemos encontrado aplicaciones de este metodo en la literatura.

5.1.2. Interpretacion de Resultados

En la literatura se encuentran dos tipos de procesos generales para interpre-tar los resultados del analisis.

5.2. TIPOS DE USO DE LAS TAXONOMIAS 61

El proceso de interpretacion presentado en [BHC+93] esta compuesto porlos siguientes pasos:

Resultado Se refiere a cual es la observacion hecha por medio del analisis.

Causa Se refiere a que situaciones en el proyecto pueden haber llevado a losresultados observados.

Consecuencia Se refiere a lo que va a suceder si no se inicia ninguna accion.

Accion Se refiere a lo que se debe realizar para prevenir las consecuenciasnegativas.

Validacion Cuando la accion se ha completado, chequear si se produjeron losresultados esperados.

El proceso de interpretacion presentado en [MHPD99] es similar:

Resultado Describir cada resultado inusual. Recopilar los hechos de variosresultados juntos y realizar un resumen de los mismos.

Causa De los resultados que se encuentran en el resumen, tratar de identificar lahistoria que explica los resultados. Intentar confirmar la historia o decidirinterpretaciones alternativas. Intercambiar ideas con las personas clavesimplicadas en el proyecto.

Accion Cuando la historia parece solida, proponer acciones especıficas paraabordar las cuestiones.

En los artıculos analizados en la siguiente seccion, que explican y analizanusos de diversas taxonomıas, generalmente no se describe exactamente el procesode interpretacion de resultados. Sin embargo, en todos los analisis que se realizanse utilizan procesos de interpretacion de resultados. Los mismos pueden sercualquiera de los dos procesos generales presentados en esta seccion o algunotro similar.

5.2. Tipos de Uso de las Taxonomıas

Esta seccion presenta actividades en las que se utilizan taxonomıas en laindustria y en la academia. Se presenta un panorama general de los distintosobjetivos que se pueden lograr mediante un analisis adecuado de los resultadosobtenidos mediante la clasificacion de defectos. Tambien se presentan aplica-ciones de las taxonomıas en experimientos formales, propuestas de mejora detaxonomıas y extensiones de las mismas.

5.2.1. Prevencion de Defectos

Uno de los propositos mas importantes del analisis de defectos es aprenderque tipos de defectos se estan inyectando y utilizar este conocimiento para pre-venir defectos similares en el futuro. La tecnica que se encarga de este propositoes llamada Defect Causal Analysis (DCA) [Car98] o Defect Prevention Process[MJHS90].


La idea es analizar la informacion de los defectos para buscar un error siste-matico. Un error sistematico es un error que se comete repetidamente y por lotanto causa muchos defectos. Una vez que el error sistematico es identificado, sucausa puede ser identificada y se puede realizar un cambio adecuado en el pro-ceso para prevenir el error sistematico y por lo tanto prevenir tambien las fallasy defectos resultantes. Estas tecnicas tienen como objetivo prevenir defectos opor lo menos permitir una deteccion temprana de los mismos.

Una fase importante de esta tecnica es la identificacion del error sistematicomediante la informacion extraıda en la clasificacion de defectos. Los tipos dedefectos mas frecuentes pueden dar una idea del error sistematico. Ademas,tambien se puede tomar en cuenta el esfuerzo promedio para encontrar y corregirun defecto, para determinar que tipo de defecto es mas importante prevenir. Unavez conocido que tipo de defecto se quiere prevenir, es importante identificar lascausas de dichos defectos, y por lo tanto, los errores sistematicos que estanocurriendo. Una vez identificados los errores sistematicos, se debe armar unplan de accion para lograr prevenir los mismos en el futuro.

Por ejemplo, luego de realizar la clasificacion de defectos mediante una ta-xonomıa, las graficas indican que la mayorıa de los defectos se encuentran enlas especificaciones. Al decidir atacar esa area, una lluvia de ideas identificalas siguientes causas: no comprender claramente los requisitos del cliente, laasignacion de resposabilidades no esta clara y ausencia de standards de docu-mentacion. Por lo tanto, un posible plan de accion para mejorar el proceso (yprevenir futuros defectos) podrıa ser el siguiente: mejorar las tecnicas actualespara relevar requerimientos, utilizar una herramienta para una asignacion cla-ra y adecuada de tareas y responsabilidades de cada persona involucrada en elproyecto y crear y aplicar un standard de documentacion.

La forma basica de analisis de la clasificacion de defectos utilizada en pre-vencion de defectos es la construccion de graficas.

Reporte de Casos

En [Nar03] se presentan tecnicas y herramientas para la creacion de una es-trategia de prevencion de defectos, que aplicada en todas las fases del ciclo devida del software, puede reducir el tiempo y los recursos necesarios para desa-rrollar sistemas de alta calidad. Inicialmente, se analizan los defectos mediantela informacion extraıda de la clasificacion realizada utilizando la taxonomıa deBeizer. La aplicacion de la taxonomıa resulta fundamental para la identificacionde los errores sistematicos. A partir de dichos errores sistematicos se logra armarun plan de accion de prevencion. Luego de aplicar la estrategia de prevencionde defectos el numero de defectos se reduce en un 60 %.

En [She09] se presenta un caso de estudio de prevencion de defectos en undesarrollo de software para un DVD Player. En este caso, la clasificacion dedefectos se realiza aplicando ODC. El uso de ODC permite descubrir que losdefectos funcionales son un area prioritaria a atacar y se realizo un analisisprofundo de defectos para identificar las causas de los mismos y por lo tanto,planificar las acciones necesarias para prevenirlos. Como resultado de la ejecu-cion del plan de accion, se obtiene que los defectos de tipo funcionales se reducende un 28 % a un 12 %, ademas de que los defectos son detectados en fases mastempranas del proyecto.


5.2.2. Control de Pruebas e Inspecciones

Como se describio anteriormente, el atributo “tipo” de ODC tiene distintasfirmas segun la etapa del proceso en la que se encuentre el producto, por loque cada actividad de deteccion de defectos tiene una distribucion esperada. Laexistencia de desviaciones de la distribucion actual respecto a la distribucionesperada, puede indicar problemas potenciales en el proyecto.

Por ejemplo, una situacion extrana es cuando en un proyecto en la fasede pruebas de integracion se encuentra con una gran proporcion de defectos deasignacion o chequeo. No se espera una gran proporcion de estos tipos de defectosen dicha fase, ya que los defectos de asignacion y chequeo estan asociados apruebas unitarias. Una posible interpretacion de esta situacion es que se realizouna prueba de integracion demasiado pronto o que las pruebas unitarias nofueron efectivas.

La informacion de la clasificacion de defectos tambien puede ser utilizadapara evaluar la efectividad de las inspecciones de software y usar el conocimientoadquirido para control de inspecciones. La propuesta consiste en analizar lostipos de defectos encontrados y compararlos con los tipos de defectos esperados.

Por ejemplo, en una inspeccion de codigo, la proporcion de defectos encontra-dos para algun valor de un atributo es muy pequena comparada a la proporcionesperada. Esto es un indicador de que algo extrano ocurrio: la inspeccion fuerealizada por un equipo inexperiente. Al volver a realizar la inspeccion por unequipo de expertos, se encuentran mas defectos relacionados a dicho valor.

El uso de una taxonomıa junto a las distribuciones esperadas, brinda unaforma de controlar si las inspecciones estan siendo efectivas o si estan quedandodefectos sin detectar.

La forma basica de analisis de la clasificacion de defectos utilizada en controlde pruebas e inspecciones es la de distribuciones esperadas.

Reporte de Casos

En [CP02] se presenta un caso de estudio que consiste de un analisis restros-pectivo de un desarrollo de software para comprender la efectividad del procesode verificacion. El analisis se basa en el atributo Trigger de ODC, que brindauna guıa para comprender el grado de efectividad en la prueba, probables causasy consecuencias de la verificacion. Como resultado de la aplicacion de ODC yde un analisis del atributo Trigger, se identifican que elementos de desarrollopueden ayudar al ciclo de pruebas, si existen beneficios adquiridos por el usode una buena arquitectura, un buen diseno y un buen proceso para relevar derequerimientos, y que se puede mejorar para aumentar la efectividad del procesode verificacion.

5.2.3. Plan de Pruebas

En [Sch99], se describe un metodo para planificar y controlar las pruebasmediante el uso de ODC. Dicho metodo se basa en el mapeo entre el numero dedefectos encontrados y el numero de casos de prueba ejecutados, analizando siel espacio de defectos ha sido lo suficientemente explorado o no.

Mediante esta tecnica es posible identificar areas de mejora potencial. Unarea sin pruebas y con un numero bajo o alto de defectos, indica la presencia de


defectos que no son objetos de casos de prueba. Aquı nuevos casos de pruebadeben ser definidos. Por otro lado, un area con un alto numero de pruebas y sindefectos, indica que se esta realizando demasiado esfuerzo en probar productosque no tienen defectos. Aquı se debe utilizar ese esfuerzo en las pruebas de otroscomponentes. Finalmente, un area con un bajo numero de casos de pruebadescubriendo una gran cantidad de defectos es un area problematica. Se debenrealizar mas pruebas en dicha area o un analisis profundo de dicho componentedel sistema.

La forma basica de analisis de la clasificacion de defectos utilizada en plande pruebas es la construccion de graficas.

Reporte de Casos

En [BMK02], se presenta un caso de estudio en el que se muestra como unpequeno equipo, con pocos recursos, puede beneficiarse mediante la identifica-cion especıfica de las deficiencias en las pruebas. El equipo utiliza ODC paraidentificar que tipos de pruebas se necesitan para mejorar la calidad del pro-ducto antes de liberarlo, ya que la verificacion no se realiza correctamente porfalta de experiencia en el area. En este caso, el equipo es capaz de evaluar ra-pidamente la efectividad de la verificacion e implementar acciones correctivaspara fortalecer el tarea de testing. En el trabajo, no se presentan los resultadosobtenidos luego de la aplicacion de dichas acciones correctivas.

En el mismo artıculo, se presenta otro caso de estudio de un producto dealta calidad, con el objetivo de mejorar el proceso de verificacion para disminuirlos defectos de campo (aquellos defectos que se descubren luego que el productoes liberado). Para ello se clasifican los defectos de campo mediante ODC y atraves de un analisis de los mismos, el equipo toma medidas para fortalecer losplanes de pruebas, mejorar la educacion de funciones de verificacion dentro delequipo, incrementar las pruebas de regresion para los componentes identificadosy mejorar la documentacion. La aplicacion de ODC en este proyecto da comoresultado la rapida identificacion de areas a mejorar. Como resultado de laaplicacion de las medidas tomadas por el equipo, realmente se logra mejorar laefectividad del proceso de verificacion y dicha mejora lleva a tomar la decisionde aplicar ODC en futuros proyectos.

5.2.4. Reduccion de Defectos de Campo

Los defectos no son detectados unicamente durante el desarrollo, sino tam-bien luego de que el producto es liberado al cliente. Estos defectos son llamadosdefectos de campo. Analizar los defectos encontrados por el cliente, permite en-contrar la razon por la que no fueron encontrados durante el desarrollo. Esteconocimiento puede ser utilizado para mejorar el desarrollo y el proceso de veri-ficacion, ademas de prevenir que ocurran defectos de campo similares en futurosproyectos, lo que incrementa la calidad con la que el sistema es percibido por elcliente.

La reduccion de defectos de campo puede considerarse un caso particular deprevencion de defectos.

Generalmente, para analizar que areas pueden ser mejoradas, se usa la in-formacion sobre el impacto de los defectos detectados, por ejemplo analizandola distribucion de los defectos segun los valores posibles del atributo Impacto


de ODC. Tambien se puede analizar el atributo Trigger de ODC, mejorando laactividad de deteccion prestando mas atencion a los triggers de los defectos decampo.

La forma basica de analisis de la clasificacion de defectos utilizada en reduc-cion de defectos de campo es la construccion de graficas.

Reporte de Casos

En [BMK02] se presenta un caso de estudio de un producto de alta calidadcon un objetivo de disminuir los defectos de campo. Se clasifican los defectosde campo mediante ODC, identificando las caracterısticas de los defectos quese escaparon en la fase de verificacion. Luego se implementa un plan de accionmejorando los planes de prueba, no solo logrando el objetivo de disminuir losdefectos de campo sino que aumentando la satisfaccion del cliente y disminuyen-do los costos de garantıa. Aplicar ODC en dicho proyecto permite una rapidaidentificacion de las areas de mejora potencial.

5.2.5. Evaluar y Mejorar Cambios del Proceso

Generalmente la distribucion de los defectos tiende a ser bastante establecuando subsecuentes liberaciones del mismo producto son desarrolladas. En es-tos casos, la distribucion de los defectos puede ser utilizada para monitorear elimpacto de los cambios del proceso.

Por ejemplo, si en una liberacion se encuentra un error sistematico en losdefectos de interfaz y se implementa una accion para prevenir este error, entoncesla proporcion de defectos de este tipo deberıa disminuir con el paso del tiempo.

La forma basica de analisis de la clasificacion de defectos utilizada en laevaluacion y mejora de cambios del proceso es la construccion de graficas.

Reporte de Casos

En [Chu08] se presenta un white paper de la empresa NIIT Technologiesque es una organizacion CMMI nivel 5. En la misma se utiliza ODC comoherramienta de registro y seguimiento de defectos, utilizando los resultados dela clasificacion para guiar la mejora del proceso. En dicho reporte se muestra ladistribucion de defectos segun el tipo de defecto, antes y luego de realizar unplan de accion, observandose una amplia reduccion de la cantidad de defectosde los tipos atacados en el plan de accion. El uso de ODC permite identificarlas areas de mejora y evaluar la efectividad de los cambios del proceso.

En [BHC+93] se presenta un caso de estudio, donde se muestra mediantegraficas que la interpretacion de los resultados de la clasificacion mediante ODCpermiten al equipo de desarrollo identificar y corregir problemas del proceso,ası como tambien validar la efectividad de las acciones correctivas. Los resul-tados muestran que el analisis mediante ODC permite una mejora real y queODC puede comenzar a utilizarse en cualquier etapa del ciclo de vida del pro-ducto dando buenos resultados. Ademas muestra que los costos del proceso declasificacion y analisis son muy bajos comparados con los beneficios obtenidos.


5.2.6. Soporte de Root Cause Analysis

Root cause analysis (RCA) es un metodo de resolucion de problemas enfo-cado a identificar las causas de los problemas o acontecimientos. La practica deRCA se basa en la idea de que los problemas se resuelven mejor por tratar decorregir o eliminar las causas raız, en vez de simplemente tratar los sıntomasevidentes de inmediato. Al dirigir las medidas correctivas a las causas profun-das, es de esperar que la probabilidad de la repeticion del problema se minimice.En general, root cause analysis es visto como un enfoque que requiere bastanteelaboracion y su relacion costo/beneficio no es clara.

Sin embargo, ODC puede alterar significativamente el costo y la viabilidad deRCA, reduciendo el tiempo que tarda en realizar el trabajo y al mismo tiempo,permitiendo una mayor cobertura del alcance del defecto. ODC ayuda a eliminarlos obstaculos fundamentales que impiden la generalizacion del uso de RCA,sobre todo cuando la cantidad de defectos es muy grande y las especializacionesdel equipo de ingenierıa son limitadas.

La forma basica de analisis de la clasificacion de defectos utilizada en soportede root cause analysis es la construccion de graficas.

Reporte de Casos

En [Chi06] se presenta un caso de estudio sobre RCA junto a ODC. Semuestra que ODC logra que root cause analysis sea mas practico y escalable.El costo de analisis se reduce de 1 hora a 4 minutos por defecto. Este enfoquede RCA tiene multiples beneficios. No todos los involucrados en el desarrollotienen que estar interiorizados en root cause analysis y luego de la clasificacionmediante ODC, el analisis se relega a un grupo de expertos con mayor visionde tendencias y temas organizacionales. Tambien hay una mayor cobertura dela informacion de los defectos con menores costos de ejecucion. Ademas, losmetodos cuantitativos permiten realizar comparaciones mas facilmente entreuna liberacion y otra, entre otros beneficios.

5.2.7. Desarrollo, Extensiones y Mejoras de Taxonomıas

En la industria y la academia hay varios ejemplos de aplicaciones y casosde estudio en los que se plantea el desarrollo de nuevas taxonomıas a partirde otras ya existentes. Tambien hay interesantes propuestas de extensiones detaxonomıas existentes, con el objetivo de alcanzar nuevas metas o mejorar losresultados obtenidos. En esta seccion se presentan algunas de dichas propuestas.

Desarrollo y Validacion de una Taxonomıa

En [FDK05] se presenta un enfoque para definir, introducir y validar unataxonomıa de defectos especıfica que considera las caracterısticas de un entornoindustrial. Ademas, se presentan los resultados y experiencias de aplicar dichoenfoque en la empresa Bosch, mediante la definicion, validacion y aplicacionde una taxonomıa segun los objetivos deseados. Los resultados indican que lataxonomıa desarrollada permite clasificar defectos con buena confiabilidad, quepermite la identificacion de acciones de mejora del proceso, y que puede servircomo base para evaluar los cambios del proceso. Esta taxonomıa no se presentaen los capıtulos anteriores, ya que la misma es definida especıficamente para


un entorno industrial y ademas la taxonomıa no se encuentra detallada en elartıculo.

Extension de ODC

En [MHPD99] se presenta una adaptacion y extension de ODC que se uti-liza en la empresa Bellcore, ademas de una herramienta web llamada EfficientDefect Analyzer para soportar el uso de ODC a gran escala. En la propuestase muestran los atributos que componen la adaptacion de ODC, los posiblesmetodos de analisis para ubicar patrones de defectos, areas de mejora y posiblesacciones correctivas, ademas de ejemplos de como aplicar cada uno de los pasosde la clasificacion y del analisis.

ODC Harmony Matrices

En [SL06] se propone una tecnica desarrollada por la empresa Motorola,llamada ODC Harmony Matrices, que ayuda a monitorear la calidad de losdatos recolectados mediante ODC.

La motivacion de esta propuesta es que se ha encontrado que ODC no siem-pre se aplica correctamente. En algunos casos las personas encargadas de laclasificacion no estan bien entrenadas, lo que resulta en un conjunto de defectosincorrectamente clasificados y datos con informacion falsa.

La idea base de esta propuesta es encontrar relaciones entre los atributosTipo y Trigger de ODC, y utilizando dichas relaciones se propone un criteriopara mejorar la calidad de los datos recolectados durante la clasificacion, lo queayuda en la mejora del producto y del proceso.

Las Harmony Matrices son el resultado de la experiencia de utilizar ODCen Motorola. Se han examinado los datos historicos de las tendencias y guıasde lo que generalmente son combinaciones aceptables entre Tipo de defecto yTrigger en dicha organizacion. Las guıas se presentan en una matrız y pueden serutilizadas para ayudar a determinar la combinacion probable entre los atributos.

La clasificacion mediante ODC es un trabajo intensivo y no se automatizapor la adopcion de esta tecnica. Las matrices ayudan en el proceso subjetivo,haciendo la clasificacion de defectos menos objetiva.

Butterfly Model

En [BKS98] se presenta un framework llamado Butterfly Model. El mismoutiliza algoritmos y metodos para interpretar los datos recolectados medianteODC, con el objetivo de ayudar a las organizaciones a descubrir problemas yoportunidades de mejora, identificar rapidamente acciones prioritarias y moni-torear el resultado de las acciones.

Ademas de interpretar los datos obtenidos mediante ODC durante todo elciclo de vida del proceso, el framework incorpora otros elementos como definiciondel proceso, factores de dificultad del producto, perfiles de usabilidad del cliente,entre otros.

Por ejemplo, si una actividad es menos (o mas) efectiva de lo planificado, elButterfly Model rapidamente mide y reporta dicha debilidad (o fortaleza), iden-tifica y cuantifica el impacto de la desviacion sobre las actividades subsecuentes yel impacto en produccion. Provee detalles tecnicos y realiza analisis que ayudan


al equipo a identificar y priorizar acciones. El modelo tambien brinda repor-tes a nivel de gestion de proyecto, efectividad de la verificacion, productividad,confiabilidad, calidad y satisfaccion del cliente.

Extension de HP

En [Hub98] se presenta una extension de la taxonomıa propuesta por HPllamada Software Testing Focus. Este nuevo modelo indica que niveles de testingse deben aplicar en el futuro para encontrar defectos existentes con cierto Origeny Tipo. En este sentido, el modelo propuesto por HP brinda formas de mejorarel proceso de testing de una organizacion. El modelo puede verse en la figura5.2.

OrigenEspecificaciones Diseño Código

Interfaz de HW/SW

Interfaz de Usuario

Requerimientos/Especificaciones

Descripción Funcional

Comunicación (Inter-)

Procesos

Diseño Modular

Chequeo de Errores

Tipo

Nivel de Prueba

Definición de Datos

Descripción Lógica

Lógica

Computacional

Manejo de Datos

Interfaz/Implementación

Modular

Prueba de Integración de Sub-Sistema Prueba de

Sistema

Pruebas de Integración de Componentes de Alto Nivel

Prueba de Componentes de Alto Nivel

Prueba Unitaria

Integración Unitaria y Prueba de

Integración de Componentes de

Bajo Nivel

NOTA: Los tipos subrayados aplican a más de un Origen.

Figura 5.2: Extension de la taxonomıa de HP enfocada a la verificacion

Los pasos recomendados para aplicar la extension del modelo de HP son lossiguientes:

- Clasificar los defectos usando la taxonomıa original de HP.

- Elegir las areas de defectos (Origen y Tipo) especıficas que se desean me-jorar.

- Realizar un analisis profundo para determinar las causas de estas catego-rıas de defectos.

- Implementar un plan de prevencion de defectos para estas areas.

- Aplicar la extension del modelo para determinar en que nivel de pruebahay que enfocarse en el proximo proyecto.


- Determinar planes de accion y asignar responsables.

- Ejecutar los planes en el siguiente proyecto.

- Al finalizar el siguiente proyecto, volver a clasificar y evaluar nuevamentelos defectos y sus tendencias.

- Documentar los cambios.

Este procedimiento se basa en que no todos los defectos se generan equitati-vamente. Por lo tanto enfatiza la prevencion de defectos y la deteccion tempranade los mismos en las primeras etapas del desarrollo, como pueden ser las etapasde Requerimientos y Diseno. Como se puede apreciar, el modelo se utiliza alfinalizar el desarrollo en la etapa de verificacion, como una retrospeccion. Susresultados estan enfocados en la mejora a futuro.

5.2.8. Experimentos Formales

En esta seccion se presentan experimentos formales realizados en la acade-mia, con entornos variados, en los que se utilizan diversas taxonomıas de defectosde software durante el desarrollo de los mismos.

Reporte de Experimentos

En [BS87] se presentan un conjunto de experimentos en los que se compa-ra la efectividad de distintas tecnicas de verificacion de software. Durante losexperimentos, se clasificaron los defectos encontrados con una taxonomıa orto-gonal de dos atributos: Tipo de defecto y Calificador. El Tipo de defecto tienelos siguientes valores posibles: Estetico, Inicializacion, Control, Computacional,Interfaz o Datos. El calificador puede tomar los valores Omiso o Incorrecto.La taxonomıa utilizada fue creada especıficamente para este experimento, noes general, por lo que no esta incluıda entre las taxonomıas presentadas en loscapıtulos anteriores. Ademas, se considera similar a ODC, pero mas reduciday especıfica, por lo que no aporta visiones nuevas de un defecto. A partir delos resultados de los experimentos, se extraen interesantes conclusiones sobre laefectividad de las distintas tecnicas de verificacion y algunos de los resultadosson presentados discriminando segun el tipo de defecto.

En [JV03] se presentan y realizan los mismos experimentos previamente rea-lizados por Basili en [BS87] que investigan la efectividad de distintas tecnicasde verificacion. En este estudio ademas se intenta relacionar cada tecnica deverificacion con tipos de defectos que cada una detecta. En los experimentosrealizados, para la clasificacion de defectos se utilizo la misma taxonomıa uti-lizada por Basili, pero reducida (es decir, se utilizo un conjunto mas pequenode valores posibles para clasificar el Tipo de defecto). Los resultados de losexperimentos son presentados segun el Tipo de defecto.

En [BLV01] se presenta un estudio para determinar la efectividad de lasreuniones de inspecciones. En dicho estudio se realiza un experimento con masde mil estudiantes de grado, aplicando la tecnica de inspecciones en documentosde requerimientos de software. Para la clasificacion de los defectos encontradosse utilizo una taxonomıa de defectos de requerimientos propia, creada a partirde ideas tomadas del Standard de Requerimientos de Software presentado por


la IEEE. Esta taxonomıa no esta incluıda en los capıtulos anteriores ya que lamisma no es presentada formalmente en el artıculo (no se indica que atributostiene, ni cual es el conjunto de valores posibles para cada uno). En el experimentose compara la performance de equipos nominales y reales, ademas de investigarlas razones de perdida en las reuniones.

En [KS01] se presenta una taxonomıa para evaluar y comparar la efectivi-dad de tecnicas de inspecciones de software. La misma se llama ODC-CC y estaconformada por los siguientes atributos: Trigger (se refiere a la tarea que seestaba realizando durante la inspeccion, similar al atributo Trigger propuestopor ODC), Target (es el producto bajo inspeccion, similar al atributo Targetpropuesto por ODC), Tipo de defecto (a diferencia de ODC, considera el tipode defecto segun el codigo y no segun la correccion necesaria para solucionar elproblema como lo hace ODC; ademas se incrementa la granularidad del atributoaumentando la precision con respecto a ODC) y Calificador (tambien aumentala granularidad del mismo respecto a ODC, brindando un conjunto mas ampliode valores posibles). Su uso y aplicacion para este caso de estudio es considera-do satisfactorio, pero la taxonomıa no es completamente aceptada ya que hayalgunos temas de repetibilidad y validez que son discutidos. Esta taxonomıa noes incluıda en el conjunto de taxonomıas presentadas en capıtulos anteriores, yaque la misma es creada especıficamente para este experimento, y la validez dela misma para uso general es discutida.

En [LR97] se presenta un esquema de caracterizacion para experimentoscontrolados, de forma de evaluar las tecnicas de deteccion de defectos. Dichoesquema permite la comparacion de resultados entre experimentos similares yestablece un contexto para el analisis de resultados de experimentos cruzados.En el artıculo ademas se presenta la aplicacion del esquema en cuatro experi-mentos que comparan distintas tecnicas de deteccion de defectos de codificacion.En lo experimentos realizados, se utiliza la taxonomıa propuesta por Basili pa-ra clasificar los defectos encontrados. Los resultados de los experimentos sonpresentados segun el Tipo de defecto.

En [VH09] se presenta un caso de estudio para evaluar la efectividad y elcosto de cinco tecnicas de verificacion unitaria: inspecciones, particiones de equi-valencia y valores lımite, tablas de decision, caminos linealmente independientesy criterio de condicion multiple. En este estudio se realiza un experimento con17 estudiantes de grado, que dado un programa de pequeno porte, crean unconjunto de casos prueba cumpliendo una tecnica de verificacion determinada.Los estudiantes ademas ejecutan dichas pruebas y para cada falla, detectan eldefecto en el codigo y clasifican el mismo segun las taxonomıas propuestas porIBM (ODC) y Beizer. En el experimento, para ODC solo se toma en cuentalos atributos Tipo de defecto y Calificador. Para Beizer, se clasifica el Tipo dedefecto con una profundidad de hasta nivel 3. El estudio finalmente extrae con-clusiones preliminares sobre la efectividad de las tecnicas y costos de las mismas,presentando los resultados de los experimentos segun el tipo de defecto.

En [Mye78] se presenta un experimento para evaluar la efectividad de sietetecnicas de verificacion. La particularidad de este experimento es que el mismoes realizado por 59 personas con 11 anos de experiencia (en promedio) en el areade programacion y no por estudiantes de grado con pocos anos de experienciaprogramando. Los participantes aplican diversas tecnicas de verificacion en pro-gramas pequenos y se muestran los resultados diferenciando cuantas personasfueron capaces de detectar cada defecto y mediante que tecnica. Los defectos

5.3. ANALISIS DE EXPERIMENTO FORMAL 71

ademas se clasifican por el tipo de defecto; no se aclara cuales fueron los va-lores utilizados para dicho atributo ni se indica si se utilizo una taxonomıa enparticular. El analisis muestra que ciertos tipos de defectos son mas difıciles dedetectar que otros (independientemente de la tecnica utilizada), ademas de quela capacidad de detectar determinado tipo de defectos de alguna forma varıaentre una tecnica de verificacion y otra.

En [WRBM97] se presenta un reporte que describe un estudio empırico con elobjetivo de comparar y combinar tres tecnicas de verificacion. El experimento serealiza por 47 estudiantes de grado aplicando diversas tecnicas en programas depequeno porte. Los resultados se discuten globalmente segun la tecnica utilizaday en algunos casos se particulariza segun una clasificacion del defecto detectado.Dicha clasificacion esta formada por un unico atributo, que toma los siguientesvalores posibles: Defecto que puede manifestarse mediante una falla, defecto quejamas se manifiesta mediante una falla, defecto que implica una salida incorrec-ta, o defecto menor (como puede ser un texto con errores ortograficos). Comotrabajo a futuro, entre otras cosas los autores plantean estudiar la existenciade relaciones entre tipos de defecto y efectividad de deteccion de las tecnicas,ademas de explorar el comportamiento en un contexto industrial (no solamenteacademico). La taxonomıa o clasificacion utilizada en este experimento no seincluye en el conjunto de taxonomıas presentadas en capıtulos anteriores, yaque el conjunto de valores posibles para el atributo no presenta la propiedad deser mutuo-excluyente.

5.3. Analisis de Experimento Formal

El grupo de Ingenierıa de Software de la Facultad de Ingenierıa de la Ude-laR, realizo un experimento formal que consiste en la verificacion unitaria decuatro programas implementados con lenguaje Java. Dichos programas son depequeno porte (entre 400 y 900 lıneas de codigo). Los mismos son construıdosespecialmente para el experimento y sus defectos son conocidos. El experimen-to es realizado por 14 estudiantes de 4to y 5to ano de la carrera de Ingenierıaen Computacion. El mismo consiste en la aplicacion de cinco tecnicas de veri-ficacion unitaria, la busqueda en codigo de los defectos detectados durante laverificacion y la clasificacion de dichos defectos utilizando las taxonomıas deIBM (ODC) y Beizer. Como parte del trabajo de este proyecto de grado anali-zamos los resultados obtenidos en ambas clasificaciones para dos de los cuatroprogramas utilizados.

Antes del comienzo del experimento, los 14 estudiantes fueron preparadoscon un curso de cada una de las tecnicas de verificacion unitaria aplicadas (ins-pecciones, particiones de equivalencia y valores lımite, tablas de decision, cami-nos linealmente independientes y criterio de condicion multiple), un curso sobrelos scripts a utilizar durante la ejecucion del experimento, un curso sobre lastaxonomıas ODC y Beizer, ademas de un entrenamiento en la ejecucion de lastecnicas en un programa simple.

Para la clasificacion de los defectos en ODC, solo se toman en cuenta losatributos Tipo y Calificador. Para la clasificacion en Beizer, solo se clasificahasta el nivel 3 de la jerarquıa. En nuestro analisis presentamos los resultados dela clasificacion de los defectos que fueron encontrados por mas de un verificador,para de esta forma poder observar la cantidad de clasificaciones distintas de un


mismo defecto.

5.3.1. Programa 1

Este programa es un generador de examen multiple opcion usando LATEX yHSQLDB. El programa genera dos archivos LATEX a partir de la seleccion, porparte del usuario, de distintas preguntas multiple opcion que se encuentran enuna base de datos. Uno de los archivos contiene la letra del examen multipleopcion y el otro contiene las soluciones. Estos archivos se pueden compilar en elambiente LATEX. Ademas, el programa permite el ingreso de nuevas preguntasa la base de datos.

El programa contiene 38 defectos conocidos y es verificado por 9 estudiantes:uno aplica inspecciones, dos aplican particiones de equivalencia y valores lımite,dos aplican tablas de decision, dos aplican caminos linealmente independientesy dos aplican criterio de condicion multiple. Los estudiantes que realizan elexperimento no conocen los defectos ni la cantidad de defectos que contiene elprograma.

En los Cuadros 5.1 y 5.2 se presentan las clasificaciones de ODC y Beizerobtenidas en la experiencia para cada defecto. Solo se muestran aquellos defectosque fueron detectados por mas de un estudiante.

Tipo Calificador Defecto1 2 11 12 13 14 19 26 27 28 30 31 32 33

Chequeo Faltante 2 2 2 2Asig./Inic. Faltante 3 1 3 4 4 2Asig./Inic. Incorrecto 4 1 2

Algoritmo/Metodo Incorrecto 3 1 1 1Algoritmo/Metodo Faltante 1 1

#Encontrados 2 2 4 4 3 2 2 2 2 3 4 2 5 3#Clasif. Distintas 1 1 2 1 1 2 1 1 2 1 1 1 2 2

Cuadro 5.1: Programa 1. Clasificacion con ODC

Tipo de Defecto Defecto1 2 11 12 13 14 19 26 27 28 30 31 32 33

2.1.1 1 12.2.1 1 12.3.1 12.5 1 12.6 1 1

3.1.2 13.1.4 2 1 33.1.5 13.2.1 1 1 13.2.2 14.1.3 1 1 1 24.2.3 1 1 2 2 1 14.2.4 1 1 1 14.2.8 1 1


Cuadro 5.2: Programa 1. Clasificacion con Beizer

5.3. ANALISIS DE EXPERIMENTO FORMAL 73

5.3.2. Programa 2

Es un programa matematico que permite calcular la correlacion entre dosconjuntos de numeros x e y, calcular la significacion de la correlacion, calcular losparametros de regresion lineal para un conjunto de n pares de datos y calcularun intervalo de prediccion para una estimacion.

El programa contiene 50 defectos conocidos y es verificado por 11 estudiantes:tres aplican inspecciones, dos aplican particiones de equivalencia y valores lımite,uno aplica tablas de decision, dos aplican caminos linealmente independientesy tres aplican criterio de condicion multiple. Los estudiantes que realizan elexperimento no conocen los defectos ni la cantidad de defectos que contiene elprograma.

En los Cuadros 5.3, 5.4, 5.5 y 5.6 se presentan las clasificaciones de ODC yBeizer obtenidas en la experiencia para cada defecto. Solo se muestran aquellosdefectos que fueron detectados por mas de un estudiante.

Tipo Calificador Defecto1 2 3 4 5 6 7 9 12 20 24 27 28 29 30

Chequeo Faltante 3 2 2 1 2 3 2 3 3 9 2Asig./Inic. Faltante 1Asig./Inic. Incorrecto 3 2 8 2

Algoritmo/Metodo Incorrecto 3 1#Encontrados 6 3 2 2 3 8 2 2 2 3 2 3 3 9 2

#Clasif. Distintas 2 1 1 1 2 1 2 1 1 1 1 1 1 1 1

Cuadro 5.3: Programa 2. Clasificacion con ODC, parte 1

Tipo Calificador Defecto32 33 34 36 38 39 40 44 45 46 47 48 49 50

Chequeo Faltante 3 2 2 4 3Asig./Inic. Faltante 3Asig./Inic. Incorrecto 2 1 1 2 1 2 1 1Asig./Inic. Extrano 1 1 1 1 1 1

Algoritmo/Metodo Incorrecto 3Algoritmo/Metodo Faltante 3


Cuadro 5.4: Programa 2. Clasificacion con ODC, parte 2

5.3.3. Analisis de Resultados del Experimento

Para analizar los resultados obtenidos en el experimento formal, considera-mos los resultados de las clasificaciones de los defectos de ambos programas. Esnecesario aclarar que no se conoce la clasificacion correcta para cada defecto,por lo que solo se analizaran los resultados obtenidos entre sı.

En total existen 43 defectos que fueron clasificados por al menos dos estu-diantes. Analizando la cantidad de clasificaciones distintas, podemos observarque existen 59 clasificaciones distintas entre todos los defectos en ODC y 90 enBeizer. Esto significa que la cantidad de clasificaciones distintas en promediopara un defecto es de 1.37 para ODC y de 2.09 para Beizer. El valor optimo es1, que implica que todos los estudiantes clasificaron un mismo defecto con losmismos valores de atributos.


Tipo de Defecto Defecto1 2 3 4 5 6 7 9 12 20 24 27 28 29 30

2.1.1 22.4.1 1 1 1 1 3 12.4.2 12.6 1

3.1.2 2 2 2 1 1 2 2 2 2 53.2.1 13.2.2 3 1 13.2.3 13.2.5 1 2 14.1.1 14.1.3 2 2 14.2.1 2

#Encontrados 6 3 2 2 3 8 2 2 2 3 2 3 3 9 2#Clasif. Distintas 3 2 1 1 2 5 2 2 2 2 1 2 2 3 2

Cuadro 5.5: Programa 2. Clasificacion con Beizer, parte 1

Tipo de Defecto Defecto32 33 34 36 38 39 40 44 45 46 47 48 49 50

2.3.1 22.4.1 1 2 13.1.2 2 2 2 23.1.4 13.2.1 23.2.2 1 2 13.2.3 2 2 2 2 2 2 2 24.1.4 14.2.1 14.2.3 1


Cuadro 5.6: Programa 2. Clasificacion con Beizer, parte 2

Por otro lado, si analizamos la cantidad maxima de clasificaciones distin-tas para un defecto, podemos observar que la cantidad maxima en ODC es 3,mientras que en Beizer dicha cantidad es 5. Estos valores pueden justificarse porla estructura de cada taxonomıa. ODC es ortogonal y tomando en cuenta sololos atributos Tipo y Calificador, la cantidad de clasificaciones posible para undefecto es 24 (8 valores posibles para Tipo y 3 valores posibles para Calificador).Por otro lado, la taxonomıa de Beizer es jerarquica y tomando en cuenta quese clasifica hasta nivel 3 de la jerarquıa, la cantidad de clasificaciones posiblepara un defecto es 122 (sumatoria de todos los valores posibles de la jerarquıade nivel 3).

Analizando la cantidad de defectos que fueron clasificados igual por todos losestudiantes, podemos observar que dicha cantidad es 28 en ODC y 13 en Beizer.En otras palabras, en ODC el 65 % de los defectos fueron clasificados igual portodos los estudiantes y solo el 30 % en Beizer. Ademas, relacionado a este valor,se observa que en ODC hasta 8 estudiantes clasificaron un defecto con el mismovalor en sus atributos. Sin embargo, en Beizer, en casi todos los casos que undefecto fue clasificado con el mismo valor por todos los estudiantes, la cantidadde estudiantes que clasifico dicho defecto es 2. Solamente en un defecto de los43 defectos analizados, dicha cantidad asciende a 3.

Estos analisis realizados sobre los resultados de los programas 1 y 2 muestran

5.4. RECOMENDACIONES DE USO 75

que clasificar en ODC es mas simple que clasificar en la taxonomıa de Beizer.De todas formas, se puede apreciar que no es sencillo clasificar en ninguna delas dos taxonomıas, ya que en ODC el 45 % de los defectos fueron clasificadosde distinta forma por los estudiantes y en la taxonomıa de Beizer dicho valorasciende al 70 %.

5.4. Recomendaciones de uso

En los artıculos y reportes presentados en la seccion 5.2, se encuentran distin-tas recomendaciones de uso sobre las taxonomıas o explicacion sobre la experien-cia vivida al aplicar las mismas. A continuacion se presentan las recomendacionesy experiencias reportadas.

Una de las lecciones aprendidas en [Nar03], es que para que el proceso deprevencion de defectos sea realmente efectivo, el equipo de software debe estaraltamente entrenado en el uso de la taxonomıa (en este estudio se utilizo lataxonomıa de Beizer). Inicialmente recomiendan tener un equipo experto comosoporte inicial, hasta que el equipo este totalmente capacitado en el uso de lataxonomıa elegida.

En [Nar03] tambien consideran escencial el uso de una herramienta de regis-tro y seguimiento de defectos segun la taxonomıa elegida, que ademas permitaobtener resultados estadısticos automaticamente, facilitando de esta forma elproceso de clasificacion y analisis.

Para la clasificacion de defectos, en [She09] explica que eligieron utilizar ODCporque es un mecanismo generico que no esta atado a un dominio especıfico, y deesta manera es mas facil comparar los resultados de distintos proyectos. Otra delas razones de elegir ODC fue la facil capacidad de integracion en cualquier fasedel ciclo de vida del producto, incluso en organizaciones que tienen establecidoun proceso estructurado.

En [She09] ademas se presentan limitaciones encontradas al aplicar ODC.En algunos casos les resulto difıcil clasificar debido a que ODC es demasiadoabtracto. Plantean dudas sobre la propiedad de mutuo-exclusion del Tipo dedefecto (consideran que un defecto puede pertenecer a mas de un Tipo de de-fecto). Han encontrado contradicciones, es decir, casos de que un mismo defectose clasifico distinto por dos personas distintas, lo cual puede resultar en analisisfallidos.

En [MHPD99] y [SL06] tambien se presentan las clasificaciones inconsisten-tes como una falla potencial. Si bien su experiencia sugiere que la mayorıa delas personas necesitan algunas horas para aprender a clasificar correctamente,los autores recomiendan un perıodo de entrenamiento mas largo, ademas demonitorear la calidad de los datos de la clasificacion por expertos en el area.

En la experiencias presentadas en [KS01], notaron que clasificar correcta-mente es una tarea con dificultades. Recomiendan una etapa de entrenamientoextensa antes de aplicar formalmente una taxonomıa.

En el experimento presentado en [VH09], notaron que clasificar en ODC esmas facil que clasificar en Beizer. En ODC, el conjunto de verificadores gene-ralmente clasifico el mismo defecto bajo el mismo tipo. Sin embargo, en Beizerlos resultados de la clasificacion eran distintos para la mayorıa de los verifica-dores. Los autores concluyen que es mejor que la clasificacion sea realizada porexpertos y no por verificadores principiantes.


5.5. Conclusiones

En este capıtulo se presenta un conjunto variado de usos de las taxonomıasen la industria y en la academia, junto a los reportes de uso encontrado paracada caso.

En el Cuadro 5.7, se puede observar los tipos de uso existentes por reportecitado. Los tipos posibles de usos son los siguientes:

[1] Prevencion de Defectos

[2] Control de Pruebas e Inspecciones

[3] Plan de Pruebas

[4] Reduccion de Defectos de Campo

[5] Evaluar y Mejorar Cambios del Proceso

[6] Soporte de Root Cause Analysis

[7] Desarrollo, Extensiones y Mejoras de Taxonomıas

[8] Experimentos

Reporte [1] [2] [3] [4] [5] [6] [7] [8][Nar03] 4

[She09] 4

[CP02] 4

[BMK02] 4 4

[Chu08] 4

[BHC+93] 4

[Chi06] 4

[FDK05] 4

[MHPD99] 4

[SL06] 4

[BKS98] 4

[Hub98] 4

[BS87] 4

[JV03] 4

[BLV01] 4

[KS01] 4

[LR97] 4

[VH09] 4

[Mye78] 4

[WRBM97] 4

Cuadro 5.7: Tipos de Uso de Taxonomıas por Reporte

Por otro lado, en el Cuadro 5.8, se puede observar los resultados obtenidospor reporte citado. Los posibles resultados obtenidos son los siguientes:

[A] Identificacion de errores sistematicos o causas

5.5. CONCLUSIONES 77

[B] Reduccion de defectos

[C] Identificacion de areas de potencial mejora y mejora del proceso

[D] Reduccion de costos

[E] Definicion e integracion de taxonomıa

[F] Propuestas de mejoras de taxonomıas

[G] Evaluar tecnicas de verificacion

[H] Recomendaciones de uso y experiencia vivida

Reporte [A] [B] [C] [D] [E] [F] [G] [H][Nar03] 4 4 4

[She09] 4 4 4

[CP02] 4 4

[BMK02] 4 4 4 4

[Chu08] 4 4

[BHC+93] 4 4

[Chi06] 4 4

[FDK05] 4

[MHPD99] 4 4 4

[SL06] 4 4

[BKS98] 4 4

[Hub98] 4 4

[KS01] 4

[BS87] 4

[JV03] 4

[BLV01] 4

[KS01] 4

[LR97] 4

[VH09] 4 4

[Mye78] 4

[WRBM97] 4

Cuadro 5.8: Resultados de Uso de Taxonomıas por Reporte

Definitivamente, clasificar defectos mediante una taxonomıa no es una tareasencilla. Es necesario una etapa de aprendizaje extensa que incluya varias horasde entrenamiento y retroalimentacion por parte de un experto en la taxonomıaen cuestion. El hecho de no lograr un buen aprendizaje y aplicacion de la taxo-nomıa a utilizar, afecta negativamente la capacidad de obtencion de resultadosexactos y por lo tanto, afecta tambien la correctitud de los analisis posteriores.

Entre los usos mas frecuentes de las taxonomıas se encuentran la reduccionde defectos, la prevencion de defectos, la planificacion, evaluacion y mejora de laactividad de verificacion y del proceso. En el capıtulo se presentan varios reportessobre dichos usos en la academia y en la industria, donde las taxonomıas songeneralmente utilizadas por organizaciones con procesos CMMI de nivel superiora 3.


En la industria, las organizaciones generalmente comienzan utilizando unataxonomıa (usualmente ODC), y con el correr del tiempo la van adaptando,extendiendo y mejorando segun su entorno, sus necesidades y la experienciavivida. Resultados de este proceso fueron reportados por las empresas Motorolay Bellcore, entre otras.

Las taxonomıas con valores de atributos ambiguos (por ejemplo, Beizer) ocon valores de atributo bien definidos pero muy extensas (por ejemplo, IEEE),practicamente no son utilizadas en la industria. No se encontraron reportesde uso de las taxonomıas de Beizer, IEEE, Kaner, ni Binder en la industria.Ademas, escasos reportes de uso de las mismas se encontraron en la academia.

De todas formas, el uso de una taxonomıa sin un analisis posterior adecuadono es de utilidad.

Capıtulo 6

Taxonomıas para DesarrolloIndividual y Organizacional

Actualmente, el grupo de Ingenierıa de Software de la Facultad de Ingenie-ria, Universidad de la Republica, se encuentra trabajando en el estudio de laefectividad y el costo de tecnicas de verificacion [VH09, VMBH09, VAL+09]. Enparticular, de tecnicas de verificacion unitaria. En este contexto resulta de graninteres mostrar los resultados de efectividad y costo de las tecnicas discriminan-do segun el tipo de defecto.

Es a partir de este estudio, que actualmente esta realizando el grupo deIngenierıa de Software, que surge la necesidad de analizar los posibles atributos ypropiedades que debe tener una taxonomıa a ser utilizada durante la verificacionunitaria.

En una organizacion el desarrollo de sistemas de software se realiza en equi-po. Un equipo esta compuesto por un conjunto de individuos, y todos juntosejecutan un proceso de desarrollo a nivel organizacional para lograr cumplircon el desarrollo segun los objetivos planteados. En particular, cada individuorealiza ciertas tareas durante la fase de implementacion como diseno de un mo-dulo, codificacion, liberacion de un modulo, entre otras. Es decir, durante lafase de implementacion, cada individuo lleva a cabo su proceso de desarrolloindividual, que paralelamente se esta ejecutando con el proceso de desarrollode la organizacion. Como la deteccion de defectos no surge unicamente durantela actividad de verificacion sino durante todo el proceso de desarrollo, resultainteresante construir una taxonomıa de defectos especıfica para un proceso dedesarrollo individual, considerando que durante dicho proceso se aplican tecnicasde verificacion unitaria.

De esta forma es que resulta de interes diferenciar los componentes necesa-rios para una taxonomıa a ser utilizada por una persona durante el desarrolloindividual de los componentes necesarios para una taxonomıa a ser utilizadapor un equipo a nivel organizacional. La taxonomıa de desarrollo individual seaplica de forma personal, buscando la mejora individual. Los defectos inyecta-dos por un individuo serıan registrados y clasificados segun una taxonomıa dedesarrollo individual. La otra taxonomıa busca los defectos que se escapan a losindividuos y defectos que surgen de la integracion, entre otros. Es importanterecordar que en la literatura no se encuentran reportes de uso de taxonomıas

79

80 CAPITULO 6. DESARROLLO INDIVIDUAL Y ORGANIZACIONAL

para desarrollo individual, solamente a nivel organizacional, a menos del Perso-nal Software Process [Hum05] que usa una adaptacion de la taxonomıa de IBMy que no analiza los resultados de su uso.

En la seccion 6.1 se realiza un analisis de atributos para una taxonomıa segunel proceso de desarrollo individual u organizacional. A partir de los resultados delanalisis, en la seccion 6.2 se brindan lineamientos para construir una taxonomıaespecıfica para un proceso de desarrollo individual.

6.1. Analisis de Atributos

Para poder crear una taxonomıa especıfica segun el proceso de desarrollo in-dividual u organizacional, es necesario discutir que atributos son necesarios parael desarrollo individual y cuales son necesarios a nivel organizacional. Mediantela actividad de verificacion, cada proceso de desarrollo (individual y organiza-cional) se relaciona fuertemente con distintos niveles de prueba. Los niveles deprueba existentes son: Unitario, Integracion y Sistema. El desarrollo a nivel or-ganizacional se relaciona a los niveles de prueba de integracion y de sistema,mientras que el desarrollo individual esta asociado a las pruebas unitarias. Acontinuacion se presentan brevemente los tres niveles de prueba.

El nivel de prueba unitario propone verificar unidades de software de formaaislada. Una unidad puede ser un metodo, una clase o un conjunto pequeno declases que forman un modulo. La idea es escribir casos de prueba para cada fun-cion no trivial o metodo en el modulo de forma que cada caso sea independientedel resto.

El nivel de prueba de integracion se refiere a las pruebas que se realizan unavez que se han aprobado las pruebas unitarias. El objetivo es verificar la comu-nicacion entre dos o mas componentes. Las pruebas de integracion se focalizanen los defectos de las interfaces y se utilizan en la integracion de modulos, sub-sistemas o sistemas. Consiste en realizar pruebas para verificar que un conjuntode partes de software funcionan bien juntos.

El nivel de prueba de sistema tiene como objetivo verificar el sistema softwareen su totalidad, para comprobar si el mismo cumple con sus requerimientos.El mismo abarca las pruebas funcionales, de usabilidad, de rendimiento, deseguridad, entre otras.

Existen diferencias en como se practica cada nivel de prueba en la industria.Las pruebas unitarias de una unidad generalmente son disenadas y ejecutadaspor el desarrollador de la misma. Ademas, la correccion de los defectos encon-trados por las pruebas unitarias generalmente tambien es realizada por el mismodesarrollador. Existen algunos casos en donde la verificacion unitaria es cruzada.Es decir, el diseno y ejecucion de pruebas unitarias no es realizada por el mismodesarrollador, sino por otro. De todas formas, este ultimo caso no es comun enla industria.

La verificacion a nivel de integracion y sistema no se practica de la mismaforma que la verificacion unitaria. En algunos casos las pruebas son disenadas yejecutadas por un equipo de verificadores especializado, que no esta compuestopor los implementadores del sistema. El equipo de verificadores puede ser internoa la empresa que esta desarrollando el sistema o tercerizado. Aquı los defectosencontrados son reportados y luego corregidos por el equipo de implementacion.En otros casos, las pruebas a nivel de integracion y sistema son disenadas y

6.1. ANALISIS DE ATRIBUTOS 81

ejecutadas por el mismo equipo de desarrolladores que construyo el sistema. Seesta tendiendo cada vez mas a que la implementacion y la verificacion a nivelde sistema sea realizada por equipos distintos.

El objetivo de esta seccion es realizar un analisis de atributos segun el procesode desarrollo individual y organizacional. Este analisis permite determinar paracada uno de dichos procesos de desarrollo, que atributos son indispensables ono para una taxonomıa. El analisis se realiza de la siguiente manera. Para cadauno de atributos propuestos en el marco de comparacion, se discute sobre losbeneficios de incluir o no el mismo, indicando finalmente que tan necesaria es lainclusion de dicho atributo.

Definimos una escala que determina que tan necesaria es la inclusion de unatributo en una taxonomıa.

Alta Resulta indispensable, necesario o muy conveniente incluir el atributo enla taxonomıa.

Depende La necesidad de inclusion del atributo en la taxonomıa esta determi-nada por ciertas condiciones. Si dichas condiciones se cumplen, entonces esnecesario o conveniente incluir el atributo en la taxonomıa. De lo contrariono resulta indispensable incluir el atributo en la taxonomıa.

Baja No resulta indispensable o necesario incluir el atributo en la taxonomıa.

A continuacion se presenta la discusion para cada atributo del marco decomparacion. Recordar que la verificacion unitaria esta fuertemente asociadaal proceso de desarrollo individual, y que las pruebas de integracion y sistemaestan asociadas al proceso de desarrollo a nivel organizacional.

Ubicacion sospechada

Para el desarrollo individual este atributo sirve de ayuda para detectar undefecto en el codigo. Como generalmente en la verificacion unitaria, la correccionde defectos es realizada por el mismo desarrollador encargado de disenar y eje-cutar las pruebas, no resulta necesario incluir este atributo. Puede existir alguncaso de verificacion unitaria cruzada, en donde tal vez sea de utilidad conoceresta ubicacion. De todas formas no consideramos que sea necesario registrar for-malmente esta informacion, podrıa utilizarse mediante una simple notificacional desarrollador encargado de la deteccion y correccion del defecto. Por lo tan-to, para el desarrollo individual, proponemos clasificar el atributo “Ubicacionsospechada” con el valor “Baja” de la escala.

Para el desarrollo a nivel organizacional, la inclusion de dicho atributo de-pende del modo en que se esta aplicando la verificacion. Se considera que elmismo colabora en la deteccion del defecto para la correccion, siempre y cuandola sospecha sea “buena”. Si la verificacion es realizada por un equipo que noparticipo en la implementacion, la confianza de la ubicacion sospechada no vaa ser alta. Es decir, en este caso no tendrıa sentido registrar dicho atributo.Sin embargo, si la verificacion es realizada por el mismo equipo que implementoel sistema, la ubicacion sospechada brindarıa mayor confianza y podrıa ser deutilidad para disminuir el tiempo de deteccion de defecto. Por lo tanto, para eldesarrollo a nivel organizacional, proponemos clasificar el atributo “Ubicacionsospechada” con el valor “Depende” de la escala.


Ubicacion real

Tanto para el desarrollo individual como organizacional, la inclusion de dichoatributo resulta muy conveniente ya que el mismo es frecuentemente utilizadoen los analisis que se presentan en la academia y en la industria. Por ejemplo,el mismo permite identificar las areas y/o productos con mayor densidad dedefectos. Por lo tanto, para ambos procesos de desarrollo, proponemos clasificarel atributo “Ubicacion real” con el valor “Alta” de la escala.

Fase de provocacion de la falla

Si bien este atributo no es muy utilizado en la industria (de las seis taxono-mıas presentadas, solo se encuentra como atributo en la taxonomıa propuestapor la IEEE), nosotros consideramos que es importante y beneficioso registrarel mismo. Conocer la fases en las que se provocan fallas permite mejorar el desa-rrollo y el proceso. Entre otras cosas, se puede mejorar el proceso para lograruna deteccion temprana de defectos. Por lo tanto, para ambos procesos de desa-rrollo, proponemos clasificar el atributo “Fase de provocacion de la falla” con elvalor “Alta” de la escala.

Fase de inyeccion

Si bien este atributo no aparece en las taxonomıas estudiadas, el PersonalSoftware Process utiliza la fase de inyeccion para luego analizar la distribucionde defectos segun cada fase. De esta manera el programador puede mejorarsu proceso personal. En general, conocer dicha distribucion permite mejorarcualquier proceso de desarrollo de software. Por lo tanto, para ambos procesosde desarrollo, proponemos clasificar el atributo “Fase de inyeccion” con el valor“Alta” de la escala.

Sıntoma

Este atributo describe lo que se observa al momento de la falla y sirve deayuda para ubicar el defecto para poder corregirlo. Como generalmente en laverificacion unitaria, la correccion de defectos es realizada por la misma perso-na encargada de disenar y ejecutar las pruebas, no resulta necesario registrareste atributo a nivel individual. Puede existir algun caso de verificacion unitariacruzada, en donde tal vez sea de utilidad conocer el sıntoma. De todas formasno consideramos que sea necesario registrar formalmente esta informacion, po-drıa utilizarse mediante una simple notificacion al desarrollador encargado dela deteccion y correccion del defecto. Por lo tanto, para el desarrollo individual,proponemos clasificar el atributo “Sıntoma” con el valor “Baja” de la escala.

Para el desarrollo a nivel organizacional, es conveniente incluir este atributoya que el mismo colabora en la deteccion del defecto para la correccion, sinimportar en este caso si la verificacion es realizada por el mismo equipo que im-plemento el sistema o no. Por lo tanto, para el desarrollo a nivel organizacional,proponemos clasificar el atributo “Sıntoma” con el valor “Alta” de la escala.

6.1. ANALISIS DE ATRIBUTOS 83

Tipo

Este atributo es muy utilizado en los analisis presentados en la academia y enla industria. Por ejemplo, en la academia el mismo es utilizado para discriminarlos resultados de los experimentos de evaluacion de tecnicas de verificacion portipo de defecto. Por lo tanto, para ambos procesos de desarrollo, proponemosclasificar el atributo “Tipo” con el valor “Alta” de la escala.

Mecanismo de provocacion de la falla

Este atributo indica cual es la actividad que se estaba realizando cuando seproduce la falla. El mismo es muy utilizado en los analisis que se presentan enla academia y en la industria. Por ejemplo, en la industria se usa este atributopara el control de pruebas e inspecciones, para la reduccion de defectos de cam-po, entre otros. Por lo tanto, para ambos procesos de desarrollo, proponemosclasificar el atributo “Mecanismo de provocacion de la falla” con el valor “Alta”de la escala.

Mecanismo de inyeccion

Este atributo se refiere a como se inyecta el defecto. Si bien resulta intere-sante conocer si los defectos son inyectados por omisiones, por hacer las cosasincorrectamente o por no hacerlas de la mejor manera, consideramos que la utili-dad de este atributo depende del avance que tenga una organizacion respecto alanalisis por tipo de defecto. Por lo tanto, para ambos procesos de desarrollo, pro-ponemos clasificar el atributo “Mecanismo de inyeccion” con el valor “Depende”de la escala.

Impacto del defecto

Para ambos procesos de desarrollo, consideramos que la inclusion del mismodepende de los analisis posteriores a realizarse. Por ejemplo, si se desea aplicaruna tecnica de prevencion de defectos, se podrıa identificar las areas a atacarconociendo cuales son las areas con mayor cantidad de defectos de alto impacto.Si no se desea realizar un analisis de ese estilo, seguramente no sea necesarioo util incluirlo. Por lo tanto, para ambos procesos de desarrollo, proponemosclasificar el atributo “Impacto del defecto” con el valor “Depende” de la escala.

Causa (Error)

Si bien resulta muy interesante conocer cuales son los errores humanos quese cometen para poder eliminar los defectos de raız, consideramos que es muydifıcil registrar este atributo correctamente. Hace falta mucho trabajo aun enel area para poder pensar en un analisis que considere las causas humanas. Porlo tanto, para ambos procesos de desarrollo, proponemos clasificar el atributo“Causa (Error)” con el valor “Bajo” de la escala.

Fuente responsable

Para ambos procesos de desarrollo, consideramos que la inclusion del mismodepende de los analisis posteriores a realizarse. Por ejemplo, si se desea discri-minar los defectos segun si los mismos fueron desarrollados “en casa”, si estan


en librerıas o si son externos, es necesario incluir este atributo. De lo contrario,la inclusion del mismo no serıa indispensable. Por lo tanto, para ambos procesosde desarrollo, proponemos clasificar el atributo“Fuente responsable” con el valor“Depende” de la escala.

Recorreccion

Este atributo se refiere a si el defecto se inyecta durante la correccion de otrodefecto. El mismo podrıa ser utilizado en algun analisis especıfico, pero no con-sideramos que sea indispensable incluirlo en una taxonomıa. Por lo tanto, paraambos procesos de desarrollo, proponemos clasificar el atributo “Recorreccion”con el valor “Baja” de la escala.

Impacto de la falla, Probabilidad de ocurrencia, Gravedad y Prioridad

El atributo “Impacto de la falla” se refiere al impacto que produce la fallaen el producto al momento en que ocurre la falla. “Probabilidad de ocurrencia”se refiere a la probabilidad estimada de ocurrencia de la falla. El atributo “Gra-vedad” se refiere a que tan grave es la falla que ocurre. Y “Prioridad” se refierea que prioridad tiene el defecto de ser corregido. Si bien estos atributos tienendistinto significado, todos pueden utilizarse con el mismo objetivo de guiar latoma de decisiones sobre en que orden corregir los defectos. Como generalmenteen la verificacion unitaria todos los defectos encontrados se corrigen inmediata-mente, sin importar el impacto de la falla, ni la probabilidad de ocurrencia, ni lagravedad, ni la prioridad de los mismos, no le encontramos demasiado sentido aregistrar dichos atributos. Por lo tanto, para el desarrollo individual, propone-mos clasificar los atributos “Impacto de la falla”, “Probabilidad de ocurrencia”,“Gravedad” y “Prioridad” con el valor “Baja” de la escala.

Para el desarrollo a nivel organizacional, consideramos que la inclusion delos mismos depende del uso. Si alguno de dichos atributos se desea utilizarpara darle prioridad a los defectos en su correccion, es conveniente incluir losatributos elegidos. Pero al ser varios los atributos que se pueden utilizar paraguiar la correccion, no es necesario incluirlos todos. Si bien todos pueden serutilizadas, consideramos que el atributo “Prioridad” es el mas indicado paraguiar el orden en que los defectos son corregidos. Por lo tanto, para el desarrolloa nivel organizacional, proponemos clasificar el atributo “Prioridad” con el valor“Alta” de la escala y proponemos clasificar los atributos “Impacto de la falla”,“Probabilidad de ocurrencia” y “Gravedad” con el valor “Depende” de la escala.

Costo de deteccion y Costo de correccion real

Para ambos procesos de desarrollo, consideramos que la inclusion de ambosatributos depende de los analisis posteriores a realizarse. Siempre que se quierarealizar un analisis de costos (en el sentido de tiempo) de deteccion y correccionde defectos, es indispensable incluir estos atributos. De lo contrario, la inclu-sion de los mismos no resulta necesaria. Por lo tanto, para ambos procesos dedesarrollo, proponemos clasificar los atributos “Costo de deteccion” y “Costo decorreccion real” con el valor “Depende” de la escala.

6.2. TAXONOMIA PARA DESARROLLO INDIVIDUAL 85

Costo estimado de correccion

Como generalmente en la verificacion unitaria todos los defectos encontradosse corrigen inmediatamente, no tiene sentido incluir este atributo. Por lo tanto,para el desarrollo individual, proponemos clasificar el atributo “Costo estimadode correccion” con el valor “Baja” de la escala.

Para el desarrollo a nivel organizacional, si bien el mismo podrıa ayudar aconstruir el cronograma no lo consideramos indispensable. Por lo tanto, parael desarrollo a nivel organizacional, proponemos clasificar el atributo “Costoestimado de correccion” con el valor “Baja” de la escala.

En el Cuadro 6.1, se presenta la clasificacion en la escala para cada atributoplanteado en la meta taxonomıa, acorde a lo discutido segun el proceso dedesarrollo individual y organizacional.

Atributos Individual OrganizacionalUbicacion sospechada Baja DependeUbicacion real Alta AltaFase de provocacion de la falla Alta AltaFase de inyeccion Alta AltaSıntoma Baja AltaTipo Alta AltaMecanismo de provocacion de la falla Alta AltaMecanismo de inyeccion Depende DependeImpacto de la falla Baja DependeImpacto del defecto Depende DependeCausa (Error) Baja BajaFuente responsable Depende DependeRecorrecion Baja BajaProbabilidad de ocurrencia Baja DependeGravedad Baja DependePrioridad Baja AltaCosto de deteccion Depende DependeCosto estimado de correccion Baja BajaCosto de correccion real Depende Depende

Cuadro 6.1: Clasificacion de Atributos en la escala, segun el Proceso de Desa-rrollo Individual y Organizacional

6.2. Taxonomıa para Desarrollo Individual

A partir del analisis de la seccion anterior, presentamos lineamientos parala construccion de una taxonomıa especıfica para un proceso de desarrollo in-dividual. Los atributos que recomendamos incorporar en dicha taxonomıa sonaquellos cuyo valor en la escala es “Alta”: Ubicacion real, Fase de provocacionde la falla, Fase de inyeccion, Tipo y Mecanismo de provocacion de la falla. Acontinuacion se presenta una discusion para cada atributo.


Ubicacion real

Como se definio anteriormente, este atributo se refiere al lugar donde seencuentra el defecto realmente. Puede referirse a la actividad responsable deconstruir el producto que contiene el defecto, o a un producto propiamentedicho.

Este atributo se encuentra presente en las taxonomıas de HP, Binder, IEEEy ODC, bajo el nombre de Origen, Fuente o Target. En todos estos casos, el con-junto de valores posibles incluye valores que representan la actividad responsablede construir el producto defectuoso. Por ejemplo, en la taxonomıa de HP, el con-junto de valores posibles para este atributo es: Especificaciones/Requerimientos,Diseno, Codigo, Entorno/Soporte, Documentacion y Otros. Los valores en lasotras taxonomıas son muy similares, tal vez un poco mas especıficos en la taxo-nomıa de IEEE, pero la diferencia entre ellos es poca.

Nos resulta correcto que una taxonomıa de desarrollo individual contengaeste tipo de valores, pero ademas nos resulta interesante que se especifique masen los valores de dicho atributo. Es decir, que ademas de la actividad responsablede forma generica, se indique la sub-actividad responsable y/o el producto quecontiene el defecto. Por ejemplo, si un defecto se debe a que en la clase “Y”del modulo “X” existe una funcion con una asignacion de una variable con unvalor incorrecto, la clasificacion para el atributo Ubicacion Real serıa: actividadCodificacion, sub-actividad Codificacion del modulo “X” y producto clase “Y”.

Incluyendo tambien las sub-actividades y productos, el desarrollador puedeconocer los productos construidos por el que contienen la mayorıa de los defectos,ademas de conocer las actividades y sub-actividades en las que participa quedebe mejorar.

Fase de provocacion de la falla

Este atributo se refiere a la fase en la que se encuentra el proyecto en elmomento en que se provoca la falla. El mismo solo se encuentra presente enla taxonomıa propuesta por la IEEE bajo el nombre de Fase del Proyecto ypresenta valores como: Requerimientos, Diseno, Implementacion, Verificacion yLiberacion, entre otros.

Para una taxonomıa de desarrollo individual, proponemos que al momentode clasificar, un individuo pueda registrar tanto valores que representen fasesdel proceso individual del desarrollador, como fases del proceso organizacional.Es decir, un desarrollador en su proceso individual, tiene las fases de requeri-mientos, diseno, implementacion, etc. de una unidad. La taxonomıa debe sercapaz de brindarle este tipo de valores para este atributo, ademas de valoresque representen fases del proceso organizacional.

Fase de inyeccion

Como se definio anteriormente, se refiere a la fase en la que se encuentra elproyecto en el momento en que se inyecta el defecto. Si bien dicho atributo noesta presente en ninguna de las taxonomıas presentadas, conocer el mismo per-mite observar la distribucion de defectos inyectados por fase. Esta distribucionpermite mejorar cualquier proceso de desarrollo de software.

Recomendamos que este atributo contenga los mismos valores que el atributofase de provocacion de la falla. Es decir, que se puedan registrar tanto fases del

6.2. TAXONOMIA PARA DESARROLLO INDIVIDUAL 87

proceso individual del desarrollador como fases del proceso organizacional.El hecho de que se registren tanto fases del proceso individual como fases

del proceso organizacional, es lo que permite diferenciar y analizar los defectosinyectados por el desarrollador de los defectos inyectados por otros miembrosdel equipo de desarrollo. Esto permite que el desarrollador pueda enfocarse enla mejora de su proceso personal.

Tipo

El tipo de defecto es el unico atributo que se encuentra en todas las taxono-mıas presentadas. Es el atributo que esta representado de forma mas variada,con valores posibles que van desde un conjunto de cardinalidad 8 en la taxonomıade ODC, pasando por un conjunto de 72 valores posibles en la IEEE, superandolas 150 opciones en la taxonomıa de Beizer. En algunos casos el conjunto devalores es jerarquico, en otros no.

Consideramos que para obtener buenos resultados en los analisis, el conjuntode valores posibles no debe ser muy amplio. Como se puede observar en diversosexperimentos, clasificar con Beizer es mucho mas difıcil que clasificar con ODC,y gran parte de ello se debe que la cardinalidad del conjunto de valores posiblespara el atributo tipo de ODC es mucho menor que en Beizer. Recomendamosutilizar un conjunto de valores reducido y manejable, pero en este momentono podemos decir la cardinalidad optima del conjunto de valores posibles. Unataxonomıa jerarquica puede ser una buena idea, ya que resulta interesante refinarel conjunto de valores. De todas formas aun falta trabajo para poder derminarsi efectivamente la jerarquıa es una buena opcion y queda pendiente su estudio.

No entramos en detalle de cuales son los valores que debe contener el conjun-to, ya que no disponemos de las herramientas y experimentos suficientes comopara determinar que valores son los mas apropiados para este atributo.

Mecanismo de provocacion de la falla

Como se definio anteriormente, se refiere a como se provoca la falla, es decir,mediante que actividad. Este atributo se encuentra presente en las taxonomıasde la IEEE y ODC, bajo el nombre de Actividad del Proyecto o Trigger. Porejemplo, en la taxonomıa de la IEEE, el conjunto de valores posibles para esteatributo es: Analisis, Revision, Auditorıa, Inspeccion, Testing, Validacion, entreotros. En ODC, los valores se focalizan en tipos de pruebas. Por ejemplo, para laverificacion unitaria, el conjunto de valores posibles para este atributo en ODCes: Prueba de Cubrimiento, Prueba Secuencial, Prueba de Interaccion, Pruebade Variacion, Cobertura de Camino Simple y Cobertura de Combinacion deCaminos.

Como planteamos anteriormente, la verificacion unitaria esta fuertementeasociada al desarrollo individual. Por lo tanto es fundamental que este atributopermita registrar todas las posibles tecnicas de verificacion unitaria. Ademas,es necesario tambien que contenga valores de otras actividades vinculadas alproceso que no sean tecnicas de verificacion (como Requerimientos, Diseno, Co-dificacion, etc.), ya que las fallas no se provocan unicamente durante la ejecucionde pruebas, sino durante todo el proceso de desarrollo.


Capıtulo 7

Conclusiones y Trabajos aFuturo

En este trabajo se busca realizar un estudio del estado del arte de taxonomıasy de la practica de las mismas. Para ello se presenta la meta taxonomıa pro-puesta por Freimut y se presentan las taxonomıas mas relevantes. Se desarrollaun marco de comparacion original y se comparan las taxonomıas presentadascontra el marco. Se realiza un estudio del estado del arte de la practica de las ta-xonomıas en la industria y en la academia. Finalmente se brindan lineamientospara la construccion de una taxonomıa especıfica para el proceso de desarrolloindividual.

En la seccion 7.1 se presentan las conclusiones y en la 7.2 el trabajo a futuro.

7.1. Conclusiones

Presentamos la meta taxonomıa de Freimut, donde se analizan posibles atri-butos y propiedades de taxonomıas, sus distintas estructuras y se expone unaguıa de como incorporar una taxonomıa a un proceso. Planteamos una discusionen la que se critican algunos aspectos de dicha meta taxonomıa.

Se realiza un estudio del estado del arte en lo que refiere a taxonomıas yse presentan las taxonomıas mas relevantes, las cuales brindan un panoramacompleto de las taxonomıas existentes tanto en la academia como en la indus-tria. Las taxonomıas propuestas por Hewlett-Packard, IBM (Orthogonal DefectClassification) y por la IEEE son utilizadas en la industria. Para las taxonomıasde Kaner, Binder y Beizer no se encontraron artıculos de su uso en la industria.

Desarrollamos y presentamos un marco de comparacion original para taxono-mıas de defectos. Este marco extiende y mejora las ideas de Freimut. El mismoesta compuesto por dos vistas relevantes: atributos y propiedades. La primervista es util para evaluar las caracterısticas de los defectos que son consideradasen una taxonomıa dada. La segunda vista es util para evaluar las cualidades ylas restricciones de los atributos.

Utilizando el marco evaluamos y comparamos las seis taxonomıas presenta-das. Los resultados muestran que cada taxonomıa considera distintas caracte-risticas de un defecto. Algunas de ellas son mas completas que otras desde elpunto de vista de atributos. Sin embargo, aquellas menos completas tienen un

89

90 CAPITULO 7. CONCLUSIONES Y TRABAJOS A FUTURO

conjunto mas amplio de valores para sus atributos, por ejemplo, Beizer y Bin-der. El analisis tambien muestra que hay diferencias en las propiedades entre lastaxonomıas. Tanto el marco desarrollado como la comparacion de las taxono-mıas se publicaron en el XV Congreso Argentino de Ciencias de la Computacion[VGH09] y una version extendida se publico en un reporte tecnico PEDECIBA[GV09].

Se estudia el estado de la practica respecto a las taxonomıas en la industriay en la academia.

Se presentan los resultados y beneficios obtenidos gracias al uso de taxono-mıas de defectos y analisis de resultados de las clasificaciones. Los resultadosobtenidos en distintos reportes reflejan que se pueden identificar los errores sis-tematicos, reducir los defectos, identificar areas de mejora potencial, reducir loscostos del proyecto y evaluar tecnicas de verificacion entre otros.

Tambien, como parte de este trabajo, se analizan los resultados obtenidosal clasificar defectos por varios estudiantes de grado en un experimento formalrealizado por el grupo de Ingenierıa de Software de la Facultad de Ingenierıa.

Los reportes de uso de taxonomıas y el analisis de los resultados obtenidos enel experimento formal muestran que clasificar defectos mediante una taxonomıaes una tarea difıcil. La etapa de aprendizaje es extensa, con varias horas de en-trenamiento. La calidad de los resultados de la clasificacion depende fuertementede como se aplique la taxonomıa elegida, por lo que no lograr un buen dominioy aplicacion de la misma afecta significativamente la correctitud y validez delos resultados de los analisis posteriores. De todas formas, aunque se logre unexcelente dominio de una taxonomıa, la aplicacion de la misma sin un analisisposterior adecuado no es de utilidad.

En una organizacion el desarrollo de sistemas de software se realiza en equi-po. Un equipo esta compuesto por un conjunto de individuos, y todos juntosejecutan un proceso de desarrollo a nivel organizacional para lograr cumplir conel desarrollo segun los objetivos planteados. En particular, durante la fase deimplementacion, cada individuo lleva a cabo su proceso de desarrollo indivi-dual, que paralelamente se esta ejecutando con el proceso de desarrollo de laorganizacion. Con el objetivo de crear una taxonomıa que pueda ser aplicadadurante el proceso desarrollo personal, en particular durante la verificacion uni-taria, se realiza un analisis de posibles atributos y propiedades que debe teneruna taxonomıa a ser utilizada en dicho contexto. En dicho analisis se discutenlas diferencias que existen en los procesos personales de desarrollo y los procesosa nivel organizacional. En el analisis, para cada uno de atributos propuestos enel marco de comparacion, se discute sobre los beneficios de incluir o no el mismo,indicando finalmente cual es la necesidad de incluir dicho atributo en una taxo-nomıa de desarrollo personal y en una taxonomıa de desarrollo organizacional.

A partir de los resultados del analisis, se brindan lineamientos para construiruna taxonomıa especıfica para un proceso de desarrollo individual. En dichataxonomıa proponemos incluir los atributos Ubicacion real, Fase de provocacionde la falla, Fase de inyeccion, Tipo y Mecanismo de provocacion de la falla.

Finalmente, creemos que la mayorıa de los objetivos propuestos para estetrabajo fueron logrados con exito y que se logro generar un compendio de co-nocimientos muy valioso para aplicar tanto en proyectos academicos como enproyectos industriales.

7.2. TRABAJOS A FUTURO 91

7.2. Trabajos a Futuro

Resulta interesante analizar las propiedades de cada taxonomıa presentadaluego de un amplio perıodo de uso de las mismas. De esta forma, se podrıaclasificar con mayor precision las propiedades de Completitud en valores deatributos, Tiempo de aprendizaje y Tiempo de clasificacion.

Resulta necesario profundizar en la taxonomıa propuesta para un procesode desarrollo individual. Si bien proponemos los atributos que debe contemplary realizamos una discusion de que tipo de valores debe brindar cada atributo,para definir una taxonomıa correctamente es necesario definir formalmente cadaatributo y sus conjuntos de valores posibles, incluyendo para cada valor, unadescripcion del mismo y por lo menos un ejemplo de un defecto que clasifica condicho valor. Ademas, es importante que la misma cumpla con las propiedadesdeseables de una taxonomıa planteadas en la meta taxonomıa.

Ademas, resulta de interes aplicar la taxonomıa propuesta para desarrolloindividual en el estudio de la efectividad y el costo de tecnicas de verificacionunitaria que se encuentra realizando actualmente el grupo de Ingenierıa de Soft-ware. De esta forma se estarıa colaborando en lograr la discriminacion de laefectividad segun el tipo de defecto.

Finalmente, se tiene pensado redactar un artıculo que contemple el estadode la practica actual de las taxonomıas y que incluya las dificultades que surgendurante la aplicacion de las mismas.

92 CAPITULO 7. CONCLUSIONES Y TRABAJOS A FUTURO

Bibliografıa

[Bei90] Boris Beizer. Software Testing Techniques, Second Edition. VanNostrand Reinhold Co., 1990. 1.2, 2.2, 3.6

[BHC+93] Inderpal Bhandari, Michael J. Halliday, Ram Chillarege, Eric Tar-ver, David Brown, and Jarir Chaar. A case study of software processimprovement during development. IEEE Transactions on SoftwareEngineering, 19, 1993. 5.1.2, 5.2.5, 5.5, 5.5

[Bin99] Robert V. Binder. Testing Object-oriented Systems Models, Pat-terns, and Tools. Addison-Wesley, 1999. 1.2, 3.3

[BKS98] Kathryn Bassin, Theresa Kratschmer, and P. Santhanam. Evalua-ting software development objectively. IEEE Software, 15:66–74,1998. 5.2.7, 5.5, 5.5

[BLV01] Alessandro Bianchi, Filippo Lanubile, and Giuseppe Visaggio. Acontrolled experiment to assess the effectiveness of inspection mee-tings. Technical report, Dipartimento di Informatica University ofBari, 2001. 5.2.8, 5.5, 5.5

[BMK02] M. Butcher, H. Munro, and T. Kratschemer. Improving softwaretesting via odc: Three case studies. IBM SYSTEMS JOURNAL,41:14, 2002. 5.2.3, 5.2.4, 5.5, 5.5

[BS87] Victor Basili, , and Richard W. Selby. Comparing the effective-ness of software testing strategies. IEEE Transactions on SoftwareEngineering, 12:1278–1296, 1987. 5.2.8, 5.5, 5.5

[Car98] David N. Card. Learning from our mistakes with defect causalanalysis. In IEEE Software, 1998. 5.2.1

[CBC+92] Ram Chillarege, Inderpal Bhandari, Jarir Chaar, Michael J. Ha-lliday, Diane Moebus, Bonnie Ray, and Man-Yuen Wong. Ort-hogonal defect classification - a concept for in-process measure-ments. IEEE TRANSACTTONS ON SOFTWARE ENGINEE-RING, 18:14, 1992. 5.1.1

[Chi96] Ram Chillarege. Handbook of Software Reliability Engineering.IEEE Computer Society Press, McGraw-Hill Book Company, 1996.1.2, 2.2, 3.5

[Chi06] Ram Chillarege. Odc - a 10x for root cause analysis. In WorkshopBerkeley CA, 2006. 5.2.6, 5.5, 5.5

93

94 BIBLIOGRAFIA

[Chu08] Neeti Churamani. Using orthogonal defect classification for defectanalysis. Technical report, NIIT Technologies, New Delhi, India,2008. 5.2.5, 5.5, 5.5

[CP02] Ram Chillarege and Kothanda Ram Prasad. Test and developmentprocess restrospective - a case study using odc triggers. In Inter-national Conference on Dependable Systems and Networks, 2002.5.2.2, 5.5, 5.5

[FDK05] Bernd Freimut, Christian Denger, and Markus Ketterer. An indus-trial case study of implementing and validating defect classificationfor process improvement and quality management. In 11th IEEEInternational Software Metrics Symposium, 2005. 5.2.7, 5.5, 5.5

[Fre01] Bernd Freimut. Developing and using defect classification schemes.Technical report, Fraunhofer IESE, 2001. 1.2, 2, 4

[Gra92] Robert B. Grady. Practical Software Metrics For Project Manage-ment and Process Improvement. Hewlett-Packard, 1992. 1.2, 2.2,3.1

[GV09] Fernanda Grazioli and Diego Vallespir. Marco teorico para evaluartaxonomıas de defectos. Technical Report RT 09-17, Instituto deComputacion – Facultad de Ingenierıa - Universidad de la Republi-ca, 2009. 7.1

[Hub98] Jon T. Huber. Software defect analysis: Real world testing impli-cations & a simple model for test process defect analysis. Technicalreport, Hewlett Packard Company, 1998. 5.2.7, 5.5, 5.5

[Hum05] Watts S. Humphrey. PSP: A Self-Improvement Process for SoftwareEngineers. Addison-Wesley, 2005. 6

[IEE93] IEEE. IEEE 1044-1993 Standard Classification for Software Ano-malies. Institute of Electrical and Electronics Engineers, 1993. 1.2,3.4

[IEE95] IEEE. IEEE Guide to Classification for Software Anomalies. Ins-titute of Electrical and Electronics Engineers, 1995. 2.4, 5.1.1

[JV03] Natalia Juristo and Sira Vegas. Functional testing, structural tes-ting, and code reading: What fault type do they each detect? Te-chnical report, Facultad de Informatica. Universidad Politecnica deMadrid, 2003. 5.2.8, 5.5, 5.5

[KFN99] Cem Kaner, Jack Falk, and Hung Quoc Nguyen. Testing ComputerSoftware (2nd. Edition). International Thomson Computer Press,1999. 1.2, 3.2

[KS01] Diane Kelly and Terry Shepard. A case study in the use of defectclassification in inspections. In –, 2001. 5.2.8, 5.4, 5.5, 5.5

[LPS00] Marek Leszak, Dewayne E. Perry, and Dieter Stoll. A case studyin root cause defect analysis. Proceedings of the 22nd internationalconference on Software engineering, 2000. 2.5, 4.2

BIBLIOGRAFIA 95

[LR97] Christopher M. Lott and H. Dieter Rombach. Repeatable softwareengineering experiments for comparing defect-detection techniques.Journal of Empirical Software Engineering, -:–, 1997. 5.2.8, 5.5, 5.5

[MHPD99] Paul Matthews, Michael Hamada, Gardner Patton, and SiddharthaDalal. Using defect patterns to uncover opportunities for improve-ment. In -, 1999. 5.1.2, 5.2.7, 5.4, 5.5, 5.5

[MJHS90] R. G. Mays, C. L. Jones, G. J. Holloway, and D.P. Studinski. Expe-riences with defect prevention. IBM SYSTEMS JOURNAL, 1990.2.5, 4.2, 5.2.1

[Mye78] Glenford J. Myers. A controlled experiment in program testing andcode walkthroughs/inspections. Communications of ACM, 21:760–768, 1978. 5.2.8, 5.5, 5.5

[Nar03] Purushotham Narayana. Software defect prevention - in a nutshell.iSixSigma Magazine, –:–, 2003. 5.2.1, 5.4, 5.5, 5.5

[Sch99] Charles P. Schultz. Orthogonal defect classification (odc) basedtest planning and development. In International Conference onApplications of Software Measurement, 1999. 5.2.3

[She09] Ajit Ashok Shenvi. Defect prevention with orthogonal defect clas-sification. In –, 2009. 5.2.1, 5.4, 5.5, 5.5

[SL06] Nirav Saraiya and Jason E. Lohner. Monitoring and improvingthe quality of odc data using the odc harmony matrices: A casestudy. In Fourth International Conference on Software EngineeringResearch, 2006. 5.2.7, 5.4, 5.5, 5.5

[VAL+09] Diego Vallespir, Cecilia Apa, Stephanie De Leon, Rosana Robaina,and Juliana Herbert. Effectiveness of five verification techniques. InXXVIII International Conference of the Chilean Computer Society,2009. 1.1, 6

[VGH09] Diego Vallespir, Fernanda Grazioli, and Juliana Herbert. A frame-work to evaluate defect taxonomies. In Proceedings del XV Con-greso Argentino de Ciencias de la Computacion, Workshop de In-genierıa de Software, pp. 643–652, ISBN 978-897-24068-4-1, SanSalvador de Jujuy, Argentina, Octubre, 2009. 7.1

[VH09] Diego Vallespir and Juliana Herbert. Effectiveness and cost of veri-fication techniques. preliminary conclusions on five techniques. InX Mexican International Conference in Computer Science, 2009.1.1, 5.2.8, 5.4, 5.5, 5.5, 6

[VL08] Diego Vallespir and Stephanie De Leon. Analisis y ejemplos dela taxonomıa de defectos de beizer. Technical Report RT 08-19,Instituto de Computacion – Facultad de Ingenierıa - Universidadde la Republica, 2008. 3.6

96 BIBLIOGRAFIA

[VMBH09] Diego Vallespir, Silvana Moreno, Carmen Bogado, and Juliana Her-bert. Towards a framework to compare formal experiments thatevaluate verification techniques. In X Mexican International Con-ference in Computer Science, 2009. 1.1, 6

[Wag08] Stefan Wagner. Defect Classifications and Defect Types Revisited.Technische Universitat Munchen, 2008. 2.5, 4.1

[WRBM97] Murray Wood, Marc Roper, Andrew Brooks, and James Miller.Comparing and combining software defect detection techniques: Areplicated empirical study. Proc. 6th European Software Eng. Conf.,Springer, -:262–277, 1997. 5.2.8, 5.5, 5.5

Documents

FACULTAD DE INGENIER IA UNIVERSIDAD DE LA REPUBLICA An