Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis

Imagina que eres un detective intentando encontrar a un único traidor oculto en una multitud de mil ciudadanos inocentes. Tu trabajo es señalar quién es el traidor antes de que cause algún problema. Esta es la realidad diaria de los ingenieros de software, quienes actúan como detectives digitales en busca de "bugs" o defectos en el código informático. En el mundo de la ingeniería de software, esta búsqueda se llama Predicción de Defectos de Software. Es un juego de alto riesgo donde el objetivo es detectar el mal código antes de que rompa el sistema.

Para jugar este juego, los ingenieros utilizan programas informáticos llamados modelos de Aprendizaje Automático (Machine Learning). Piensa en estos modelos como asistentes súper inteligentes que han leído millones de líneas de código en el pasado. Observan una nueva pieza de código y le asignan una "puntuación de sospecha" entre 0 y 1. Una puntuación de 0 significa "totalmente inocente" y una de 1 significa "culpable de cargo". La parte difícil es decidir dónde trazar la línea. Si estableces la línea demasiado baja, podrías acusar a personas inocentes (falsas alarmas), perdiendo el tiempo de todos. Si la estableces demasiado alta, podrías dejar pasar al verdadero traidor (defectos omitidos), lo cual podría ser desastroso. Durante mucho tiempo, la mayoría de los detectives simplemente usaron una regla estándar: "Si la puntuación es superior a 0.5, es culpable". Pero, como sugiere esta nueva investigación, esa regla estándar podría no estar dando en el blanco.

---

La Gran Idea del Artículo: Encontrar la Línea Perfecta

En su artículo, "Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis", Nitin Sai Bommi, Umamaheswara Sharma Bhutamapuram y Atul Negi argumentan que la vieja "regla del 0.5" es como usar un sombrero de talla única para una multitud de personas con tamaños de cabeza muy diferentes. Simplemente no le queda bien a todo el mundo.

Los autores proponen una nueva forma de jugar el juego. En lugar de confiar ciegamente en la línea por defecto, sugieren dos trucos ingeniosos para encontrar la línea perfecta para cada situación específica. Su objetivo es maximizar la diferencia entre atrapar a los malos (Probabilidad de Detección) y evitar falsas acusaciones (Probiente de Falsa Alarma). Quieren atrapar al traidor sin perder el tiempo con transeúntes inocentes.

Truco #1: El Objetivo Móvil (Umbral Óptimo)

El primer truco consiste en ajustar la "línea de sospecha". Los investigadores probaron tres tipos diferentes de asistentes detectives: Regresión Logística, Naïve Bayes y Redes Neuronales. Descubrieron que el número mágico no era 0.5 para ninguno de ellos.

• Para el asistente de Regresión Logística, el punto ideal estaba alrededor de 0.35.
• Para Naïve Bayes, era incluso más bajo, en 0.3.
• Para la Red Neuronal, era 0.38.

Piensa en esto como sintonizar una radio. Si dejas el dial en el medio, podrías escuchar estática. Pero si lo mueves ligeramente hacia la izquierda o hacia la derecha, de repente la música llega clara como el cristal. Al bajar el umbral (a alrededor de 0.3 o 0.4), estos modelos se volvieron mucho mejores para detectar los defectos reales manteniendo bajo el número de falsas alarmas. En sus pruebas a través de 36 versiones de 10 proyectos de software, este simple ajuste superó consistentemente al método estándar.

Truco #2: El Juego del "¿Qué pasaría si...?" (Explicaciones Contrafácticas)

El segundo truco es un poco más mágico. Los autores utilizaron algo llamado Explicaciones Contrafácticas. Imagina que tienes la foto de un sospechoso "culpable" (un módulo de código defectuoso). El modelo dice: "Esto es malo". Ahora, imagina que pudieras preguntarle al modelo: "¿Qué pasaría si cambiara esta pequeña cosa? ¿Se volvería inocente?".

Los investigadores hicieron exactamente eso. Tomaron código que el modelo ya sabía que era bueno o malo y preguntaron: "¿Qué pequeño cambio cambiaría esto de bueno a malo, o de malo a bueno?". Utilizaron estos escenarios de "¿qué pasaría si...?" para crear nuevos ejemplos sintéticos de código. Luego, alimentaron estos nuevos ejemplos de nuevo al modelo para darle un entrenamiento adicional.

Es como un entrenador mostrando a un jugador un video de una jugada perfecta, y luego preguntándole: "¿Qué pasaría si hubieras fallado la pelota por un centímetro?", y usar eso para enseñarle al jugador cómo ajustarse. El artículo encontró que este método ayudó a los modelos a entender mejor los datos, aunque no siempre superó al truco simple del "objetivo móvil".

Lo que Encontraron (y lo que No)

Los resultados fueron prometedores pero específicos. Los autores midieron su éxito utilizando dos herramientas principales:

1. Tasa de Omisión Falsa (FOR): ¿Con qué frecuencia pasaron por alto un defecto real? (Querían que fuera baja).
2. Porcentaje de Presupuesto Ahorrado (PSB): ¿Cuánto tiempo y dinero ahorraron al no probar el código limpio?

Cuando utilizaron su nuevo método de "objetivo móvil", los modelos funcionaron mejor que con el método antiguo. Por ejemplo, con el modelo de Regresión Logística, el umbral óptimo promedio fue de 0.35, y redujo significativamente la tasa de defectos omitidos en comparación con el umbral estándar de 0.5.

Sin embargo, los autores son cuidadosos al no llamar a esto una solución mágica. Expresan explícitamente que, si bien estos métodos mejoran el equilibrio entre atrapar errores y evitar falsas alarmas, no lo solucionan todo. El método contrafáctico (el juego del "¿qué pasaría si...?") ayudó, pero no siempre dio los mejores resultados porque el modelo no es perfecto al generar esos ejemplos falsos en primer lugar.

También señalan que sus hallazgos se basan en conjuntos de datos específicos (el repositorio PROMISE) y podrían verse diferentes si se aplicaran a tipos de proyectos de software totalmente distintos. No demostraron que esto funcione para todo el software del universo, pero sí demostraron que, para los proyectos que probaron, alejarse de la regla por defecto de 0.5 es un movimiento inteligente.

Por Qué Esto Importa

Este artículo es un recordatorio de que en el mundo del software, el "talla única" suele ser una trampa. La forma estándar de decidir qué es un error y qué no lo es puede ser demasiado rígida. Al simplemente preguntarle a la computadora: "¿Cuál es la mejor línea para trazar para este trabajo específico?" y al usar preguntas de "¿qué pasaría si...?" para aprender más, podemos construir software que sea más seguro y más económico de mantener. Es un pequeño cambio de perspectiva, pero para los detectives que cazan errores en la oscuridad digital, podría ser la linterna que necesitaban.