Los puntos clave no están disponibles para este artículo en este momento.
Los investigadores en ingeniería de software han estado interesados durante mucho tiempo en dónde y por qué ocurren errores en el código, y en predecir dónde pueden aparecer a continuación. Los datos históricos sobre la ocurrencia de errores han sido clave para esta investigación. Los sistemas de seguimiento de errores y los historiales de versiones de código registran cuándo, cómo y por quién se corrigieron los errores; a partir de estas fuentes, se pueden extraer conjuntos de datos que relacionan los cambios en los archivos con las correcciones de errores. Estos conjuntos de datos históricos se pueden utilizar para probar hipótesis sobre los procesos de introducción de errores y también para construir modelos estadísticos de predicción de errores. Desafortunadamente, los procesos y los humanos son imperfectos, y solo una fracción de las correcciones de errores están realmente etiquetadas en los historiales de versiones de código fuente, y por lo tanto, se vuelven disponibles para el estudio en los conjuntos de datos extraídos. Surge la pregunta natural: ¿son las correcciones de errores registradas en estos conjuntos de datos históricos una representación justa de la población total de correcciones de errores? En este trabajo, investigamos datos históricos de varios proyectos de software y encontramos evidencia contundente de sesgo sistemático. Luego investigamos los efectos potenciales de conjuntos de datos "injustos e imbalanced" en el rendimiento de las técnicas de predicción. Sacamos la lección de que el sesgo es un problema crítico que amenaza tanto la efectividad de los procesos que dependen de conjuntos de datos sesgados para construir modelos de predicción como la generalizabilidad de las hipótesis probadas en datos sesgados.
Bird et al. (Mon,) estudiaron esta cuestión.