Multi-stage Dynamic Selection for Cross-Project Defect Prediction

Immagina di essere un detective che cerca di risolvere un mistero, ma non hai mai visto la scena del crimine prima d'ora. Hai solo una pila di vecchi fascicoli di casi provenienti da città completamente diverse, scritti da diverse forze di polizia con i loro diversi gerghi e abitudini. Il tuo compito è prevedere dove colpirà il prossimo criminale nella tua nuova città. Questo è il lottare quotidiano degli ingegneri del software che cercano di mantenere i loro programmi privi di bug. Vogliono trovare i "difetti" (bug) nel loro codice prima che il software si blocchi, ma molti nuovi progetti sono come lavagne vuote: non sono stati in esecuzione abbastanza a lungo da costruire una cronologia di errori. Così, gli ingegneri provano a imparare da altri progetti, sperando che ciò che ha funzionato per un'azienda di videogiochi possa aiutare a correggere un'app bancaria. Questo è chiamato Cross-Project Defect Prediction (Previsione dei Difetti tra Progetti Diversi). Il problema è che ogni progetto è unico; un modello che funziona perfettamente su uno potrebbe fallire miseramente su un altro perché le "scene del crimine" (il codice) appaiono così diverse.

Entra in scena una nuova squadra di detective digitali chiamata Multi-DES. Invece di assumere un singolo detective per risolvere ogni caso nella nuova città, o costringere un "super-detective" a cercare di comprendere ogni quartiere contemporaneamente, questa squadra utilizza una strategia intelligente in due fasi. Prima, fanno l'audizione a una massa enorme di diversi detective, ognuno con il proprio stile unico e il proprio kit di strumenti, per vedere quale gruppo di esperti funziona meglio insieme guardando i vecchi fascicoli dei casi. Poi, quando arriva un nuovo caso, non scelgono solo un detective. Invece, osservano i dettagli specifici di quel nuovo caso e chiamano istantaneamente l'esperto migliore per quella specifica situazione. È come avere un team di specialisti dove un agente del traffico si occupa di un incidente stradale, un contabile forense si occupa di una frode e un negoziatore si occupa di una situazione di ostaggi, tutti scelti al volo. I ricercatori hanno scoperto che questo approccio "l'esperto giusto per il momento giusto" è molto più efficace nel trovare bug in nuovi progetti sconosciuti rispetto ai vecchi metodi che cercavano di usare la stessa singola soluzione per tutto.

L'Agenzia Investigativa: Come funziona Multi-DES

Nel mondo del software, un "difetto" è un bug — un errore nel codice che potrebbe causare il crash del programma o un comportamento anomalo. Prevedere questi bug è fondamentale perché trovarli precocemente fa risparmiare tempo e denaro. Ma ecco l'ostacolo: per insegnare a un computer come individuare un bug, di solito serve un gran numero di esempi passati di bug. I nuovi progetti non hanno ancora questi esempi. Quindi, gli ingegneri provano a prendere in prestito la conoscenza da altri progetti più vecchi. Questa è la parte "Cross-Project".

Tuttavia, c'è un grande ostacolo: lo Shift di Distribuzione (Distribution Shift). Immagina di cercare di imparare a guidare in un paese dove tutti guidano a sinistra, usando solo un manuale scritto per un paese dove tutti guidano a destra. Le regole sono simili, ma i dettagli sono invertiti. Nel software, un progetto potrebbe utilizzare uno stile di codifica specifico, mentre un altro ne utilizza uno completamente diverso. I metodi tradizionali cercano di costruire un unico modello gigante che cerchi di comprendere tutte queste differenze contemporaneamente. Gli autori di questo articolo sostengono che questo è come cercare di usare una singola mappa generica per ogni città del mondo; è troppo ampia e perde di vista le strade locali.

L'articolo propone Multi-DES (Multi-stage Dynamic Ensemble Selection), che è un po' come un'agenzia di assunzione intelligente e adattiva per i detective del software. Opera in due fasi principali:

Fase 1: La Grande Audizione (Livello di Progetto)
Prima che il sistema veda il nuovo progetto, attraversa una massiccia fase di "sovrapproduzione". Immagina una chiamata al casting dove provano ogni possibile combinazione di:

• Base Classifiers (Classificatori Base): Diversi tipi di algoritmi (come alberi decisionali, foreste casuali, ecc.). Pensali come diversi tipi di detective (quello osservatore, quello logico, quello che riconosce i pattern).
• Dynamic Selection Techniques (Tecniche di Selezione Dinamica): Diversi modi per decidere di chi fidarsi.
• Pool Sizes (Dimensioni del Pool): Quanti detective ci sono nella stanza.

Testano tutte queste combinazioni (4 algoritmi base × 8 tecniche di selezione × 10 dimensioni del pool = 320 diverse configurazioni) su un set di progetti di "addestramento". Ma non scelgono semplicemente quello che ha ottenuto il punteggio più alto in un singolo test. Invece, utilizzano una strategia chiamata Aggregate Rank Minimization (ARM).

La Strategia ARM: Il Giudice "Tuttofare"
Immagina un talent show dove devi scegliere un vincitore basandoti su canto, danza e recitazione. Se scegli solo la persona con la voce migliore, potrebbe essere terribile nella recitazione. ARM è come un giudice che classifica ogni concorrente in tutte e tre le abilità, poi somma i loro ranghi per trovare la persona che è il concorrente più costante e completo. L'articolo suggerisce che, guardando più metriche di performance (come F1-score, AUC e False Alarm) insieme, il sistema trova una configurazione che è robusta e che non fallirà quando il nuovo progetto apparirà diverso dagli altri progetti precedenti.

Fase 2: La Selezione "Al Volo" (Livello di Modulo)
Una volta scelta la migliore configurazione dell' "audizione", il sistema è pronto per il nuovo progetto. Ma ecco la magia: non applica un solo modello all'intero progetto. Il software è composto da molti "moduli" (come le singole stanze in una casa o i capitoli in un libro).

Quando il sistema osserva un modulo specifico nel nuovo progetto, si chiede: "Quale dei nostri detective addestrati è il migliore nel individuare i bug in questo specifico tipo di codice?" Seleziona dinamicamente i classificatori più competenti per quel pezzo specifico di codice. Se un modulo sembra un'app bancaria, sceglie l'"esperto di finanza" dal suo pool. Se un altro modulo sembra un motore di gioco, sceglie l'"esperto di grafica". Questo avviene in tempo reale, per ogni singolo pezzo di codice.

Cosa hanno scoperto

I ricercatori hanno testato questa idea su 82 progetti software provenienti da quattro diversi dataset pubblici (PROMISE, RELINK, NASA e AEEEM). Hanno utilizzato un metodo di test rigoroso chiamato "leave-one-project-out", il che significa che hanno addestrato il modello su 81 progetti e hanno cercato di prevedere i bug nell'82°, ripetendo poi l'operazione per ogni progetto.

I risultati sono stati piuttosto promettenti:

• Meglio del Migliore: Multi-DES ha superato o pareggiato i migliori metodi esistenti nella maggior parte dei casi. Nello specifico, ha ottenuto i migliori risultati per le metriche AUC (una misura di quanto bene il modello distingue tra codice con bug e codice pulito) e False Alarm (quanto spesso "grida al lupo") nella maggior parte dei dataset.
• I Numeri: Sul dataset AEEEM, Multi-DES ha ottenuto un AUC di 0,755, superando il secondo miglior metodo (EASC-NB) che ha ottenuto 0,692. Sul dataset NASA, ha ottenuto 0,737 rispetto a 0,666.
• Robustezza: Il sistema è stato particolarmente bravo a mantenere bassi i "False Alarms", il che significa che non ha fatto perdere tempo agli ingegneri controllando codice che era in realtà corretto.
• Nessun Inganno: Fondamentalmente, il sistema ha fatto tutto questo senza guardare alcun dato del nuovo progetto target durante la fase di addestramento. Si è basato interamente sui vecchi progetti, dimostrando che non è necessario sbirciare i segreti del nuovo progetto per costruire un buon predittore.

Cosa hanno escluso

L'articolo argomenta esplicitamente contro l'idea che un modello singolo e statico (un set fisso di regole applicate all'intero progetto) sia la soluzione migliore. Dimostrano che, poiché diverse parti di un progetto software hanno caratteristiche diverse, un approccio "taglia unica" non riesce a generalizzare bene quando il nuovo progetto è diverso dai dati di addestramento. Hanno anche escluso l'idea che sia necessario conoscere la distribuzione dei dati del progetto target in anticipo per fare buone previsioni; il loro metodo funziona anche quando il progetto target è un totale mistero.

Quanto sono sicuri?

Gli autori sono fiduciosi nei loro risultati basandosi sui dati raccolti. Non si sono limitati a simulare scenari; hanno condotto esperimenti estesi su 82 progetti reali utilizzando metriche standard e ampiamente accettate. Hanno utilizzato test statistici (il test Wilcoxon Signed-Rank) per confermare che i loro risultati non siano frutto della fortuna. L'articolo afferma che Multi-DES è "statisticamente superiore" nella maggior parte dei confronti a coppie, in particolare per AUC e False Alarm. Tuttavia, notano una piccola eccezione: sul dataset PROMISE, il loro metodo non è stato l'assoluto migliore per la metrica "False Alarm", mostrando che, sebbene il metodo sia forte, non è una bacchetta magica che vince ogni singola volta in ogni singolo scenario.

In breve, Multi-DES suggerisce che il modo migliore per prevedere i bug in un nuovo progetto sconosciuto è avere un team diversificato di esperti pronti a essere chiamati, e scegliere l'esperto giusto per il lavoro specifico, piuttosto che cercare di forzare un unico generalista a fare tutto.