FACULTAD DE INGENIERÍA UNIVERSIDAD DE LA REPÚBLICA. Un caso de estudio en Calidad de Datos para Ingeniería de Software Empírica

Transcripción

1 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

2

3 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. i

4 CONTENIDO 1 INTRODUCCIÓN MOTIVACIÓN OBJETIVOS CONCEPTOS TRABAJO REALIZADO Y RESULTADOS CONTENIDO CALIDAD DE DATOS INTRODUCCIÓN DIMENSIONES DE LA CALIDAD DE DATOS TÉCNICAS Y ACTIVIDADES DE CALIDAD DE DATOS LIMPIEZA DE DATOS INGENIERÍA DE SOFTWARE EMPÍRICA INTRODUCCIÓN POR QUÉ EXPERIMENTAR? CÓMO EXPERIMENTAR? CONCEPTOS BÁSICOS SOBRE EL DISEÑO DE EXPERIMENTOS EXPERIMENTO DESCRIPCIÓN DEL EXPERIMENTO HERRAMIENTA PARA REGISTRO DE DEFECTOS ANÁLISIS DE ERRORES EN LOS DATOS METODOLOGÍA DE TRABAJO EXACTITUD COMPLETITUD CONSISTENCIA UNICIDAD DIMENSIONES RELACIONADAS CON EL TIEMPO MEDICIÓN DE LA CALIDAD VALOR FUERA DE RANGO VALOR FUERA DE REFERENCIAL VALOR NULO REGLAS DE INTEGRIDAD INTRA-RELACIÓN REFERENCIA INVÁLIDA ii

5 6.6 REGISTRO DUPLICADO REGISTRO CONTRADICTORIO RESUMEN VALOR DE CALIDAD DE LOS DATOS REGISTRO DE ERRORES DESCRIPCIÓN DE LA ALTERNATIVA SELECCIONADA APLICACIÓN DEL REGISTRO DIAGRAMA RESUMEN LIMPIEZA Y MIGRACIÓN DE LOS DATOS TÉCNICAS DE LIMPIEZA APLICADAS DISEÑO DE LA BASE DE DATOS DESTINO PLANIFICACIÓN DE LA LIMPIEZA Y MIGRACIÓN EJECUCIÓN DE LIMPIEZAS Y MIGRACIÓN RESULTADOS OBTENIDOS RESUMEN APLICACIÓN INFORMACIÓN TÉCNICA MANUAL DE USUARIO ADAPTACIÓN DEL PROGRAMA DE LIMPIEZA Y MIGRACIÓN A OTROS EXPERIMENTOS PREVENCIÓN DE ERRORES Y OPORTUNIDADES DE MEJORA SOBRE EL DISEÑO DE LA BASE DE DATOS Y LA APLICACIÓN SOBRE EL REGISTRO DE TIEMPOS DE ACTIVIDADES OTRAS CONSIDERACIONES MEJORAS EN LA CALIDAD DE LOS DATOS CONCLUSIONES Y TRABAJOS A FUTURO CONCLUSIONES TRABAJOS A FUTURO GLOSARIO BIBLIOGRAFÍA iii

6 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. 1

7 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 2

8 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 3

9 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. 4

10 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 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. 5

11 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 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 Á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 6

12 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 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 7

13 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. 8

14 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) 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. 9

15 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 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: 10

16 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 t 1 y t 2 se cumple que: Si t 1.x = t 2.x t 1.y = t 2.y 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 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 11

17 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). 12

18 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) 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. 13

19 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) Fases de la Limpieza de Datos A continuación se detallan las fases de las cuales consta un proceso de limpieza de datos. 14

20 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) 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 15

21 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 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. 16

22 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. 17

23 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 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: 18

24 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 Tipos de Estudios Empíricos A nivel general, se identifican dos enfoques para la investigación empírica: 19

25 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 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 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 20

26 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 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 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) 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. 21

27 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 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. 22

28 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 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 23

29 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 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 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. 24

30 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. 25

31 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 26

32 variables no consideradas. Estas últimas pueden llegar a invalidar el resultado de un experimento 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.. 27

33 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 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 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. 28

34 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 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. 29

35 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 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 clienteservidor. Como sistema gestor de Base de Datos se utiliza HSQLDB. 30

36 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. PK Archivo id nombre nombre_usu fecha codigo Archivo_Software PK id archivo_id software_id PK Software id nombre descripcion total_defectos PK Categoria id taxonomia_id nombre PK PK Perfil id nm_perfil descripcion Estructura id nombre descripcion PK Tipo_Defecto Usuario id nombre nm_usuario apellido password habilitado perfil_id PK Registro_Defecto id tipo_id experimento_id archivo_id estructura_id linea descripcion linea_estructura time_deteccion PK PK Experimento id ejecutor_id creador_id software_id tecnica_id nombre fecha_ini fecha_fin time_casos time_ejecucion Registro_Taxonomia id registro_id taxonomia_id valor_categoria_id atributo_id PK PK Taxonomia id Tecnica id nombre numero descripcion nombre descripcion tipo PK Valor_Categoria id categoria_id categoria_padre nombre PK id nombre descripcion PK Atributo id nombre categoria_id Figura 1 Esquema de la base de datos de la herramienta TVerificar 31

37 La Tabla 1 muestra una breve descripción de cada tabla, indicando si contienen valores precargados (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 Archivo Representa un archivo que contiene código fuente (.java). Software Representa un software (conjunto de clases, métodos, etc.) que será sometido a verificación. 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. Usuario Representa un usuario que hará uso de la herramienta. Perfil Representa el perfil que contiene el Administrador usuario que utiliza la herramienta. Verificador Experimento Representa un experimento a ejecutar y su información asociada. Técnica Registro_Defecto Estructura Tipo_Defecto Representa una Técnica de Verificación. Cada registro de Experimento tiene una única Técnica asociada. Representa un defecto hallado en el código por un usuario Verificador. 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. 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. Taxonomia Representa las taxonomías existentes. IBM Inspecciones CCCM Trayectorias Independientes Tablas de Decisión Partición de Equivalencia y A. de Valores Límite IF FOR WHILE SWITCH DO WHILE METODO CLASE Estructura Sin estructura Caso cargada: perfil Administrador Administrador Administrador Administrador 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. Verificador 32

38 Categoria Atributo Registro_Taxonomia Valor_Categoria Representa los "nieveles" de cada taxonomía. Tabla vacía (sin uso) Representa un la clasificación de un registro de defecto según las taxonomías de Beizer e IBM. Representa las categorías de cada nivel de la taxonomía. Beizer Para IBM: Section Actividad Trigger Impacto Defect Type Qualifier Age Source Para Beizer: BeizerNivel1 BeizerNivel2 BeizerNivel3 BeizerNivel4 Ver base Verificador 33

39 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. 34

40 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 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 35

41 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 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). 36

42 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 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. 37

43 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 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). 38

44 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 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. 39

45 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 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: Medición 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. 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. 40

46 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 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 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. 41

47 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 Registro duplicado Se identifica este tipo de error cuando existen dos o más registros que aparecen repetidos de manera exacta. Existen dos situaciones: 42

48 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 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. 43

49 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. 44

50 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 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 45

51 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 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. 46

52 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 Function/Class/Object Assign/Initialization Assign/Initialization Checking 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 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: 47

53 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 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. 48

54 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 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. 49

55 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 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 50

56 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 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 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. 51

57 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 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 52

58 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 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 Experimento.time_e jecucion Registro_Defecto.ti me_deteccion Registro_Defecto.li nea NO 0 NO 0 SQL 21 SQL

59 Estandarización Registro inexistente Registro_Defecto.li nea_estructura SQL 3 Experimento.time_c SQL 0 asos Experimento.time_e SQL 0 jecucion Registro_Defecto.ti SQL 0 me_deteccion Registro_Defecto.li SQL 0 nea Registro_Defecto.li SQL 0 nea_estructura Registro_Defecto NO 0 Archivo Manual Exactitud semántica Defecto mal registrado Registro_Defecto.li nea NO 0 Registro_Defecto.li NO 0 nea_estructura Registro_Defecto.ti NO 0 me_deteccion Registro_Defecto.d NO 0 escripcion Registro_Defecto.es NO 0 tructura_id Registro_Defecto.a NO 0 rchivo_id Registro_Defecto.ti NO 0 po_id Registro_Taxonomi NO 0 a.valor_categoria_i d Tecnica.nombre Manual 0 0 Software.nombre Manual 0 Valor fuera de referencial Tipo_Defecto.nomb Manual 0 re Estructura.nombre Manual 0 Taxonomia.nombre Manual Categoria.nombre / Registro_Taxonomi a SQL 3721 Usuario.perfil_id SQL 0 Completitud Densidad Valor nulo Registro_Defecto.ti po_id Registro_Defecto.li nea Experimento.nombr e Registro_Defecto.ti me_deteccion Registro_Taxonomi a.registro_id Experimento.time_e jecucion Registro_Taxonomi a.taxonomia_id SQL 0 SQL 0 SQL 0 SQL 0 SQL 0 SQL 3 SQL

60 Consistencia Integridad intra-relación Clasificación de defectos Regla de integridad intrarelación Registro_Taxonomi SQL 2 a.valor_categoria_i d Experimento.time_c asos (técnica dinámica) SQL 3 Registro_Defecto SQL 3 (para IBM) Registro_Defecto SQL 0 (para Beizer) Experimento.time_c SQL 0 asos (técnica estática) Experimento.time_c SQL 0 asos (técnica dinámica) Registro_Defecto.ti SQL 90 me_deteccion Registro_Defecto.li SQL 0 nea_estructura Experimento.time_e SQL 2 jecucion Categoria.nombre SQL Integridad referencial Valor único Referencia inválida Valor_Categoria.no SQL 0 mbre, categoria_padre Experimento.nombr e SQL 0 Registro_Taxonomi SQL 0 a.taxonomia_id Registro_Taxonomi SQL 472 a.registro_id Valor_Categoria.ca SQL 19 tegoria_padre Registro_Defecto SQL Unicidad Duplicación Registro duplicado Registro_Taxonomi SQL 1705 a (para IBM) Registro_Taxonomi a (para Beizer) SQL 0 Archivo_Software SQL Contradicción Registro contradictorio Registro_Taxonomi a (para IBM) Registro_Taxonomi a (para Beizer) SQL 145 SQL y Programación

61 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 Exactitud Exactitud sintáctica Exactitud semántica Valor de calidad por tabla por tipo de error Valor de calidad por tipo de error Valor fuera de rango Registro_Defecto 0,97 0,97 Estandarización Registro_Defecto 1,00 Experimento 1,00 1,00 Registro inexistente Archivo 0,98 0,98 Defecto mal registrado N/A N/A N/A Valor fuera de referencial Tecnica 1,00 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 Consistencia Integridad intra-relación Integridad referencial Clasificación de defectos Regla de integridad intra-relación Experimento 0,86 Registro_Defecto 1,00 Registro_Taxonomia 0,86 Registro_Defecto 1,00 Experimento 0,95 Registro_Defecto 0,91 Valor único Experimento 1,00 Categoria 1,00 Valor_Categoria 1,00 Refrencia inválida Registro_Taxonomia 0,95 Valor_Categoria 0,90 Unicidad Duplicación Registro duplicado Registro_Defecto 1,00 Registro_Taxonomia 0,82 Contradicción Registro contradictorio Registro_Taxonomia 0,98 Archivo_Software 0,92 0,87 0,93 1,00 0,93 1,00 0,93 0,91 0,95 56

62 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. 57

63 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) 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. 58

64 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 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) 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. 59

65 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. 60

66 Tabla 11 Características de los errores identificados Dimensión Factor Tipo de error Error Granularidad con error Cantidad de objetos Objeto Medición Tabla de registro 1 Celda Experimento.time_c NO 0 asos 2 Celda Experimento.time_e NO 0 jecucion Valor fuera de 3 Celda Registro_Defecto.ti SQL reg_valor_fuera_rango 21 rango me_deteccion 32 4 Celda Registro_Defecto.li SQL 8 nea 5 Celda Registro_Defecto.li SQL 3 Exactitud sintáctica 6 Celda nea_estructura Experimento.time_c SQL reg_estandarizacion 0 asos 7 Celda Experimento.time_e SQL 0 jecucion Exactitud Estandarización 8 Celda Registro_Defecto.ti SQL 0 me_deteccion 0 9 Celda Registro_Defecto.li SQL 0 nea 10 Celda Registro_Defecto.li nea_estructura SQL 0 Registro 11 Tupla Registro_Defecto NO reg_registro_inexistente 0 inexistente 12 Tupla Archivo Manual 1 1 Exactitud semántica Defecto mal registrado 13 Celda Registro_Defecto.li nea 14 Celda Registro_Defecto.li nea_estructura 15 Celda Registro_Defecto.ti me_deteccion 16 Celda Registro_Defecto.d escripcion NO 0 NO 0 NO 0 NO

67 Valor fuera de referencial Completitud Densidad Valor nulo 17 Celda Registro_Defecto.es NO 0 tructura_id 18 Celda Registro_Defecto.a NO 0 rchivo_id 19 Celda Registro_Defecto.ti NO 0 po_id 20 Celda Registro_Taxonomi a.valor_categoria_i d NO 0 21 Celda Tecnica.nombre Manual reg_valor_fuera_referencial 0 22 Celda Software.nombre Manual 0 23 Celda Tipo_Defecto.nomb Manual 0 re 24 Celda Estructura.nombre Manual 0 25 Celda Taxonomia.nombre Manual 0 26 Celda / Tupla Categoria.nombre / Registro_Taxonomi a SQL Celda Usuario.perfil_id SQL reg_valor_nulo 0 28 Celda Registro_Defecto.ti po_id 29 Celda Registro_Defecto.li nea 30 Celda Experimento.nombr e 31 Celda Registro_Defecto.ti me_deteccion 32 Celda Registro_Taxonomi a.registro_id 33 Celda Experimento.time_e jecucion 34 Celda Registro_Taxonomi a.taxonomia_id SQL 0 SQL 0 SQL 0 SQL 0 SQL 0 SQL 3 SQL

68 Consistencia Integridad intra-relación Clasificación de defectos Regla de integridad intrarelación 35 Celda Registro_Taxonomi SQL 2 a.valor_categoria_i d 36 Celda Experimento.time_c asos (técnica dinámica) SQL 3 37 Tupla Registro_Defecto SQL reg_clasificacion 3 (para IBM) 38 Tupla Registro_Defecto SQL 0 (para Beizer) 39 Celda Experimento.time_c SQL reg_integridad_intra 0 asos (técnica estática) 40 Celda Experimento.time_c SQL 0 asos (técnica dinámica) 41 Celda Registro_Defecto.ti SQL 90 me_deteccion 42 Celda Registro_Defecto.li SQL 0 nea_estructura 43 Celda Experimento.time_e SQL 2 jecucion 44 Celda Categoria.nombre SQL reg_valor_unico Integridad referencial Valor único Referencia inválida 45 Celda Valor_Categoria.no mbre, categoria_padre 46 Celda Experimento.nombr e 47 Tupla Registro_Taxonomi a.taxonomia_id 48 Tupla Registro_Taxonomi a.registro_id 49 Tupla Valor_Categoria.ca tegoria_padre SQL 0 SQL 0 SQL reg_referencia_invalida 0 SQL 472 SQL

69 50 Tupla Registro_Defecto SQL reg_duplicado 0 Unicidad Duplicación Registro duplicado 51 Tupla Registro_Taxonomi SQL 1705 a (para IBM) 52 Tupla Registro_Taxonomi a (para Beizer) SQL 0 53 Tupla Archivo_Software SQL reg_contradictorio Contradicción Registro contradictorio 54 Tupla Registro_Taxonomi a (para IBM) 55 Tupla Registro_Taxonomi a (para Beizer) SQL 145 SQL y Programación

70 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 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. 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, 65

71 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 o 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. 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. 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 o o 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. 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. 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. 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 66

72 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 (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 67

73 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. 68

74 PK id Archivo nombre nombre_usu fecha fk_software_id PK Software id nombre descripcion Usuario PK id Experimento PK PK Perfil id nm_perfil descripcion Estructura id nombre descripcion PK nombre nm_usuario apellido password habilitado fk_perfil_id Registro_Defecto 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 PK id fk_ejecutor_id fk_creador_id fk_software_id fk_tecnica_id nombre fecha_ini fecha_fin time_casos time_ejecucion PK Tecnica id IBM_Defect_Type PK id categoria nombre descripcion tipo Tipo_Defecto PK id nombre descripcion PK Taxonomia_Beizer id categoria fk_categoria_padre codigo IBM_Qualifier PK id categoria Figura 3 Esquema de la base de datos destino 69

75 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 Archivo Software Usuario Perfil Experimento Técnica Registro_Defecto Estructura Tipo_Defecto Taxonomia_Beizer IBM_Qualifier IBM_DefectType Descripción Tabla Representa un archivo que contiene código fuente (.java). Cada archivo pertenece a un único Software. Representa un software (conjunto de clases, métodos, etc.) que será sometido a verificación. Representa un usuario que hará uso de la herramienta. Representa el perfil que contiene el usuario que utiliza la herramienta. Representa un experimento a ejecutar y su información asociada. Representa una Técnica de Verificación. Cada registro de Experimento tiene una única Técnica asociada. Representa un defecto hallado en el código por un usuario Verificador. 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. 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. 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. 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. 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. 70

76 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. 71

77 Base de Datos Origen Perfil Base de Datos Destino Perfil Estructura Estructura Software Transformación 1 Software Archivo Archivo_Software Transformación 2 Limpieza Error 53 Archivo Limpiezas manuales: Error 12 Tipo_Defecto Tipo_Defecto Tecnica Tecnica Usuario Transformación 3 Usuario Experimento Categoria Transformación 4 Experimento Valor nulo en el atributo time_casos para técnicas dinámicas Limpiezas manuales: Errores , 43 Transformación 5 Limpieza Error 26 IBM_Defect_Type Valor_Categoria Valor fuera de referencial en el atributo nombre de la tabla Categoria Transformación 6 Limpieza Error 26 IBM_Qualifier Valor fuera de referencial en el atributo nombre de la tabla Categoria Transformación 7 Limpieza Error 49 Taxonomia_Beizer Registro_Defecto Transformación 8 Limpieza Errores 26, 34, 41, 48, 51, 54, 55 Registro_Defecto Limpiezas manuales: Errores 3, 4, 5, 53 Registro_Taxonomia 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 Figura 4 Migración y limpieza de los datos 72

78 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 73

79 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 74

80 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 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. 75

81 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. 76

82 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 77

83 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 Registro inexistente Valor fuera de referencial Valor nulo Clasificación de defectos Regla de integridad intrarelación Referencia inválida Registro duplicado Registro contradictorio RegistroDefecto.time_detecc Manual 21 7 ion RegistroDefecto.linea Manual 8 4 RegistroDefecto.linea_estru Manual 3 2 ctura Archivo Manual 1 1 Categoria.nombre / Automática Registro_Taxonomia Experimento.time_ejecucion Manual 3 3 RegistroTaxonomia.taxonom NO ia_id RegistroTaxonomia.valor_c NO 2 2 ategoria_id Experimento.time_casos (técnica dinámica) Manual 3 3 Registro_Defecto (para NO 3 0 IBM) RegistroDefecto.time_detecc Semiautomática 90 Depende de la ion decisión del usuario Experimento.time_ejecucion Manual 2 1 RegistroTaxonomia.registro Automática _id ValorCategoria.categoria_p adre Automática RegistroTaxonomia (para Automática IBM) Archivo_Software Manual / 4 4 Automática RegistroTaxonomia (para Semiautomática IBM) RegistroTaxonomia (para Semiautomática Beizer) 78

84 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 Java 1.6 HSQLDB Herramientas Ecplipse 3.4 VisualSwing plug-in 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: 79

85 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. 80