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

Immagina di essere un detective che cerca di trovare un singolo traditore nascosto in una folla di mille cittadini innocenti. Il tuo compito è indicare chi è il traditore prima che possa causare problemi. Questa è la realtà quotidiana per gli ingegneri del software, che agiscono come detective digitali alla caccia di "bug" o difetti nel codice informatico. Nel mondo dell'ingegneria del software, questa caccia è chiamata Previsione dei Difetti del Software (Software Defect Prediction). È un gioco ad alta posta in gioco dove l'obiettivo è individuare il codice cattivo prima che rompa il sistema.

Per giocare a questo gioco, gli ingegneri utilizzano programmi per computer chiamati modelli di Machine Learning. Pensa a questi modelli come ad assistenti super intelligenti che hanno letto milioni di righe di codice in passato. Guardano un nuovo pezzo di codice e gli assegnano un "punteggio di sospetto" tra 0 e 1. Un punteggio di 0 significa "totalmente innocente", e un punteggio di 1 significa "colpevole accertato". La parte complicata è decidere dove tracciare la linea. Se imposti la linea troppo in basso, potresti accusare persone innocenti (falsi allarmi), sprecando il tempo di tutti. Se la imposti troppo in alto, potresti lasciare che il vero traditore sfugga (difetti mancati), il che potrebbe essere disastroso. Per molto tempo, la maggior parte dei detective ha usato una regola standard: "Se il punteggio è superiore a 0,5, è colpevole". Ma come suggerisce questa nuova ricerca, questa regola standard potrebbe non essere quella giusta.

---

La Grande Idea del Paper: Trovare la Linea Perfetta

Nel loro articolo, "Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis", Nitin Sai Bommi, Umamaheswara Sharma Bhutamapuram e Atul Negi sostengono che la vecchia "regola dello 0,5" è come usare un cappello taglia unica per una folla di persone con dimensioni della testa molto diverse. Semplicemente non va bene per tutti.

Gli autori propongono un nuovo modo di giocare al gioco. Invece di fidarsi ciecamente della linea predefinita, suggeriscono due trucchi astuti per trovare la linea perfetta per ogni specifica situazione. Il loro obiettivo è massimizzare la differenza tra l'individuazione dei cattivi (Probabilità di Rilevamento) ed evitare accuse errate (Probabilità di Falso Allarme). Vogliono catturare il traditore senza sprecare tempo con i passanti innocenti.

Trucco n. 1: Spostare l'Obiettivo (Soglia Ottimale)

Il primo trucco riguarda la regolazione della "linea di sospetto". I ricercatori hanno testato tre diversi tipi di assistenti detective: Regressione Logistica, Naïve Bayes e Reti Neurali. Hanno scoperto che il numero magico non era 0,5 per nessuno di loro.

• Per l'assistente di Regressione Logistica, il punto ideale era intorno a 0,35.
• Per Naïve Bayes, era ancora più basso, a 0,3.
• Per la Rete Neurale, era 0,38.

Pensa a sintonizzare una radio. Se lasci la manopola nel mezzo, potresti sentire solo interferenze. Ma se la sposti leggermente a sinistra o a destra, improvvisamente la musica arriva cristallina. Spostando la soglia verso il basso (intorno a 0,3 o 0,4), questi modelli sono diventati molto più bravi a individuare i veri difetti mantenendo bassi i falsi allarmi. Nei loro test su 36 versioni diverse di 10 progetti software, questo semplice aggiustamento ha superato costantemente il metodo standard.

Trucco n. 2: Il Gioco del "E se..." (Spiegazioni Controfattuali)

Il secondo trucco è un po' più magico. Gli autori hanno utilizzato qualcosa chiamato Spiegazioni Controfattuali. Immagina di avere la foto di un sospetto "colpevole" (un modulo di codice difettoso). Il modello dice: "Questo è cattivo". Ora, immagina di poter chiedere al modello: "E se cambiassi questa piccola cosa? Diventerebbe innocente?".

I ricercatori hanno fatto esattamente questo. Hanno preso del codice che il modello già sapeva essere buono o cattivo e hanno chiesto: "Quale piccola modifica trasformerebbe questo da buono a cattivo, o da cattivo a buono?". Hanno usato questi scenari "e se" per creare nuovi esempi sintetici di codice. Poi, hanno inserito questi nuovi esempi nel modello per dargli un po' di addestramento extra.

È come un allenatore che mostra a un giocatore il video di una giocata perfetta, per poi chiedere: "E se avessi mancato la palla di un pollice?" e usare questo per insegnare al giocatore come correggersi. Il paper ha scoperto che questo metodo ha aiutato i modelli a comprendere meglio i dati, anche se non ha sempre battuto il semplice trucco dello "spostamento dell'obiettivo".

Cosa Hanno Trovato (e Cosa Non Hanno Trovato)

I risultati sono stati promettenti ma specifici. Gli autori hanno misurato il loro successo usando due strumenti principali:

1. Tasso di Omissione Errata (FOR): Quanto spesso hanno mancato un difetto reale? (Volevano che fosse basso).
2. Percentuale di Budget Risparmiato (PSB): Quanto tempo e denaro hanno risparmiato non testando il codice pulito?

Quando hanno usato il loro nuovo metodo dello "spostamento dell'obiettivo", i modelli si sono comportati meglio rispetto al vecchio modo. Ad esempio, con il modello di Regressione Logistica, la soglia ottimale media era 0,35, e ha ridotto significativamente il tasso di difetti mancati rispetto alla soglia standard di 0,5.

Tuttavia, gli autori sono cauti nel non definire questo metodo come una soluzione magica. Affermano esplicitamente che, sebbene questi metodi migliorino l'equilibrio tra il catturare i bug ed evitare falsi allarmi, non risolvono tutto. Il metodo controfattuale (il gioco del "e se") ha aiutato, ma non ha sempre dato i risultati migliori perché il modello non è perfetto nel generare quegli esempi finti in primo luogo.

Evidenziano anche che le loro scoperte si basano su set di dati specifici (il repository PROMISE) e potrebbero apparire diverse se applicate a tipi di progetti software totalmente differenti. Non hanno dimostato che questo funzioni per ogni software dell'universo, ma hanno dimostrato che, per i progetti che hanno testato, allontanarsi dalla regola predefinita dello 0,5 è una mossa intelligente.

Perché Questo è Importante

Questo articolo è un promemoria del fatto che nel mondo del software, l'approccio "una taglia va bene per tutti" è spesso una trappola. Il modo standard di decidere cosa è un bug e cosa no potrebbe essere troppo rigido. Chiedendo semplicemente al computer: "Qual è la linea migliore da tracciare per questo lavoro specifico?" e usando domande del tipo "e se" per imparare di più, possiamo costruire software più sicuri e meno costosi da mantenere. È un piccolo cambio di prospettiva, ma per i detective che danno la caccia ai bug nell'oscurità digitale, potrebbe essere proprio la torcia di cui avevano bisogno.