Embed Size (px)
Citation preview
FACULTAD DE INGENIERÍA
UNIVERSIDAD DE LA REPÚBLICA
Un caso de estudio en Calidad de Datos para
Ingeniería de Software Empírica
INFORME PROYECTO DE GRADO
Bruno Bianchi Gallo
María Carolina Valverde Corrado
Tutores de Proyecto
Adriana Marotta
Diego Vallespir
Montevideo, Uruguay
Diciembre, 2009
i
RESUMEN
En este trabajo se presenta un caso de estudio en Calidad de Datos para Ingeniería de Software
Empírica.
Los datos a analizar son el resultado de un experimento formal llevado adelante en el marco de
un proyecto de grado, con la participación, como sujetos del experimento, de varios estudiantes
4to y 5to año de la Carrera Ingeniería en Computación de nuestra Facultad. El objetivo de dicho
experimento consiste en conocer el rendimiento y costo de diferentes técnicas de verificación
unitaria. El presente trabajo busca identificar los aspectos de calidad relevantes en este contexto,
así como evaluar la calidad de la información recabada en el experimento, detectando los
errores en los datos, y definir y ejecutar procesos de limpieza sobre los mismos.
El proceso realizado comienza con un análisis exhaustivo de los posibles errores sobre los datos,
identificando tipos de errores. Si bien dichos tipos de errores surgen del estudio de los datos de
este caso de estudio en particular, son de carácter general y podrían presentarse en cualquier
experimento similar. Se definen e implementan las mediciones de calidad a realizar sobre la
base de datos, y se establece la forma de registrar los resultados de las mismas. Luego se
definen e implementan procesos de limpieza (automáticos y semiautomáticos) con el fin de
corregir los errores detectados. Se detectan errores en el diseño de la base de datos, por lo que se
construye un nuevo diseño para corregirlos. La limpieza se lleva a cabo durante la ejecución de
la migración de los datos hacia el nuevo esquema. Para las implementaciones se utilizan
consultas SQL y funciones programadas en Java, obteniendo como resultado un programa que
automatiza el ciclo completo de la calidad de datos: medición, registro y limpieza, integrando
también la migración de los datos.
ii
CONTENIDO
1 INTRODUCCIÓN ................................................................................................................ 1
1.1 MOTIVACIÓN ............................................................................................................. 1
1.2 OBJETIVOS ................................................................................................................. 2
1.3 CONCEPTOS ............................................................................................................... 2
1.4 TRABAJO REALIZADO Y RESULTADOS .............................................................. 2
1.5 CONTENIDO ............................................................................................................... 3
2 CALIDAD DE DATOS ........................................................................................................ 5
2.1 INTRODUCCIÓN ........................................................................................................ 5
2.2 DIMENSIONES DE LA CALIDAD DE DATOS ........................................................ 6
2.3 TÉCNICAS Y ACTIVIDADES DE CALIDAD DE DATOS .................................... 12
2.4 LIMPIEZA DE DATOS .............................................................................................. 13
3 INGENIERÍA DE SOFTWARE EMPÍRICA ..................................................................... 18
3.1 INTRODUCCIÓN ...................................................................................................... 18
3.2 ¿POR QUÉ EXPERIMENTAR? ................................................................................ 20
3.3 ¿CÓMO EXPERIMENTAR? ..................................................................................... 22
3.4 CONCEPTOS BÁSICOS SOBRE EL DISEÑO DE EXPERIMENTOS ................... 24
4 EXPERIMENTO ................................................................................................................. 28
4.1 DESCRIPCIÓN DEL EXPERIMENTO ..................................................................... 28
4.2 HERRAMIENTA PARA REGISTRO DE DEFECTOS ............................................ 30
5 ANÁLISIS DE ERRORES EN LOS DATOS .................................................................... 34
5.1 METODOLOGÍA DE TRABAJO .............................................................................. 34
5.2 EXACTITUD .............................................................................................................. 35
5.3 COMPLETITUD ......................................................................................................... 39
5.4 CONSISTENCIA ........................................................................................................ 40
5.5 UNICIDAD ................................................................................................................. 42
5.6 DIMENSIONES RELACIONADAS CON EL TIEMPO ........................................... 44
6 MEDICIÓN DE LA CALIDAD ......................................................................................... 45
6.1 VALOR FUERA DE RANGO ................................................................................... 45
6.2 VALOR FUERA DE REFERENCIAL ....................................................................... 47
6.3 VALOR NULO ........................................................................................................... 48
6.4 REGLAS DE INTEGRIDAD INTRA-RELACIÓN ................................................... 49
6.5 REFERENCIA INVÁLIDA ........................................................................................ 49
iii
6.6 REGISTRO DUPLICADO ......................................................................................... 50
6.7 REGISTRO CONTRADICTORIO ............................................................................. 51
6.8 RESUMEN .................................................................................................................. 53
6.9 VALOR DE CALIDAD DE LOS DATOS ................................................................. 56
7 REGISTRO DE ERRORES ................................................................................................ 58
7.1 DESCRIPCIÓN DE LA ALTERNATIVA SELECCIONADA ................................. 58
7.2 APLICACIÓN DEL REGISTRO ............................................................................... 58
7.3 DIAGRAMA ............................................................................................................... 59
7.4 RESUMEN .................................................................................................................. 60
8 LIMPIEZA Y MIGRACIÓN DE LOS DATOS ................................................................. 65
8.1 TÉCNICAS DE LIMPIEZA APLICADAS ................................................................ 65
8.2 DISEÑO DE LA BASE DE DATOS DESTINO ........................................................ 67
8.3 PLANIFICACIÓN DE LA LIMPIEZA Y MIGRACIÓN .......................................... 70
8.4 EJECUCIÓN DE LIMPIEZAS Y MIGRACIÓN ....................................................... 71
8.5 RESULTADOS OBTENIDOS ................................................................................... 76
8.6 RESUMEN .................................................................................................................. 79
9 APLICACIÓN ..................................................................................................................... 80
9.1 INFORMACIÓN TÉCNICA ...................................................................................... 80
9.2 MANUAL DE USUARIO .......................................................................................... 80
9.3 ADAPTACIÓN DEL PROGRAMA DE LIMPIEZA Y MIGRACIÓN A OTROS
EXPERIMENTOS .................................................................................................................. 83
10 PREVENCIÓN DE ERRORES Y OPORTUNIDADES DE MEJORA ............................. 85
10.1 SOBRE EL DISEÑO DE LA BASE DE DATOS Y LA APLICACIÓN ................... 85
10.2 SOBRE EL REGISTRO DE TIEMPOS DE ACTIVIDADES ................................... 86
10.3 OTRAS CONSIDERACIONES ................................................................................. 87
10.4 MEJORAS EN LA CALIDAD DE LOS DATOS ...................................................... 87
11 CONCLUSIONES Y TRABAJOS A FUTURO ................................................................. 91
11.1 CONCLUSIONES ...................................................................................................... 91
11.2 TRABAJOS A FUTURO ............................................................................................ 93
12 GLOSARIO ......................................................................................................................... 95
13 BIBLIOGRAFÍA ................................................................................................................. 96
1
1 INTRODUCCIÓN
La calidad de la información en todo sistema informático resulta cada día más importante, sino
fundamental, ya que es un factor de gran peso para cualquier actividad que se realice en base a
dicha información.
En Ingeniería de Software Empírica se genera gran cantidad de datos, en base a los cuales se
obtienen conclusiones acerca de los experimentos realizados.
En este trabajo se presenta un caso de estudio en Calidad de Datos para Ingeniería de Software
Empírica. El caso de estudio consiste en el análisis de errores y limpieza de los datos
recolectados en la ejecución de un experimento formal (Vallespir et al., 2009), llevado a cabo en
la Facultad de Ingeniería. El objetivo principal del experimento es conocer el costo y
rendimiento de 5 técnicas de verificación unitaria. Participan 14 estudiantes ejecutando técnicas
de verificación sobre distintos programas. Los datos sobre tiempos de ejecución de las técnicas
y los defectos encontrados se ingresan mediante una herramienta web llamada Grillo (Faggiano
et al., 2008), y se guardan en una base de datos relacional.
Los datos resultantes del experimento deben ser analizados estadísticamente para poder concluir
acerca del rendimiento y el costo de las técnicas de verificación. Sin embargo, estos tienen
errores que es necesario limpiar con el fin de obtener resultados que reflejen más fielmente la
realidad. Para ello se usará conocimiento del área Calidad de Datos, y en particular aplicada a la
Ingeniería de Software Empírica.
1.1 MOTIVACIÓN
La abstracción con la cual se define el concepto de calidad, puede hacer difícil la valoración de
los resultados y beneficios que se obtienen a partir de la aplicación de distintas técnicas y/o
actividades de la calidad. Tal como establece Robert Pirsig (Marotta, 2009), “Even though
quality cannot be defined, you know what it is”. A pesar de que no se puede definir la calidad,
sabemos lo que es. Sabemos su importancia, sabemos lo que significa. En los últimos años ha
ido adquiriendo mayor relevancia, convirtiéndose en un aspecto fundamental que es necesario
considerar para todo sistema de información.
Dentro de las disciplinas que forman parte de la Ingeniería de Software, la Verificación ha ido
tomando un papel de relevancia cada vez mayor. El área de Calidad de Datos también ha tenido
esta tendencia, debido a la creciente cantidad de información que se genera y almacena,
incrementando también su valor e importancia para las organizaciones. La mala calidad de los
datos influye de manera muy significante y profunda en la efectividad y eficiencia de cualquier
organización, llevando en algunos casos a pérdidas multimillonarias (Batini and Scannapieca,
2006). Cada día se hace más notoria la importancia y necesidad en distintos contextos de un
nivel de calidad adecuado para los datos.
El caso de estudio que se presenta no es la excepción en este sentido. Resulta de suma
importancia que se logre obtener datos de buena calidad en todo experimento. Esto se debe a
que dichos datos son el punto de partida para análisis estadísticos, estudios comparativos y
análisis de datos, en los cuales se basan los resultados de las experiencias. De nada serviría
analizar y obtener conclusiones a partir de datos incorrectos o de mala calidad. Es más, sería
“nocivo” en el sentido de que representan una falsa realidad.
2
El dominio de aplicación de la Calidad de Datos sobre Ingeniería de Software Empírica, no se
encuentra actualmente muy desarrollado. Esto motiva a avanzar y dar los primeros pasos en este
sentido. A pesar de que se cuenta con poca experiencia, hay mucho para abordar y aportar.
Con la mira puesta en mejorar la calidad de las experiencias empíricas en Ingeniería de
Software, en particular en lo que refiere a Verificación, es que se plantea este trabajo. El camino
a seguir implica mejorar la calidad de los datos generados a partir de los experimentos. Esta
tarea se lleva a cabo estableciendo pautas y actividades aplicables no a uno, sino a un conjunto
de experimentos con determinadas características, que conduzcan a la ejecución de
experimentos de mayor calidad en el área de Ingeniería de Software Empírica.
1.2 OBJETIVOS
Existen dos objetivos principales para el proyecto. Por un lado, se busca conocer qué errores
tienen los datos de la base bajo estudio así como su forma de limpieza. Para esto se requiere
establecer previamente las técnicas de detección y corrección de errores a utilizar en cada caso.
Se deben implementar además procesos automáticos y semiautomáticos que den soporte a la
limpieza de los datos. La limpieza contempla errores en el diseño del esquema de la base de
datos, por lo que debe diseñarse un nuevo esquema que corrija los mismos, y realizar la
migración de datos correspondiente.
Por otro lado, se pretende generalizar los resultados obtenidos para este caso de estudio en
particular, de manera tal de extender su aplicabilidad para otros experimentos similares. Se
busca generalizar tanto la implementación de los procesos de limpieza que se hayan generado,
así como los tipos de errores que se identifiquen sobre los datos.
1.3 CONCEPTOS
A lo largo de todo el informe se utiliza el término “defecto” para identificar un defecto
detectado por un verificador en el código fuente (esto es, una imperfección sobre el software
verificado). Los defectos son clasificados por los verificadores según dos taxonomías: IBM y
Beizer. La taxonomía de IBM es una clasificación ortogonal de defectos, es decir, los defectos se
clasifican según categorías que son ortogonales entre sí, mientras que Beizer es una taxonomía
jerárquica.
Por otra parte, se denomina “error” a los errores que son encontrados en los datos con respecto a
la evaluación de su calidad. Un error es la instanciación de un tipo de error sobre un atributo y/o
tabla específica. El término “tipo de error” se utiliza para definir conceptualmente un error
genérico para determinado factor y dimensión de la calidad de los datos.
1.4 TRABAJO REALIZADO Y RESULTADOS
A través de un análisis exhaustivo de la base de datos bajo estudio, se identifican errores tanto
en los datos como en el diseño de la misma. Se construye un nuevo diseño que corrige los
errores identificados en el diseño original, y el cual se utiliza como destino de la migración de
los datos limpios.
Para la medición, limpieza y migración de los datos se implementa un programa Java que
automatiza la gran mayoría de las tareas, consultando al usuario en los casos que así lo
requieren. El mismo resulta ser aplicable a otros experimentos similares, que utilicen la
3
herramienta Grillo para el registro de sus datos. Junto con el programa se incluye la
documentación sobre cómo adaptar el mismo a otros casos de las mismas características.
Se genera documentación con respecto a las técnicas de calidad de datos utilizadas, así como los
distintos tipos de errores identificados. Se obtiene un conjunto de los tipos de errores que
pueden ocurrir sobre los datos, en cualquier experimento de características similares a las
presentadas en el presente proyecto.
Se incluyen también pautas y oportunidades de mejora para evitar la ocurrencia de los errores
detectados en futuros experimentos. La prevención de errores es otro aspecto de suma
importancia para la Calidad de Datos.
Para cumplir con los objetivos planteados, es indispensable adquirir conocimientos en el área de
Calidad de Datos. Por ello se debe estudiar en la literatura existente en el área las distintas
dimensiones de la calidad de los datos, sus factores y las formas de medirlos, así como las
técnicas de limpieza para los distintos tipos de errores. Es necesario también conocer acerca de
los fundamentos de la Ingeniería de Software Empírica (terminología, principios), para poder
enfocar el conocimiento del área de Calidad de Datos hacia esta disciplina en particular. Dada la
naturaleza de los datos, es imprescindible contar con conocimientos de Verificación de
Software, en particular de las técnicas de verificación unitaria utilizadas durante el desarrollo
del experimento bajo estudio, y de las taxonomías en las cuales se clasifican los defectos.
Estudiar sobre Calidad de Datos, Ingeniería de Software Empírica y Verificación de Software,
así como aplicar los conocimientos adquiridos, también forma parte del trabajo realizado en el
presente proyecto.
1.5 CONTENIDO
El informe consta de 9 capítulos además del actual. En los primeros dos capítulos, “Calidad de
Datos” e “Ingeniería de Software Empírica”, se presentan los conceptos y características
fundamentales sobre el área de Calidad de Datos e Ingeniería de Software Empírica
respectivamente. Luego se describe brevemente el experimento bajo estudio, en el capítulo
titulado “Experimento”. En dicho capítulo se describe también la herramienta Grillo con la cual
se registran los defectos y el esquema de la base de datos de la misma, la cual será objeto de
estudio durante el proyecto.
En el capítulo “Análisis de Errores en los Datos” se presentan cuáles son los tipos de errores
que podrían contener los datos, agrupados según su dimensión de calidad. Se describe también
los pasos seguidos para la identificación de dichos tipos de errores y la definición de las
mediciones para cada uno, a ejecutar sobre los datos bajo estudio. El resultado de esta ejecución
se presenta en el capítulo “Medición de la Calidad”, mostrando el detalle de cómo se realiza la
medición de aquellos errores considerados significativos y representativos del total. Se incluye
también un resumen del resultado global de la medición.
En el capítulo “Registro de Errores” se indica de qué forma se lleva a cabo el registro de la
metadata de los errores, luego de un análisis de distintas alternativas de registro. Se presenta la
aplicación de la alternativa seleccionada para determinados tipos de errores. Al final de este
capítulo se muestra un resumen de todos los errores y tipos de errores identificados sobre los
datos, incluyendo el resultado de su medición y registro.
A continuación, en el capítulo “Limpieza y Migración de los Datos” se describe la limpieza de
los errores que fueron previamente presentados, incluyendo el resultado obtenido a partir de la
4
misma. Estas limpiezas se ejecutan de manera automática o semiautomática durante la
migración de la base de datos de la herramienta Grillo, y de manera manual al finalizar la
misma.
En el capítulo “Aplicación” se describe brevemente la aplicación implementada para ejecutar la
limpieza y migración de los datos. Se incluyen además qué aspectos deben considerarse a la
hora de aplicar este programa en otro experimento similar. Las alternativas para evitar que los
mismos errores sucedan en futuros experimentos, se presentan en el capítulo “Prevención de
errores y oportunidades de mejora”. Se establece cuáles son los errores que es posible prevenir
y de qué manera, cuáles pueden ocasionar una potencial mejora en la calidad de los datos, y
cuáles no se ven contemplados.
Finalmente, el capítulo “Conclusiones y Trabajos a Futuro” presenta las conclusiones acerca
del trabajo, los logros obtenidos, las limitaciones identificadas, y las tareas que serían de interés
abordar en futuros trabajos.
Adicionalmente, se entregan junto con este informe 6 Anexos. En el Anexo A - Catálogo de
Errores, se describen todos los errores considerados para los datos bajo estudio. Se incluye
también el análisis de alternativas para el registro de los errores, y el detalle del registro según la
alternativa seleccionada en los Anexos B y C respectivamente. La descripción de la limpieza y la
migración se encuentran en el Anexo D, mientras que las consultas realizadas a los verificadores
que participaron en el experimento forman parte del Anexo E. Finalmente, se detallan los
resultados obtenidos a partir de la limpieza de todos los errores en el Anexo F.
5
2 CALIDAD DE DATOS
El objetivo del presente capítulo es abordar la temática de la calidad en los datos, llegando a
conocer sus conceptos y características fundamentales, y sobretodo comprender su relevancia
para nuestro estudio.
En primera instancia se introducen sus principales conceptos, las dimensiones y factores de
calidad. Luego se explican las técnicas y actividades que se llevan a cabo en el área de la
calidad de datos, y en línea con este último punto se trata la limpieza de datos, cuyo objetivo
final es la mejora en la calidad de los mismos. Este capítulo se basa fuertemente en (Batini and
Scannapieca, 2006) y (Marotta, 2009).
2.1 INTRODUCCIÓN
Previo a cualquier análisis de datos, es importante conocer acerca de la relevancia de la calidad
de datos. Es por esto que se menciona de manera breve de qué trata la calidad de datos y el
motivo por el cual resulta importante (por no decir imprescindible) su estudio. Finalmente se
trata cuáles son las áreas de investigación que le competen.
2.1.1 ¿Qué es la Calidad de Datos?
Los datos representan objetos del mundo real. Dichas representaciones resultan ser aplicables en
contextos de diferentes y variadas características. Por otro lado, los datos pueden ser
almacenados o sometidos a algún proceso o transformación, siendo siempre de suma
importancia para garantizar la sobrevivencia y éxito de las organizaciones.
El problema de la calidad de datos ha sido objeto de estudio desde varias perspectivas y por
diferentes áreas a lo largo de los años, tal es el caso de la Estadística, Gestión o Computación. A
medida que su importancia se hace más evidente a los ojos de estas y otras áreas, se incrementan
también las investigaciones e intenciones de mejora en este sentido.
Es indudable que el almacenamiento y/o procesamiento de datos es de vital importancia en la
vida de todas las personas y organizaciones, en una gran variedad de actividades (más allá de la
informática y los sistemas de información). Existen varios ejemplos de situaciones de la vida
cotidiana, donde se hace necesario almacenar, procesar, transmitir y utilizar datos. Uno de ellos,
cuando elaboramos una lista para hacer las compras almacenamos datos correspondientes a qué
productos comprar, en qué cantidad, de qué marca.
En cuanto al concepto de calidad de datos, suele suceder que intuitivamente se piensa en ciertos
aspectos de los datos. Por lo general se tiende a pensar en que los datos sean exactos. Sin
embargo, hace falta ahondar más en este concepto, para entender que hay varias “caras” o
aspectos (las llamadas dimensiones), que hacen a la calidad de los datos. Más adelante en el
documento se explican algunas dimensiones (exactitud, completitud, actualidad, entre otras) en
detalle. Como ejemplo trivial, se puede pensar en la situación de la elaboración de una lista para
compras:
Si se omite anotar un producto o la cantidad a comprar de cierto producto, se enfrenta el
problema de completitud.
Si ocurre una equivocación en la cantidad de cierto producto o se escribe mal su marca,
se enfrenta el problema de exactitud.
6
Si en lugar de llevar la lista de hoy se lleva la de ayer, se enfrenta el problema de
actualidad.
Entonces, se puede decir que la definición de la calidad de los datos está relacionada
estrechamente con la exactitud, completitud, consistencia y actualidad de los datos (entre otros).
Es por esto que la calidad de datos es denominada un concepto “multifacético”, ya que depende
y es función de las dimensiones que la definen.
2.1.2 La Importancia de la Calidad de Datos
Son pocas las ocasiones en las cuales se es consciente de las consecuencias que la mala calidad
de datos trae aparejada. Sin embargo, es de suma importancia lograr identificar sus causas para
eliminar, o en su defecto mejorar, la problemática de raíz.
En el ejemplo anterior de elaboración de la lista de compras, la mala calidad de los datos puede
acarrear consecuencias no deseadas (como omitir comprar un producto que se necesitaba, o una
cantidad equivocada), ninguna de ellas de gravedad. Pero no es difícil pensar en otro tipo de
situaciones (listas de productos para importación en cantidades masivas, nombres de clientes
duplicados, errores en cobros, errores médicos) donde una falta puede provocar problemas de
gravedad.
La mala calidad de los datos influye de manera muy significante y profunda en la efectividad y
eficiencia de las organizaciones así como en todo el negocio, llevando en algunos casos a
pérdidas multimillonarias. Cada día se hace más notoria la importancia y necesidad en distintos
contextos de un nivel de calidad adecuado para los datos.
2.1.3 Áreas de Investigación en Calidad de Datos
Lograr calidad en los datos es una tarea compleja y multidisciplinaria, debido a su importancia,
naturaleza, y la variedad de tipos de datos y sistemas de información que pueden estar
implicados.
La investigación dentro del área de calidad de datos incluye los siguientes puntos:
Dimensiones: las mediciones sobre el nivel de calidad de los datos se aplican a las
dimensiones de interés.
Metodologías: proveen guías de acción.
Modelos: representan las dimensiones y otros aspectos de la calidad de datos.
Técnicas: proveen soluciones a problemas de calidad de datos.
Herramientas: son necesarias para que las metodologías y técnicas puedan llevarse a
cabo de manera efectiva.
2.2 DIMENSIONES DE LA CALIDAD DE DATOS
En la sección anterior, se introdujeron a modo de ejemplo conceptos como exactitud,
completitud y actualidad. Todas estas características (y varias más) de los datos, se denominan
dimensiones de la calidad de los datos.
Cada dimensión refleja un aspecto distinto de la calidad de los datos. Las mismas pueden estar
referidas a la extensión de los datos (su valor), o a la intensión (su esquema). De esta manera
7
podemos distinguir entre calidad en los datos y calidad en los esquemas. El foco del presente
proyecto es en la calidad inherente a los datos.
Se define factor de calidad como un aspecto particular de una dimensión. En este sentido, una
dimensión puede ser vista como un agrupamiento de factores de calidad que tienen el mismo
propósito.
Es claro que la mala calidad en los datos puede provocar varios problemas, así como también la
mala calidad de un esquema (por ejemplo un esquema de una base de datos relacional sin
normalizar) podría provocar problemas mayores, tales como redundancias. Ambos tipos de
dimensiones, tanto las referidas a los datos como a los esquemas, proveen una visión cualitativa
de la calidad, mientras que las medidas cuantitativas se representan mediante las métricas.
Una métrica es un instrumento que define la forma de medir un factor de calidad. Un mismo
factor de calidad puede medirse con diferentes métricas. Por otro lado, definimos método de
medición como un proceso que implementa una métrica. A su vez, una misma métrica puede
ser medida por diferentes métodos.
Existen varias dimensiones que reflejan distintos aspectos de los datos. Esto no resulta ser una
sorpresa al considerar que los datos pretenden representar todo tipo de características de la
realidad, desde espaciales y temporales, hasta sociales. A continuación se describen algunas
dimensiones de la calidad de datos.
2.2.1 Exactitud (Accuracy) y Unicidad (Uniqueness)
La exactitud se puede definir como la cercanía que existe entre un valor v del mundo real, y su
representación v‟.
De acuerdo al enfoque teórico que se trata más adelante, la exactitud se define como una
correcta y precisa asociación entre los estados del sistema de información y los objetos del
mundo real.
Existen tres factores de exactitud: exactitud semántica, exactitud sintáctica y precisión.
La exactitud sintáctica se refiere a la cercanía entre un valor v y los elementos de un dominio
D. Esto es, si v corresponde a algún valor válido de D (sin importar si ese valor corresponde a
uno del mundo real).
Para poder medir la exactitud sintáctica se puede utilizar la comparación de funciones, métrica
que mide la distancia entre un valor v y los valores en el dominio D. Otras alternativas posibles
son la utilización de diccionarios que representen fielmente el dominio, o el chequeo de los
datos contras reglas sintácticas.
La exactitud semántica se refiere a la cercanía que existe entre un valor v y un valor real v‟.
Esta dimensión se mide fundamentalmente con valores booleanos (indicando si es un valor
correcto o no), para lo cual es necesario conocer cuáles son los valores reales a considerar.
En este caso, interesa medir que tan bien se encuentran representados los estados del mundo
real. Una de las métricas utilizadas es la comparación de los datos con referenciales
considerados válidos.
La precisión, por otra parte, se refiere al nivel de detalle de los datos.
El enfoque hasta ahora ha sido en la exactitud a nivel de valores, o sea, del valor de una celda (o
campo) de una tupla. Sin embargo, es posible pensar en la exactitud a nivel de tupla, o a nivel de
8
tablas, e incluso considerando la base entera. Es decir, se pueden considerar distintos niveles de
granularidad a la hora de evaluar la calidad de los datos. Es por esto que se definen funciones de
agregación, las cuales miden la exactitud de conjuntos de datos. Por ejemplo, obtener la medida
de una tupla a partir de la medida de exactitud de cada una de sus celdas. El ratio es una
función de agregación que consiste en identificar la cantidad de valores correctos sobre la
cantidad de valores totales. Brinda un porcentaje de valores correctos. Otros ejemplos de
funciones de agregación son los promedios y promedios ponderados.
Para aclarar los conceptos se plantea un ejemplo sencillo. Se posee una base de datos donde se
almacena el nombre y la edad de determinadas personas. Para el dato “Edad” se especifica que
su valor estará en el rango 0 a 120. Además, se sabe que existe una persona llamada Oscar
Javier Morales, de 23 años de edad. Se consideran entonces los siguientes casos:
Si existe un registro para una persona donde el campo edad tiene el valor 234, entonces
se trata de un error sintáctico (valor fuera del rango 0 a 120).
Si existe un registro para Oscar donde el campo edad tiene el valor 19, entonces se trata
de un error semántico, ya que es sabido que Oscar no tiene 19 años, sino que tiene 23
(en este caso no hay error sintáctico, pues 19 es un valor válido para la edad).
Se enfrenta un problema de precisión si existe el interés de conocer la edad exacta de
Oscar, ya que solo se conoce la cantidad de años, no los meses ni días de vida.
A pesar de que la exactitud semántica es generalmente más compleja de medir que la exactitud
sintáctica (ya que se requieren conocer los valores del mundo real), cuando ocurren errores de
tipeo ambos tipos de exactitud coinciden. Al modificar su valor, se logrará exactitud sintáctica,
ya que el valor escrito correctamente se corresponderá con alguno del dominio, y semántica, ya
que existirá un valor real asociado al valor escrito correctamente.
Una forma de chequear la exactitud semántica es comparar diferentes fuentes de datos, y
encontrar a partir de estas el valor correcto deseado. Esto también requiere de la resolución del
problema de identificación de objetos, el cual consiste en identificar si dos tuplas representan el
mismo objeto en el mundo real.
En el caso en que la exactitud sea considerada en un conjunto de valores, es necesario
considerar también la duplicación. Dicha problemática ocurre cuando un objeto del mundo real
se encuentra presente más de una vez (más de una tupla representa exactamente el mismo
objeto).
Sin embargo, podrían existir también tuplas que representan el mismo objeto del mundo real
pero con diferentes claves. Este aspecto es considerado por la dimensión de Unicidad. Es
importante destacar aquí que existen diferentes situaciones que pueden llevar a la duplicación de
datos:
cuando la misma entidad se identifica de diferentes formas,
cuando ocurren errores en la clave primaria de una entidad,
cuando la misma entidad se repite con diferentes claves.
Distinguimos dos factores de la dimensión Unicidad:
Duplicación: la misma entidad aparece repetida de manera exacta.
Contradicción: la misma entidad aparece repetida con contradicciones.
9
2.2.2 Completitud (Completeness)
La completitud se puede definir como la medida en que los datos son de suficiente alcance y
profundidad.
De acuerdo al enfoque teórico, esta dimensión se define como la capacidad del sistema de
información de representar todos los estados significativos de una realidad dada.
Existen dos factores de la completitud: cobertura y densidad.
La cobertura se refiere a la porción de datos de la realidad que se encuentran contenidos en el
sistema de información. Al igual que para la exactitud semántica, la cobertura involucra una
comparación del sistema de información con el mundo real. Una vez más un referencial es
requerido. Debido a que suele ser difícil obtenerlo, otra alternativa es estimar el tamaño de tal
referencial.
La densidad se refiere a la cantidad de información contenida, y la faltante acerca de las
entidades del sistema de información.
Completitud de Datos Relacionales
La completitud en un modelo relacional puede caracterizarse por los siguientes aspectos:
Valores nulos: el significado de los valores nulos puede ser variado. Un valor nulo
puede indicar que dicho valor no existe en el mundo real, que el valor existe en el
mundo real pero no se conoce, o que no se sabe si el valor existe o no en el mundo real.
Es importante conocer la causa de su presencia.
Suposiciones:
o CWA (Suposiciones del Mundo Cerrado, Closed World Assumption): todos los
valores del mundo real se encuentran en el modelo relacional. En un modelo
CWA con valores nulos, la completitud se define a partir de la granularidad de
los elementos del modelo (completitud del valor, de la tupla, de un atributo, o
de la relación).
o OWA (Suposiciones del Mundo Abierto, Open Worl Assumption): no se puede
asegurar que todos los valores del mundo real se encuentran en el modelo
relacional. En un modelo OWA sin valores nulos, la completitud se mide como
la cantidad de tuplas representadas en la relación sobre su tamaño total (la
cantidad de objetos del mundo real que constituye la totalidad de la relación).
Por ejemplo, si se requiere tener registrados en una base de datos los datos (nombre, edad y
sexo) de todas las personas que habitan en el planeta Tierra, entonces cada persona no registrada
en la base degradará la completitud de los datos (esto sería completitud a nivel de la relación).
También se verá disminuida la completitud si no se cuenta con la edad de ciertas personas, o
con su sexo (esto último se refiere a la completitud a nivel de tupla o registro).
2.2.3 Dimensiones Relacionadas con el Tiempo
Los cambios y actualizaciones de los datos son un aspecto importante de la calidad de datos a
tener en cuenta. Es posible afirmar que en determinados contextos un dato no actualizado es de
mala calidad y puede llegar a ocasionar problemas graves.
10
Como ejemplo, suponer que se planean unas vacaciones a una isla del Caribe. Además de los
preparativos correspondientes, se verifica el pronóstico del clima para asegurar que no ocurran
huracanes en los días que se estará allí. Si la información climática no fue debidamente
actualizada (por ejemplo si se consulta una página web que no posee mantenimiento), puede que
se esté recibiendo el pronóstico equivocado, y por ende, que se estropeen las vacaciones. Por lo
tanto, el pronóstico podría ser muy completo y exacto desde el punto de vista de la información
climática que brinda, pero si es antiguo de nada serviría.
Se describen las siguientes dimensiones relacionadas con el tiempo:
Actualidad (Currency): trata sobre la actualización de los datos y su vigencia. Esta
dimensión puede ser medida de acuerdo a la información de “última actualización".
Volatilidad (Volatility): se refiere a la frecuencia con que los datos cambian en el
tiempo. Una medida para esta dimensión es la cantidad de tiempo que los datos
permanecen siendo válidos.
Edad (Timeliness): especifica que tan actuales/viejos son los datos para la tarea/evento
en cuestión. Para medir esta dimensión es necesario considerar una métrica de
actualidad, y verificar que los datos se encuentren dentro del límite establecido por la
tarea/evento en cuestión.
2.2.4 Consistencia (Consistency)
Esta dimensión hace referencia al cumplimiento de las reglas semánticas que son definidas
sobre los datos.
De acuerdo al enfoque teórico, la inconsistencia de los datos se hace presente cuando existe más
de un estado del sistema de información asociado al mismo objeto de la realidad. Una situación
que podría ocasionar inconsistencias en los datos es la incorporación de datos externos o con
otros formatos.
Un ejemplo sencillo: si en una tabla se almacenan datos de personas, tales como fecha de
nacimiento y edad, entonces si en un registro se tiene como fecha de nacimiento el 01/01/2005 y
como edad 42 años, existe una inconsistencia (como se explica a continuación, se estaría
violando una regla intra-relacional).
Restricciones de integridad
Las restricciones de integridad definen propiedades que deben ser cumplidas por todas las
instancias de un esquema relacional.
Se distinguen tres tipos de restricciones de integridad:
Restricciones de dominio: se refiere a la satisfacción de reglas sobre el contenido de los
atributos de una relación.
Restricciones intra-relacionales: se refiere a la satisfacción de reglas sobre uno o varios
atributos de una relación.
Restricciones inter-relacionales: se refiere a la satisfacción de reglas sobre atributos de
distintas relaciones.
Existen además diferentes tipos de dependencias:
11
Dependencias de clave: no existen dos instancias de una relación r con la misma clave
k.
Dependencias de inclusión (restricciones referenciales): algunas instancias de la
relación r están contenidas en instancias de otra relación s. Un ejemplo de esta
dependencia son las restricciones de clave foránea.
Dependencias funcionales: una relación r satisface la dependencia funcional X->Y si
para todo par de tuplas t1 y t2 se cumple que: Si t1.x = t2.x t1.y = t2.y
2.2.5 Relaciones entre las Dimensiones
Es claro que las dimensiones no son independientes entre sí, sino que se interrelacionan de
manera estrecha. Es necesario ser cuidadoso a la hora de invertir esfuerzo en mejorar un aspecto
(dimensión) de la calidad de datos, ya que podría estar afectando negativamente otro aspecto de
estos.
En línea con lo mencionado anteriormente, dependiendo del contexto particular en el cual nos
situemos elegiremos mejorar aquellas dimensiones que consideramos de mayor valor para la
calidad de nuestros datos, e ignorar las que no la perjudican o afectan de manera significativa.
A modo de ejemplo, se mencionan algunas de las relaciones negativas más comunes entre
diferentes dimensiones de la calidad de datos:
Datos exactos, completos o consistentes podría implicar su desactualización debido al
tiempo que es necesario invertir en actividades de chequeo y corrección.
La completitud (muchos datos) tiene mayores probabilidades de acarrear errores de
inconsistencia en los datos.
Sin embargo, también existen correlaciones positivas, esto es, que mejoran más de un factor. Es
importante identificar en primera instancia cuáles son los factores o dimensiones que se requiere
mejorar de acuerdo al contexto de aplicación, para luego evaluar si es posible realizarlo de
forma conjunta.
A modo de ejemplo, mencionamos algunas de las correlaciones positivas más comunes entre
diferentes factores de la calidad de datos:
La corrección de errores de tipeo mejora tanto la exactitud semántica como sintáctica.
Si se logran obtener datos más actualizados, se podría mejorar la exactitud semántica
(más datos corresponderían a la realidad).
Si se completan los valores nulos (densidad) también se podría mejorar la exactitud
semántica.
2.2.6 Enfoque en las Dimensiones de la Calidad de Datos
A continuación se definen tres enfoques distintos que es posible adoptar con respecto a las
definiciones de las dimensiones en Calidad de Datos.
Enfoque Teórico
Este enfoque considera la correcta representación de la realidad en un sistema de información.
En este aspecto, interesa conocer las deficiencias que se generan cuando ocurren desviaciones
12
en dicha representación. Dentro de las deficiencias relativas al diseño del sistema de
información, se destacan las siguientes:
Representación incompleta: cuando un objeto del mundo real no se asocia con ningún
estado del sistema de información.
Representación ambigua: cuando varios objetos del mundo real se asocian con el mismo
estado del sistema de información.
Representación sin significado: cuando existen estados del sistema de información que
no se encuentran asociados con ningún objeto del mundo real.
En lo que respecta a las deficiencias operacionales destacamos los errores (garbling), que se
refieren a una incorrecta asociación entre los objetos de la realidad y los estados del sistema de
información.
Enfoque Empírico
En este caso la información es obtenida a partir de entrevistas, cuestionarios y experimentos.
Se destacan cuatro categorías:
Calidad de Datos intrínseca: calidad que los datos deben tener por sí sola (ejemplo:
exactitud).
Calidad de Datos contextual: toma en cuenta el contexto en que los datos son utilizados
(ejemplo: completitud).
Calidad de Datos representacional: referente a la calidad de la representación de los
datos (ejemplo: interpretación).
Calidad de Datos para la accesibilidad de los mismos.
Enfoque intuitivo
Las dimensiones son definidas de acuerdo al sentido común y la experiencia práctica.
Se destacan tres categorías: esquema conceptual, valor de los datos y formato de los datos.
2.3 TÉCNICAS Y ACTIVIDADES DE CALIDAD DE DATOS
En esta sección se explican algunas actividades y técnicas desarrolladas para mejorar la calidad
de los datos.
Las actividades relativas a la calidad de datos se refieren a cualquier proceso (o transformación)
que se aplica a los datos con el objetivo de mejorar su calidad. Para llevar a cabo dichas
actividades, se hace uso de distintas técnicas.
A continuación se describen algunas actividades relativas a la calidad de los datos:
Obtención de nueva información: es el proceso de refrescar la información almacenada
en la base con datos de mayor calidad (por ejemplo ingresar datos más precisos, de
mayor actualidad).
Estandarización: es el proceso de “normalizar” los datos almacenados, de manera que
queden almacenados respetando cierto formato (por ejemplo todos los números de
teléfono deben incluir el código de región).
13
Identificación de Objetos: es el proceso por el cual se identifican registros (dentro de
una misma tabla, o entre tablas) que hacen referencia al mismo objeto de la realidad.
Integración de datos: hace referencia a la actividad de unificar datos provenientes de
distintas fuentes, resolviendo los problemas que esto trae aparejados (redundancias,
problemas de consistencia, duplicación).
Confiabilidad de las fuentes: implica “calificar” a las distintas fuentes de información de
acuerdo a la calidad de los datos que proveen (esto tiene más sentido considerando un
sistema P2P por ejemplo).
Composición de calidad: hace referencia a la definición de un álgebra para calcular la
composición (o agregación) de las medidas de las dimensiones de calidad de datos. Por
ejemplo, calcular la completitud de una unión de relaciones, a partir de la completitud
de cada relación.
Detección de errores: dadas una o más tablas, y ciertas reglas que los registros de dichas
tablas deben cumplir, este es el proceso de detectar qué registros no cumplen con dichas
reglas.
Corrección de errores: luego de la detección, esta actividad se encarga de corregir los
registros con errores, de manera que se respeten todas las reglas correspondientes.
Optimización de costos: implica obtener la mejor relación costo-beneficio al aplicar
procesos de mejora de la calidad de los datos.
2.4 LIMPIEZA DE DATOS
La limpieza de datos es un arma fundamental para lograr mejorar la calidad de los datos. Es por
esto que resulta imprescindible abordar esta temática, para conocer y comprender los problemas
que debe enfrentar, así como las fases que forman parte de cualquier proceso de limpieza. Por
otro lado, la limpieza de datos abre caminos para la detección, corrección y prevención de
errores en los datos. Estos puntos se analizan al final de esta sección.
Esta sección se basa fuertemente en (Erhard Rahm, 2000).
2.4.1 Introducción
La limpieza de datos (data cleaning o data cleansing) intenta resolver la problemática de la
detección y corrección de errores e inconsistencias que ocurren en los datos, con el fin de
mejorar su calidad. Estas actividades son de mayor importancia en las bases de datos en las
cuáles la información se ingresó de alguna manera que deja lugar a la aparición de errores. Por
ejemplo, cuando la información la ingresan personas desde el teclado, cuando se obtiene de
fuentes no muy confiables o cuando se integran diferentes fuentes de información. En este
último caso se vuelve necesario también consolidar los datos cuyo significado es el mismo (pero
varían en su representación), así como descartar aquellos datos que se encuentren duplicados.
Un ejemplo de ello son Data warehouses y sistemas de información basados en web.
Existen variadas herramientas que dan soporte a la limpieza de datos. Sin embargo, es
importante tener en mente que esta tarea implica, además de la utilización de herramientas, un
arduo trabajo manual o de programación de bajo nivel para su resolución.
14
2.4.2 Problemas que Enfrenta la Limpieza de Datos
Tanto la limpieza como la transformación de datos se encuentran abocadas a resolver la misma
problemática, ya que es necesario realizar transformaciones a nivel de la estructura,
representación o contenido de los datos para lograr efectivamente su limpieza.
Los problemas que enfrenta la limpieza de datos se pueden clasificar como sigue:
Problemas provenientes de una sola fuente de información.
La calidad de los datos depende en gran medida de las restricciones de integridad y el
esquema en el cual se encuentran inmersos. Por ejemplo, las bases de datos tienen menor
probabilidad de poseer errores e inconsistencias en los datos, a diferencia de los archivos de
texto plano en los cuales no existe ningún tipo de reglas ni restricciones con respecto a los
datos ni sus valores.
Se distinguen además problemas a nivel del esquema o a nivel de instancia. Estas últimas
son las que conciernen a la calidad de los datos, y son ocasionados por ejemplo por errores
de tipeo.
Problemas provenientes de varias fuentes de información.
Cuando se integran varias fuentes de información, los problemas existentes para una sola
fuente se incrementan drásticamente. En este caso, se distinguen dos tipos de problemas a
nivel del esquema:
Conflictos de nombres: cuando se utiliza el mismo nombre para representar distintos
objetos, o cuando distintos nombres representan el mismo objeto.
Conflictos estructurales: cuando el mismo objeto se representa de distinta manera en
fuentes de información distintas.
A nivel de instancia, los conflictos que pueden suceder son:
Diferentes representaciones para el mismo valor (por ejemplo el sexo con valores F/M o
0/1).
Diferentes interpretaciones del mismo valor (por ejemplo una medida expresada en
minutos o segundos).
Diferentes niveles de agregación.
Diferentes puntos en el tiempo.
Sin duda, una de las mayores problemáticas de la limpieza de datos es la identificación de datos
que representan el mismo objeto del mundo real. Sin embargo, al momento de realizar esta tarea
es necesario considerar que a pesar de que existe información redundante, en muchas ocasiones
los datos que representan el mismo objeto podrían complementarse (por ejemplo obtener la
dirección y el teléfono a partir del registro de una persona, y su edad y sexo a partir de otro
registro de la misma persona).
2.4.3 Fases de la Limpieza de Datos
A continuación se detallan las fases de las cuales consta un proceso de limpieza de datos.
15
Análisis de datos: esta fase consiste en determinar los errores e inconsistencias que
deberán eliminarse. Para ello se realiza una inspección manual y se utilizan programas
de análisis de datos.
Existen dos enfoques:
o Data profiling: consiste en analizar los datos de una base de datos y a partir de
estos obtener propiedades que se cumplen en la misma. Se centra en el análisis
de los atributos: su contenido, estructura, dependencias en una relación,
solapamiento con atributos de otras relaciones, valores faltantes y duplicados.
Ejemplos:
Para valores ilegales: definición de cardinalidades, valores máximos y
mínimos, variaciones/desviaciones.
Para errores de tipeo: ordenar los campos de manera tal que los valores
con errores se sitúen cerca de los reales.
Para valores faltantes: cantidad de nulos, presencia de valores por
defecto pueden indicar también la falta de un valor.
Variación en la representación de valores: comparar columnas iguales
de tablas (fuentes) distintas.
Duplicados: ordenar los valores por cantidad de ocurrencias.
o Data mining: se ocupa de la identificación de patrones en conjuntos de datos
(por ejemplo definir una relación entre distintos atributos).
Definición de transformaciones de datos y reglas de mapeo: consiste en un conjunto de
pasos durante los cuales se llevan a cabo transformaciones a nivel del esquema y de las
instancias. Para ello se pueden utilizar herramientas de ETL (Extraction,
Transformation, Loading), sentencias SQL (Standar Query Language) o funciones
definidas por el usuario (UDF - User Defined Functions).
2.4.4 Detección y Corrección de Errores
Utilizar el término error puede resultar demasiado amplio, teniendo en cuenta el concepto
multifacético con el que se define la calidad de datos. Por lo tanto, se puede poner foco en:
Detectar y corregir inconsistencias: básicamente se trata de detectar registros que no
cumplan con determinadas reglas, y luego modificar los datos, por ejemplo a partir de la
obtención de nueva información, para que cumplan con las reglas. Esta tarea incluye
asegurar que la información se encuentra consistente (sin contradicciones) y libre de
redundancias.
Una técnica para la localización de errores es la llamada Data editing, la cual consiste
en la definición de reglas (edits) que deben ser respetadas por cierto conjunto de datos,
para lograr de esta manera la detección de inconsistencias. Los edits representan
condiciones de error, por lo cual deben ser consistentes y no redundantes. Los datos de
un registro deben ser ajustados de manera tal que cumplan con las reglas, pero
minimizando las modificaciones a los datos.
A modo de ejemplo, se tiene una tabla de personas donde se almacenan (entro otros
datos) si la persona tiene empleo y la edad de la persona. Luego, es posible definir una
16
regla que especifique que si la edad de la persona es menor a 16, entonces el campo
empleo debe ser false. A partir de esta regla, se pueden identificar los registros que no la
cumplan, y corregirlos.
Existen varias formas de corregir los errores detectados:
o Refrescar la base de datos con nuevos datos.
o Utilizar los edits definidos de manera tal que cuando no se cumple una regla, se
imputa un valor que haga que la misma sea verdadera.
Detectar y corregir datos incompletos: si se consideran las tablas de las bases de datos
relacionales, el primer caso de incompletitud a tener en cuenta son los valores nulos. En
este caso si bien es muy simple detectar los datos incompletos, puede que corregir sea
difícil (en el caso de no tener forma de obtener la información faltante).
Aquí se distinguen dos tipos de fuentes de incompletitud: datos truncados, que
corresponden a aquellos datos que son eliminados por no ser significantes para la
realidad en cuestión, por ejemplo, y datos censurados, que corresponden a aquellos
datos que se sabe que no fueron obtenidos, ya sea porque no se pudo o porque se
omitió.
Detectar y corregir anomalías: este es el caso de datos cuyo valor difiere en gran medida
con respecto a los demás datos. La situación puede ser cualquiera de las siguientes:
o El valor fue mal medido, o mal ingresado en la base.
o El valor corresponde a una “muestra” distinta a la de todos los demás.
o El valor es correcto y simplemente corresponde a algún suceso inusual de la
realidad.
Estos datos se pueden identificar a partir de dos medidas distintas: midiendo la distancia de los
valores registrados a los valores que se espera que haya (desviación interna), o midiendo la
variación de los datos en el tiempo con respecto a otros datos (desviación relativa). Existen
varias técnicas para ello. Una de ellas, calcula el valor promedio y la desviación estándar de
cierto conjunto de datos, para identificar aquellos valores que se desvíen “demasiado” del valor
promedio. Se podría definir por ejemplo un valor límite a partir del cual el dato es sospechoso
de estar incorrectamente registrado. Otras técnicas utilizan también el factor tiempo para
identificar datos anómalos, partiendo de la base que datos medidos o registrados en cierto lapso
de tiempo pueden estar altamente relacionados, y también teniendo en cuenta posibles ciclos
donde aparezcan “picos” en los valores, por ejemplo como puede ser el uso de celulares en
Navidad o Año Nuevo.
Lidiar con estas anomalías implica un doble esfuerzo: primero se deben identificar, y luego
decidir si corresponden a datos correctos de sucesos de la realidad poco comunes, o si
corresponden a datos incorrectos y deben ser corregidos.
2.4.5 Prevención de Errores
Consiste en evitar que ocurran inconsistencias en los datos a futuro. Para ello es necesario
identificar primero cuáles son las causas de los errores y cómo lograr eliminarlas de manera
permanente.
17
La localización y corrección de errores se lleva a cabo para datos cuya creación y actualización
es poco frecuente. Sin embargo, la prevención de errores a través del manejo de procesos es
utilizada en mayor medida cuando los datos son actualizados y creados de manera frecuente. Se
incluyen controles a los procesos en los cuales los datos son creados y/o actualizados para evitar
que sucedan inconsistencias.
Los edits también pueden ser utilizados para la prevención de errores y la mejora de procesos,
evitando la ocurrencia de ciertas inconsistencias en la base.
Otra forma de prevención de errores consiste en identificar cuáles con las actividades manuales
en las cuales suelen ocurrir la mayor cantidad de errores, y buscar su automatización.
18
3 INGENIERÍA DE SOFTWARE EMPÍRICA
No es común experimentar en la Ingeniería de Software. Para conocer los motivos de ello, se
requiere en primera instancia tener un conocimiento sobre los experimentos en general, y sobre
la experimentación aplicada al caso particular de la Ingeniería de Software. Dicho tema es
tratado en la primera sección. Se profundiza luego en los motivos que conducen a experimentar
para lograr entender su importancia en todas las disciplinas, y la Ingeniería de Software no
resulta ser la excepción en este sentido. El cómo experimentar es otra de las temáticas que se
aborda en este capítulo. Finalmente se detallan los conceptos básicos que es preciso conocer en
cuanto al diseño de los experimentos.
El objetivo del presente capítulo va más allá de conocer los conceptos fundamentales con
respecto a la Ingeniería de Software Empírica. Se enfoca en comprender por qué resulta
verdaderamente imprescindible experimentar en esta disciplina, y los motivos por los cuales la
realidad se aleja de esta idea, a pesar de ser conscientes de sus consecuencias.
Este capítulo se basa fuertemente en (Juristo and Moreno, 2001).
3.1 INTRODUCCIÓN
La experimentación se refiere a la correspondencia de las suposiciones, asunciones,
especulaciones y creencias acerca del software con hechos de la realidad.
En la actualidad, puede suceder que ciertas ideas sean tomadas como verdaderas de acuerdo a la
connotación que las personas vuelcan sobre estas. Si cierta idea es asumida como verdadera y
utilizada por una cantidad de personas significativa, entonces en algunos casos la idea se
convierte en certera para toda la sociedad. Por el contrario, si una idea es descartada por la
sociedad, entonces perderá validez y dejará de ser utilizada.
Sin embargo, no resulta difícil comprender que esta metodología “natural” de selección acerca
de las ideas verdaderas, no es apropiada para las disciplinas de la Ingeniería, entre ellas, para la
Ingeniería de Software. Esta última requiere pruebas que tengan sus raíces en hechos de la
realidad (no en supuestos), que establezcan si un determinado enfoque o técnica es realmente
mejor o peor que otra. A pesar de esto, son pocas las ideas de la Ingeniería de Software que son
probadas con hechos de la realidad, con datos empíricos, y menos aún las que siguen un
enfoque formal para la experimentación. Sin embargo, muchas de estas ideas son asumidas
como válidas y utilizadas por toda la comunidad científica.
Uno de los motivos de la inmadurez de la Ingeniería de Software es la falta de conducción de
experimentos controlados. Es necesario comprender que de no existir tal carencia, la
experimentación permitiría confirmar teorías, conocer los factores que hacen a un software
bueno o mejor que otro, así como las técnicas, métodos y herramientas más apropiadas para un
software bajo determinadas situaciones.
3.1.1 ¿Por Qué no se Experimenta en la Ingeniería de Software?
En la actualidad, la Ingeniería de Software no cuenta con un nivel de desarrollo en materia de
experimentación formal comparable con otras disciplinas de la Ingeniería. Esto puede deberse a
varios motivos, uno de los cuales es la resistencia a llevar a cabo experimentos en esta área.
Existen algunas falacias que son comúnmente utilizadas como excusas para no llevar a cabo la
experimentación en la Ingeniería de Software. Se mencionan a continuación algunas de estas:
19
El método científico tradicional no es aplicable.
El nivel de experimentación actual es aceptable.
Los experimentos tienen un costo muy alto.
Las demostraciones son suficientes.
La experimentación enlentecerá el progreso.
La tecnología cambia demasiado rápido.
Lo cierto es que dichas excusas poco tienen de real, y pueden encontrarse argumentos para
refutar cada una de ellas.
Por otro lado, y más allá de la invalidez de las excusas antes mencionadas, se identifican una
serie de dificultades particulares a la hora de experimentar en la Ingeniería de Software:
Los desarrolladores de Software en general no conocen la importancia ni el significado
del método científico. Por lo tanto, no comprenden lo fundamental de validar sus
teorías.
Los desarrolladores de Software dicen no poseer el entrenamiento adecuado para
analizar los datos de un experimento, ni para comprender cómo fueron analizados para
otros experimentos. Sin embargo, este es un caso de negligencia (más que de
inhabilidad) ya que poco entrenamiento es requerido para desarrollar tales tareas.
Sería de gran apoyo contar con libros que traten sobre el diseño y análisis de
experimentos, ya que de esta manera se podría acceder a ejemplos que faciliten el
entendimiento de los conceptos asociados con la Ingeniería de Software empírica.
Generalmente los estudios empíricos que chequean la validez de las ideas de otros no
son fácilmente publicables, lo que desmotiva a realizar replicaciones.
Existe una inmensa cantidad de variables que influyen en el desarrollo de software. Sin
embargo, dicha complejidad no debería llevar al abandono de la experimentación, sino a
superar estos obstáculos para lograr así avanzar en la materia.
A pesar de que es difícil llegar a resultados generales en la Ingeniería de Software (del
estilo “la alternativa A es siempre mejor que la B”), sí es posible determinar bajo qué
circunstancias sucede que una alternativa sea mejor que otra.
No es despreciable el efecto que tiene el factor humano en los experimentos, ya que la
misma técnica o proceso aplicado de la misma manera por personas diferentes, llevará
casi con seguridad a resultados distintos. Este es un obstáculo más que impide la
generalización de resultados.
A pesar de los obstáculos y dificultades que enfrenta la comunidad de la Ingeniería de Software,
la causa subyacente a la negación en la experimentación es la falta de conciencia de su
necesidad e importancia. Por otro lado, los clientes (consumidores de productos de software)
deberían también exigir la validación de los experimentos para su mayor seguridad.
3.1.2 Tipos de Estudios Empíricos
A nivel general, se identifican dos enfoques para la investigación empírica:
20
Estudios cuantitativos. Su objetivo es obtener una relación numérica entre las variables
o alternativas en cuestión. Los datos obtenidos para este tipo de estudio son siempre
valores numéricos.
Estudios cualitativos. Su objetivo es intentar explicar las formas en que determinados
objetos (tales como las personas) manejan sus comportamientos en entornos
particulares. Se enfoca en obtener una visión integral del contexto bajo estudio. Los
datos obtenidos para este tipo de estudio son textos, gráficos o imágenes.
Por otro lado, existen estudios cuantitativos subjetivos, cuando las personas brindan los datos
desde su punto de vista, y cuantitativos objetivos, cuando los datos son obtenidos por ejemplo a
partir de una herramienta. Análogamente existen estudios cualitativos subjetivos y objetivos.
Los estudios son llevados a cabo desde un enfoque cualitativo o cuantitativo, o incluso ambos,
dependiendo de la realidad que se examina. Si bien las investigaciones cuantitativas pueden
llegar a resultados más formales y justificables, las cualitativas complementan a estas para
definir el cuerpo del conocimiento de cualquier disciplina. De esta manera, ambos enfoques
resultan ser complementarios.
3.1.3 Amplitud de los Estudios Experimentales
Existen tres tipos de roles (los cuales requieren cierto grado de experiencia) que deben formar
parte del proceso de prueba de una idea o teoría para alcanzar su validez:
Investigadores. Llevan a cabo experimentos en sus laboratorios, bajo condiciones
controladas y sin presiones del mercado, para comprobar la validez de su propuesta. Las
teorías y resultados son luego publicados, para que otros investigadores puedan también
replicar el experimento y publicar nuevos resultados.
Innovadores. Llevan a cabo el experimento en proyectos reales, y se hacen responsables
por los riesgos que corren a cambio de poder experimentar con lo último en innovación.
Deben luego publicar sus resultados, estableciendo cuándo falló el experimento y
cuándo no, y qué mejoras deberían realizarse al mismo.
Desarrolladores rutinarios. Luego de superados los dos niveles anteriores, y a la luz del
riesgo que se asume, y de las fallas y mejorías requeridas por el experimento, los
usuarios podrán aplicarlo a proyectos reales. Se publica luego su comportamiento
indicando bajo qué circunstancias fue sometido el experimento.
3.2 ¿POR QUÉ EXPERIMENTAR?
En la presente sección se trata acerca del rol de la experimentación en la investigación científica
y tecnológica, el motivo por el cual se vuelve sumamente necesario experimentar en la
Ingeniería de Software, así como los principales conceptos respecto a la experimentación y el
conocimiento científico.
3.2.1 Investigación y Experimentación
La investigación es una actividad llevada a cabo de manera voluntaria y consciente con el fin de
encontrar un conocimiento certero sobre alguna cuestión en particular. Cierto conocimiento será
considerado científicamente válido, siempre y cuando su validez haya sido demostrada, y
además exista una comprobación de este conocimiento contra la realidad. El conocimiento
21
probado es de suma importancia ya que permite predecir el comportamiento de los elementos en
juego (por ejemplo, a partir de las leyes de Newton es posible calcular la fuerza neta de un
objeto). De manera contraria a las opiniones que son meramente subjetivas, las investigaciones
científicas son estudios objetivos basados en la observación del mundo real y la
experimentación con éste.
A pesar de conocer la importancia de la investigación y experimentación para todas las
disciplinas, la actividad esencial de comprobación de ideas contra la realidad es, en la mayoría
de los casos, ignorada en el campo de la Ingeniería de Software. De esta manera, la validez de
los modelos, procesos, métodos y técnicas que son utilizados de manera continua para la
construcción de Software, están meramente basados en la subjetividad y especulación.
3.2.2 El Factor Humano en la Ingeniería de Software
Un elemento crucial que es necesario considerar en el área de la Ingeniería de Software es la
influencia del factor humano, como ser experiencia, conocimiento y capacidad de las personas,
en el uso de sus artefactos (métodos, herramientas, paradigmas). El elemento humano es
importante para esta disciplina, ya que la misma se ve influenciada por las relaciones entre las
personas (tales como el equipo de un proyecto), así como por su contexto social (la cultura
organizacional, por ejemplo).
El aspecto social se convierte entonces en una dificultad a la hora de llevar a cabo experimentos,
haciendo que los mismos resulten más complejos. Sin embargo, no debería servir de excusa
para no experimentar (tal como sucede en la realidad), ya que este hecho lleva a que los
artefactos de la Ingeniería de Software sean utilizados sin tener certeza alguna de cuáles serán
sus resultados. Por el contrario, debería servir de impulso para adquirir mayor conocimiento en
este aspecto, y lograr así realizar experimentos que consideren al factor social y su influencia de
manera apropiada.
3.2.3 El Método Científico
Las actividades que se llevan a cabo en toda investigación científica son las que siguen:
Interacción con la realidad. Esta actividad puede realizarse mediante la observación
(pasiva), caso en el que los investigadores perciben cosas de la realidad sin interferir ni
tener control sobre ella. O también mediante la experimentación (activa), en cuyo caso
los investigadores someten al objeto en cuestión a nuevas condiciones y observan sus
reacciones, interfiriendo y controlando la realidad.
Especulación. Los investigadores formulan hipótesis acerca de su percepción del mundo
real. En el campo de la Ingeniería de Software, esta actividad comprende encontrar
relaciones entre las variables en juego para predecir las consecuencias en el proceso de
desarrollo mismo y en el producto resultante.
Confrontación con la realidad. Consiste en el chequeo de las especulaciones teóricas
(ideas) contra la realidad (hechos).
3.2.4 ¿Por Qué los Experimentos Requieren ser Replicados?
Comprobar las ideas contra la realidad no es suficiente para la experimentación. Es necesario
además proveer a la comunidad con los datos requeridos para que el experimento pueda ser
replicado por agentes externos y sus resultados verificados.
22
Sin embargo, en el área de la Ingeniería de Software resulta prácticamente imposible replicar
dos experimentos de manera exacta. Esto último significaría contar con las mismas personas, la
misma experiencia, el mismo proceso de desarrollo, los mismos productos, lo cual sin duda se
aleja de la realidad. Es por este motivo que la replicación se convierte en similitud para la
Ingeniería de Software.
Es necesario definir entonces las características de un proyecto de desarrollo que harán que dos
proyectos similares se conviertan en “idénticos”. Una vez más, es el factor humano el que hace
esta tarea más compleja por ser el más variado e impredecible. Existen también algunas formas
de diseñar los experimentos que permiten llevar a cabo réplicas de los mismos y obtener
conclusiones, a pesar de las diferencias “incontrolables” que existan entre ellos.
Se distinguen dos objetivos a la hora de llevar a cabo la replicación de un experimento. Si la
replicación se realiza bajo condiciones similares al original, entonces el objetivo resulta ser la
confirmación de la hipótesis del primer experimento. Si por el contrario una variable es
modificada durante la replicación, entonces el objetivo es chequear si dicha variable podría ser
generalizada para ciertos valores.
3.2.5 Conocimiento Empírico vs Conocimiento Teórico
Para culminar esta sección, resulta relevante destacar la necesidad que existe de contar con un
modelo teórico que se asocie al fenómeno en cuestión, siempre que existan datos que sean
obtenidos de la realidad. De no ser así, los datos recabados carecerán de sentido. Por otra parte,
la interpretación de dichos datos será diferente dependiendo del modelo teórico asociado.
Sin embargo, no siempre es posible asociar un modelo teórico a un estudio, ya sea debido a su
complejidad o la falta de conocimiento acerca de éste. Tal es el caso del desarrollo de Software.
Bajo estas circunstancias se utiliza un modelo empírico, cuya principal diferencia con el teórico
es que se enfoca en entender el comportamiento del fenómeno bajo características particulares,
así como la relación que existe entre las variables presentes.
La adquisición de nuevo conocimiento puede ser llevado a cabo mediante cualquiera de los tres
niveles de investigación que aquí se mencionan.
Inspección: conocer cuáles son las variables que afectan otras (por ejemplo, que
variables de desarrollo afectan las características del proceso o producto).
Empírica: encuentra un modelo empírico que establece cómo afectan las variables a
otras dependiendo de su valor (por ejemplo, cuál es el mejor valor de ciertas variables
para optimizar el resultado).
Mecánica: produce un modelo teórico que establece por qué las variables logran la
influencia antes establecida.
3.3 ¿CÓMO EXPERIMENTAR?
En esta sección se presentan a grandes rasgos los pasos que es necesario seguir para realizar un
experimento. Se describe qué tipo de relaciones se pueden buscar entres las variables a
considerar, la estrategia de refinamiento paso a paso, así como las fases que constituyen un
experimento. Finalmente, se introduce el rol de la estadística en la experimentación.
23
3.3.1 Buscando Relaciones entre las Variables
El objetivo de todo experimento que estudia determinado fenómeno, es establecer (o descubrir)
las relaciones que existen entre las variables involucradas en dicho fenómeno, con el fin de
lograr luego predecir cuál será el comportamiento de las mismas bajo determinadas
circunstancias. Por ejemplo, podríamos querer establecer la relación que existe entre la robustez
de un sistema o aplicación y el lenguaje en el que fue implementado. Seguramente, si se
consulta sobre este aspecto a diferentes Programadores e Ingenieros en Sistemas obtendremos
distintas respuestas (dependiendo de la experiencia particular de cada uno). El hecho es que no
existe información científicamente válida en el área de Ingeniaría de Software para responder
esta y muchas otras preguntas similares. ¿Se conoce si algún paradigma de programación hace
más fácil mantener las aplicaciones? La orientación a objetos suele adjudicarse esta virtud, pero
¿hay pruebas formales en este sentido? Más que información científicamente válida, lo que
existen son opiniones.
Se distinguen tres categorías de relaciones entre variables, dependiendo de cuánto se conoce
sobre la relación en cuestión:
Relaciones descriptivas. Son relaciones donde sólo se conoce cierto patrón de
comportamiento, pero sin tener medida de cuánto afecta una variable a otra. Por
ejemplo, generalmente (no es posible afirmarlo, solo decir “generalmente”) si la etapa
de análisis lleva más de lo planeado, luego es de esperar que la etapa de desarrollo
también resulte ser más larga. Lo que no se puede especificar ni prever es por ejemplo
en qué proporción una etapa afecta a la otra.
Correlaciones. Este tipo de relación sucede cuando se conoce que cierta(s) variable(s)
afectan a una tercera, de acuerdo a determinada función conocida. Si bien se conocen
estas correlaciones, no necesariamente hay una teoría de fondo, por lo que no se puede
distinguir entre causa y efecto.
Relaciones causales. Existe este tipo de relación cuando, por ejemplo, se sabe que las
variables A y B causan todos los cambios en la variable C. O sea, se sabe que la
variable C varía dependiendo solamente de los valores de A y B. Es el grado máximo
de conocimiento que se puede tener sobre determinada relación.
Al último tipo de relación descrito se lo conoce como causalidad determinista, pues dada la
causa siempre se obtiene el efecto esperado. Existe también la causalidad probabilística, donde
dada la causa se sabe que se obtendrá el efecto esperado con una probabilidad menor a 1.
3.3.2 Estrategia de Refinamiento Paso a Paso
La idea básica en que se fundamenta esta estrategia es utilizar la experiencia adquirida a través
de sucesivos experimentos para diseñar y ejecutar los siguientes. En lugar de diseñar un
experimento exhaustivo que tenga en cuenta múltiples variables y todas las relaciones entre
ellas, resulta más conveniente realizar sucesivos experimentos más “elementales”, con menor
cantidad de variables que sean conocidas y resulten más fáciles de controlar. De esta manera, se
puede ir obteniendo gradualmente un mejor conocimiento del fenómeno en estudio, para así
poder perfeccionar el diseño y ejecución de los siguientes experimentos.
Es por esto que diseñar completamente un experimento por primera vez no resultaría
conveniente, ya que implicaría conocer qué variables son las más importantes, qué valores fijar
a los parámetros, entre otros. Este tipo de decisiones son más fáciles de tomar a medida que se
24
va adquiriendo conocimiento del fenómeno en estudio. Se podría decir que el mejor momento
para diseñar un experimento es luego de haberlo ejecutado, y no al principio cuando el
conocimiento acerca del mismo es menor.
Existen más ventajas por las cuales es conveniente llevar a cabo una serie de experimentos de
moderado tamaño. Por ejemplo, a medida que se van ejecutando experimentos es posible
evaluar sus resultados y tomar ciertas decisiones tales como alterar los rangos de valores de las
variables, o inclusive quitar/agregar variables. Puede darse el caso también en que el objetivo
mismo del experimento sufra modificaciones.
3.3.3 Fases de un Experimento
Se definen cuatro fases para un experimento:
Definición de objetivos. Se transforma la hipótesis general en términos de qué variables
del fenómeno se van a examinar. Es importante poder definir un procedimiento
cuantitativo con el fin de evaluar la hipótesis.
Diseño Implica definir un plan para la ejecución del experimento. Se deben definir
todas las condiciones bajo las cuales se llevará a cabo el experimento, como ser las
variables que lo afectarán, quiénes van a participar, cuántas veces se repetirá el
experimento, entre otras. Un buen diseño, siempre apunta a obtener la mayor cantidad
de conocimiento posible, en la menor cantidad de experimentos.
Ejecución Se ejecuta el experimento de acuerdo al diseño.
Análisis del resultado. En esta etapa se analizan los datos obtenidos durante el
experimento, en busca de relaciones entres las variables consideradas.
Como ya se mencionó, existen distintos tipos de relaciones entre las variables: descriptivas,
correlaciones, y relaciones causales. Para identificar relaciones descriptivas, puede bastar con
examinar los datos en busca de patrones de comportamiento entre las variables. Ahora, para
identificar correlaciones o relaciones causales, hace falta aplicar técnicas de análisis de datos,
las que implican realizar análisis estadísticos sobre los datos. Uno de los estudios más comunes
que se realiza sobre los datos se conoce como “test de significancia”, el cual tiene como
objetivo establecer si las variaciones observadas en los datos recolectados tienen significado
estadístico.
3.4 CONCEPTOS BÁSICOS SOBRE EL DISEÑO DE
EXPERIMENTOS
El diseño es una parte fundamental de un experimento y puede repercutir en el mismo de
manera significativa. Es por ello que se tratan a continuación algunas nociones básicas sobre el
diseño de experimentos que es necesario conocer. Se establece además la terminología que es
utilizada para este fin, y que permite lograr un entendimiento común con el resto de la
comunidad científica.
3.4.1 Terminología para el Diseño de Experimentos
Se mencionan los principales conceptos que es preciso conocer con respecto al diseño de
experimentos y se presentan dos ejemplos a través de los cuales se introducen los mismos.
25
Se considera un experimento que consiste en la evaluación de la efectividad de un analgésico en
personas de entre 25 y 40 años de edad, llamado Efec-Analgésico. El segundo experimento
consiste en la evaluación de la efectividad de 5 técnicas de verificación de software sobre un
conjunto de programas, llamado Efec-Técnicas (Apa, 2009). Este último experimento tiene gran
similitud con el caso de estudio del presente proyecto.
Unidad experimental (experimental unit): son los objetos sobre los cuales es llevado a
cabo un experimento. Aplicado al campo de la Ingeniería de Software, una unidad
experimental podría ser un proyecto de software, o alguno de los productos intermedios
obtenidos durante el mismo.
En Efec-Analgésico la unidad experimental es el grupo de personas entre 25 y 40 años,
mientras que en Efec-Técnica es el conjunto de programas al cuál se le aplican las
técnicas de verificación.
Sujetos del experimento (experimental subjects): son las personas que llevan a cabo el
experimento. Como ya se ha mencionado, el factor humano influye de manera
significativa en los resultados de un experimento dentro de la Ingeniería de Software (el
resultado del mismo será distinto dependiendo de la persona que lo aplique), y resulta
por lo tanto imprescindible considerar el efecto de esta variable a la hora de diseñar los
experimentos.
En el caso de Efec-Analgésico, los sujetos son quienes administran los analgésicos a los
pacientes, por ejemplo enfermeros. En Efec-Técnica, los sujetos son las personas que
ejecutan las técnicas de verificación.
Variable de respuesta (response/dependent variable): es el resultado cuantitativo de un
experimento. En el área de la Ingeniería de Software, es por ejemplo la característica del
proyecto de software que está siendo analizada.
Para el ejemplo Efec-Analgésico, podría ser el grado en que el analgésico calma el
dolor, o la rapidez con la actúa. En Efec-Técnica, podría ser para cada técnica la
cantidad de defectos encontrados sobre la cantidad de defectos totales del software
verificado.
Parámetros (parameters): son características que se mantienen invariadas durante el
experimento, y por lo tanto no se desea que afecte el resultado del mismo. Los
parámetros pueden ser cualitativos o cuantitativos. Resulta preciso mencionar que los
resultados arrojados por un experimento serán ciertos sólo bajo las condiciones
impuestas por los parámetros.
En el ejemplo Efec-Analgésico un parámetro a considerar es el rango de edades (25 a 40
años). En el ejemplo de Efec-Técnica un parámetro podría ser la cantidad de líneas de
código de los programas (entre 100 y 200 por ejemplo), o fijar cierto nivel de
experiencia para los verificadores.
Factores (factors, predictor/independent variables): son características variadas
intencionalmente durante el experimento, y por lo tanto afectan el resultado del mismo.
Para el caso de Efec-Analgésico el factor es el analgésico que se utilice, mientras que en
Efec-Técnica el factor es el conjunto de técnicas.
Alternativas (alternatives, levels, treatment): son los valores posibles que pueden tomar
los factores durante un experimento.
26
Las alternativas en el caso de Efec-Analgésico serían los distintos analgésicos que se
utilicen (Perifar, Zolben,), mientras que para Efec-Técnica serían los distintos tipos de
técnicas que se utilicen (Inspecciones, Trayectorias Independientes, Partición de
Equivalencia).
Interacciones (interactions): suceden cuando el efecto de un factor depende del valor
de otro. Debido a que influencian el resultado del experimento, deben ser considerados
en el diseño del mismo.
Variaciones no deseadas (undesired variations, blocking variables): son variables
inevitables que afectan el resultado del experimento.
En Efec-Analgésico podrían provocarse este tipo de variaciones debido a la distinta
respuesta que presenta cada persona a los fármacos. En el caso de Efec-Técnica, el
hecho de no considerar la experiencia de los verificadores podría introducir variaciones
no deseadas.
Experimento unitario (elementary/unitary experiment): cada aplicación de una
combinación de alternativas de factores llevada a cabo por sujetos sobre una
determinada unidad experimental, constituye un experimento unitario.
Para el caso de Efec-Analgésico un experimento unitario involucra el analgésico x,
aplicado por el enfermero i al paciente j. Para el caso de Efec-Técnica, un experimento
unitario involucra la técnica x, aplicada por el verificador i al programa j.
Replicación externa (external replication): replicaciones de un experimento llevadas a
cabo por otros investigadores y con diferentes muestras. Recordar que en la Ingeniería
de Software la replicación exacta de un experimento no es posible, por lo tanto cuando
hablamos de “replicación” nos estamos refiriendo a “la mayor similitud posible”.
Existen distintos tipos de replicaciones externas.
o Sin alterar la hipótesis: este tipo de replicación se realiza con el fin de verificar
los resultados de un experimento, en alguna de las siguientes formas.
Repitiendo el experimento con la mayor similitud posible.
Variando la forma en que fue llevado a cabo el experimento.
o Alterando la hipótesis: el objetivo es generalizar los resultados de un
experimento (ampliando su campo de aplicación), en alguna de las siguientes
formas.
Alterando el diseño del experimento.
Alterando factores del experimento.
o Reformulando los objetivos e hipótesis del experimento: con el fin de analizar el
experimento en mayor profundidad.
Replicación interna (internal replication): repetición de uno o más experimentos
unitarios. La cantidad de repeticiones que serán llevadas a cabo en un experimento debe
ser establecido durante el diseño del mismo.
Error experimental (experimental error): se refiere a las variaciones inevitables que
ocurren entre repeticiones, tales como errores en la medición de los resultados, o
27
variables no consideradas. Estas últimas pueden llegar a invalidar el resultado de un
experimento.
3.4.2 Las Variables de Respuesta en los Experimentos
Existen diferentes métricas que pueden ser utilizadas con el fin de medir las variables de
respuesta de un experimento, esto es, el resultado cuantitativo de un experimento luego de la
finalización del mismo. A través de un análisis estadístico pueden obtenerse promedios,
desviaciones estándar e intervalos de confianza. El análisis de resultados puede involucrar
diversas actividades, las cuáles no se mencionan aquí ya que no es el foco del presente proyecto.
Es posible medir los atributos internos o externos de una variable de respuesta. Los primeros se
miden al considerar un producto, proceso o recurso sin considerar su comportamiento. Por otra
parte, los últimos consideran el comportamiento de un producto, proceso o recurso y su relación
con el exterior. .
28
4 EXPERIMENTO
Esta sección se basa fuertemente en el Informe de Proyecto de Grado realizado por Cecilia Apa
(Apa, 2009). Se describe el experimento que se llevó a cabo, y cuyos datos son objeto de
estudio y limpieza en el presente trabajo. Se describen brevemente algunos aspectos del mismo,
así como la herramienta utilizada para registrar la información acerca de los defectos detectados
durante la aplicación de las distintas técnicas de verificación.
4.1 DESCRIPCIÓN DEL EXPERIMENTO
El experimento fue realizado como un trabajo de proyecto de grado, por estudiantes de la
carrera Ingeniería en Computación de la Facultad de Ingeniería – Universidad de la República.
4.1.1 Contexto Experimental
El experimento fue desarrollado en un contexto académico, en el marco de la asignatura Módulo
de Taller que se dicta en el 4° año de la carrera Ingeniería en Computación de la Facultad de
Ingeniería - Universidad de la República. Participaron un total de 14 estudiantes. Las técnicas de
verificación que se utilizaron son:
Inspecciones (estática).
Particiones en Clases de Equivalencia y Análisis de Valores Límites (dinámica, caja
negra).
Tablas de Decisión (dinámica, caja negra).
Criterio de Cubrimiento de Condición Múltiple (dinámica, caja blanca).
Trayectorias Linealmente Independientes (dinámica, caja blanca).
Los verificadores clasificaron los defectos detectados según dos taxonomías: IBM y Beizer. La
taxonomía de IBM es una clasificación ortogonal de defectos. Se divide en dos grandes
categorías: Opener Section y Closer Section. Dentro de cada categoría, se clasifica un defecto
según distintos aspectos o sub-categorías. En el experimento solo interesó clasificar los defectos
según las sub-categorías DefectType y Qualifier, ambas pertenecientes a Closer Section.
Por otra parte, la taxonomía de Beizer es jerárquica. La clasificación de un defecto es un número
de 4 dígitos, por ejemplo: 3xxx se utiliza para defectos de estructura en el software
implementado, 32xx para defectos de procesamiento, 322x para evaluación de expresión. Las
categorías más generales (como 3xxx) se dividen en sub-categorías (como 32xx y 322x) que
representan una clasificación más específica del defecto. No fue requisito excluyente lograr la
máxima especificidad al clasificar los defectos.
Los programas a verificar fueron construidos por estudiantes de 4to año de la carrera Ingeniería
en Computación, en lenguaje Java, especialmente para uso del experimento.
4.1.2 Objetivos
Se destaca como principal objetivo conocer las relaciones de efectividad entre las técnicas de
verificación utilizadas y los distintos tipos de defectos.
29
4.1.3 Unidad Experimental
La unidad experimental es el software. Se utilizan 4 programas de distinta naturaleza:
Contable con base de datos.
Cálculos matemáticos.
Generación de un documento consumiendo datos de una base de datos.
Procesador de texto.
El hecho de contar con varios tipos de programa surge de la suposición de que un programa
podría concentrar defectos de un determinado tipo y tener muy pocos de otros. Es por ello que
se trata de lograr una muestra más representativa de programas para tener la mayor cantidad de
tipos de defectos posible.
4.1.4 Ejecución de los Experimentos Unitarios
Los verificadores hicieron uso de Guías de Trabajo (Vallespir, Apa and De León, 2008), las
cuales explican detalladamente la forma de realizar la ejecución del experimento y cómo llevar
registro de los datos que se deben recolectar. Cada experimento unitario (llamado Experiencia
de Verificación) consistió en un verificador aplicando determinada técnica de verificación a
determinado programa. El diseño del experimento distribuye a los 14 participantes en 40
experiencias de verificación, cada una con un programa y una técnica de verificación a ejecutar.
De esta manera, cada verificador aplicó distintas técnicas a distintos programas, y registró (en la
sección 4.2 se explica el detalle de cómo se realizó el registro) los siguientes datos acerca de
cada experiencia:
Fecha y hora de comienzo.
Fecha y hora de finalización.
Tiempo de diseño de casos de prueba.
Tiempo de ejecución de la experiencia.
Defectos encontrados.
Para cada uno de los defectos fue necesario registrar los siguientes datos:
Archivo en el cual se encuentra el defecto.
Número de línea de código del defecto.
Clasificación del defecto en IBM y Beizer.
Estructura en la cual se encuentra el defecto (IF, FOR, WHILE, MÉTODO,
NINGUNA)
Número de línea en que comienza la estructura (si es que se ingresó estructura en el
ítem anterior).
Tiempo de detección del defecto.
Descripción del defecto.
30
4.2 HERRAMIENTA PARA REGISTRO DE DEFECTOS
Para la recolección de datos se utilizó una herramienta disponible vía web llamada TVerificar, la
cual fue construida a medida para la recolección de datos del experimento (Apa et al., 2008).
En TVerificar se cargaron todos los experimentos unitarios identificados por: programa a
verificar, técnica de verificación a aplicar y nombre del verificador.
Cada verificador contaba con un usuario en la herramienta mediante el cual accedía a las
experiencias que tenía asignadas, y registraba los datos requeridos.
4.2.1 Descripción de la Herramienta
La herramienta TVerificar (o Grillo) centraliza el registro de los defectos por parte de todas las
experiencias de verificación en una misma base de datos, y permite tener un control y
seguimiento de las mismas. Sus principales funcionalidades son gestionar datos de las
entidades:
Usuarios.
Técnicas de Verificación.
Experiencias.
Registro de Defectos.
La herramienta es una aplicación web y la arquitectura está basada en un modelo cliente-
servidor. Como sistema gestor de Base de Datos se utiliza HSQLDB.
31
4.2.2 Diseño de la Base de Datos
Se presenta en la Figura 1 el esquema de datos utilizado para almacenar la información
concerniente a los experimentos, las pruebas ejecutadas por los verificadores, así como el
registro de los defectos.
Archivo_Software
PK id
archivo_id
software_id
Software
PK id
nombre
descripcion
total_defectos
Categoria
PK id
taxonomia_id
nombre
Estructura
PK id
nombre
descripcion
Registro_Taxonomia
PK id
registro_id
taxonomia_id
valor_categoria_id
atributo_id
Perfil
PK id
nm_perfil
descripcion
Registro_Defecto
PK id
tipo_id
experimento_id
archivo_id
estructura_id
linea
descripcion
linea_estructura
time_deteccion
Taxonomia
PK id
nombre
numero
descripcion
Experimento
PK id
ejecutor_id
creador_id
software_id
tecnica_id
nombre
fecha_ini
fecha_fin
time_casos
time_ejecucion
Tecnica
PK id
nombre
descripcion
tipo
Archivo
PK id
nombre
nombre_usu
fecha
codigo
Tipo_Defecto
PK id
nombre
descripcion
Valor_Categoria
PK id
categoria_id
categoria_padre
nombre
Usuario
PK id
nombre
nm_usuario
apellido
password
habilitado
perfil_id
Atributo
PK id
nombre
categoria_id
Figura 1 – Esquema de la base de datos de la herramienta TVerificar
32
La Tabla 1 muestra una breve descripción de cada tabla, indicando si contienen valores pre-
cargados (en cuyo caso se especifican los valores), o en caso contrario qué perfil de usuario
ingresa datos en las mismas.
Tabla 1 – Descripción de las tablas de la base de datos
Nombre Tabla Descripción Tabla Caso pre-cargada:
valores
Caso cargada: perfil
Archivo Representa un archivo que contiene
código fuente (.java).
Administrador
Software Representa un software (conjunto de
clases, métodos, etc.) que será
sometido a verificación.
Administrador
Archivo_Software Asocia un registro de la tabla Archivo
con otro registro de la tabla Software.
La relación entre las entidades Archivo
y Software se representa con la entidad
Archivo_Software ya que un Archivo
puede estar asociado a 0..N Software, y
a su vez un Software puede estar
asociado a 1..N Archivo.
Administrador
Usuario Representa un usuario que hará uso de
la herramienta.
Administrador
Perfil Representa el perfil que contiene el
usuario que utiliza la herramienta.
· Administrador
· Verificador
Experimento Representa un experimento a ejecutar y
su información asociada.
Los campos Fecha Fin,
Tiempo de Ejecución y
Tiempo de Casos no son
obligatorios y pueden ser
cargados tanto por un
usuario Administrador
como por un Verificador.
El resto de los campos son
obligatorios y solo pueden
ser completados por un
usuario Administrador.
Técnica Representa una Técnica de
Verificación. Cada registro de
Experimento tiene una única Técnica
asociada.
· Inspecciones
· CCCM
· Trayectorias
Independientes
· Tablas de Decisión
· Partición de
Equivalencia y A. de
Valores Límite
Registro_Defecto Representa un defecto hallado en el
código por un usuario Verificador.
Verificador
Estructura Representa los tipos de estructuras que
pueden existir en el código fuente. A
cada registro de la tabla
Registro_Defecto se le asocia un único
registro de la tabla Estructura.
· IF
· FOR
· WHILE
· SWITCH
· DO WHILE
· METODO
· CLASE
Tipo_Defecto Representa si el defecto está contenido
o no en una estructura. A cada registro
de la tabla Registro_Defecto se le
asocia un único registro de la tabla
Tipo_Defecto.
· Estructura
· Sin estructura
Taxonomia Representa las taxonomías existentes. · IBM
33
· Beizer
Categoria Representa los "nieveles" de cada
taxonomía.
Para IBM:
· Section
· Actividad
· Trigger
· Impacto
· Defect Type
· Qualifier
· Age
· Source
Para Beizer:
· BeizerNivel1
· BeizerNivel2
· BeizerNivel3
· BeizerNivel4
Atributo Tabla vacía (sin uso)
Registro_Taxonomia Representa un la clasificación de un
registro de defecto según las
taxonomías de Beizer e IBM.
Verificador
Valor_Categoria Representa las categorías de cada nivel
de la taxonomía.
Ver base
34
5 ANÁLISIS DE ERRORES EN LOS DATOS
En el presente capítulo se describe, para cada dimensión de la calidad de datos (descriptas en la
sección 2.2 DIMENSIONES DE LA CALIDAD DE DATOS), cuáles son los tipos de errores
que podrían contener los datos bajo estudio. Se clasifican además dichos errores según los
factores de cada dimensión.
5.1 METODOLOGÍA DE TRABAJO
De manera tal de lograr identificar los tipos de errores en los datos, se llevan a cabo las
siguientes tareas:
Estudio sobre Calidad de Datos. Conocimiento de las dimensiones y los factores de
calidad, y qué tipos de errores pueden suceder en cualquier base de datos, para luego
instanciarlos en nuestro proyecto en particular.
Estudio y conocimiento sobre experimentos en el área de la Ingeniería de Software
Empírica, y en particular sobre el experimento en cuestión: en qué consistió, cómo se
llevó a cabo, qué técnicas de verificación y taxonomías fueron utilizadas.
Exploración de la herramienta Grillo donde se registraron los defectos durante la
ejecución del experimento, para poder inducir qué errores pudieron haber sido
cometidos durante el ingreso de los datos.
Entendimiento y manipulación de la base de datos que contiene los registros de
defectos, exploración de la misma y realización de consultas para identificar nuevos
errores.
Trabajo en conjunto con María Eugenia Decia, estudiante de la carrera Ingeniería en
Computación de la Facultad de Ingeniería – Universidad de la República, quien
colaboró en la identificación de posibles errores en los datos como parte de su trabajo
de la asignatura Módulo de Taller que se dicta en el 4° año de la carrera.
Luego de analizar los posibles errores en los datos que fueron identificados en primera
instancia, se llega a una clasificación y descripción en detalle de los principales tipos de errores
encontrados.
Por cada tipo de error identificado, se describen los siguientes aspectos:
En qué consiste (breve descripción), estableciendo por qué resulta importante su
consideración.
Las posibles causas o causas conocidas (en caso de que se tenga conocimiento de cuales
son).
Las métricas utilizadas con el fin de medirlo, incluyendo su granularidad (puede ser a
nivel de celda, tupla, tabla o base entera). Para todos los casos la unidad del resultado
de la medida es un booleano. Esto es, se indica si el objeto medido contiene o no un
error.
Las dimensiones de calidad de datos que se miden son: Exactitud, Completitud, Consistencia
y Unicidad. En la Tabla 2 se muestran los tipos de errores para los cuales se definen métricas,
por cada factor y cada dimensión.
35
Tabla 2 – Tipos de errores
Dimensión Factor Tipo de error
Exactitud Exactitud sintáctica Valor fuera de rango
Estandarización
Exactitud semántica Registro inexistente
Defecto mal registrado
Valor fuera de referencial
Completitud Densidad Valor nulo
Clasificación de defecto
Consistencia Integridad intra-relación Reglas de integridad intra-relación
Valor único
Integridad referencial Referencia inválida
Unicidad Duplicación Registro duplicado
Contradicción Registro contradictorio
5.2 EXACTITUD
Para la dimensión Exactitud, se identifican los tipos de errores que se mencionan a
continuación.
Dentro del factor exactitud sintáctica:
o Valor fuera de rango.
o Estandarización.
Dentro del factor exactitud semántica:
o Registro inexistente.
o Defecto mal registrado.
o Valores fuera de referencial.
Dentro del factor precisión, no se identifican errores en los a datos a tener en cuenta. A
pesar de que resulta de interés el nivel de precisión alcanzado en la clasificación de un
defecto según la taxonomía jerárquica de Beizer, no es considerado un error el hecho de
no haber logrado la clasificación más precisa.
A continuación se describe cada uno de estos tipos de errores de manera detallada.
5.2.1 Valor fuera de rango
Resulta de interés que los valores de los tiempos y líneas de código se encuentren dentro de un
rango determinado, el cual debe ser previamente definido. El valor de un tiempo que se
encuentra fuera de rango influiría significativamente a la hora de analizar los datos y obtener
resultados y conclusiones del experimento en cuestión (por ejemplo, cuánto se tardó en
promedio en detectar un defecto de tipo X). De la misma manera, un valor fuera de rango en las
líneas de código no permitiría identificar, por ejemplo, cuáles son los registros de defectos que
corresponden al mismo defecto de la realidad.
Es importante considerar, sin embargo, que si un valor cae fuera del rango determinado no
significa necesariamente que dicho valor sea erróneo. El hecho de que existan valores
“anómalos” pero correctos es parte de toda experiencia empírica. A pesar de tener conocimiento
36
de ello, en muchos casos resulta complejo poder distinguir aquellos valores anómalos (pero
correctos) de los errores reales. Resulta particularmente complejo en lo que respecta a los
tiempos, como puede ser el caso de los tiempos de detección de errores, para los cuales se
establece un rango en base a promedios y desviaciones estándar (más adelante se detalla el
procedimiento). No así en el caso de las líneas de código, donde el rango está especificado por
la cantidad de líneas de cada archivo.
Debido a que todos los campos involucrados en el presente tipo de error son editables (sus
valores se “digitan” en la herramienta), es posible que ocurran errores al ingresar los mismos.
Una posible fuente de error en el caso de los tiempos, es que los mismos hayan sido tomados de
manera equivocada, ya sea porque no se comprendió cómo tomarlos o porque ocurrió un error
cuando se calcularon o registraron los mismos.
Por otra parte, una posible fuente de error para el caso de las líneas, puede deberse a que se haya
solicitado un pedido de corrección del código fuente, por encontrar un defecto bloqueante o que
cubra otros defectos. En este caso, a pesar de que se requiere registrar la línea del archivo
original, es posible que se haya registrado la línea del archivo corregido.
Medición
La granularidad es a nivel de celda, ya que involucra aquellos campos referentes a los tiempos y
líneas de código del defecto.
La forma de medir este tipo de error consiste en establecer, para todos los valores de las celdas
involucradas, si se encuentran o no dentro de determinado rango.
Para cada uno de los casos identificados (tiempos y líneas) se establecen los criterios para
determinar apropiadamente el rango que se va considerar para evaluar los valores, y se
identifican los outliers mediante consultas en SQL.
Para el caso de los tiempos, el rango tiene su mínimo en 0 y a priori no se podría definir un
valor máximo con certeza. Sin embargo, se determina estadísticamente un intervalo
considerando el valor medio y la desviación estándar de los tiempos registrados. Se considerará
libre de error a aquellos valores dentro del rango [0, media + 2*desviación estándar], mientras
que los tiempos fuera de dicho intervalo se considerarán como candidatos a contener errores, y
por lo tanto serán analizados de manera aislada.
Por otra parte, para el caso de las líneas de código se definirá un rango que tiene su mínimo en 1
y máximo igual a la cantidad de líneas que el archivo posee. Es necesario considerar aquí que
los defectos que no se encuentran asociados a ninguna línea en particular poseen en este campo
los valores 0, 999, 9999, y así sucesivamente. Por lo tanto, estos valores deberán tener un
tratamiento aparte ya que se situarán fuera del rango definido pero, sin embargo, se encuentran
libres de errores.
5.2.2 Estandarización
Interesa que todos los tiempos se encuentren registrados en la unidad de medida minutos, de
forma tal de que las operaciones (por ejemplo hallar promedios) o comparaciones que se
realicen entre los tiempos tengan sentido. Se considera, sin embargo, que dicha estandarización
queda incluida en el tipo de error Valor fuera de rango, ya que se puede pensar en tiempos muy
pequeños como expresados en horas, o por el contrario tiempos muy grandes expresados en
segundos (alejándose ambos del promedio definido).
37
Interesa además que los valores de los tiempos y líneas sean enteros. El significado de un
tiempo con fracciones es difícil de interpretar, y no interesa lograr una precisión mayor a
minutos. Por otra parte, carece de sentido que un número de línea no sea un valor entero.
Debido a que existe un control en la herramienta que no permite el ingreso de valores con
decimales, la posible fuente de error sería en este caso que el valor haya sido directamente
almacenado en la base de manera errónea.
La estandarización de las fechas de inicio y fin del experimento no resultan de particular interés.
Medición
La granularidad es a nivel de celda, ya que involucra aquellos campos referentes a los tiempos y
líneas de código del defecto.
La forma de medir este tipo de error consiste en verificar mediante la ejecución de consultas
SQL si los valores de los tiempos y líneas son enteros.
5.2.3 Registro inexistente
En este caso se identifican aquellos registros (tuplas) que no corresponden a ningún objeto de la
realidad. Esto es, registros que se encuentran almacenados en la base de datos, pero que se
asocian a un objeto que en la realidad no existe. Los registros inexistentes no deberían formar
parte de la base en cuestión ya que no reflejan la realidad, además de que su consideración a la
hora de analizar los datos afectaría el resultado obtenido. Es por este motivo que interesa
identificarlos.
Se analizan dos casos:
Registro de defectos
La causa conocida de este error corresponde a una equivocación, ya sea de distracción o
concepto, por parte del verificador al registrar un defecto que fue detectado en el código,
pero que no corresponde a un defecto real (donde el verificador consideró que existe un
defecto, en realidad no hay defecto alguno).
Archivos
La causa conocida de este error corresponde a una equivocación por parte del administrador
de la herramienta, al registrar archivos (.java) que no forman parte del experimento en
cuestión.
Medición
La granularidad es a nivel de tupla, ya que tuplas de las tablas mencionadas intervienen en este
tipo de error.
No se identifica una forma automática de medir este tipo de error, ya sea mediante una sentencia
SQL o un algoritmo determinado.
La métrica utilizada consiste entonces en la revisión manual de las tuplas involucradas en el
presente tipo de error, con el fin de identificar si las mismas corresponden o no a objetos de la
realidad. En el Capítulo 6 se analizará la viabilidad de llevar a cabo esta actividad para cada
caso.
38
5.2.4 Defecto mal registrado
Este tipo de error corresponde al caso de defectos que sí existen en la realidad, pero se “asocian”
de manera incorrecta a un registro de defecto. Esto significa que los datos que se registran de un
defecto no son válidos para ese defecto dado (a pesar de que sí son valores sintácticamente
correctos). Un defecto mal registrado no permite, en general, lograr identificarlo dentro del
código a partir de sus datos, ya que los mismos son incorrectos.
Cualquiera de los campos que se ingresan al registrar un defecto podría contener errores
ocasionados por una equivocación por parte del verificador, ya sea por falta de comprensión, un
error de concepto o distracción.
Con respecto a la clasificación del defecto, resulta sumamente complejo verificar si la misma se
realizó de manera correcta, motivo por el cual no se analizará este error en el marco del presente
proyecto.
Con respecto a la aplicación de las técnicas de testing, no resulta posible en principio identificar
cuándo las mismas fueron aplicadas de manera incorrecta a partir de errores en los datos. Una
posibilidad consiste en, ante la presencia de casos dudosos, chequear su correctitud contra los
casos de prueba diseñados. Este caso tampoco se analizará dentro del marco del presente
proyecto.
Medición
La granularidad es a nivel de celda, ya que involucra campos del registro de defecto.
No se identifica una forma automática de medir este tipo de error ya sea mediante una sentencia
SQL o un algoritmo determinado.
La métrica utilizada consiste entonces en la revisión manual de las celdas involucradas en el
presente tipo de error, con el fin de identificar si las mismas corresponden o no a datos válidos.
En el Capítulo 6 se analizará la viabilidad de llevar esta actividad a cabo para cada caso.
5.2.5 Valor fuera de referencial
Es posible verificar si, para ciertos campos, los valores que poseen en la base se encuentran
dentro de referenciales definidos. Además, para aquellos campos que contienen combos, se
pueden utilizar como referenciales los valores definidos para los mismos, de manera tal de
verificar que sólo existan valores permitidos en esos campos.
Puede suceder a causa de incorporación de datos externos, o de ingreso de datos directamente en
la base, que existan valores en los campos que no corresponden a ninguno de los permitidos por
un combo dado. Por otra parte, un usuario Administrador de la herramienta podría definir o
registrar de manera incorrecta el conjunto de valores permitidos para un campo. Este hecho
puede ocasionar que existan valores que es posible ingresar en la herramienta, pero que se
encuentran fuera del referencial considerado como válido para un campo dado.
Medición
La granularidad es a nivel de celda, ya que se verifica para determinados campos si existen
valores fuera de los referenciales.
La manera de medir este tipo de error consiste en comparar los valores de los campos
involucrados en este tipo de error contra los referenciales considerados como válidos
(previamente definidos).
39
Debido a que no se incorporaron datos externos en la base, sino que el ingreso de los mismos se
realiza siempre mediante el uso de la herramienta, la estrategia (parte manual, parte mediante
consultas SQL) utilizada para la medición de este tipo de error es la siguiente. En primera
instancia, se verifica en conjunto con la persona responsable del experimento si los valores
actualmente cargados en ciertas tablas son correctos (esto es, si son todos los requeridos y nada
más que esos). En caso de encontrar valores incorrectos, se analiza si existen registros en la base
(mediante consultas SQL) que utilicen y/o referencien dichos valores.
5.3 COMPLETITUD
Para la dimensión Completitud, se identifican los tipos de errores que se mencionan a
continuación.
Dentro del factor densidad:
o Valor nulo.
o Clasificación de defectos.
Dentro del factor cobertura, no se identifican errores en los a datos a tener en cuenta.
Esto se debe a que la cobertura hace referencia (en este caso de estudio en particular) a
la cantidad de defectos registrados en comparación con la cantidad de defectos que
realmente hay en el código verificado. No resulta de interés medir este tipo de error,
además de que no se conoce a priori cuántos defectos reales existen en los programas
verificados.
A continuación se describe cada uno de estos tipos de errores de manera detallada.
5.3.1 Valor nulo
Interesa conocer qué información fue registrada y cuál fue omitida. Para aquella información
que fue omitida, interesa conocer la causa de la omisión, y en caso que sea posible, determinar
el valor que debería tomar en lugar de nulo.
La existencia de valores nulos influye en el análisis de los datos que se lleve a cabo, ya que al
obtener estadísticas de los mismos se hace necesario dejar de lado aquellos valores vacíos. A
modo de ejemplo, un nulo en cualquiera de los tiempos que no sea considerado como tal al
momento de calcular un promedio, afectará el resultado obtenido.
Resulta necesario identificar en primera instancia cuáles son los campos que admiten nulos y
cuáles no, según el esquema actual de la base de datos. Luego, se identifican aquellos campos
que admiten nulos, pero deberían en la realidad contener algún valor distinto de vacío (el hecho
de que admitan nulos es un error en el diseño de la base de datos). Este último caso es el que
interesa medir. Se asume que el control sobre los campos declarados como no nulos se realiza
correctamente por el SGBD.
El motivo de omisión de los campos podría ser cualquiera de los siguientes:
El Verificador no ingresa el valor (puede ser por omisión accidental o por no saber
determinarlo).
Un error en el manejo de los datos (ya sea de la aplicación web, o de la base) que
ocasiona que el valor ingresado por el Verificador no se almacene correctamente.
40
Medición
La granularidad es a nivel de celda, ya que intervienen aquellos campos que deberían tener un
valor distinto de nulo.
Luego de identificados cuáles son los campos involucrados en este tipo de error, su forma de
medición consiste en verificar mediante la ejecución de consultas SQL si los mismos contienen
valores nulos.
5.3.2 Clasificación de defectos
Interesa que todos los defectos que han sido detectados en los distintos programas estén
clasificados según las categorías Defect Type y Qualifier dentro de la taxonomía IBM. Pueden
encontrarse además clasificados según otras categorías dentro de esta misma taxonomía, pero
estos datos no se tomarán en cuenta.
Con respecto a la taxonomía Beizer, interesa que el defecto haya sido clasificado en al menos el
Nivel 1 de dicha taxonomía. No es necesario que se logre la máxima precisión dentro de esta
taxonomía, pero sí que se cuente con una clasificación para cada defecto.
En resumen, todo defecto debe tener una clasificación según la taxonomía de Beizer y una
clasificación según la taxonomía de IBM, que consta de un valor en la categoría Defect Type y
un valor en la categoría Qualifier. Por lo tanto, la falta de cualquiera de ellas representa un error
de completitud.
La falta de clasificación en alguna de las categorías especificadas puede deberse a:
Una omisión por parte del Verificador al registrar un defecto, y omitir clasificarlo según
alguna de las taxonomías.
Falta de conocimiento por parte del Verificador al no saber cómo clasificar el defecto
que se está registrando.
Un error de la aplicación o la base de datos al almacenar la información referente a la
clasificación del defecto.
Medición
La granularidad es a nivel de tupla, ya que son las tuplas de registros de defectos las que
intervienen en este tipo de error.
La forma de medir este tipo de error consiste en verificar mediante la ejecución de consultas
SQL si los defectos han sido clasificados en las categorías de interés.
5.4 CONSISTENCIA
La consistencia captura la satisfacción de reglas semánticas definidas sobre los datos. Resulta
por lo tanto necesario identificar en primera instancia cuáles son las reglas existentes, para
evaluar luego su cumplimiento (ó no) en el dominio bajo estudio. Vale destacar que en la base
de datos del experimento muchos de estos aspectos son controlados por el SGBD.
Por otra parte, los controles realizados por el SGBD se aplican sobre todos los datos, ya que es
sabido que no se incorporan datos por fuera del manejador.
Para la dimensión Consistencia, se identificaron los tipos de errores que se mencionan a
continuación.
41
Dentro del factor integridad intra-relación:
o Reglas de integridad intra-relación.
o Valor único.
Dentro del factor integridad referencial:
o Referencia inválida.
A continuación se describe cada uno de estos tipos de errores de manera detallada.
5.4.1 Reglas de integridad intra-relación
Se definen un conjunto de reglas sobre los atributos que deben ser satisfechas en la base bajo
estudio. El hecho de que alguna de estas reglas sea violada, afecta la consistencia de los datos y
por lo tanto cualquier análisis que se lleve a cabo a partir de estos.
La causa principal por la cual estas reglas no son satisfechas, es la falta de definición de
restricciones en la base de datos (a nivel de diseño). En este caso, podría ocurrir un error cuando
un usuario Verificador registra cierta información sobre los defectos y/o su experimento,
ocasionando la violación de una regla que no se encuentra controlada en la base. A modo de
ejemplo, puede ocurrir una confusión acerca de cuál es la técnica de verificación que se está
aplicando, ocasionando que los datos que se ingresen no sean correctos para la técnica en
cuestión.
Medición
La granularidad es a nivel de celda, ya que involucra aquellos campos que deben satisfacer las
reglas definidas.
La forma de medir este tipo de error consiste en verificar mediante la ejecución de consultas
SQL si se cumplen las reglas de integridad intra-relación definidas para la realidad bajo estudio.
5.4.2 Valor único
Interesan aquellas tuplas que contengan el mismo valor en ciertos atributos (distintos a la clave
primaria), pero que deberían ser únicos.
Resulta necesario identificar en primera instancia cuáles son los campos que son declarados
como únicos y cuáles no, según el esquema actual de la base de datos. Luego, se identifican
aquellos campos que no contienen la restricción de unicidad, pero que deberían tenerla (para
reflejar fielmente la realidad). Estas últimas tuplas son las que interesa medir. Se asume que el
control sobre los campos declarados como únicos se realiza correctamente por el SGBD.
La causa de este error es la no definición de restricciones unique sobre los campos involucrados.
Medición
La granularidad es a nivel de celda, ya que involucra aquellos campos que deben contener
valores únicos.
La forma de medir este tipo de error consiste en verificar mediante la ejecución de consultas
SQL si se cumplen las restricciones de unicidad en las celdas que interesa medir.
42
5.4.3 Referencia inválida
Es necesario considerar en el presente análisis la satisfacción de reglas entre atributos de
distintas tablas. Instanciando esto a la base de datos bajo estudio, se identifican referencias hacia
determinadas tuplas que no existen, y por lo tanto resultan ser referencias inválidas.
La fuente de este tipo de error se debe a un error en el diseño del esquema de la base de datos,
ya que se omite la definición de foreign keys sobre ciertos atributos.
En primera instancia, se analizan las restricciones de integridad referencial existentes sobre la
base de datos en cuestión. A partir de dicho análisis, se obtienen los campos para los cuales la
definición de foreign key fue omitida.
Se analizan tres casos:
Taxonomía inválida
Se referencia a una taxonomía que no existe en la base del experimento.
Registro de defecto inválido
Se referencia a una registro de defecto que no existe en la base del experimento. Una
posible causa de este error podría ser que la eliminación de defectos no se realice de manera
correcta. Esto es, que al eliminar un defecto se elimine su registro, pero no las tuplas que
referencian al mismo.
Categoría padre inválido
Se referencia a categorías que no existen en la base en del experimento. Este hecho podría
ocasionar una inconsistencia que influye en cualquier análisis que se realice en los datos
respecto a la clasificación de los defectos encontrados.
Medición
La granularidad es a nivel de tupla, ya que involucra tuplas que referencian a otras inexistentes.
La forma de medir este tipo de error consiste en verificar mediante la ejecución de consultas
SQL si existen tuplas que contengan referencias inválidas.
5.5 UNICIDAD
Para la dimensión Unicidad, se identifican los tipos de errores que se mencionan a continuación.
Dentro del factor duplicación:
o Registro duplicado.
Dentro del factor contradicción:
o Registro contradictorio.
A continuación se describe cada uno de estos tipos de errores de manera detallada.
5.5.1 Registro duplicado
Se identifica este tipo de error cuando existen dos o más registros que aparecen repetidos de
manera exacta. Existen dos situaciones:
43
Cuando contienen el mismo valor en la clave y demás atributos (o en su defecto valores
nulos).
A pesar de contener distinta clave primaria, hacen referencia al mismo objeto de la
realidad y contienen los mismos datos en los campos que se definan (según el criterio
de duplicación considerado).
A pesar de que los controles del SGBD evitan la existencia de registros duplicados con la
misma clave primaria, se realizan los chequeos necesarios para verificar que no existan registros
repetidos (según el criterio que será definido) en la base bajo estudio.
La causa de este tipo de error se puede deber a una equivocación por parte del usuario
Verificador (por ejemplo al registrar varias veces el mismo defecto), o un error de la
herramienta que ocasione se almacenen registros repetidos en la base.
Es importante considerar este tipo de error ya que, de no ser así, los resultados obtenidos a partir
del análisis de los datos que se lleve a cabo resultarían erróneos. A modo de ejemplo, si se
poseen registros de defectos duplicados, esto es, que hacen referencia al mismo defecto, la
cantidad de defectos total que se obtenga no será real (se estarán contando registros de más).
Medición
La granularidad es a nivel de tupla, ya que involucra aquellas tuplas que se encuentren
duplicadas.
La forma de medir este tipo de error consiste en verificar mediante la ejecución de consultas
SQL si existen tuplas duplicadas, según los criterios de duplicación que se definan.
5.5.2 Registro contradictorio
Se identifica este tipo de error cuando existen dos o más registros que aparecen repetidos de
manera contradictoria. Esto significa que contienen distinto valor en la clave y/o demás
atributos (o en su defecto valores nulos), a pesar de que hacen referencia al mismo objeto de la
realidad.
El ejemplo más claro de este tipo de error es tener dos clasificaciones distintas dentro de una
misma taxonomía, asociadas al mismo defecto. Es decir, un defecto debe estar clasificado de
una única manera según una misma taxonomía.
La causa de este tipo de error se puede deber a una equivocación por parte del Verificador, o un
error de la herramienta que ocasione se almacenen registros contradictorios en la base. Por
ejemplo, errores al refrescar los combos que contienen información de las categorías en la
herramienta utilizada, pudieron ocasionar que los niveles de las categorías ingresadas para
Beizer no se correspondan con la jerarquía definida.
Es importante considerar este tipo de error ya que, de no ser así, los resultados obtenidos a partir
del análisis de los datos que se lleve a cabo resultarían erróneos. A modo de ejemplo, si se
requiere conocer cuántos registros de defectos fueron clasificados según determinada categoría,
podría estar considerando dos veces el mismo defecto (en dos categorías distintas), sin lograr
conocer cuál es la clasificación real del mismo.
Medición
La granularidad es a nivel de tupla, ya que involucra aquellas tuplas que son contradictorias.
44
La forma de medir este tipo de error consiste en verificar mediante la ejecución de consultas
SQL y algoritmos programados si existen tuplas contradictorias.
5.6 DIMENSIONES RELACIONADAS CON EL TIEMPO
Se considera que no existen errores en la calidad de los datos bajo estudio desde el punto de
vista de las dimensiones relacionadas con el tiempo.
Los datos son actuales y vigentes. Además, es conocido que los datos no han sufrido
modificaciones desde su ingreso, y que los mismos no cambian con el tiempo ya que son el
resultado de la ejecución de un experimento específico.
45
6 MEDICIÓN DE LA CALIDAD
En este capítulo se muestra cómo se realiza la medición de los posibles errores identificados
sobre la base de datos de la herramienta Grillo. Llamamos error a cada instanciación de un tipo
de error (dentro de los identificados en el capítulo anterior) sobre un atributo y/o tabla
específica, dependiendo de su granularidad.
La gran mayoría de los posibles errores identificados fueron medidos (existen algunas pocas
excepciones correspondientes a mediciones manuales que no fueron realizadas). Se presenta a
continuación la medición de aquellos considerados significativos y representativos del total. El
detalle de todos los errores así como sus mediciones se presenta en el Anexo A - Catálogo de
Errores.
Para cada error detallado, se describe la siguiente información:
El atributo y/o tabla involucrada.
Su forma de medición.
El resultado obtenido a partir de la medición.
6.1 VALOR FUERA DE RANGO
El tipo de error Valor fuera de rango se mide sobre los tiempos y líneas de código.
La forma de medir estos errores consiste en establecer un rango al que debe pertenecer el valor
de cada celda, y verificarlo mediante la ejecución de consultas SQL.
Se presenta en esta sección el detalle de la medición realizada para el atributo time_deteccion de
la tabla Registro_Defecto.
6.1.1 Valor fuera de rango en el atributo time_deteccion de la tabla
Registro_Defecto
Para obtener el rango dentro del cual deben situarse los tiempos de detección de los defectos, se
calcula el promedio y desviación estándar discriminando por tipo de defecto (según la categoría
Defect Type de la taxonomía IBM). Es necesario además que no se consideren los defectos
detectados con la técnica “Inspecciones”, ya que los mismos tienen tiempo de detección igual a
0 y alterarían el promedio de manera no deseada.
La consulta que permite obtener dichos datos es la siguiente:
SELECT DISTINCT vc.nombre AS "IBM Defect Type", AVG(time_deteccion) AS "Promedio",
SQRT(VAR_SAMP(time_deteccion)) AS "Desviación estandar"
FROM registro_defecto rd, registro_taxonomia rt, valor_categoria vc, experimento e, tecnica t
WHERE rt.registro_id=rd.id AND rt.valor_categoria_id = vc.id AND vc.categoria_id=5 AND
rd.experimento_id=e.id AND e.tecnica_id=t.id AND t.nombre != 'Inspecciones'
GROUP BY vc.nombre
46
La Tabla 3 muestra para cada tipo de defecto, el promedio y desviación estándar de los tiempos
de detección de los defectos que son obtenidos.
Tabla 3 – Promedio y desviación estándar por tipo de defecto
IBM Defect Type Promedio Desviación
estándar
Algorithm/Method 10 12
Assign/Initialization 7 9
Checking 6 25
Function/Class/Object 7 5
Interface/O-O Messages 6 6
En vista de los resultados obtenidos, es posible definir un rango para cada tipo de defecto (según
IBM Defect Type), y de esta forma identificar los tiempos de detección que no se encuentran
dentro del rango correspondiente. Como ya se mencionó, el rango a considerar es [0, promedio
+ 2*desv. estándar].
La consulta para hallar los outliers es la siguiente (el contenido de la tabla reg_rango_tiempos
se detalla en el Capítulo 7: REGISTRO DE ERRORES).
SELECT DISTINCT rd.id, rd.time_deteccion
FROM registro_defecto rd, registro_taxonomia rt, valor_categoria vc, tecnica t, experimento e,
reg_rango_tiempos ra
WHERE rt.registro_id=rd.id AND rt.valor_categoria_id=vc.id AND rd.experimento_id=e.id
AND e.tecnica_id=t.id AND t.nombre != 'Inspecciones' AND (vc.id=ra.valor_categoria_id
AND rd.time_deteccion > (ra.promedio + (ra.desv_estandar*2)))
La Tabla 4 resume el resultado obtenido a partir de la ejecución de la consulta, mostrando la
cantidad de registros con valores que se encuentran fuera de rango por cada tipo de defecto, en
al atributo time_deteccion de la tabla Registro_Defecto.
Tabla 4 – Cantidad de registros con valores fuera de rango
IBM Defect Type Cantidad de registros con valores fuera de rango
Function/Class/Object 1
Interface/O-O Messages 2
Checking 2
Algorithm/Method 7
Assign/Initialization 9
Se observa que se detectan un total de 21 registros que contienen valores en el campo
time_deteccion fuera del rango definido.
47
En la Tabla 5 se destacan aquellas tuplas de la tabla Registro_Defecto cuyo valor se aleja de
manera más notoria del rango definido, incluyendo su tiempo de detección, tipo de defecto y
valor máximo para el rango definido. En particular, existen dos registros de defectos (348 y
317) cuyo valor en el campo time_deteccion es casi seis veces mayor en comparación al
máximo definido.
Tabla 5 – Tuplas con los valores más lejanos al rango definido
Id Registro_Defecto Tiempo de detección IBM Defect Type Máximo
360 35 Function/Class/Object 17
132 60 Assign/Initialization 25
304 64 Assign/Initialization 25
348 312 Checking 56
317 376 Checking 56
Considerando además que existen un total de 1009 tuplas en la tabla Registro_Defecto, la
proporción de aquellos que contienen valores fuera de rango en el tiempo de detección resulta
en un 2,1%. Sin embargo, estos valores pueden tener un peso importante a la hora de analizar la
información, debido a la importante distancia con la que se alejan del promedio definido.
6.2 VALOR FUERA DE REFERENCIAL
El tipo de error Valor fuera de referencial se mide sobre el atributo nombre de cada una de las
tablas Tecnica, Software, TipoDefecto, Estructura, Taxonomia y Categoria.
La forma de medir estos errores consiste en verificar mediante la ejecución de consultas SQL si
el valor de cada celda se encuentra dentro de un referencial previamente definido, y que es
considerado como válido.
Se presenta en esta sección el detalle de la medición realizada para el atributo nombre de la
tabla Categoria.
6.2.1 Valor fuera de referencial en el atributo nombre de la tabla Categoria
Como ya se mencionó, la taxonomía IBM es ortogonal. La clasificación de un defecto según
esta taxonomía consiste en un conjunto de valores correspondientes a distintas categorías. En el
experimento bajo estudio, solamente interesa registrar los valores correspondientes a las
categorías DefectType y Qualifier.
En este error en particular se distinguen dos casos distintos, con diferentes granularidades. Por
un lado, se busca de manera manual cuáles son los valores que se encuentran fuera del
referencial definido para el atributo nombre de la tabla Categoria. Como se observa, este caso
es a nivel de celda.
Por otro lado, se procede a encontrar cuáles son las tuplas de la tabla Registro_Taxonomia que
corresponden a alguna de estas categorías, ya que son valores que se encuentran fuera del
referencial válido. Aquí se mide (dentro del mismo error) con granularidad a nivel de tupla.
Se detecta manualmente que la tabla Categoria contiene cinco valores que no se encuentran
dentro del referencial definido. Estos son: Section, Actividad, Trigger, Impacto, Age y Source.
La consulta que mide este error a nivel de tupla (aquellas que se encuentran fuera del
referencial) es la siguiente:
48
SELECT DISTINCT rd.id, rt.id, c.nombre
FROM registro_defecto rd, categoria c, valor_categoria vc, registro_taxonomia rt
WHERE rt.registro_id=rd.id AND rt.valor_categoria_id=vc.id AND vc.categoria_id=c.id
AND c.nombre NOT IN ('Defect Type', 'Qualifier', 'BezierNivel1', 'BezierNivel2', 'BezierNivel3',
'BezierNivel4')
Como resultado de la medición, se obtienen 3721 registros que contienen este error. A modo de
resumen, la Tabla 6 muestra la cantidad de registros de la tabla Registro_Defecto con valores
fuera de referencial por cada categoría. Vale destacar que existen 685 registros que por contener
el error Referencia inválida en el atributo registro_id no son considerados en la siguiente tabla.
Tabla 6 – Cantidad de registros con valores fuera de referencial
Categoría Cantidad de registros con valores fuera de referencial
Section 1009
Age 1006
Source 1006
Actividad 5
Trigger 5
Impacto 5
A partir de la Tabla 6 se observa que todos los defectos registrados han sido clasificados según
la categoría Section (recordar que existen un total de 1009 registros de defecto), y casi un 100%
en las categorías Age y Source. Por otra parte, solamente un 0,5% de los defectos han sido
clasificados según Actividad, Trigger e Impacto.
6.3 VALOR NULO
Se incluyen en este tipo de error los atributos que deberían ser no nulos, pero no fueron
definidos como tales en la base de datos.
La forma de medir estos errores consiste en verificar mediante la ejecución de consultas SQL si
los valores de las celdas que interesa medir se encuentran vacíos.
Se presenta en esta sección el detalle de la medición realizada para el atributo time_casos de la
tabla Experimento para experimentos asociados a técnicas de verificación dinámicas.
6.3.1 Valor nulo en el atributo time_casos de la tabla Experimento para
técnicas dinámicas
Mediante la siguiente consulta se verifica si existen valores nulos para el atributo involucrado.
SELECT e.id FROM tecnica t, experimento e
WHERE e.tecnica_id=t.id AND t.nombre !='Inspecciones' AND e.time_casos IS NULL
A partir del resultado obtenido, se observan un total de 3 registros que contienen este error.
Considerando que existen un total de 44 tuplas en la tabla Experimento, la proporción de
aquellos que contienen valores nulos en el campo time_casos para las técnicas dinámicas resulta
en un 6,8%. Vale destacar que los 3 registros obtenidos como resultado de esta consulta,
coinciden con aquellos obtenidos para la medición sobre el atributo time_ejecucion.
49
El atributo time_casos representa el tiempo de diseño de casos de prueba. La existencia de nulos
en este campo en particular, se puede deber a una omisión por parte del Verificador al ingresar o
calcular dicho tiempo.
6.4 REGLAS DE INTEGRIDAD INTRA-RELACIÓN
Los atributos que intervienen en la definición de reglas de integridad intra-relación son los
correspondientes a tiempos, líneas de código, técnica de verificación y tipo del defecto.
La forma de medir este tipo de error consiste en verificar mediante la ejecución de consultas
SQL si se cumplen las reglas de integridad intra-relación definidas.
Se presenta en esta sección el detalle de la medición realizada sobre el atributo time_deteccion
de la tabla Registro_Defecto para el caso de ejecución de técnicas de verificación estáticas.
6.4.1 Regla sobre el atributo time_deteccion de la tabla Registro_Defecto
para técnicas estáticas
Para las técnicas de verificación estáticas, el tiempo de detección del defecto debe ser igual a 0.
Esto se debe a que durante la ejecución de una técnica estática se trabaja sobre el código,
detectando directamente los defectos (al contrario de las técnicas dinámicas en las cuales un
defecto se manifiesta a través de una falla externa).
Una posible causa de este error en particular, puede ser incluir el tiempo incurrido en clasificar
el defecto dentro del tiempo de detección del mismo, lo cual ocasiona que sea mayor a 0.
En este caso la regla que se define es que el atributo time_deteccion de la tabla
Registro_Defecto, debe tener el valor 0 para defectos hallados a partir de la ejecución de
técnicas estáticas.
La consulta que mide este error es la siguiente:
SELECT rd.id, rd.time_deteccion
FROM tecnica t, experimento e, registro_defecto rd
WHERE rd.experimento_id=e.id AND e.tecnica_id=t.id AND t.nombre='Inspecciones' AND
rd.time_deteccion!=0
A partir del resultado obtenido, se observan un total de 90 registros que contienen este error.
Considerando que existen un total de 1009 tuplas en la tabla Registro_Defecto, la proporción de
aquellos que no cumplen con la regla de integridad intra-relación recién definida resulta en un
8,9%.
6.5 REFERENCIA INVÁLIDA
Los atributos involucrados son aquellos sobre los cuales se deberían tener la restricción de
foreign key, pero no la poseen.
Se miden las tuplas que contienen referencias inválidas (esto es, apuntan a tuplas que no existen
en la base), mediante la ejecución de consultas SQL.
Se presenta en esta sección el detalle de la medición realizada sobre el atributo registro_id de la
tabla Registro_Taxonomia.
50
6.5.1 Referencia inválida en el atributo registro_id de la tabla
Registro_Taxonomia
La consulta que mide este error es la siguiente:
SELECT rt.id FROM registro_taxonomia rt WHERE registro_id NOT IN
(SELECT id FROM registro_defecto)
order by registro_id
A partir del resultado obtenido, se observan un total de 472 registros que contienen este error.
Considerando que existen un total de 9682 tuplas en la tabla Registro_Taxonomia, la proporción
de aquellos que poseen referencias inválidas en el campo registro_id resulta en un 4,8%. Vale
destacar que dentro de los registros retornados por la consulta anterior, existen 421 que ya
fueron considerados dentro del error Valor fuera de referencial en el atributo nombre de la
tabla Categoria.
Por otra parte, los 472 registros devueltos por la consulta anterior referencian a 33 registros de
defectos que no existen (esto se debe a que cada tupla de la tabla Registro_Defecto se encuentra
asociada a varias de Registro_Taxonomia).
6.6 REGISTRO DUPLICADO
Las tuplas que intervienen en el presente tipo de error corresponden a tuplas de las tablas
Registro_Defecto y Registro_Taxonomia.
La forma de medir estos errores consiste en verificar la existencia de tuplas duplicadas mediante
la ejecución de consultas SQL, según criterios de duplicación definidos. Esto es, que existen dos
o más tuplas de la tabla Registro_Defecto con el mismo valor en ciertos atributos que serán
definidos, o que existen dos o más tuplas de las tablas Registro_Taxonomia que se asocien a la
misma categoría para el mismo defecto.
Se presenta en esta sección el detalle de la medición realizada sobre las tuplas de
Registro_Taxonomia para la taxonomía IBM.
6.6.1 Registro_Taxonomía duplicado para la taxonomía IBM
Se considera que dos o más tuplas de la tabla Registro_Taxonomia se encuentran duplicadas si
se asocian a una misma tupla de Registro_Defecto y una misma tupla de Categoria (dentro de la
taxonomía de IBM).
La consulta que traduce las condiciones recién mencionadas y mide este error, es la siguiente:
(SELECT r1.id, r1.registro_id
FROM registro_taxonomia r1, registro_taxonomia r2, valor_categoria vc1, valor_categoria
vc2
WHERE r1.valor_categoria_id = vc1.id AND r2. valor_categoria_id = vc2.id AND
r1.registro_id = r2.registro_id AND r1. valor_categoria_id =r2. valor_categoria_id AND
r1.id< r2.id AND r1.taxonomia_id = 1 AND r2.taxonomia_id = 1)
UNION
(SELECT r2.id, r2.registro_id
FROM registro_taxonomia r1, registro_taxonomia r2, valor_categoria vc1, valor_categoria
vc2
51
WHERE r1. valor_categoria_id = vc1.id AND r2. valor_categoria_id = vc2.id AND
r1.registro_id = r2.registro_id AND r1. valor_categoria_id = r2. valor_categoria_id AND
r1.id< r2.id AND r1.taxonomia_id = 1 AND r2.taxonomia_id = 1)
El resultado de la ejecución de esta consulta retorna un total de 1705 registros de la tabla
Registro_Taxonomia, los cuales corresponden a 171 registros de la tabla Registro_Defecto (esto
se debe a que cada tupla de Registro_Defecto se encuentra asociada a varias tuplas de
Registro_Taxonomia). Debido a que el resultado de la consulta incluye también los registros
“originales”1, la cantidad que se encuentran duplicados son un total de 1534. Considerando que
existen 9682 tuplas en la tabla Registro_Taxonomia, la proporción de aquellas que se
encuentran duplicadas resulta en un valor del 15,8%.
Vale destacar que dentro de los registros retornados por la consulta anterior, existen 773 ya
considerados dentro del error Valor fuera de referencial en el atributo nombre de la tabla
Categoria y 204 incluidos en el error Referencia inválida en el atributo registro_id.
Se observa a partir del resultado obtenido que la cantidad de tuplas de la tabla
Registro_Taxonomia duplicados para un mismo defecto y una misma categoría, varía desde un
valor mínimo de 2 hasta un máximo de 44. La Tabla 7 permite visualizar, a modo de ejemplo,
algunos de las tuplas de la tabla Registro_Defecto que contienen tuplas de Registro_Taxonomia
duplicados, así como su cantidad para cada caso.
Tabla 7- Cantidad de registros duplicados por tupla
Identificador Registro_Defecto Cantidad de registros duplicados
29 2
48 6
79 8
473 16
165 20
40 25
49 29
901 44
Se puede concluir además que ocurren errores en la herramienta al almacenar los datos, que
ocasionan la existencia de tuplas duplicadas en la base.
6.7 REGISTRO CONTRADICTORIO
Existen dos casos de contradicción. El primero involucra las tuplas de la tabla
Registro_Taxonomia, y se presenta cuando dos o más tuplas que representan distintas
clasificaciones en una misma taxonomía, están asociadas a un mismo defecto (es decir,
referencian a una misma tupla de la tabla Registro_Defecto). La contradicción radica en que un
defecto no puede tener dos clasificaciones distintas según una misma taxonomía. Esta situación
se debe a un error en el diseño de la base de datos, que se describe en el Capítulo 8: LIMPIEZA
Y MIGRACIÓN DE LOS DATOS.
El segundo caso de contradicción involucra las tuplas de la tabla Archivo_Software. Se presenta
cuando existen dos o más tuplas de la tabla Archivo_Software que asocian una misma tupla de
1 Decimos que un registro A es “original” si existe al menos un registro B que sea duplicado de A. Estos
registros no se deben considerar dentro del total de duplicados.
52
la tabla Archivo con distintas tuplas de la tabla Software (es decir, cuando un archivo pertenece
a dos o más softwares distintos). La contradicción está en que en la realidad planteada, dos
software distintos no pueden tener ningún archivo en común. Una vez más, esta situación se
debe a un error en el diseño de la base de datos.
La forma de medir estos errores consiste en verificar mediante la ejecución de consultas SQL y
algoritmos programados la existencia de tuplas contradictorias.
Se presenta en esta sección el detalle de la medición realizada sobre la tabla
Registro_Taxonomia para la taxonomía Beizer.
6.7.1 Registro_Taxonomia contradictorio para la taxonomía Beizer
La forma de medir este error consiste en verificar la existencia de tuplas contradictorias.
Recordar que la taxonomía de Beizer es jerárquica. Existen distintas categorías y subcategorías
para clasificar los defectos, numeradas 1xxx, 2xxx, 3xxx y 4xxx. Las subcategorías son de la
forma 11xx, 12xx, 21xx, y así sucesivamente. De esta forma, un defecto se clasifica, por
ejemplo, como 1xxx, 11xx (más específico) o 211x.
En los datos bajo estudio se miden de manera distinta dos casos similares de contradicción con
respecto a esta taxonomía. El primer caso de contradicción se presenta cuando un defecto tiene
asociadas dos (o más) clasificaciones distintas, pero hijas de una misma categoría en la
jerarquía. Por ejemplo, un defecto aparece clasificado como 11xx y como 12xx, ambas
clasificaciones hijas de la categoría 1xxx.
El otro caso de contradicción, se da cuando un defecto tiene asociadas dos (o más)
clasificaciones distintas, las cuales no están relacionadas en la jerarquía. Por ejemplo, un defecto
aparece clasificado como 11xx y como 22xx.
Debido al diseño del esquema de la base de datos (inadecuado para representar la jerarquía), se
requiere definir dos procesos de medición distintos para cada caso de contradicción descripto.
Existe un tercer caso que no es considerado una contradicción y sucede cuando un defecto tiene
asociadas varias clasificaciones, pero todas ellas pertenecientes a una misma rama de la
jerarquía. Por ejemplo, un defecto puede estar clasificado como 1xxx y como 12xx. En este
caso, simplemente se considera la clasificación más precisa (12xx en el ejemplo).
La consulta que realiza la medición del primer caso de contradicción es la siguiente:
(SELECT r1.id, r1.registro_id
FROM registro_taxonomia r1, registro_taxonomia r2, valor_categoria vc1, valor_categoria
vc2
WHERE r1.valor_categoria_id = vc1.id AND r2. valor_categoria_id = vc2.id AND
r1.registro_id = r2.registro_id
AND r1. valor_categoria_id!= r2. valor_categoria_id AND vc1.categoria_id =
vc2.categoria_id AND r1.taxonomia_id = 2 AND r2.taxonomia_id = 2)
UNION
(SELECT r2.id, r2.registro_id
FROM registro_taxonomia r1, registro_taxonomia r2, valor_categoria vc1, valor_categoria
vc2
WHERE r1. valor_categoria_id = vc1.id AND r2. valor_categoria_id = vc2.id AND
r1.registro_id = r2.registro_id
53
AND r1. valor_categoria_id!= r2. valor_categoria_id AND vc1.categoria_id =
vc2.categoria_id AND r1.taxonomia_id = 2 AND r2.taxonomia_id = 2)
A partir de la ejecución de la consulta, se obtienen 2 registros contradictorios, los cuales
corresponden al mismo registro de defecto.
Para la medición del segundo caso de contradicción, se define un algoritmo mediante
programación. Como resultado de su ejecución, se obtienen un total de 63 registros de la tabla
Registro_Taxonomia, los cuales corresponden a 21 registros de la tabla Registro_Defecto.
Se encuentran entonces un total de 65 tuplas de la tabla Registro_Taxonomia contradictorios,
que corresponden a 22 tuplas de la tabla Registro_Defecto. Debido a que el resultado de la
consulta incluye también los registros “originales”, la cantidad de registros contradictorios son
un total de 43. Considerando que existen 9682 tuplas en la tabla Registro_Taxonomia, la
proporción de aquellos contradictorios resulta en tan solo un 0,4%. Sin embargo, es necesario
conocer para todas estas tuplas cuál es la categoría (dentro del conjunto de posibles valores) en
la cual se clasificó el registro de defecto para la taxonomía de Beizer.
Se observa a partir del resultado obtenido que la cantidad de registros contradictorios, varía
desde un valor mínimo de 2 hasta un máximo de 6. La Tabla 8 permite visualizar, a modo de
ejemplo, algunas tuplas de la tabla Registro_Defecto que contienen tuplas de
Registro_Taxonomia contradictorios, así como su cantidad para cada caso.
Tabla 8 – Cantidad de registros contradictorios por tupla
Identificador Registro_Defecto Cantidad de registros contradictorios
asociados
897 2
278 3
432 6
6.8 RESUMEN
La Tabla 9 muestra todos los errores que fueron identificados sobre la base de datos, indicando
a qué dimensión, factor y tipo de error corresponden. Se incluye si fue posible llevar a cabo la
medición de cada error, y en caso positivo si la medición es manual o automática (SQL,
programación). Finalmente, se muestra cuántos objetos erróneos se obtienen como resultado de
la ejecución de la medición (discriminado por error y por tipo de error).
Tabla 9 – Errores identificados
Dimensión Factor Tipo de error Objeto Medición
Cantidad de
instancias con
error
Exactitud Exactitud
sintáctica
Valor fuera de
rango
Experimento.time_c
asos
NO 0
32
Experimento.time_e
jecucion
NO 0
Registro_Defecto.ti
me_deteccion
SQL 21
Registro_Defecto.li
nea
SQL 8
54
Registro_Defecto.li
nea_estructura
SQL 3
Estandarización
Experimento.time_c
asos
SQL 0
0
Experimento.time_e
jecucion
SQL 0
Registro_Defecto.ti
me_deteccion
SQL 0
Registro_Defecto.li
nea
SQL 0
Registro_Defecto.li
nea_estructura
SQL 0
Exactitud
semántica
Registro
inexistente
Registro_Defecto NO 0 1
Archivo Manual 1
Defecto mal
registrado
Registro_Defecto.li
nea
NO 0
0
Registro_Defecto.li
nea_estructura
NO 0
Registro_Defecto.ti
me_deteccion
NO 0
Registro_Defecto.d
escripcion
NO 0
Registro_Defecto.es
tructura_id
NO 0
Registro_Defecto.a
rchivo_id
NO 0
Registro_Defecto.ti
po_id
NO 0
Registro_Taxonomi
a.valor_categoria_i
d
NO 0
Valor fuera de
referencial
Tecnica.nombre Manual 0
3721
Software.nombre Manual 0
Tipo_Defecto.nomb
re
Manual 0
Estructura.nombre Manual 0
Taxonomia.nombre Manual 0
Categoria.nombre /
Registro_Taxonomi
a
SQL 3721
Completitud Densidad Valor nulo
Usuario.perfil_id SQL 0
1332
Registro_Defecto.ti
po_id
SQL 0
Registro_Defecto.li
nea
SQL 0
Experimento.nombr
e
SQL 0
Registro_Defecto.ti
me_deteccion
SQL 0
Registro_Taxonomi
a.registro_id
SQL 0
Experimento.time_e
jecucion
SQL 3
Registro_Taxonomi
a.taxonomia_id
SQL 1324
55
Registro_Taxonomi
a.valor_categoria_i
d
SQL 2
Experimento.time_c
asos (técnica
dinámica)
SQL 3
Clasificación de
defectos
Registro_Defecto
(para IBM)
SQL 3
3 Registro_Defecto
(para Beizer)
SQL 0
Consistencia
Integridad
intra-relación
Regla de
integridad intra-
relación
Experimento.time_c
asos (técnica
estática)
SQL 0
92
Experimento.time_c
asos (técnica
dinámica)
SQL 0
Registro_Defecto.ti
me_deteccion
SQL 90
Registro_Defecto.li
nea_estructura
SQL 0
Experimento.time_e
jecucion
SQL 2
Valor único
Categoria.nombre SQL 0
0
Valor_Categoria.no
mbre,
categoria_padre
SQL 0
Experimento.nombr
e
SQL 0
Integridad
referencial
Referencia
inválida
Registro_Taxonomi
a.taxonomia_id
SQL 0
491 Registro_Taxonomi
a.registro_id
SQL 472
Valor_Categoria.ca
tegoria_padre
SQL 19
Unicidad
Duplicación Registro
duplicado
Registro_Defecto SQL 0
1705 Registro_Taxonomi
a (para IBM)
SQL 1705
Registro_Taxonomi
a (para Beizer)
SQL 0
Contradicción Registro
contradictorio
Archivo_Software SQL 4
214
Registro_Taxonomi
a (para IBM)
SQL 145
Registro_Taxonomi
a (para Beizer)
SQL y
Programa-
ción
65
56
6.9 VALOR DE CALIDAD DE LOS DATOS
La Tabla 10 muestra el valor de calidad obtenido por cada tabla discriminada por tipo de error, y
por cada tipo de error que fue medido. El valor de calidad se calcula como: cantidad de tuplas
sin error / cantidad de tuplas totales (por tabla).
Para calcular el valor de calidad por tipo de error (sin discriminar por tabla), se realiza un
promedio del valor de calidad obtenido por cada tabla que interviene en dicho tipo de error.
Tabla 10 – Valor de calidad
Dimensión Factor Tipo de error Tabla
Valor de
calidad por
tabla por tipo
de error
Valor de
calidad
por tipo
de error
Exactitud Exactitud
sintáctica
Valor fuera de rango Registro_Defecto 0,97 0,97
Estandarización Registro_Defecto 1,00 1,00
Experimento 1,00
Exactitud
semántica
Registro inexistente Archivo 0,98 0,98
Defecto mal registrado N/A N/A N/A
Valor fuera de
referencial
Tecnica 1,00
0,87
Software 1,00
Tipo_Defecto 1,00
Estructura 1,00
Taxonomia 1,00
Categoria 0,50
Registro_Taxonomia 0,62
Completitud Densidad Valor nulo Usuario 1,00
0,93 Experimento 0,86
Registro_Defecto 1,00
Registro_Taxonomia 0,86
Clasificación de
defectos
Registro_Defecto 1,00 1,00
Consistencia Integridad
intra-relación
Regla de integridad
intra-relación
Experimento 0,95 0,93
Registro_Defecto 0,91
Valor único Experimento 1,00
1,00 Categoria 1,00
Valor_Categoria 1,00
Integridad
referencial
Refrencia inválida Registro_Taxonomia 0,95 0,93
Valor_Categoria 0,90
Unicidad Duplicación Registro duplicado Registro_Defecto 1,00 0,91
Registro_Taxonomia 0,82
Contradicción Registro contradictorio Registro_Taxonomia 0,98 0,95
Archivo_Software 0,92
57
Se observa que los tipos de errores con menor valor de calidad (esto es, aquellos para los que se
identificaron una mayor cantidad de tuplas erróneas) son:
Valor fuera de referencial en el atributo nombre de la tabla Categoria.
Valor nulo en los atributos time_ejecucion, time_casos para técnicas dinámicas y
taxonomía_id.
Registro_Taxonomía duplicado para las taxonomías IBM y Beizer.
58
7 REGISTRO DE ERRORES
Luego de identificar cuáles son los tipos de errores en los datos y su forma de medición, se
procede al registro de los mismos. En el presente capítulo se indica de qué forma se lleva a cabo
el registro de los metadatos. El Anexo B – Evaluación de Alternativas para el Registro de
Errores describe el análisis de tres alternativas distintas para el registro de errores, y el motivo
por el cual se opta por una de ellas.
A continuación, se presentan ejemplos de registro para tres tipos de errores (considerados
significativos del total), para los cuales se aplica la alternativa seleccionada. El Anexo C –
Metadata: Registro de Errores detalla el registro de todos los tipos de errores identificados.
7.1 DESCRIPCIÓN DE LA ALTERNATIVA SELECCIONADA
La alternativa elegida consiste en la creación de una nueva tabla por cada tipo de error, la cual
contiene el resultado de las mediciones de todos los errores correspondientes a ese tipo de error.
El nombre de la nueva tabla será igual al nombre del tipo de error que se está registrando, más
un prefijo „reg_‟.
Dependiendo del tipo de error a registrar la estructura de la tabla será distinta, y contendrá para
todos los casos el identificador del registro, además de información relevante y particular del
tipo de error que se está midiendo. Cada tabla de registro contiene además referencias (foreign
keys) a aquellas tablas de la base que participan del tipo de error en cuestión.
Se crea además un catálogo de errores (reg_catalogo_errores) que contiene información
específica de cada error. Todas las tablas que registran los tipos de errores harán referencia a
esta tabla, indicando cuál es el error que se está registrando.
7.2 APLICACIÓN DEL REGISTRO
A continuación se describe cómo se aplica la forma de registro de errores seleccionada a tres
tipos de errores en particular: Valor fuera de rango (Exactitud), Referencia inválida
(Consistencia) y Registro duplicado (Unicidad).
7.2.1 Ejemplo 1: Valor fuera de rango
Para registrar el tipo de error Valor fuera de rango, se crean dos tablas auxiliares en la base
origen:
reg_rango_tiempos: contiene el promedio y la desviación estándar por cada tipo de
defecto (IBM Defect Type).
reg_cant_lineas: contiene la cantidad de líneas por cada archivo de cada software.
Se crea además una nueva tabla reg_valor_fuera_rango, en la cual se registra el resultado de las
mediciones para los error de este tipo. En este caso, se muestra el registro para el error Valor
fuera de rango en el atributo time_deteccion. La estructura de la misma se describe a
continuación:
id. Identificador autonumerado.
59
registro_id. Registro de defecto que contiene el error (clave foránea a la tabla
Registro_Defecto).
error_id. Indica cuál es el error que se está registrando (clave foránea a la tabla
reg_catalogo_errores).
valor. Indica el valor erróneo.
7.2.2 Ejemplo 2: Referencia inválida
Para registrar el tipo de error Referencia inválida, se crea una nueva tabla de nombre
reg_referencia_invalida, en la cual se registra el resultado de la medición para los errores de
este tipo. En este caso, me muestra el registro para el error Referencia inválida en el atributo
registro_id. La estructura de la misma se describe a continuación:
id. Identificador autonumerado.
registro_taxonomia_id. Identificador del registro que contiene una referencia inválida
(clave foránea a la tabla Registro_Taxonomia).
valor_categoria_id. Identificador del valor de la categoría que contiene una referencia
inválida (clave foránea a la tabla Valor_Categoria).
error_id. Indica cuál es el error que se está registrando (clave foránea a la tabla
reg_catalogo_errores).
7.2.3 Ejemplo 3: Registro duplicado
Para registrar el tipo de error Registro duplicado, se crea una nueva tabla de nombre
reg_duplicado, en la cual se registra el resultado de la medición para los errores de este tipo. En
este caso, se muestra el registro para el error Registro_Taxonomia duplicado para la taxonomía
IBM. La estructura de la misma se describe a continuación:
id. Identificador autonumerado.
registro_id. Identificador del registro de defecto que se encuentra duplicado (clave
foránea a Registro_Defecto).
registro_taxonomia_id. Identificador del registro que se encuentra duplicado (clave
foránea a Registro_Taxonomia).
id_duplicado. Identifica cuáles son los registros duplicados (aquellas tuplas que
contengan el mismo valor en este campo corresponderán a los registros duplicados,
junto con el “original”).
error_id. Indica cuál es el error que se está registrando (clave foránea a
reg_catalogo_errores).
7.3 DIAGRAMA
En la Figura 2 se muestra el diagrama que representa el esquema de la base de datos origen
luego de ejecutada la medición y registro (para los tres tipos de errores mencionados),
incluyendo las tablas de registro que son creadas. Estas últimas se visualizan en color
anaranjado, mientras que las tablas de la base de datos origen para las cuales se genera la
metadata se observan en color verde.
60
Figura 2 – Esquema de la base con metadatos
7.4 RESUMEN
Luego de ejecutadas la medición y registro de todos los errores que fueron identificados en los
datos, se detalla en la Tabla 11 las características principales de cada error y tipo de error, así
como el resultado obtenido para cada caso.
61
Tabla 11 – Características de los errores identificados
Dimensión Factor Tipo de error Error Granula-
ridad Objeto Medición Tabla de registro
Cantidad de objetos
con error
Exactitud
Exactitud
sintáctica
Valor fuera de
rango
1 Celda Experimento.time_c
asos
NO 0
32
2 Celda Experimento.time_e
jecucion
NO 0
3 Celda Registro_Defecto.ti
me_deteccion
SQL reg_valor_fuera_rango 21
4 Celda Registro_Defecto.li
nea
SQL 8
5 Celda Registro_Defecto.li
nea_estructura
SQL 3
Estandarización
6 Celda Experimento.time_c
asos
SQL reg_estandarizacion 0
0
7 Celda Experimento.time_e
jecucion
SQL 0
8 Celda Registro_Defecto.ti
me_deteccion
SQL 0
9 Celda Registro_Defecto.li
nea
SQL 0
10 Celda Registro_Defecto.li
nea_estructura
SQL 0
Exactitud
semántica
Registro
inexistente
11 Tupla Registro_Defecto NO reg_registro_inexistente 0 1
12 Tupla Archivo Manual 1
Defecto mal
registrado
13 Celda Registro_Defecto.li
nea
NO 0
0
14 Celda Registro_Defecto.li
nea_estructura
NO 0
15 Celda Registro_Defecto.ti
me_deteccion
NO 0
16 Celda Registro_Defecto.d
escripcion
NO 0
62
17 Celda Registro_Defecto.es
tructura_id
NO 0
18 Celda Registro_Defecto.a
rchivo_id
NO 0
19 Celda Registro_Defecto.ti
po_id
NO 0
20 Celda Registro_Taxonomi
a.valor_categoria_i
d
NO 0
Valor fuera de
referencial
21 Celda Tecnica.nombre Manual reg_valor_fuera_referencial 0
3721
22 Celda Software.nombre Manual 0
23 Celda Tipo_Defecto.nomb
re
Manual 0
24 Celda Estructura.nombre Manual 0
25 Celda Taxonomia.nombre Manual 0
26 Celda /
Tupla
Categoria.nombre /
Registro_Taxonomi
a
SQL 3721
Completitud Densidad Valor nulo
27 Celda Usuario.perfil_id SQL reg_valor_nulo 0
1332
28 Celda Registro_Defecto.ti
po_id
SQL 0
29 Celda Registro_Defecto.li
nea
SQL 0
30 Celda Experimento.nombr
e
SQL 0
31 Celda Registro_Defecto.ti
me_deteccion
SQL 0
32 Celda Registro_Taxonomi
a.registro_id
SQL 0
33 Celda Experimento.time_e
jecucion
SQL 3
34 Celda Registro_Taxonomi
a.taxonomia_id
SQL 1324
63
35 Celda Registro_Taxonomi
a.valor_categoria_i
d
SQL 2
36 Celda Experimento.time_c
asos (técnica
dinámica)
SQL 3
Clasificación de
defectos
37 Tupla Registro_Defecto
(para IBM)
SQL reg_clasificacion 3
3 38 Tupla Registro_Defecto
(para Beizer)
SQL 0
Consistencia
Integridad
intra-relación
Regla de
integridad intra-
relación
39 Celda Experimento.time_c
asos (técnica
estática)
SQL reg_integridad_intra 0
92
40 Celda Experimento.time_c
asos (técnica
dinámica)
SQL 0
41 Celda Registro_Defecto.ti
me_deteccion
SQL 90
42 Celda Registro_Defecto.li
nea_estructura
SQL 0
43 Celda Experimento.time_e
jecucion
SQL 2
Valor único
44 Celda Categoria.nombre SQL reg_valor_unico 0
0
45 Celda Valor_Categoria.no
mbre,
categoria_padre
SQL 0
46 Celda Experimento.nombr
e
SQL 0
Integridad
referencial
Referencia
inválida
47 Tupla Registro_Taxonomi
a.taxonomia_id
SQL reg_referencia_invalida 0
491 48 Tupla Registro_Taxonomi
a.registro_id
SQL 472
49 Tupla Valor_Categoria.ca
tegoria_padre
SQL 19
64
Unicidad
Duplicación Registro
duplicado
50 Tupla Registro_Defecto SQL reg_duplicado 0
1705 51 Tupla Registro_Taxonomi
a (para IBM)
SQL 1705
52 Tupla Registro_Taxonomi
a (para Beizer)
SQL 0
Contradicción Registro
contradictorio
53 Tupla Archivo_Software SQL reg_contradictorio 4
214
54 Tupla Registro_Taxonomi
a (para IBM)
SQL 145
55 Tupla Registro_Taxonomi
a (para Beizer)
SQL y
Programa-
ción
65
65
8 LIMPIEZA Y MIGRACIÓN DE LOS DATOS
En los capítulos anteriores, se realiza un análisis detallado acerca de cuáles son los errores que
contienen los datos bajo estudio, y se establece como se miden y registran, así como los
resultados obtenidos en las mediciones. Para completar el ciclo de la calidad de los datos, se
describe en el presente capítulo cómo se lleva a cabo la limpieza de los errores que fueron
previamente presentados. Esta limpieza se lleva a cabo durante la migración de la base de datos
de la herramienta Grillo. El detalle de la limpieza de todos los errores se encuentra en el Anexo
D – Detalle de la Migración y Limpiezas sobre los Datos.
Para comenzar, se aplican los conceptos previamente introducidos (Capítulo 2 CALIDAD DE
DATOS), y que influyen en la calidad de los datos. Esto incluye el análisis de técnicas y
actividades de limpieza que apliquen en el contexto del presente proyecto. Posteriormente, se
define un esquema para la base de datos destino de la migración, que permite corregir los
errores identificados sobre el esquema actual de la base. Se describe además cómo se lleva a
cabo la migración de los datos del experimento, junto con la ejecución de las limpiezas.
Finalmente, se detallan los resultados obtenidos a partir de la limpieza y migración de los datos,
por cada error detallado en el Capítulo 6: MEDICIÓN DE LA CALIDAD.
Se incluye también el trabajo realizado por María Eugenia Decia en la asignatura Módulo de
Taller, el cual consistió en la implementación de parte del programa de limpieza y migración.
8.1 TÉCNICAS DE LIMPIEZA APLICADAS
Se describen a continuación distintas técnicas y actividades para análisis y limpieza de datos
(introducidas en las Secciones 1.3, 1.4 y 1.5), enfatizando aquellas que resulten de utilidad y
aplican para el análisis y limpieza de los datos de este caso en particular.
La primera fase de todo proceso de limpieza es la Detección de Errores, la cual fue presentada
en el capítulo Capítulo 6 MEDICIÓN DE LA CALIDAD. En esta sección se retoma dicha fase,
presentando las técnicas aplicadas y como antecedente de la etapa de Corrección de Errores.
Detección de errores. Consiste en evaluar si los registros cumplen o no con ciertas
condiciones previamente especificadas. Las técnicas que se describen a continuación son
algunas de las aplicadas para la detección de errores.
o Data editing (detección de inconsistencias). La aplicación de esta técnica consiste
en la definición de reglas de consistencia, más específicamente, reglas de integridad
intra-relación e integridad referencial.
Dentro de esta técnica se incluye la detección de los tipos de errores Reglas de
integridad intra-relación, Valor único y Referencia inválida.
o Detección de datos incompletos (valores nulos). Mediante la ejecución de consultas
SQL, se detectan cuáles son los datos que contienen nulos pero que deberían
contener un valor distinto de vacío.
Dentro de esta técnica se incluye la detección de los tipos de errores Valor nulo y
Clasificación de defectos.
o Detección de anomalías. Esta técnica consiste en identificar casos “extraños” (o
anómalos) que será necesario corregir. Esto puede realizarse, por ejemplo,
66
estableciendo rangos o definiendo referenciales a los cuales los valores de ciertos
campos deben pertenecer.
Luego de identificadas las anomalías, es necesario decidir si corresponden a datos
correctos de sucesos de la realidad (generalmente poco comunes), ó si corresponden
a datos incorrectos y deben ser corregidos.
Dentro de esta técnica se incluye la detección de los tipos de errores Valor Fuera de
rango y Valor fuera de referencial.
o Estandarización. Debido a que las mediciones realizadas indican que no hay errores
de estandarización en los datos, no se aplican técnicas de limpieza en este caso. Se
incluye aquí la detección del tipo de error Estandarización.
o Integración de datos. Debido a que no se llevó a cabo integración de datos de
distintas fuentes en la base bajo estudio, no se aplican técnicas de este tipo.
o Identificación de Objetos. Se identifican los registros que hacen referencia al mismo
objeto de la realidad (duplicación), y se realiza la limpieza (unificación)
correspondiente. Se identifican además aquellos objetos que aparecen repetidos
pero con distintos datos (contradicción). Vale destacar que el caso correspondiente
a registros de defecto que representan a un mismo defecto en el código, no se
analiza en el marco del presente proyecto.
Dentro de esta técnica se incluye la detección de los siguientes tipos de errores:
Registro duplicado y Registro contradictorio.
Corrección de errores. Esta es la última fase del proceso de limpieza, y es aquella en la cual
se establecen las acciones a llevar a cabo para la corrección de los errores que fueron
detectados durante el análisis de los datos. A continuación se presentan algunas de las
técnicas a utilizar.
o Definición de transformaciones de datos y reglas de mapeo: se utilizan sentencias
SQL y funciones programadas en Java para llevar a cabo las limpiezas automáticas.
o Corrección de inconsistencias. Para cada caso particular de inconsistencia, la
acción correctiva a tomar será distinta. Se incluye aquí la limpieza de los errores
identificados a partir de la aplicación de la técnica data editing.
o Corrección de datos incompletos (valores nulos). Es necesario tomar una acción
correctiva para los valores nulos detectados. Algunas estrategias posibles son:
No hacer nada: permanecer con valor nulo.
Asignar un valor por defecto a todos valores nulos.
Estudiar los casos uno a uno para intentar identificar las causas de su
incompletitud, y encontrar su valor correcto siempre que sea posible.
Se incluye aquí la limpieza de los errores identificados a partir de la aplicación de la
técnica detección de datos incompletos.
o Corrección de anomalías. Resulta necesario establecer, siempre que sea posible,
cuál fue la causa de cada anomalía detectada (ya sea que el valor fue mal medido o
mal ingresado en la base, que corresponde a una “muestra” distinta a la de todos los
demás, ó es correcto y simplemente corresponde a algún suceso inusual de la
67
realidad). A partir de la identificación de las causas, es posible determinar las
acciones correctivas que se llevarán a cabo en consecuencia.
Se incluye aquí la limpieza de los errores identificados a partir de la aplicación de la
técnica detección de anomalías.
o Obtención de nueva información. Esta técnica se lleva a cabo mediante la
realización de consultas concretas a los sujetos y responsables del experimento. De
esta manera, es posible limpiar y actualizar ciertos datos que hayan sido
previamente identificados como candidatos a contener errores. Las consultas se
realizan mediante email (el detalle de estas consultas se encuentran en el Anexo E –
Consulta a Sujetos).
También se realiza la comparación de los valores candidatos a contener errores, con
planillas utilizadas por los sujetos para el registro de los defectos (en paralelo a la
herramienta Grillo). Vale destacar que no se cuenta con la totalidad de las planillas,
y las mismas no contienen toda la información requerida.
Dentro de esta técnica se incluye la limpieza de los tipos de errores Valor fuera de
rango, Registro inexistente, Valor nulo y Reglas de integridad intra-relación.
Es importante mencionar aquí que todos los errores que se resuelven mediante esta
técnica deberán ser limpiados de manera manual, ya que corresponden a casos
particulares de limpieza. Esto es, dependiendo de cada valor erróneo en particular,
la limpieza a aplicar será distinta (no resulta posible su automatización).
8.2 DISEÑO DE LA BASE DE DATOS DESTINO
A partir de un estudio detallado del diseño de la base de datos de la herramienta Grillo, es
posible identificar errores en el mismo que se traducen en errores en los datos. Por este motivo,
es necesario definir un nuevo diseño que corrija estos errores, y que será el esquema destino
para la migración de datos a llevar a cabo.
A continuación se detallan los errores que fueron identificados sobre el diseño del esquema de
la base de datos.
En la realidad planteada, cada defecto hallado en el código es categorizado según dos
taxonomías: IBM y Beizer. En el diseño actual de la base, existe una tabla
Registro_Defecto que representa un defecto en el código, y otra tabla
Registro_Taxonomía que representa una clasificación dentro de alguna taxonomía. La
relación entre Registro_Taxonomía y Registro_Defecto es N a 1. Luego, esto puede
producir varios errores en los datos de la base. Por ejemplo, puede suceder que un
defecto esté clasificado más de una vez en una misma taxonomía, o al contrario, que
solamente esté clasificado en una de ellas. En este caso podría pensarse en un diseño
que se ajuste mejor a la realidad y que deje menos margen de error a los datos de la
base.
En resumen, el diseño debe asegurar que una tupla de la tabla Registro_Defecto esté
asociada a exactamente tres tuplas de la tabla Registro_Taxonomía (uno para Beizer,
uno para IBM Qualifier y otro para IBM Defect Type).
La representación de las diferentes categorías dentro de cada taxonomía se realiza
mediante las tablas Categoria y ValorCategoria. Con respecto a la clasificación de un
68
defecto dentro de la taxonomía jerárquica de Beizer, interesa conocer solamente la
categoría más específica a la que se logra llegar al clasificar. Según el esquema actual,
sin embargo, puede darse el caso de que un defecto en el código esté asociado a más de
una categoría dentro de una misma taxonomía.
Según el esquema actual de la base de datos, es posible que un mismo archivo
pertenezca (esto es, esté asociado) a más de un software. Este hecho ocasiona la
existencia de contradicciones en los datos, generando errores del tipo Registro
contradictorio (específicamente sobre la tabla Archivo_Software). La contradicción
radica en que en la realidad planteada, dos softwares distintos no pueden tener ningún
archivo en común.
Se omite la definición de la restricción not null y unique sobre ciertos atributos, así
como la definición de determinadas foreign keys, las cuales es necesario considerar en
el nuevo esquema definido. El detalle de estos errores se describen en los tipos de
errores Valor nulo, Valor único y Referencia inválida respectivamente.
Se presenta en la Figura 3 el esquema de la base de datos destino, que corrige los errores recién
mencionados.
69
Software
PK id
nombre
descripcion
Estructura
PK id
nombre
descripcion
Perfil
PK id
nm_perfil
descripcion
Registro_Defecto
PK id
fk_tipo_id
fk_experimento_id
fk_archivo_id
fk_estructura_id
linea
descripcion
linea_estructura
time_deteccion
fk_defect_type
fk_qualifier
fk_beizer
Experimento
PK id
fk_ejecutor_id
fk_creador_id
fk_software_id
fk_tecnica_id
nombre
fecha_ini
fecha_fin
time_casos
time_ejecucion
Tecnica
PK id
nombre
descripcion
tipo
Archivo
PK id
nombre
nombre_usu
fecha
fk_software_id
Tipo_Defecto
PK id
nombre
descripcion
Usuario
PK id
nombre
nm_usuario
apellido
password
habilitado
fk_perfil_id
IBM_Defect_Type
PK id
categoria
Taxonomia_Beizer
PK id
categoria
fk_categoria_padre
codigo
IBM_Qualifier
PK id
categoria
Figura 3 – Esquema de la base de datos destino
70
La Tabla 12 muestra una breve descripción de cada tabla contenida en el nuevo esquema
definido.
Tabla 12 – Descripción de las tablas del nuevo esquema
Nombre Tabla Descripción Tabla
Archivo Representa un archivo que contiene código fuente (.java).
Cada archivo pertenece a un único Software.
Software Representa un software (conjunto de clases, métodos, etc.) que será sometido a
verificación.
Usuario Representa un usuario que hará uso de la herramienta.
Perfil Representa el perfil que contiene el usuario que utiliza la herramienta.
Experimento Representa un experimento a ejecutar y su información asociada.
Técnica Representa una Técnica de Verificación. Cada registro de Experimento tiene
una única Técnica asociada.
Registro_Defecto Representa un defecto hallado en el código por un usuario Verificador.
Estructura Representa los tipos de estructuras que pueden existir en el código fuente. A
cada registro de la tabla Registro_Defecto se le asocia un único registro de la
tabla Estructura.
Tipo_Defecto Representa si el defecto está contenido o no en una estructura. A cada registro
de la tabla Registro_Defecto se le asocia un único registro de la tabla
TipoDefecto.
Taxonomia_Beizer Representa la taxonomía de Beizer. Implementa la jerarquía utilizando una
clave foránea sobre sí misma (fk_categoría_padre), la cual apunta al “padre”
en la jerarquía. Cada registro representa entonces una clasificación de defecto
en el código según la taxonomía mencionada.
A cada registro de la tabla Registro_Defecto se le asocia un único registro de la
tabla Taxonomia_Beizer.
IBM_Qualifier Cada registro de esta tabla representa un valor de la categoría Qualifier (de
Closer Section), dentro de la taxonomía IBM de defectos en el código. A cada
registro de la tabla Registro_Defecto se le asocia un único registro de la tabla
IBM_Qualifier.
IBM_DefectType Cada registro de esta tabla representa un valor de la categoría Defect Type (de
Closer Section), dentro de la taxonomía IBM de defectos en el código. A cada
registro de la tabla Registro_Defecto se le asocia un único registro de la tabla
IBM_DefectType.
8.3 PLANIFICACIÓN DE LA LIMPIEZA Y MIGRACIÓN
Por una parte, es necesario ordenar la ejecución de la limpieza de los distintos errores, ya que
existen dependencias en los datos que hay que considerar. Por este motivo, se diferencian tres
etapas que deben realizarse de manera secuencial. El orden en el cual se limpien los errores que
forman parte de una misma etapa no resulta relevante (no así para el orden de ejecución entre
etapas). El detalle acerca de qué errores se incluyen en cada etapa se encuentra en el Anexo D –
Detalle de la Migración y Limpiezas sobre los Datos.
Por otra parte, el orden establecido para llevar a cabo la migración de los datos comienza desde
las tablas que no contienen referencias a otras, siguiendo con aquellas que referencian a tuplas
ya cargadas, y así sucesivamente.
En resumen, cada error será limpiado durante la ejecución de la migración de las distintas
tablas, considerando las etapas de la limpieza y el orden de la migración previamente definidos.
71
8.4 EJECUCIÓN DE LIMPIEZAS Y MIGRACIÓN
Tanto la migración de los datos como la limpieza de la mayoría de los errores se realizan de
manera automática. En esta sección se describe para cada tabla de la base origen a migrar, en
qué tabla de la base destino se almacenarán sus datos. Se mencionan también las modificaciones
realizadas sobre las estructuras de las tablas (cuando corresponda) y las limpiezas sobre los
datos que se realizan de manera automática durante la migración de cada una de ellas. Para
aquellos errores cuya limpieza no es posible automatizar, se establece la forma manual en la
cual serán limpiados al finalizar el programa de limpieza y migración.
La descripción de la aplicación implementada para ejecutar la limpieza y migración de los datos
se encuentra en el Capítulo 9 APLICACIÓN.
La Figura 4 muestra el diagrama que representa la migración tabla por tabla desde la base de
datos origen hacia la destino, en el mismo orden en que se migran (de arriba hacia abajo). Se
incluyen también las limpiezas automáticas que se aplican durante la migración, y aquellas
manuales al finalizar la misma. La numeración de los errores corresponde a la establecida en el
Anexo A – Catálogo de Errores. Se resaltan las de los errores que fueron descriptos en el
Capítulo 6 MEDICIÓN DE LA CALIDAD en color anaranjado. Las tablas que intervienen en la
limpieza y migración de esos errores se muestran en color gris.
72
Base de Datos Origen Base de Datos Destino
Tipo_Defecto Tipo_Defecto
Registro_Defecto
Registro_Taxonomia
Registro_Defecto
Perfil Perfil
Estructura Estructura
Software Transformación 1 Software
Archivo
Archivo_Software Archivo
Tecnica Tecnica
Usuario Usuario
Experimento Experimento
Categoria
Valor_Categoria
IBM_Defect_Type
IBM_Qualifier
Taxonomia_Beizer
Limpieza
Error 53Transformación 2
Transformación 3
Transformación 4
Transformación 5Limpieza
Error 26
Transformación 6
Transformación 7
Transformación 8
Limpieza
Error 26
Limpieza
Error 49
Limpieza
Errores 26,
34, 41, 48, 51,
54, 55
Limpiezas
manuales:
Errores 3,
4, 5, 53
Limpiezas
manuales:
Error 12
Limpiezas
manuales:
Errores 33.
36, 43
Valor fuera de
referencial en el
atributo nombre
de la tabla
Categoria
Referencia
inválida en el
atributo
registro_id
Referencia inválida en el
atributo registro_id
Registro_Taxonomía
contradictorio para la
taxonomía IBM
Registro_Taxonomía
contradictorio para la
taxonomía Beizer
Valor fuera de
rango en el
atributo
time_deteccion
Valor fuera de
referencial en el
atributo nombre de
la tabla Categoria
Valor fuera de
referencial en el
atributo nombre de la
tabla Categoria
Valor nulo en el atributo
time_casos para
técnicas dinámicas
Figura 4 – Migración y limpieza de los datos
73
8.4.1 Migración y limpiezas automáticas
A continuación se presenta la migración de los datos tabla por tabla, así como los errores que
son limpiados de manera automática durante la misma. Se detallan las limpiezas de los errores
que fueron previamente presentados (Capítulo 6: MEDICIÓN DE LA CALIDAD). La forma en
que se limpian todos los errores se encuentra en el Anexo D – Detalle de la Migración y
Limpiezas sobre los datos.
Las tablas Perfil, Estructura, Tipo_Defecto y Tecnica se migran sin sufrir modificaciones a las
tablas del mismo nombre de la base destino.
La tabla Software se migra a la tabla del mismo nombre de la base destino, llevando a cabo la
Transformación 1. Esta transformación consiste en la eliminación del campo total_defectos,
debido a que el mismo no es utilizado.
Las tablas Archivo y Archivo_Software se migran a la tabla Archivo de la base destino, llevando
a cabo la Transformación 2. Esta transformación consiste en las siguientes modificaciones sobre
la estructura de la tabla Archivo:
Se elimina la restricción unique sobre el campo nombre, ya que pueden existir distintos
archivos que tengan el mismo nombre.
Se elimina el campo codigo, ya que el mismo se encuentra vacío en todos los casos (no
es utilizado).
Se agrega el campo software_id, el cual corresponde a una clave foránea a la tabla
Software. De esta manera, la relación entre Archivo y Software es ahora N a 1 (deja de
ser N a N). La tabla Archivo_Software es consultada con el fin de actualizar el campo
software_id por cada archivo migrado.
La tabla Usuario se migra a la tabla del mismo nombre de la base destino, llevando a cabo la
Transformación 3. Esta transformación consiste en la definición de la restricción not null sobre
el campo perfil_id.
La tabla Experimento se migra a la tabla del mismo nombre de la base destino, llevando a cabo
la Transformación 4. Esta transformación consiste en las siguientes modificaciones sobre su
estructura:
Definición de la restricción not null sobre los campos time_ejecucion y nombre.
Definición de la restricción unique sobre el campo nombre.
Las tablas Categoria y Valor_Categoria son migradas a las nuevas tablas IBM_Defect_Type,
IBM_Qualifier y Taxonomia_Beizer de la base destino a través de las Transformaciones 5, 6 y 7
respectivamente. Dichas transformaciones consisten en migrar solamente las tuplas de la tabla
Valor_Categoria, filtrando por la categoría correspondiente (dependiendo de la tabla que se esté
cargando). El detalle de estas transformaciones se encuentra en el Anexo D – Detalle de la
Migración y Limpiezas sobre los Datos.
Durante la migración de estas tablas es necesario considerar la limpieza del error Valor fuera de
referencial en el atributo nombre de la tabla Categoria. Se distinguen dos aspectos. Por un
lado, se deben eliminar todas las tuplas de la tabla Categoria que corresponden a valores que se
encuentran fuera del referencial definido como válido. La creación las dos nuevas tablas
IBM_Defect_Type y IBM_Qualifier, las cuales corresponden a las únicas categorías válidas para
la taxonomía de IBM, no permite que se almacene la clasificación de ninguna otra. Por otro
74
lado, es necesario eliminar aquellos registros que referencien a alguno de los valores que se
encuentran fuera del referencial. Esto se describe durante la migración de la tabla
Registro_Defecto.
Las tablas Registro_Defecto y Registro_Taxonomia se migran a la tabla Registro_Defecto de la
base destino. Durante la migración de la tabla Registro_Defecto se lleva a cabo la
Transformación 8. Esta transformación consiste en las siguientes modificaciones sobre la
estructura de la tabla Registro_Defecto:
Definición de la restricción not null sobre los campos tipo_id, línea y time_deteccion.
Definición de restricciones de clave foránea hacia cada una de las nuevas tablas
IBM_Defect_Type, IBM_Qualifier y Taxonomia_Beizer.
Además, durante esta misma transformación se almacena la información acerca de la
categorización de un defecto según las taxonomías de IBM y Beizer. Estos datos se obtienen a
partir de las tablas Categoria, Valor_Categoria, Registro_Defecto y Registro_Taxonomia,
como se muestra en la Figura 4. El detalle de estas transformaciones se encuentra en el Anexo D
– Detalle de la Migración y Limpiezas sobre los Datos.
Durante la migración de estas tablas es necesario considerar la limpieza de los siguientes
errores:
Valor fuera de referencial en el atributo nombre de la tabla Categoria
Durante la migración de las clasificaciones de los registros de defectos para la
taxonomía de IBM, se consideran solamente aquellas que correspondan a las categorías
Defect Type y Qualifier. Los datos correspondientes a todas aquellas clasificaciones que
sean distintas a las recién mencionadas no serán migrados.
Regla sobre el atributo time_deteccion para técnicas estáticas
En este caso (verificación utilizando técnicas estáticas), el tiempo de detección de un
defecto es 0, ya que el defecto se identifica en el código mismo y no a través de una
falla al utilizar el software. La forma de limpiar este error consiste en consultar al
usuario del programa de limpieza y migración entre dos opciones: migrar el valor
almacenado en la base bajo estudio, ó ingresar el valor cero en el campo
correspondiente al tiempo de detección.
Referencia inválida en el atributo registro_id
La forma de limpiar este error consiste en no migrar a la base destino aquellas tuplas de
la tabla Registro_Taxonomía que contienen una referencia inválida en el campo
registro_id. Esto se debe a que las tuplas de Registro_Defecto contienen la información
más relevante de un defecto, por lo que carece de sentido contar con tuplas de la tabla
Registro_Taxonomia que no estén asociados a ningún registro de defecto válido.
Para ello, toda tupla que contenga una referencia inválida en el registro de defecto no
será migrada a la base de datos destino.
Registro_Taxonomía duplicado para la taxonomía IBM
Para limpiar este error, se eliminan las N-1 tuplas que se encuentren duplicadas (siendo
N la cantidad de tuplas iguales de la tabla Registro_Taxonomia que existen para una
75
determinada tupla de la tabla Registro_Defecto), siempre manteniendo el registro
“original”.
Para ello, se migra solamente una de las categorizaciones en caso de que se encuentren
duplicados (mismo registro defecto y misma categoría).
Registro_Taxonomía contradictorio para la taxonomía Beizer
En este caso es necesario definir una única tupla de la tabla Registro_Taxonomia (de
entre las contradictorias) que permanecerá asociada al registro de defecto. Las demás
tuplas son descartadas.
Para ello, se consulta al usuario del programa de limpieza y migración, quien debe
seleccionar una única clasificación para cada defecto involucrado, de entre el conjunto
de clasificaciones contradictorias.
8.4.2 Limpiezas manuales
Luego de finalizado el programa de limpieza y migración, se llevan a cabo las limpiezas
manuales directamente sobre la base de datos origen. Los siguientes errores deben ser limpiados
de esta manera:
Valor fuera de rango en el atributo time_deteccion
Valor nulo en el atributo time_casos para técnicas dinámicas
Para el caso del error Valor fuera de rango en el atributo time_deteccion, el primer paso para la
limpieza consiste en conocer (siempre que sea posible) si realmente existe un error en los datos,
y en caso de ser así determinar cómo corregirlo. Para ello se llevan a cabo las siguientes
actividades:
Consultas a los sujetos que formaron parte del experimento mediante el envío de mails,
para conocer si creen o recuerdan que existe o no un error en los datos (el detalle de
estas consultas se encuentran en el Anexo E – Consulta a Sujetos).
Comparación de los valores que se encuentran fuera de rango con planillas utilizadas
por los sujetos, donde se registraron los datos del experimento y los defectos detectados
(en paralelo al registro en la herramienta Grillo).
A continuación, se actualiza (esto es, se corrige) el valor de la base con el de la planilla de
registro de defectos solamente en el siguiente caso:
el valor de la planilla es distinto al ingresado en la herramienta, se encuentra dentro del
rango definido y la respuesta del sujeto establece que probablemente existe un error en
el valor ingresado.
Por otra parte, se mantiene el mismo valor de la base origen (esto es, no se realiza corrección)
cuando ocurre alguna de estas situaciones:
el valor de la planilla es el mismo valor que el de la base,
la respuesta del sujeto establece que el valor ingresado es correcto,
no se cuenta con las planillas,
la respuesta del sujeto establece que probablemente existe un error en el dato, pero no se
conoce con certeza cuál debería ser el valor correcto para dicho dato.
76
Para el caso del error Valor nulo en el atributo time_casos para técnicas dinámicas, se actualiza
el valor de la base con el de la planilla de registro de defectos siempre que se encuentre el valor
faltante. En caso contrario, se consulta a los responsables del experimento por el dato, ya que
pueden tener conocimiento del motivo de alguno de los errores así como de su forma de
corrección.
8.5 RESULTADOS OBTENIDOS
En la presente sección se detallan los resultados obtenidos a partir de la limpieza y migración de
los datos, por cada error descripto anteriormente. El resultado de la limpieza de todos los errores
para los cuales se hallaron tuplas erróneas se encuentran en el Anexo F – Resultado Detallado
de la Limpieza.
Valor fuera de rango en el atributo time_deteccion
Se detectaron un total de 21 tuplas erróneas de la tabla Registro_Defecto como resultado de la
medición de este error. Los resultados obtenidos a partir de la limpieza son los siguientes.
o Para 9 registros, los sujetos establecen que el tiempo registrado es el correcto
(recordar que las tuplas encontradas por este error son sólo candidatas a contener
errores). Dentro de esos 9 registros, 4 de ellos pudieron ser comparados con las planillas
de registros de defectos, comprobando en todos los casos que el tiempo ingresado en la
herramienta coincide con el tiempo registrado en la planilla. Estos registros no serán
modificados (permanecerá el valor original), al comprobarse la no existencia de errores
en los mismos.
o Para 3 registros, el sujeto responde con el envío de la planilla, no estableciendo si
cree que existe o no un error. Se comprueba que el tiempo ingresado en la herramienta
coincide con el tiempo registrado en la planilla. Por lo tanto, estos registros no serán
modificados.
o Para 2 registros, la respuesta del sujeto establece que no recuerda si el tiempo
registrado es correcto, y tampoco se cuenta con la planilla correspondiente. Estos
registros no serán modificados (permanecerá el valor original), debido a que no es
posible confirmar si contienen errores.
o Para 3 registros, los sujetos establecen que efectivamente existe un error en el
tiempo registrado. Sin embargo, no es posible especificar el tiempo exacto invertido en
la detección de dichos defectos debido a que no se cuenta con la planilla
correspondiente. Por lo tanto, estos registros no pueden ser modificados, a pesar de que
se comprueba la existencia de errores en sus datos.
o Finalmente, los 4 registros restantes serán limpiados. Se comprueba, mediante la
comparación de los valores ingresados en la herramienta con la planilla correspondiente,
que efectivamente existe un error. En este caso, el sujeto no establece si cree que existe
un error o no. Se aprecia que la causa del error para 3 de ellos se debe a que se ingresa
el valor de la línea de código en el campo correspondiente al tiempo de detección (se
puede deber a un error de distracción). En el registro restante, existe diferencia de un
dígito entre el valor registrado y la planilla (se puede deber a un error de tipeo). Para
todos los casos, la limpieza consiste en actualizar el valor del campo
Registro_Defecto.time_deteccion con el de la planilla correspondiente.
77
En conclusión, se comprueba la existencia de errores para la tercera parte (7 tuplas de un total
de 21) de las tuplas resultantes de la medición del presente error, logrando aplicar limpieza
manual para 4 de estas (19%).
Vale destacar que 3 de los 4 registros que fueron limpiados corresponden a valores que se
alejan más notoriamente del rango definido (tal como se muestra en la Tabla 5 del Capítulo 6),
incluyendo aquellos cuyo valor es casi seis veces mayor en comparación al máximo definido.
Valor fuera de referencial en el atributo nombre de la tabla Categoria
Como resultado de la limpieza de este error, existen 6 tuplas de la tabla Categoria
correspondientes a la taxonomía IBM que no son consideradas durante la migración (Section,
Actividad, Trigger, Impacto, Age y Source). Por otra parte, tampoco son consideradas ninguna
de las 3721 clasificaciones de registros de defectos que corresponden a las categorías antes
mencionadas.
Valor nulo en el atributo time_casos para técnicas dinámicas
Se detectan un total de 3 tuplas de la tabla Experimento que contienen este error.
Para 2 de ellas, se consulta con los responsables de la ejecución del experimento, estableciendo
que corresponden a experimentos inválidos (ya sea porque no se culminaron o porque fueron
reemplazados por otro).
Para el caso restante se detecta que existe un valor faltante, el cual se obtiene a partir de la
planilla donde se registra el tiempo de actividades del sujeto en cuestión.
Vale destacar que las 3 tuplas que contienen este error coinciden con lo resultantes del error
Valor nulo en el atributo time_ejecucion. Por lo tanto, se aplican las mismas limpiezas para
ambos errores.
Regla sobre el atributo time_deteccion para técnicas estáticas
Se detectan un total de 90 tuplas de la tabla Registro_Defecto que contienen este error.
De acuerdo a la decisión que toma el usuario del programa de limpieza y migración, el valor del
tiempo de detección de cada uno de los registros de defectos en cuestión se modificará por 0 ó
se mantendrá el original.
Referencia inválida en el atributo registro_id
Se detectan 472 tuplas de la tabla Registro_Taxonomia que contienen este error, los cuales son
limpiados en su totalidad al no ser migrados.
Registro_Taxonomía duplicado para la taxonomía IBM
Como resultado de la limpieza de este error se eliminan 1534 tuplas de la tabla
Registro_Taxonomia. Como consecuencia a ello, existen 171 tuplas de la tabla
Registro_Defecto que ahora contienen solamente una única clasificación, eliminando aquellas
que se encontraban duplicadas.
Registro_Taxonomía contradictorio para la taxonomía Beizer
Como resultado de la limpieza de este error se eliminan 43 tuplas de la tabla
Registro_Taxonomia. Como consecuencia a ello, existen 22 tuplas de la tabla Registro_Defecto
que ahora contienen solamente una única clasificación, eliminando aquellas que se encontraban
78
contradictorias. La elección de la clasificación que queda asociada al registro de defecto la
realiza el usuario del programa de limpieza y migración.
8.6 RESUMEN
La Tabla 13 muestra por cada error que fue identificado sobre los datos y cuya medición es
distinta de vacío, si se lleva a cabo su limpieza. En caso positivo, se indica si la misma es
automática (mediante programación), semiautomática (incluyendo consultas al usuario) o
manual (mediante la ejecución de un script). Finalmente se detalla la cantidad de tuplas que
contienen errores y la cantidad que fueron limpiadas.
Tabla 13 – Limpieza de los errores
Tipo de error Objeto Limpieza
Cantidad de
objetos con
error
Cantidad de
objetos
limpiados
Valor fuera de
rango
RegistroDefecto.time_detecc
ion
Manual 21 7
RegistroDefecto.linea Manual 8 4
RegistroDefecto.linea_estru
ctura
Manual 3 2
Registro
inexistente
Archivo Manual 1 1
Valor fuera de
referencial
Categoria.nombre /
Registro_Taxonomia
Automática 3721 3721
Valor nulo
Experimento.time_ejecucion Manual 3 3
RegistroTaxonomia.taxonom
ia_id
NO 1324 1324
RegistroTaxonomia.valor_c
ategoria_id
NO 2 2
Experimento.time_casos
(técnica dinámica)
Manual 3 3
Clasificación de
defectos
Registro_Defecto (para
IBM)
NO 3 0
Regla de
integridad intra-
relación
RegistroDefecto.time_detecc
ion
Semiautomática 90 Depende de la
decisión del
usuario
Experimento.time_ejecucion Manual 2 1
Referencia
inválida
RegistroTaxonomia.registro
_id
Automática 472 472
ValorCategoria.categoria_p
adre
Automática 19 19
Registro
duplicado
RegistroTaxonomia (para
IBM)
Automática 1705 1705
Registro
contradictorio
Archivo_Software Manual /
Automática
4 4
RegistroTaxonomia (para
IBM)
Semiautomática 145 145
RegistroTaxonomia (para
Beizer)
Semiautomática 65 65
79
9 APLICACIÓN
En este capítulo se describe brevemente la aplicación implementada para ejecutar la limpieza y
migración de los datos. Incluye información técnica (ambiente, herramientas utilizadas,
implementación), así como un breve manual de usuario.
9.1 INFORMACIÓN TÉCNICA
El programa que implementa la limpieza y migración de los datos bajo estudio es una aplicación
Java de escritorio. Se utilizó la versión 1.6 de Java, y Eclipse 3.4 como entorno de desarrollo
(IDE), incluyendo el plug-in VisualSwing para la construcción de la interfaz gráfica. El acceso a
los datos (tanto de la base de datos origen como destino) se realiza a través del sistema gestor de
base de datos HSQLDB.
En la Tabla 14 se observan las principales características técnicas (ambiente y herramientas) del
programa construido.
Tabla 14 – Características técnicas
Ambiente Herramientas
Ecplipse 3.4
Java 1.6 VisualSwing plug-in
HSQLDB Windows XP, Vista
En cuanto a la implementación, se definieron las siguientes clases:
Inicio: Esta clase implementa la ventana principal.
TipoError: Esta clase es responsable de ejecutar las mediciones y crear el registro de
todos los errores que se encuentren en la base de datos origen. Es decir, crea todas las
tablas de registros incluyendo el catálogo de errores, realiza las mediciones definidas, y
carga, a partir del resultado de las mediciones, todas las tablas donde se almacena la
metadata sobre los errores de los datos bajo estudio.
MigracionDatos: Esta clase implementa la limpieza y migración de los datos. Se
cargan todas las tablas de la base destino a partir de los datos limpios de la base origen
(cada limpieza se aplica durante la migración de la tabla correspondiente). En caso de
que se requiera la decisión del usuario, se lo consulta a través de ventanas emergentes.
ValorCategoria y ValorCategoriaCandidatos: Clases auxiliares para la limpieza de
los registros de defectos que poseen clasificaciones contradictorias.
9.2 MANUAL DE USUARIO
El uso de la aplicación es muy sencillo. Se asume que el usuario tiene perfil técnico y posee
conocimiento de los datos a procesar. La ventana principal contiene cuatro browsers para
seleccionar:
80
Ubicación del esquema origen: Se selecciona un directorio que debe contener los archivos
esquemaorigen.script y esquemaorigen.properties, correspondientes a la base de datos
HSQLDB origen.
Ubicación del esquema destino: Se selecciona un directorio que debe contener los archivos
esquemadestino.script y esquemadestino.properties, correspondientes a la base de datos
HSQLDB destino.
(opcional) Script SQL de limpiezas manuales a ejecutar sobre la base de datos destino:
Luego de realizada la limpieza y migración automática, puede ser necesario realizar
correcciones “manuales”. En caso de seleccionar un archivo en este browser, el
programa ejecuta todas las sentencias SQL especificadas en dicho archivo sobre la base
de datos destino.
(opcional) Archivo de log: Si se desea generar un log de las operaciones realizadas durante
la ejecución del programa, se debe indicar en este browser el archivo correspondiente al
log.
Para comenzar con la migración se debe presionar el botón “Comenzar Migración”, tal como se
muestra en la Figura 5.
Figura 5 – Ventana de Inicio
Para algunos procesos de limpieza “semi-automáticos” es necesario indicarle al programa cómo
proceder en la corrección de los datos. En estos casos, se consulta al usuario a través de
ventanas emergentes. Se despliega la información relevante y el usuario decide entre las
opciones disponibles, luego presiona “Aceptar”. Estos casos se muestran en la Figura 6 y Figura
7.
81
Figura 6 – Consulta a Usuario
Figura 7 – Consulta a Usuario
82
Si la migración se completó con éxito se despliega el mensaje indicado en la Figura 8.
Figura 8 – Fin de Migración
En caso de que la migración no se haya completado con éxito, ya sea porque el usuario canceló
u ocurrió algún error durante la ejecución del programa o del script, se muestra en pantalla el
mensaje “Migración incompleta”, junto con la excepción que provocó la cancelación.
9.3 ADAPTACIÓN DEL PROGRAMA DE LIMPIEZA Y MIGRACIÓN
A OTROS EXPERIMENTOS
Una característica muy importante del programa de limpieza y migración es que su uso puede
generalizarse a otros experimentos similares, que utilicen la herramienta Grillo para el registro
de sus datos. En esta sección se detalla qué aspectos deben considerarse a la hora de aplicar el
programa en otro experimento.
9.3.1 Elementos particulares de cada experimento
A continuación se describen los elementos que pueden variar con cada experimento, y que es
necesario tener en cuenta para aplicar el programa de limpieza y migración:
Catálogo de errores (tabla reg_catalogo_errores): los errores identificados para este
caso de estudio pueden presentarse en cualquier otro experimento. El catálogo que crea
el programa contiene una gran cantidad de errores, identificados a partir de un detallado
análisis de los datos. Solamente será necesario modificar el mismo si se desea no
considerar algún error o por el contrario introducir uno nuevo. La forma de agregar un
nuevo error al catálogo consiste simplemente en introducir un nuevo registro en la tabla
reg_catalogo_errores.
Tablas de registro: Análogamente al punto anterior, los tipos de errores identificados
en los datos bajo estudio pueden presentarse en cualquier experimento similar. Son el
resultado de un estudio detallado de los datos, por lo que se cuenta con un amplio
conjunto de tipos de errores. De nuevo, las tablas de registro solamente deberían
modificarse si se desea no considerar algún tipo de error o por el contrario introducir
uno nuevo. La forma de crear nuevas tablas de registro es la misma para todos los casos,
la cual se detalla en el Capítulo 6: Registro de errores.
Tabla reg_cant_lineas: esta tabla indica la cantidad de líneas que posee cada archivo
fuente. Si los fuentes varían con el experimento, entonces el contenido deberá
actualizarse con la información correspondiente.
Mediciones y limpiezas manuales: Para cualquier limpieza manual que se requiera
realizar sobre los datos, el programa ofrece la posibilidad de ejecutar un script
83
directamente sobre la base de datos destino, luego de realizadas todas las mediciones y
limpiezas automáticas. El contenido de este script depende de los casos particulares que
se identifiquen en cada experimento.
En el caso de las mediciones manuales, a modo de ejemplo, se registra en la tabla
reg_registro_inexistente la metadata correspondiente al tipo de error Registro
Inexistente. Este tipo de error fue medido y registrado de manera manual, esto es, se
identificó manualmente una tupla que representa un archivo que no existe en la realidad
y se insertó en la tabla mencionada. En cualquier otro experimento, para casos de
mediciones manuales se debe proceder de la misma manera que para el ejemplo
presentado.
Valores fuera de referencial: en caso de que se identifiquen nuevos referenciales, la
medición y limpieza de los datos se realizaría de la misma manera que para el presente
caso de estudio, pero utilizando los nuevos referenciales que sean definidos como
válidos.
En conclusión, resulta sumamente sencillo y práctico aplicar el programa de limpieza y
migración a otros experimentos similares, con ajustes menores como los que se mencionaron
anteriormente. Se puede ejecutar el programa sin realizar ninguna modificación, salvo para las
mediciones manuales. Las limpiezas manuales son opcionales, y complementan a las
automáticas por deberse a casos particulares que no es posible generalizar. En comparación con
las limpiezas manuales, las automáticas son las que eliminan la mayor cantidad de errores, los
cuales se corrigen durante la ejecución del programa de limpieza y migración.
Vale destacar que los errores identificados sobre los datos refieren tanto a la base de datos
particular de la herramienta Grillo, como a la ejecución de un experimento en sí. Debido a esto
último, existen ciertos tipos de errores que podrían ocurrir también en otra experiencia empírica
de las mismas características que la que aquí se describe, sin necesariamente utilizar la
herramienta Grillo.
84
10 PREVENCIÓN DE ERRORES Y OPORTUNIDADES DE
MEJORA
Considerando los diversos tipos de errores que presentan los datos y sus causas, en este capítulo
se establecen alternativas para evitar que los mismos errores sucedan en futuros experimentos.
No se presenta aquí un análisis exhaustivo ni un detalle de cómo implementar mejoras en un
determinado experimento, sino pautas generales que pueden ser útiles.
10.1 SOBRE EL DISEÑO DE LA BASE DE DATOS Y LA
APLICACIÓN
Un correcto diseño de la base de datos es de suma importancia en cualquier sistema de
información. Además, es necesario considerar que los datos almacenados en la base de un
experimento serán luego el punto de partida de análisis estadísticos, estudios comparativos,
entre otros. Cualquier error en el diseño de la base, puede traducirse fácilmente en errores en los
datos (como se vio en el caso bajo estudio), distorsionando luego los resultados que se quieran
obtener a partir de los mismos. Es por esto que asegurar un correcto diseño de la base resulta
necesario, sino imprescindible. Es natural también, que luego de ejecutado un experimento, se
identifiquen varios aspectos a mejorar. El diseño de la base donde se recolectan resultados
puede y debe formar parte del ciclo de “refinamiento paso a paso” (donde se utiliza la
experiencia adquirida a través de sucesivos experimentos para diseñar y ejecutar los siguientes).
En el diseño de la base bajo estudio se detectan varios errores. Muchos de ellos se encuentran
relacionados con la omisión de ciertas restricciones, como ser not null, unique y foreing key (tal
como se detalla en los tipos de errores Valor nulo, Valor único y Referencia inválida
respectivamente).
En cuanto a otro tipo de reglas de integridad intra-relación, pueden definirse triggers a nivel de
la base y/o programar controles a nivel de la aplicación que no permitan a los usuarios generar
errores de este tipo. Dichas reglas se encuentran definidas en el tipo de error Reglas de
integridad intra-relación. Por otra parte, la definición de ciertos controles ya sea a nivel de base
o de aplicación en lo que respecta a la clasificación de defectos, evitaría la ocurrencia de errores
del tipo Clasificación de Defectos. Dichos controles no deberían permitir que un defecto sea
registrado sin ser clasificado según las categorías de interés (siempre y cuando la clasificación
sea realizada por el mismo Verificador que registra el defecto). Errores del tipo Estandarización
se evitarían fácilmente definiendo controles que no permitan el ingreso de valores con
decimales. Vale destacar que este control se encuentra actualmente implementado en la
herramienta Grillo.
Se identifican errores también en tablas pre-cargadas, ya que en algunos casos contienen valores
que no interesan. Por ejemplo, en las categorías dentro la taxonomía IBM, tal como se detalla en
el tipo de error Valor fuera de referencial. La correcta definición y validación de los valores que
deben contener dichas tablas, es una forma de prevenir la ocurrencia de este tipo de error.
Otros errores detectados corresponden al diseño de las entidades y sus relaciones. Existen dos
casos: la representación de un defecto y sus clasificaciones mediante la entidad
Registro_Taxonomia, y la representación de la relación entre un archivo y un software mediante
la entidad Archivo_Software. Estas relaciones no reflejan fielmente la realidad, permitiendo que
ocurran errores de contradicción y duplicados, como se observa en los tipos de errores Registro
85
duplicado y Registro contradictorio. Modificaciones sobre el esquema de la base de datos
ayudan a prevenir algunos de estos errores, y/o mejorar la calidad de los datos almacenados.
Por otra parte, en caso de que se pueda definir con certeza un criterio que establezca cuándo dos
o más registros de defectos se encuentran duplicados (por ejemplo: misma línea, mismo archivo,
mismo sujeto), sería posible implementar controles sobre la aplicación que verifiquen este
hecho. Sin embargo, este criterio resulta complejo de definir. A modo de ejemplo, es posible
que exista más de un defecto en la misma línea del mismo archivo. Sumado a esto, errores del
tipo Defecto mal registrado podrían incurrir en una equivocación en los controles, al considerar
que dos defectos están duplicados cuando en realidad el error se encuentra en los datos
registrados.
En conclusión, el diseño de la base de datos a utilizar debe ser objeto de una fuerte revisión,
evaluando que todos los aspectos mencionados (restricciones, entidades, relaciones) reflejen
fielmente la realidad. De esta manera la calidad de los datos almacenados se verá sin dudas
beneficiada. Vale destacar que en el marco del presente proyecto se presenta un nuevo esquema
de base de datos, el esquema destino de la migración de datos, que considera y corrige todos los
aspectos antes mencionados.
10.2 SOBRE EL REGISTRO DE TIEMPOS DE ACTIVIDADES
Durante la ejecución del experimento bajo estudio, muchas de las actividades realizadas por los
verificadores requerían ser cronometradas y el tiempo insumido en cada una registrado, tiempo
de diseño de casos de prueba, tiempo de detección de un defecto, entre otros. Cada verificador
era responsable de medir sus tiempos y luego registrarlos, ingresando su valor a través de la
herramienta Grillo. Se identifica aquí una posible causa de varios errores en los datos, como ser
tiempos mal registrados (mal tipeados), mal medidos, y también registros de tiempos
inconsistentes (por ejemplo, tiempos de detección de defectos mayores a cero durante la
ejecución de una técnica de verificación estática). Estos errores forman parte de los tipos Valor
fuera de rango, Estandarización, Defecto mal registrado y Reglas de integridad intra-relación.
Una posible solución a estos errores, es incluir un cronómetro interactivo en la herramienta
utilizada para el registro (por ejemplo ofreciendo opciones de “comienzo”, “fin” y “pausa”). De
esta manera, cada verificador solamente debe indicar qué actividad está realizando y manipular
el cronómetro adecuadamente. Una vez finalizada la tarea, el tiempo medido quedaría
automáticamente registrado, evitando que el verificador lo ingrese desde el teclado y en
consecuencia los errores que ello podría ocasionar. En el caso de tiempos de detección de
defectos para técnicas estáticas, el cronómetro no estaría disponible y un cero se guardaría
automáticamente. Con esta alternativa, se uniformiza el registro de tiempos, se estandariza la
unidad de medida y se logra una mayor precisión.
Otro aspecto importante con respecto a los tiempos, es tener claramente definido qué es lo que
se debe medir. Por ejemplo, para el tiempo de detección de defectos, tener claro si el tiempo
invertido en estudio debe incluirse en el registro o no. Esto surge a partir de la respuesta de un
sujeto que es consultado respecto al valor del tiempo de detección de un defecto, que se
encuentra fuera del rango definido. En su respuesta, el sujeto establece haber incluido dentro de
este tiempo aquel dedicado en estudio (búsqueda en Internet más específicamente) del posible
defecto. En otro caso, la respuesta del sujeto establece que se incluye también el tiempo de
corrección del defecto junto con el de detección. Los verificadores no deberían tener dudas en
cuanto a si el tiempo utilizado en determinada tarea o actividad debe registrarse.
86
10.3 OTRAS CONSIDERACIONES
Con respecto a otros errores que fueron identificados en los datos, existen ciertas pautas a tener
en cuenta que podrían ayudar a evitarlos en futuros experimentos. Tal es el caso del registro de
la línea de código en donde se identifica determinado defecto. Conociendo los archivos sobre
los cuáles van a trabajar los verificadores, resulta posible tener contabilizadas sus líneas
previamente. De esta manera, cuando se hace un registro de defecto para un archivo el número
de línea pueda ser verificado (evitando los errores del tipo Valor fuera de rango). Para el caso
de los defectos que no tienen una línea de código asociada, resultaría más adecuado poder
indicarlo de manera explícita, por ejemplo agregando un campo que indique si el defecto tiene
una línea asociada. De esta manera se evitan situaciones como la del experimento bajo estudio,
donde se indica que un defecto no tiene línea asociada ingresando determinados valores (0,
999*) en el campo línea de la tabla correspondiente.
Otro aspecto a tener en cuenta, son las clasificaciones de los defectos. Dependiendo de los
objetivos del experimento que se esté ejecutando, puede no interesar que los verificadores
realicen la clasificación de los defectos. Si este es el caso, hay dos opciones para evitar varios
errores relacionados a este punto. La primera es que luego de contar con todos los defectos que
los verificadores detectaron, el o los responsables del experimento clasifiquen los defectos
según su criterio. Otra opción es conocer de antemano los defectos que presentan los archivos
que se verifican durante el experimento, y tenerlos ya clasificados. Esta última opción puede ser
más costosa (ya que contar con la información correspondiente a todos los defectos en el código
fuente puede no resultar trivial y requiere cierto esfuerzo) pero permitiría evitar ciertos errores.
Se podría saber si se registró algún defecto que no existe, o si se registró de manera incorrecta, y
además conocer de qué tipo son los defectos que se encuentran (evitando errores del tipo
Registro inexistente y Defecto mal registrado). A pesar de que no es posible evitar
completamente la ocurrencia de estos errores, sí se puede mejorar la calidad de los datos
registrados.
En conclusión, cuanto mayor sea el control sobre el experimento (dependiendo también de sus
objetivos), mayor será la seguridad en que los datos registrados sean de buena calidad. Sin
embargo, es importante considerar que existen ciertos tipos de errores que, dadas las
características de toda experiencia empírica, no es posible solucionar (a modo de ejemplo,
errores de tipeo, de distracción o de concepto introducidos por los sujetos).
10.4 MEJORAS EN LA CALIDAD DE LOS DATOS
Teniendo en cuenta las pautas presentadas anteriormente, se presenta en esta sección un análisis
acerca del beneficio en la calidad de los datos en caso de implementar las mismas.
De un total de 55 errores identificados sobre la base de datos bajo estudio, es posible evitar la
ocurrencia de 38 de ellos mediante las estrategias planteadas anteriormente. Otros 7 quedarían
contemplados, su ocurrencia podría verse disminuida ocasionando una mejora en la calidad de
los datos. Por otra parte, existen 10 errores para los cuales habría que considerar otras formas de
prevención que escapan el alcance de este proyecto, ya que las presentadas en las secciones
anteriores no prevendrían su ocurrencia.
A continuación se presenta una discusión acerca de cuáles son los errores que se encuentran
dentro de cada categoría mencionada.
Errores que es posible evitar
87
Del tipo Valor fuera de rango es posible prevenir los 2 errores sobre las líneas, al
establecer el rango al cual deben pertenecer estos valores (incluyendo como dato la
cantidad de líneas por archivo).
Los 16 errores correspondientes a Valor nulo, Valor único y Referencia inválida,
pueden ser prevenidos mediante la definición de nuevas restricciones en el esquema de
la base de datos. .
Los tipos de errores Reglas de integridad intra-relación, Clasificación de Defectos y
Estandarización, que involucran 12 errores diferentes, pueden evitarse mediante la
definición de triggers a nivel de la base y/o controles a nivel de la aplicación. El tipo de
error Estandarización también se previene con la inclusión de un cronómetro en la
herramienta, al asegurar que se registran todos los tiempos en la misma unidad de
tiempo, y con la misma precisión.
La ocurrencia de los 6 errores correspondientes al tipo Valor fuera de referencial se
previene mediante la correcta definición y validación de los valores que contienen las
tablas precargadas por parte de los responsables del experimento. Se evita de esta
manera que los valores de las celdas que se eligen de entre un conjunto (combos),
correspondan siempre a valores válidos.
El tipo de error Registro inexistente se puede prevenir mediante la comparación de los
registros con objetos de la realidad, siempre y cuando sea posible conocer cuáles son
dichos objetos. Para el caso de la tabla Archivo, resulta sencillo hacer esto (se poseen
los fuentes del experimento), por lo cual se puede prevenir este error.
La instanciación del tipo de error Registro contradictorio sobre la tabla
Archivo_Software se soluciona con el nuevo esquema de la base definido, al no permitir
que un mismo archivo se encuentre asociado a más de un software.
Errores contemplados (potencial mejora en la calidad de los datos)
Con respecto a la representación de los defectos y sus clasificaciones, es posible mejorar
la forma en que se representa esta realidad en el diseño de la base, evitando que cada
registro de defecto se encuentre asociado a una cantidad de tuplas mayor a las
estrictamente necesarias. Se requiere que cada registro de defecto se encuentre asociado
a exactamente 3 tuplas que representan su clasificación (IBM Defect Type, IBM
Qualifier y Beizer), tal como se refleja en el nuevo esquema definido. A modo de
ejemplo, en la base actual existen registros de defectos que poseen hasta 28 registros
taxonomía asociados. No es posible asegurar, sin embargo, que este nuevo esquema
prevenga la ocurrencia de los 4 errores del tipo Registro duplicado y Registro
contradictorio referentes a la clasificación de los defectos. Sí se puede establecer con
certeza que el nuevo esquema mejora y simplifica la forma en que esto se representa,
haciendo que el análisis de los datos resulte más sencillo al eliminar tuplas innecesarias.
Los 3 errores del tipo Valor fuera de rango sobre los tiempos, se contemplan mediante
la inclusión de un cronómetro a la herramienta. A pesar de que esta propuesta no
asegura su prevención (el cronómetro puede no ser utilizado correctamente), sin duda
mejoraría la calidad de los tiempos que son registrados.
Errores no contemplados
88
Más allá de los controles que sean implementados, no es posible garantizar la
prevención de los 8 errores del tipo Defecto mal registrado que ocurren al registrar los
datos de un defecto (por ejemplo debido a errores de tipeo, de distracción o de
concepto), aunque sin duda dichos controles contribuirán en mejorar la calidad de los
datos. Bajo la suposición de que se conozca de antemano cuáles son los registros de
defectos que existen en el código verificado, tampoco resulta factible distinguir un error
del tipo Defecto mal registrado (donde algunos de los datos que se registran son
erróneos) con uno de Registro inexistente instanciado sobre tuplas de Registro_Defecto
(donde el defecto que se está registrando no existe en la realidad).
Tampoco es posible asegurar que cierto registro de defecto se corresponda o no con uno
de la realidad (tipo de error Registro inexistente), y por lo tanto no resulta posible la
prevención del tipo de error. Por el mismo motivo, no es posible asegurar la prevención
del tipo de error Registro duplicado sobre tuplas de Registro_Defecto. Dos defectos que
se registran con los mismos datos pueden corresponder a defectos en el código distintos,
si sucede que los datos fueron mal registrados.
89
La Tabla 15 resume la discusión recién presentada. Se detallan cuáles son los tipos de errores
que podrían ser prevenidos, cuáles contemplados (no se pueden prevenir pero sí mejorar), y
cuáles no poseen solución. Se muestra además la posible solución (en caso que exista una), y la
cantidad de errores en cada caso.
Tabla 15 – Tipos de errores evitables, contemplados y no contemplados
Tipos de errores Cantidad de
errores por
tipo de error
Solución Cantidad
de errores
total
EVITABLES
Valor fuera de rango Líneas (2) Control incluyendo cantidad de
líneas por archivo
38
Estandarización Todos (5) Cronómetro en herramienta
Registro inexistente Archivo_Software
(1)
Comparación con fuentes de
cada Software
Valor fuera de
referencial
Todos (6)
Definición y validación de
valores en tablas pre-cargadas
Valor nulo Todos (10) Definición de restricciones not
null
Clasificación de
defectos
Todos (2) Controles a nivel de
base/aplicación
Reglas de integridad
intra-relación
Todos (5) Controles a nivel de
base/aplicación
Valor único Todos (3) Definición de restricciones
unique
Referencia inválida Todos (3) Definición de foreign keys
Registro
contradictorio
Archivo_Software
(1)
Cambio en esquema (relación
Archivo y Software)
CONTEM-
PLADOS
Valor fuera de rango Tiempos (3) Cronómetro en herramienta
7
Registro duplicado Registro_Taxono
mia para IBM y
Beizer (2)
Cambio en esquema
(clasificación de defectos)
Registro
contradictorio
Registro_Taxono
mia para IBM y
Beizer (2)
Cambio en esquema
(clasificación de defectos)
NO CONTEM-
PLADOS
Registro inexistente Registro_Defecto
(1)
10 Defecto mal
registrado
Todos (8)
Registro duplicado Registro_Defecto
(1)
90
11 CONCLUSIONES Y TRABAJOS A FUTURO
Es fundamental que los datos resultantes de todo experimento gocen de buena calidad, ya que
estos son el punto de partida para análisis estadísticos, estudios comparativos y análisis de
datos. En este trabajo se presenta un caso de estudio en la calidad de los datos obtenidos a partir
de la ejecución de un experimento. El objetivo de dicho experimento consiste en conocer el
rendimiento y costo de diferentes técnicas de verificación unitaria. Los datos recolectados
durante el experimento se almacenaron en una base de datos relacional. Dichos datos contienen
errores, los cuales es necesario corregir en la mayor medida posible.
Los aspectos a destacar de este trabajo son: el análisis de los posibles errores a encontrar en los
datos generados en este tipo de experimentos, la limpieza de los datos del experimento bajo
estudio, migrando los mismos a un nuevo esquema que se adecúa mejor a la realidad planteada,
y la construcción de un programa que automatiza la gran mayoría de los procesos de limpieza y
migración.
11.1 CONCLUSIONES
Con el fin de detectar errores sobre la base de datos bajo estudio, se aplican un conjunto de
técnicas y actividades definidas en el área de calidad de datos. Algunas de ellas son: Data
editing para la detección de inconsistencias, Detección de datos incompletos para valores nulos,
Detección de anomalías, Identificación de objetos, entre otras.
Como resultado del análisis de los datos y la aplicación de dichas técnicas, se identifican un
total de 12 tipos de errores asociados a 4 dimensiones de la calidad de datos: Exactitud,
Completitud, Consistencia y Unicidad. Si bien los mismos surgen del estudio de los datos de
este caso en particular, errores de estos tipos podrían presentarse en cualquier experimento
similar.
Se establecen pautas de trabajo que, análogamente a los tipos de errores identificados, resultan
ser aplicables a la Calidad de Datos sobre la Ingeniería de Software Empírica. A partir de estos
resultados es posible replicar este trabajo para otros experimentos, logrando una mejora en la
calidad de los datos obtenidos, e influyendo directamente sobre la validez de sus resultados.
Se destaca que el presente trabajo es la primera experiencia de Calidad de Datos aplicada al área
de Ingeniería de Software Empírica, dentro del Instituto de Computación de la Facultad de
Ingeniería. Este dominio de aplicación no había sido explorado con anterioridad en dicho
Instituto, y no se poseía ninguna experiencia previa al respecto. En la comunidad académica en
general, a pesar de que no se ha logrado un gran avance, se observa que existe interés en este
tema. Este año se realizó el primer workshop de calidad en Ingeniería de Software (Caballero et
al., 2009).
La instanciación de cada uno de los 12 tipos de errores sobre las tablas y/o atributos de la base,
da como resultado un total de 55 errores sobre los datos. Para 38 de ellos, es posible realizar su
medición de manera automática, esto es, mediante sentencias SQL y/o algoritmos programados
en Java. Por otro parte, existen 6 errores cuya medición es manual por no ser posible su
automatización. No resulta factible en el marco de este proyecto realizar la medición para los 11
errores restantes por motivos de tiempo y alcance.
Los resultados de las mediciones indican la presencia de 18 errores sobre las tuplas de la base,
de entre los 44 que fue posible medir. Estos resultados se registran en la base de datos original.
91
Se crean para ello un total de 14 nuevas tablas, las cuales contienen la metadata de los errores,
almacenando la información de aquellas tuplas que los contienen.
Para realizar la corrección de los datos se implementa un programa en Java que automatiza la
gran mayoría de los procesos de limpieza, y la migración de los datos en su totalidad. Se destaca
como un logro importante la fácil adaptación del programa implementado a otros experimentos
de características similares, que utilicen la herramienta Grillo para registrar sus datos.
Para llevar a cabo la limpieza de los datos, se aplican técnicas y actividades de la calidad de
datos, tales como: Definición de transformaciones de datos y reglas de mapeo, Corrección de
anomalías e inconsistencias, Corrección de datos incompletos y Obtención de nueva
información. De un total de 55 errores identificados, se trabaja sobre la limpieza de los 18 de
ellos que fue posible medir y para los cuales se encontraron tuplas erróneas. No resulta posible
realizar la medición de 11 errores, mientras que para los restantes 26 no se identifican tuplas
erróneas.
Los procesos de limpieza automáticos que son ejecutados por el programa implementado,
permiten la corrección de tuplas correspondientes a 7 errores diferentes. A través de procesos
semiautomáticos de limpieza, también ejecutados durante el programa implementado y que
requieren la intervención del usuario, se corrigen tuplas correspondientes a 3 errores distintos.
Para todos los casos, la limpieza que se aplique dependerá de la elección del usuario. Se aplican
limpiezas manuales sobre 7 errores. En la mayoría de los casos dichas limpiezas consisten en
realizar consultas a los sujetos que participaron en el experimento y a sus responsables. No
resulta posible aplicar limpieza para 1 caso, el cual no es de especial interés que sea corregido.
Se detectan errores a nivel del diseño de la base de datos de la herramienta Grillo que se
traducen en errores en los datos, y por lo tanto deben ser corregidos mediante la definición de un
nuevo esquema. Se lleva a cabo la migración de los datos desde la base destino hacia el
esquema definido, durante la cual se ejecutan los procesos de limpieza automáticos y
semiautomáticos.
De un total de 6906 errores identificados sobre las tuplas de la base, lograron ser limpiados
6793. A modo de resumen, la Tabla 16 muestra el valor de calidad obtenido para las tablas
sobre las cuales se identifican tuplas erróneas. Vale destacar que una tupla errónea puede
contener más de un error diferente. Se puede apreciar cómo mejora el valor de calidad de todas
las tablas luego de aplicar las limpiezas definidas.
Tabla 16 – Valor de calidad por tabla
Tabla Valor de calidad por tabla
(antes limpieza)
Valor de calidad por tabla
(después limpieza)
Archivo 0,98 1,00
Archivo_Software 0,92 1,00
Experimento 0,89 0,98
Valor_Categoria 0,90 1,00
Registro_Defecto 0,88 0,98
Categoria 0,50 1,00
Registro_Taxonomia 0,48 1,00
92
Uno de los logros que destacamos de este trabajo es la limpieza de los datos del experimento
bajo estudio, y la migración de los mismos hacia un nuevo esquema definido para tal fin, y que
se adecúa de mejor manera a la realidad planteada. Más de un 98% de los errores detectados
son corregidos. Esto se realiza mediante la implementación de un programa que automatiza la
gran mayoría de las limpiezas y la migración de los datos. La definición de tipos de errores y
pautas de trabajos aplicables no a uno, sino a un conjunto de experimentos, es sin duda otro
logro fundamental.
A nivel personal, este trabajo nos brindó la posibilidad de profundizar nuestro conocimiento en
dos grandes áreas de conocimiento, como son la Calidad de Datos y la Ingeniería de Software
Empírica.
Las limitaciones de este trabajo están dadas por el programa implementado para la limpieza y
migración de los datos, el cual es generado para la base de la herramienta Grillo. A pesar de
que sí resulta fácilmente adaptable a otros experimentos que utilicen la misma herramienta,
requeriría de mayores ajustes el poder extender su aplicabilidad a experimentos que utilicen
otras herramientas con otras bases. Sin embargo, vale destacar que los tipos de errores
identificados sí resultan ser aplicables a cualquier otra experiencia, independientemente de la
herramienta utilizada.
11.2 TRABAJOS A FUTURO
Como primer paso a realizar sobre este trabajo, sería muy interesante llevar a cabo un análisis
estadístico de los datos limpios. A partir de la comparación de los resultados de este análisis con
los ya realizados sobre los datos originales, se podrían obtener valiosas conclusiones acerca de
la limpieza y de su impacto sobre la calidad de los datos. A su vez, las conclusiones mismas del
experimento podrían llegar a verse afectadas, dependiendo de la medida en que la limpieza
ejecutada afecte los análisis realizados.
De manera de seguir avanzando en pos de lograr experiencias empíricas de mayor calidad y
pensando en futuras replicaciones del experimento bajo estudio, creemos resultaría conveniente
adaptar la herramienta Grillo para que trabaje con el nuevo esquema de la base de datos.
Sumado a esto se debería adaptar el programa de limpieza y migración para que solamente
realice las limpiezas sobre el nuevo esquema. En caso de detectar nuevos errores, se podrían
implementar más procesos de limpieza en el mismo programa.
De la mano con esta evolución de la herramienta, podrían implementarse las mejoras propuestas
en el capítulo Prevención de Errores y Oportunidades de Mejora. Como se explica en dicho
capítulo, a través de la aplicación de estas mejoras es posible evitar 38 de los 55 errores
detectados. Es una proporción importante de errores a evitar y aportaría a mejorar la calidad de
los datos de los experimentos. Para otros 7 errores se presentan pautas para disminuir su
ocurrencia, aunque no se asegura evitarlos. Existen 10 errores para los cuales habría que seguir
indagando para encontrar una forma factible de evitarlos, o de lo contrario prevenirlos en la
mayor medida posible.
Si bien logramos obtener un conjunto de tipos de errores aplicados al área de Calidad de Datos
sobre Ingeniería de Software Empírica, se podrían agregar nuevos tipos de errores que puedan
eventualmente detectarse. Esto podría ser también el punto de partida para continuar con la
identificación de tipos de errores para otras disciplinas dentro de la Ingeniería de Software
Empírica. Seguramente aportaría a ambas áreas el poder contar con tipos de errores catalogados
según la disciplina a la cual se aplican.
93
El hecho de poder verificar que los mismos tipos de errores definidos para este caso de estudio
particular aplican sobre otro experimento de las mismas características, y obteniendo resultados
similares, permitiría avanzar en este sentido y concluir más fehacientemente la aplicabilidad de
estos tipos de errores para cualquier experimento similar.
94
12 GLOSARIO
Defectos (aplicado a Testing): imperfecciones en el software, detectados sobre el código
fuente.
Falla: manifestación externa de un defecto en el software.
Tipo de error: dada una dimensión y un factor de calidad de datos, es la definición de
un error conceptual sobre la calidad de los datos.
Errores (aplicado a Calidad de Datos): es la instanciación de un tipo de error sobre un
atributo y/o tabla específica. Se refiere a un error en la calidad de los datos.
95
13 BIBLIOGRAFÍA
Apa, C. (2009) Proyecto de Grado: Diseño y Ejecución de un Experimento con 5 Técnicas de
Verificación Unitaria, Instituto de Computación, Facultad de Ingeniería de la UdelaR.
Batini, C. and Scannapieca, M. (2006) Data Quality: Concepts, Methodologies and
Techniques, Springer - ISBN-13 978-3-540-33172-8.
Caballero, I., Calero, C., Al-Hakim, L. and Serrano, M.Á. (2009) 1st International
Workshop on Data Quality for Software Engineering (DQ4SE 2009), [Online], Available:
HYPERLINK "http://alarcos.esi.uclm.es/DQ4SE/" http://alarcos.esi.uclm.es/DQ4SE/ .
Erhard Rahm, H.H.D. (2000) Data Cleaning: Problems and Current Approaches, Universidad
de Leipzig, Alemania: IEEE Data Engineering Bulletin, Vol. 23(4): 3-13, 2000.
Faggiano, J., Apa, C., De León, S. and Robaina, R. (2008) Documentación Herramienta
Grillo, Instituto de Computación, Facultad de Ingeniería de la UdelaR: Documentos de trabajo
interno.
Juristo, N. and Moreno, A.M. (2001) Basics of Software Experimentation, Boston: Kluwer
Academic Publishers - ISBN 0-7923-7990-X.
Marotta, A. (2009) Material Curso Calidad de Datos, Instituto de Computación, Facultad de
Ingeniería de la UdelaR.
Vallespir, D., Apa, C. and De León, S. (2008) Material Módulo de Taller de Verificación,
Instituto de Computación, Facultad de Ingeniería de la UdelaR: Documentos de trabajo interno.
Vallespir, D. and Herbert, J. (2009) Effectiveness and cost of verification techniques,
preliminary conclusions on five techniques, Mexican International Conference on Computer
Science.
Vallespir, D., Herbert, J., Apa, C., De León, S. and Robaina, R. (2009) Effectiveness of Five
Verification Techniques, XXVIII International Conference of the Chilean Computer Society.
