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

Stellen Sie sich vor, Sie sind ein Detektiv, der versucht, einen einzelnen verborgenen Verräter in einer Menge von tausend unschuldigen Bürgern zu finden. Ihre Aufgabe ist es, die Person zu entlarven, die der Verräter ist, bevor sie Unruhe stiften kann. Dies ist die tägliche Realität für Softwareentwickler, die wie digitale Detektive auf der Jagd nach „Bugs“ oder Fehlern im Computercode sind. In der Welt des Software-Engineerings wird diese Jagd als Software Defect Prediction (Softwarefehlerprognose) bezeichnet. Es ist ein Spiel mit hohem Einsatz, bei dem das Ziel darin besteht, den schlechten Code zu entdecken, bevor er das System beschädigt.

Um dieses Spiel zu spielen, nutzen Ingenieure Computermodelle, die als Machine Learning Modelle bezeichnet werden. Betrachten Sie diese Modelle als superintelligente Assistenten, die in der Vergangenheit Millionen von Codezeilen gelesen haben. Sie betrachten ein neues Stück Code und geben ihm einen „Verdachtswert“ zwischen 0 und 1. Ein Wert von 0 bedeutet „völlig unschuldig“, und ein Wert von 1 bedeutet „schuldig durch die Tat“. Der knifflige Teil ist die Entscheidung, wo man die Linie zieht. Wenn Sie die Linie zu niedrig ansetzen, begehen Sie möglicherweise Fehlurteile über Unschuldige (Fehlalarme), was Zeit verschwendet. Wenn Sie sie zu hoch ansetzen, lassen Sie den echten Verräter vielleicht entkommen (übersehene Defekte), was katastrophal sein kann. Lange Zeit nutzten die meisten Detektive eine Standardregel: „Wenn der Wert über 0,5 liegt, ist die Person schuldig.“ Aber wie diese neue Forschung nahelegt, könnte diese Standardregel danebenliegen.

---

Die große Idee der Arbeit: Die perfekte Linie finden

In ihrer Arbeit „Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis“ argumentieren Nitin Sai Bommi, Umamaheswara Sharma Bhutamapuram und Atul Negi, dass die alte „0,5-Regel“ wie ein Einheitsmodell für Hüte ist, das man einer Menschenmenge mit sehr unterschiedlichen Kopfgrößen aufsetzt. Er passt einfach nicht jedem.

Die Autoren schlagen einen neuen Weg vor, das Spiel zu spielen. Anstatt blind der Standardlinie zu vertrauen, schlagen sie zwei kluge Tricks vor, um die perfekte Linie für jede spezifische Situation zu finden. Ihr Ziel ist es, die Differenz zwischen dem Erraten der Bösen (Wahrscheinlichkeit der Entdeckung) und dem Vermeiden falscher Anschuldigungen (Wahrscheinlichkeit eines Fehlalarms) zu maximieren. Sie wollen den Verräter fangen, ohne Zeit mit unschuldigen Passanten zu verschwenden.

Trick Nr. 1: Das Verschieben der Torpfosten (Optimaler Schwellenwert)

Beim ersten Trick geht es darum, die „Verdachtslinie“ anzupassen. Die Forscher testeten drei verschiedene Arten von Detektiv-Assistenten: Logistische Regression, Naïve Bayes und Neuronale Netze. Sie fanden heraus, dass die magische Zahl für keinen von ihnen 0,5 war.

• Für den Logistische Regression-Assistenten lag der ideale Punkt bei etwa 0,35.
• Für Naïve Bayes war er sogar noch niedriger, bei 0,3.
• Für das Neuronale Netz lag er bei 0,38.

Stellen Sie sich das wie das Einstellen eines Radios vor. Wenn Sie den Regler in der Mitte lassen, hören Sie vielleicht nur Rauschen. Aber wenn Sie den Regler ein kleines Stück nach links oder rechts drehen, kommt plötzlich die Musik kristallklar durch. Durch das Senken des Schwellenwerts (auf etwa 0,3 oder 0,4) wurden diese Modelle viel besser darin, echte Defekte zu entdecken, während sie gleichzeitig die Anzahl der Fehlalarme niedrig hielten. In ihren Tests über 36 verschiedene Versionen von 10 Softwareprojekten übertraf diese einfache Anpassung die Standardmethode konsequent.

Trick Nr. 2: Das „Was wäre wenn“-Spiel (Kontrafaktische Erklärungen)

Der zweite Trick ist ein wenig magischer. Die Autoren verwendeten etwas, das man Kontrafaktische Erklärungen nennt. Stellen Sie sich vor, Sie haben ein Foto eines „schuldigen“ Verdächtigen (eines fehlerhaften Codemoduls). Das Modell sagt: „Dies ist schlecht.“ Nun stellen Sie sich vor, Sie könnten das Modell fragen: „Was wäre, wenn ich diese eine winzige Sache ändern würde? Würde sie dann unschuldig werden?“

Die Forscher taten genau das. Sie nahmen Code, von dem das Modell bereits wusste, dass er gut oder schlecht war, und fragten: „Welche kleine Änderung würde diesen von gut zu schlecht oder von schlecht zu gut umschlagen lassen?“ Sie nutzten diese „Was wäre wenn“-Szenarien, um neue, synthetische Beispiele von Code zu erstellen. Dann speisten sie diese neuen Beispiele zurück in das Modell, um ihm ein wenig zusätzliches Training zu geben.

Es ist wie ein Trainer, der einem Spieler ein Video eines perfekten Spielzugs zeigt und dann fragt: „Was wäre, wenn du den Ball um einen Zoll daneben getroffen hättest?“, und dies nutzt, um den Spieler zu lehren, wie er sich anpassen muss. Die Arbeit fand heraus, dass diese Methode den Modellen half, die Daten besser zu verstehen, obwohl sie nicht immer den einfachen „Verschieben der Torpfosten“-Trick schlagen konnte.

Was sie fanden (und was sie nicht fanden)

Die Ergebnisse waren vielversprechend, aber spezifisch. Die Autoren maßen ihren Erfolg mit zwei Hauptwerkzeugen:

1. False Omission Rate (FOR): Wie oft haben sie einen echten Defekt übersehen? (Sie wollten, dass dieser niedrig ist).
2. Percent of Saved Budget (PSB): Wie viel Zeit und Geld haben sie gespart, indem sie den sauberen Code nicht getestet haben?

Als sie ihre neue „Verschieben der Torpfosten“-Methode anwandten, schnitten die Modelle besser ab als die alte Methode. Beispielsweise war beim Modell der Logistischen Regression der durchschnittliche optimale Schwellenwert 0,35, und er reduzierte die Rate der übersehenen Defekte im Vergleich zum Standard-0,5-Schwellenwert signifikant.

Die Autoren sind jedoch vorsichtig, dies nicht als Allheilmittel zu bezeichnen. Sie stellen ausdrücklich fest, dass diese Methoden zwar die Balance zwischen dem Aufspüren von Bugs und dem Vermeiden von Fehlalarmen verbessern, aber nicht alles lösen. Die kontrafaktische Methode (das „Was wäre wenn“-Spiel) half zwar, lieferte aber nicht immer die besten Ergebnisse, da das Modell selbst nicht perfekt darin ist, diese künstlichen Beispiele zu generieren.

Sie weisen auch darauf hin, dass ihre Ergebnisse auf spezifischen Datensätzen (PROMISE Repository) basieren und anders aussehen könnten, wenn sie auf völlig andere Arten von Softwareprojekten angewendet würden. Sie haben nicht bewiesen, dass dies für jede Software im Universum funktioniert, aber sie haben gezeigt, dass es für die von ihnen getesteten Projekte ein kluger Schachzug ist, von der Standard-0,5-Regel abzuweichen.

Warum das wichtig ist

Diese Arbeit ist eine Erinnerung daran, dass in der Welt der Software „Einheitslösungen“ oft eine Falle sind. Die Standardmethode, zu entscheiden, was ein Bug ist und was nicht, könnte zu starr sein. Indem wir den Computer einfach fragen: „Was ist die beste Linie für diesen spezifischen Job?“ und indem wir „Was wäre wenn“-Fragen nutzen, um mehr zu lernen, können wir Software bauen, die sicherer und kostengünstiger zu warten ist. Es ist eine kleine Verschiebung der Perspektive, aber für die Detektive, die Bugs in der digitalen Dunkelheit jagen, könnte es genau das Taschenlampenlicht sein, das sie brauchten.