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

Stel je voor dat je een rechercheur bent die probeert één enkele verborgen verrader te vinden in een menigte van duizend onschuldige burgers. Jouw taak is om aan te wijzen wie de verrader is voordat deze problemen kan veroorzaken. Dit is de dagelijkse realiteit voor software engineers, die optreden als digitale rechercheurs op zoek naar "bugs" of defecten in computercode. In de wereld van software engineering wordt deze jacht Software Defect Prediction genoemd. Het is een spel met hoge inzet waarbij het doel is om de slechte code op te sporen voordat deze het systeem laat breken.

Om dit spel te spelen, gebruiken engineers computerprogramma's die Machine Learning-modellen worden genoemd. Denk aan deze modellen als superintelligente assistenten die miljoenen regels code uit het verleden hebben gelezen. Ze bekijken een nieuw stuk code en geven het een "verdachtingsscore" tussen 0 en 1. Een score van 0 betekent "volledig onschuldig," en een score van 1 betekent "schuldig aan de beschuldiging." Het lastige deel is het bepalen waar je de lijn trekt. Als je de lijn te laag zet, beschuldig je misschien onschuldige mensen (vals alarm), wat ieders tijd verspilt. Als je de lijn te hoog zet, laat je misschien de echte verrader ontsnappen (gemiste defecten), wat rampzalig kan zijn. Al heel lang gebruiken de meeste rechercheurs een standaardregel: "Als de score boven de 0,5 ligt, is het schuldig." Maar zoals dit nieuwe onderzoek suggereert, kan deze standaardregel de plank volledig misslaan.

---

Het Grote Idee van het Papier: De Perfecte Lijn Vinden

In hun paper, "Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis," betogen Nitin Sai Bommi, Umamaheswara Sharma Bhutamapuram en Atul Negi dat de oude "0,5-regel" is als het gebruiken van een een maat voor iedereen is, zoals een hoed, voor een menigte mensen met zeer verschillende hoofden. Het past simpelweg niet bij iedereen.

De auteurs stellen een nieuwe manier voor om het spel te spelen. In plaats van blindelings de standaardlijn te vertrouwen, suggereren ze twee slimme trucs om de perfecte lijn voor elke specifieke situatie te vinden. Hun doel is om het verschil te maximaliseren tussen het vangen van de slechteriken (Probability of Detection) en het vermijden van valse beschuldigingen (Probability of False Alarm). Ze willen de verrader vangen zonder tijd te verspillen aan onschuldige omstanders.

Truc #1: De Verschuivende Doelpalen (Optimal Threshold)

De eerste truc gaat over het aanpassen van de "verdachtingslijn." De onderzoekers testten drie verschillende soorten detective-assistenten: Logistic Regression, Naïve Bayes en Neural Networks. Ze ontdekten dat het magische getal voor geen van hen 0,5 was.

• Voor de Logistic Regression-assistent lag het ideale punt rond de 0,35.
• Voor Naïve Bayes lag het zelfs nog lager, op 0,3.
• Voor het Neural Network was het 0,38.

Denk hierbij aan het afstemmen van een radio. Als je de knop in het midden laat staan, hoor je misschien ruis. Maar als je de knop iets naar links of rechts draait, komt de muziek plotseling kristalhelder binnen. Door de drempelwaarde te verlagen (naar rond de 0,3 of 0,4), werden deze modellen veel beter in het opsporen van de echte defecten, terwijl het aantal valse alarmen laag bleef. In hun tests over 36 verschillende versies van 10 softwareprojecten presteerde deze eenvoudige aanpassing consequent beter dan de standaardmethode.

Truc #2: Het "Wat als"-spel (Counterfactual Explanations)

De tweede truc is een beetje magisch. De auteurs gebruikten iets dat Counterfactual Explanations wordt genoemd. Stel je voor dat je een foto hebt van een "schuldige" verdachte (een defect code-module). Het model zegt: "Dit is slecht." Stel je nu voor dat je de vraag aan het model kunt stellen: "Wat als ik dit ene kleine dingetje zou veranderen? Zou het dan onschuldig worden?"

De onderzoekers deden precies dat. Ze namen code die het model al kende als goed of slecht, en vroegen: "Wat kleine verandering zou dit van goed naar slecht, of van slecht naar goed doen?" Ze gebruikten deze "wat als"-scenario's om nieuwe, synthetische voorbeelden van code te creëren. Vervolgens voedden ze deze nieuwe voorbeelden terug aan het model om het een beetje extra training te geven.

Het is als een coach die een speler een video van een perfecte actie laat zien, en dan vraagt: "Wat als je de bal een centimeter naast je had geraakt?" en dit vervolgens gebruikt om de speler te leren hoe hij moet bijsturen. Het paper vond dat deze methode de modellen hielp de data beter te begrijpen, hoewel het niet altijd de beste resultaten gaf dan de eenvoudige "verschuivende doelpalen"-truc.

Wat Ze Vonden (en Wat Ze Niet Vonden)

De resultaten waren veelbelovend maar specifiek. De auteurs maten hun succes met behulp van twee belangrijke instrumenten:

1. False Omission Rate (FOR): Hoe vaak misten ze een echt defect? (Ze wilden dat dit laag was).
2. Percent of Saved Budget (PSB): Hoeveel tijd en geld bespaarden ze door de schone code niet te testen?

Wanneer ze hun nieuwe "verschuivende doelpalen"-methode gebruikten, presteerden de modellen beter dan de oude manier. Bijvoorbeeld, met het Logistic Regression-model was de gemiddelde optimale drempelwaarde 0,35, en het verminderde het aantal gemiste defecten aanzienlijk vergeleken met de standaard 0,5 drempelwaarde.

De auteurs zijn echter voorzichtig om dit niet als een wondermiddel te bestempelen. Ze stellen expliciet dat hoewel deze methoden de balans verbeteren tussen het vangen van bugs en het vermijden van valse alarmen, ze niet alles oplossen. De counterfactual-methode (het "wat als"-spel) hielp wel, maar leverde niet altijd de beste resultaten op omdat het model zelf niet perfect is in het genereren van die nepvoorbeelden.

Ze wijzen er ook op dat hun bevindingen gebaseerd zijn op specifieke datasets (de PROMISE repository) en er anders uit kunnen zien als ze op totaal andere soorten softwareprojecten worden toegepast. Ze hebben niet bewezen dat dit voor elke software in het universum werkt, maar ze hebben wel aangetoond dat voor de projecten die zij testten, het afwijken van de standaard 0,5-regel een slimme zet is.

Waarom Dit Er Toe Doet

Dit paper is een herinnering aan het feit dat in de wereld van software "één maat voor iedereen" vaak een valstrik is. De standaardmanier om te beslissen wat een bug is en wat niet, kan te rigide zijn. Door de computer simpelweg te vragen: "Wat is de beste lijn om te trekken voor dit specifieke werk?" en door "wat als"-vragen te gebruiken om meer te leren, kunnen we software bouwen die veiliger en goedkoper te onderhouden is. Het is een kleine verschuiving in perspectief, maar voor de rechercheurs die op zoek zijn naar bugs in de digitale duisternis, kan het precies de zaklamp zijn die ze nodig hadden.