image

Open source evengoed als gesloten software

dinsdag 7 mei 2013, 17:05 door Redactie, 6 reacties

Open source software bevat gemiddeld evenveel fouten als gesloten software, zo blijkt uit analyse van 450 miljoen regels code. Coverity analyseerde zowel gesloten als open source programma's en ontdekte dat de kwaliteit van software in het algemeen steeds beter wordt. De hoeveelheid fouten per 1000 regels code wordt vaak gebruikt om de kwaliteit van software te bepalen.

Bij open source producten werden per 1000 regels code 0,69 fouten ontdekt, terwijl dit bij gesloten software 0,68 was. Volgens Coverity hebben zowel de onderzochte open als gesloten programma's een betere kwaliteit dan het binnen de industrie geaccepteerde gemiddelde van 1 fout per 1000 regels code.

Omvang
Als softwareprojecten de 1 miljoen regels code passeren is er een directe correlatie tussen de omvang en kwaliteit van gesloten projecten en een omgekeerde correlatie voor open source projecten. De geanalyseerde gesloten code had gemiddeld 0,98 fouten voor projecten tussen de 500.000 en 1.000.000 miljoen regels code.

Bij projecten met meer dan een miljoen regels code daalde het aantal fouten naar 0,66 per 1000 regels. Dat suggereert volgens de analisten dat de kwaliteit van gesloten software bij grotere projecten beter wordt.

Bij open source projecten tussen de 500.000 en 1.000.000 miljoen regels code werden per duizend regels code 44 defecten aangetroffen, maar dat aantal steeg naar 0,75 fouten als de miljoen regels code werd gepasseerd.

Het verschil is volgens Coverity toe te schrijven aan de verschillende dynamiek tussen open source en gesloten ontwikkelteams, alsmede het moment dat deze teams geformaliseerde testprocessen toepassen.

Reacties (6)
07-05-2013, 18:37 door rob
Toch vind ik het nog niet zo heel betrouwbaar.. Het onderzoek gaat om enkele honderen projecten. Er staat niet *hoeveel* van die projecten dan meer dan 1 miljoen regels code hebben - dus is niet duidelijk of de bug-dichtheid statistisch relevant is over alle categorien. Ik vind namelijk de daling bij >1 miljoen regels niet eenvoudig te verklaren. Wellicht is het niet statistisch relevant omdat het aantal dergelijke projecten op 1 hand te tellen zijn, waardoor de kwaliteits standaarden van die specifieke projecten doorslaggevend worden.
07-05-2013, 19:39 door KwukDuck
Gelukkig gaat het idee van Open Source ontwikkeling niet om het 'goed' zijn van code...
07-05-2013, 21:52 door Anoniem
De gehanteerde getallen vormen daarbij een ondergrens omdat alle analysetools een bepaalde niet te verwaarlozen blinde vlek hebben. In de werkelijkheid (en die zul je naar alle waarschijnlijkheid nooit kunnen meten) ligt de bug density waarschijnlijk (veel?) hoger. En wat rob zei.
07-05-2013, 22:09 door Duck-man
kijk dat is een kwaliteitsnorm. Als ik voor data analyse een programma schrijf groeit deze en na een tijdje gooi ik de bezem er door waardoor de aantal regels codes halveert. Als in het oude programma een foutje zit en in de aangepaste is blijven zitten. Welk programma is dan het beste? De overwoekerde of de opgeschoonde? Volgens de norm is de overwoekerde code het best omdat die meer regels heeft per foutje heeft. Toch vind ik netjes geschreven code beter.
Het aantal taalfouten in een boek zegt toch ook niks of het het goed boek is?
Ik kijk liever of een programma bied wat ik zoek.
08-05-2013, 10:13 door Hans_US
@redactie: volgens mij klopt "500.000 en 1.000.000 miljoen regels code" niet. Dit moet zijn "500.000 en 1 miljoen regels code"
08-05-2013, 10:38 door Anoniem
@Duck-man: Bij grotere projecten is volledig herschrijven enorm tijdsintensief en je loopt een gerede kans om precies dezelfde fouten die je voorheen met veel pijn en moeite uit je programma gehaald hebt opnieuw te introduceren. Als je je programma modulair geschreven hebt is het vaak een betere optie om je op individuele modules te richten, het is vrij eenvoudig te achterhalen welke modules onnodig complex en groot geworden zijn en de ontwerpspecificaties van individuele modules zijn veelal stukken gedetailleerder dan die van het programma als geheel.

Als ik een boek koop waar ontzettend veel taalfouten in staan dan mag het wel om een goed verhaal gaan (een goed softwareontwerp), maar ik begin dan toch te twijfelen aan de aandacht die aan de productie van het boek besteed is (een slordige implementatie van een goed ontwerp).
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.