estrategias para mejoras en el mantenimiento de software
TRANSCRIPT
Estrategias para mejoras en el mantenimiento de software Emitzá Guzmán Ortega
Technische Universität München
Abstract
El reporte de bug juega un rol importante en el proceso de mantenimiento de
software. Dentro de este trabajo proponemos mejorar la calidad del texto presente en
los reportes de bugs, así como mecanismos para detectar y completar información
faltante en el reporte y predecir preguntas aclaratorias, a fin de acelerar los tiempos de
solución del bug.
1. Introducción
El mantenimiento de software utiliza de 60 a 80% de los recursos en el ciclo de
desarrollo [1] y los desarrolladores pasan el 49% de su tiempo de trabajo corrigiendo
bugs [2]. El mantenimiento de software está conformado por actividades como el
reporte del bug por parte de un usuario o desarrollador, la asignación de un
desarrollador encargado, la localización del bug, el entendimiento de las causas que
dieron lugar al bug y la corrección pertinente. Los reportes de bugs son un
componente vital dentro de este proceso, ya que permiten reportar anomalías
presentes en el software. Los reportes comúnmente incluyen una descripción del bug
en lenguaje natural, stack traces, pedazos de código y parches [3]. Dentro del proceso
de mantenimiento de software, la calidad de la información dentro del reporte es
determinante para la velocidad con que se resuelve el bug [4]. Reportes que usan un
lenguaje poco claro tienden a resolverse más lentamente que aquellos que usan un
lenguaje claro [4,5]. Asimismo, desarrolladores han expresado que reportes con
información incorrecta o incompleta son más díficiles de resolver [4]. Cuando la
información proporcionada es incorrecta o no clara los desarrolladores pueden hacer
preguntas adicionales, lo que ocasiona retardos en los tiempos de solución del bug.
Esta tesis pretende resolver estos problemas mediante la implementación y evaluación
de una herramienta que analiza y propone mejoras en el lenguaje utilizado en los
reportes de bugs y que detecta información incorrecta o faltante, recomendando las
correcciones pertinentes. Además, la herramienta será capaz de predecir, en base al
minado de reportes ya existentes, posibles preguntas aclaratorias por parte del
desarrollador encargado de resolver el bug.
Este trabajo se divide en tres áreas principales:
1. Análisis del lenguaje utilizado en reportes de bugs
2. Detección de información incorrecta o faltante en reportes de bugs
3. Predicción de preguntas aclaratorias en reportes de bugs
2. Preguntas de Investigación
Las principales preguntas de investigación divididas en las áreas detectadas
previamente son las siguientes:
Análisis de lenguaje utilizados en reportes de bugs
¿Qué impacto tiene la claridad del texto en el tiempo de solución del bug?, ¿se
pueden aplicar las métricas comúnmente utilizadas para calcular la claridad en
reportes de bugs?, ¿ayudan los métodos de simplificación para mejorar la
claridad en los reportes de bugs?
Detección de información incorrecta o faltante en reportes de bugs
¿Qué impacto tiene la información faltante o incorrecta en el tiempo de solución
de bugs?, ¿hay algún tipo de información que tienda a ser proporcionada de
manera errónea?, ¿cómo ayuda la detección y corrección de información
incorrecta y la insercion de información faltante en el tiempo de solución de
bugs?
Predicción de preguntas aclaratorias en reportes de bugs
¿Qué hacen los desarrolladores para obtener información faltante y para obtener
información aclaratoria?, ¿en qué medida afecta en el tiempo de solución de un
bug la inserción de información que es respuesta a una pregunta aclaratoria
predecida?
3. Metodología
Para la mejora del lenguaje en la descripción de reportes de bugs se analizarán
métricas previamente utilizadas para evaluar la calidad de ensayos escolares y
artículos de divulgación. Algunas de las métricas a utilizar son: Kincaid, ARI,
Coleman-Liau, Flesh, Fog, Lix y SMOG. La aplicación de estas métricas en reportes
de bugs es novedosa, debido a la brevedad de la información encontrada en los
reportes y a la presencia de tecnicismos referentes al software que se describe. Se
evaluará el desempeño de las métricas contra la percepción de desarrolladores. Para
la obtención de textos más comprensibles se aplicarán algoritmos de simplificación de
lenguaje [6].
Para detectar información faltante utilizaremos los campos comúnmente presentes en
los sistemas para reportar bugs como meta-datos. Sugerirémos al que hace el reporte
que llene los campos en caso de que estén vacíos y hayan sido detectados como
importantes por desarrolladores [4]. Asimismo, nos basaremos en el trabajo realizado
por Bettenburg et al. [3] y Bacchelli et al. [7] para detectar información relevante en
el reporte de bug que no está contenida en campos específicos. Además,
implementaremos sensores que puedan proporcionar información con respecto al
entorno de la aplicación. Esta información se comparará con la suministrada por el
que hace el reporte y en caso de que sean diferentes, se emitirá una advertencia.
Para la predicción de preguntas frecuentes se clasificarán los reportes de bugs
antiguos pertenecientes al mismo proyecto de acuerdo a su temática principal. Para
esto se utilizarán algoritmos de clasificación como latent Dirichlet allocation (LDA) y
máquinas de vectores de soporte (VSM). Después se detectarán las preguntas por
medio de expresiones regulares y se agruparán con otras preguntas similares. Los
grupos de preguntas similares se ordenarán de acuerdo a su tamaño (frecuencia de
aparición). Este ranking y la clasificación de reportes serán la base para las predicción
de preguntas aclaratorias. La obtención de estas preguntas se utilizará para sugerir al
que está reportando que inserte la información que dé respuesta a las preguntas
aclaratorias en el reporte.
4. Contribuciones
Las principales contribuciones de este trabajo son el análisis de la calidad del
texto en los reportes de bug, su mejoramiento y el estudio del impacto que este
mejoramiento tiene en el tiempo de solución. Además de el estudio de los
mecanismos que utilizan desarrolladores para obtener información faltante o no
clara en el reporte de bug. Otras contribuciones son la implementación y
evaluación de mecanismos que permiten completar la información faltante y
predecir preguntas aclaratorias.
Referencias
[1] Canfora, G., & Cimitile, A. (2001). Software Maintenance. Handbook of Software Engineering and Knowledge Engineering (pp. 91–120).
[2] LaToza, T. D., Venolia, G., & DeLine, R. (2006). Maintaining mental models: a study of developer work habits. Proceeding of the 28th international conference on Software engineering - ICSE ’06 (pp. 492–501).
[3] Bettenburg, N., Premraj, R., Zimmermann, T., & Kim, S. (2008). Extracting structural information from bug reports. Proceedings of the 2008 international workshop on Mining software repositories - MSR ’08 (p. 27-30).
[4] Bettenburg, N., Just, S., Schröter, A., Weiss, C., Premraj, R., & Zimmermann, T. (2008). What makes a good bug report? Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering - SIGSOFT ’08/FSE-16 (p. 308-318).
[5] Hooimeijer, P., & Weimer, W. (2007). Modeling bug report quality. Proceedings of the twenty-second IEEE/ACM international conference on Automated software engineering - ASE ’07 (p. 34-43).
[6] Chandrasekar, R., Doran, C., & Srinivas, B. (1996). Motivations and methods for text simplification. Proceedings of the 16th conference on Computational linguistics - (Vol. 2, p. 1041-1044).
[7] Bacchelli, A., Dal Sasso, T., D’Ambros, M., & Lanza, M. (2012). Content classification of development emails. Proceedings of the 2012 International Conference on Software Engineering Pages - ICSE ’12 (pp. 375–385).