Invoering

De software-industrie is een van de grootste en meest succesvolle industrieën in de geschiedenis. Maar softwaretoepassingen behoren tot de duurste en meest foutgevoelige vervaardigde objecten in de geschiedenis. Software heeft nauwkeurige schattingen van planningen nodig, kosten, en kwaliteit. Deze zijn moeilijk te bereiken als de fundamentele statistieken verkeerd zijn en de werkelijkheid vervormen. Vanaf 2014 de software-industrie werkt onder een verscheidenheid aan niet-standaard en zeer onnauwkeurige metingen en statistieken, verergerd door zeer slordige meetmethoden. De fouten in softwaremetingen en -statistieken veroorzaken fouten in softwareschattingen. Hieronder volgen beschrijvingen van de meer verontrustende onderwerpen over softwarestatistieken in alfabetische volgorde vanuit mijn oogpunt. Twee ervan zijn zowel wijdverbreid als lastig:

• Kosten per defect benadelen kwaliteit
• Regels code bestraffen talen op hoog niveau en maken vereisten en ontwerp onzichtbaar

Lastige statistieken

Kosten per defect statistieken benadelen de kwaliteit en zorgen ervoor dat de software met de meeste bugs er het goedkoopst uitziet. Er zijn geen ISO- of andere normen voor het berekenen van de kosten per defect. Kosten per defect meten niet de economische waarde van softwarekwaliteit. De stedelijke legende die het kost 100 keer zoveel om defecten na de release op te lossen als vroege defecten is niet waar en is gebaseerd op het negeren van vaste kosten. Vanwege vaste kosten voor het schrijven en uitvoeren van testcases, kosten per defect stijgen gestaag omdat er steeds minder defecten worden gevonden. Dit wordt veroorzaakt door een standaardregel van productie-economie: “als een proces een hoog percentage vaste kosten heeft en er een vermindering is in de geproduceerde eenheden, de kosten per eenheid gaan omhoog.Dit verklaart waarom de kosten per defect in de loop van de tijd lijken te stijgen, hoewel de werkelijke reparatiekosten voor defecten vlak zijn en niet veel veranderen. Er zijn natuurlijk zeer verontrustende defecten die duur en tijdrovend zijn, maar deze zijn relatief zeldzaam.

Defecte dichtheid metrische gegevens meten het aantal bugs dat aan klanten is vrijgegeven. Er zijn geen ISO- of andere normen voor het berekenen van defectdichtheid. Eén methode telt alleen vrijgegeven codedefecten. Een meer complete methode omvat bugs die hun oorsprong vinden in vereisten en ontwerp, evenals codedefecten, en omvat ook "slechte reparaties" of bugs in defecte reparaties zelf. Er kan meer zijn dan een 300% variatie tussen het tellen van alleen codebugs en het tellen van bugs uit alle bronnen.

Functiepuntstatistieken werden uitgevonden door IBM circa 1975 en geplaatst in het publieke domein circa 1978. Functiepuntstatistieken meten economische productiviteit met behulp van zowel "werkuren per functiepunt" en "functiepunten per maand”. Ze zijn ook handig voor het normaliseren van kwaliteitsgegevens zoals "defecten per functiepunt". Er zijn echter tal van functiepuntvariaties en ze produceren allemaal verschillende resultaten: automatisch, mislukte, COSMIC, Snel, Fisma, IFPUG, Mark II, NESMA, niet aangepast, enzovoort. Er zijn ISO-normen voor: COSMIC, Fisma, IFPUG, Mark II en NESMA. Ondanks de ISO-normen produceren ze alle vijf verschillende tellingen. Aanhangers van elke functiepuntvariant claimen "nauwkeurigheid" als een deugd, maar er is geen cesiumatoom of onafhankelijke manier om de nauwkeurigheid vast te stellen, dus deze beweringen zijn onjuist. COSMIC-functiepunten produceren bijvoorbeeld hogere tellingen dan IFPUG-functiepunten voor veel toepassingen, maar dat duidt niet op "nauwkeurigheid" omdat er geen objectieve manier is om de nauwkeurigheid te kennen.

Doel-/vraagstatistieken (GQM) werden uitgevonden door Dr. Victor Basili van de Universiteit van Maryland. Het concept is aantrekkelijk. Het idee is om een ​​soort van tastbaar doel of doel te specificeren, en bedenk dan vragen die beantwoord moeten worden om het doel te bereiken. Dit is een goed concept voor alle wetenschap en techniek en niet alleen voor software. Echter, aangezien elk bedrijf en elk project de neiging heeft om unieke doelen te specificeren, GQM-methode: leent zich niet voor parametrische schattingstools of benchmarkgegevensverzameling. Het zou niet moeilijk zijn om GQM te combineren met functiepuntstatistieken en andere effectieve softwarestatistieken, zoals efficiëntie bij het verwijderen van defecten. Verschillende nuttige doelen kunnen bijvoorbeeld zijn "Hoe kunnen we defectpotentialen bereiken van minder dan 1.0 per functiepunt?" of "Hoe kunnen we productiviteitspercentages van 100 functiepunten per maand?" Een ander goed doel dat eigenlijk een doel zou moeten zijn voor elk bedrijf en elk softwareproject in de wereld zou zijn "Hoe kunnen we meer bereiken dan? 99% in efficiëntie voor het verwijderen van defecten:?”

Regels code (LOC) metrieken bestraffen talen op hoog niveau en zorgen ervoor dat talen op laag niveau er beter uitzien dan ze zijn. LOC-statistieken maak ook eisen en ontwerp onzichtbaar. Er zijn geen ISO- of andere normen voor het tellen van LOC-statistieken. Ongeveer de helft van de kranten en tijdschriftartikelen gebruikt fysieke LOC en de helft gebruikt logische LOC. Het verschil tussen het aantal fysieke en logische LOC kan groter zijn 500%. LOC-statistieken maken vereisten en ontwerp onzichtbaar en negeren vereisten en ontwerpfouten, die het aantal codedefecten overtreft. Hoewel er benchmarks zijn op basis van LOC, de intrinsieke fouten van LOC-statistieken maken ze onbetrouwbaar. Wegens gebrek aan normen voor het tellen van LOC, benchmarks van verschillende leveranciers voor dezelfde toepassingen kunnen sterk verschillende resultaten bevatten.

Verhaalpunt metrics worden veel gebruikt voor agile projecten met 'user stories'. Story punten hebben geen ISO-standaard voor het tellen of een andere standaard. Ze zijn zeer dubbelzinnig en kunnen zoveel variëren als 400% van bedrijf naar bedrijf en project naar project. Er zijn weinig bruikbare benchmarks die storypoints gebruiken. Het is duidelijk dat verhaalpunten niet kunnen worden gebruikt voor projecten die geen gebruikersverhalen gebruiken, dus ze zijn waardeloos voor vergelijkingen met andere ontwerpmethoden.

technische schuld is een nieuwe maatstaf en verspreidt zich snel. Het is een briljante metafoor ontwikkeld door Ward Cunningham. Het concept van "technische schuld” is dat onderwerpen die tijdens de ontwikkeling worden uitgesteld in het belang van de planningssnelheid, na de release meer zullen kosten dan ze aanvankelijk zouden hebben gekost. Er zijn echter geen ISO-normen voor technische schuld en het concept is zeer dubbelzinnig. Het kan per over 500% van bedrijf naar bedrijf en project naar project. Slechter, technische schuld omvat niet alle kosten die gepaard gaan met slechte kwaliteit en kortere ontwikkeltrajecten. Technische schuld laat geannuleerde projecten achterwege, gevolgschade of schade aan gebruikers, en de proceskosten voor slechte kwaliteit.

Gebruik case-punten worden gebruikt door projecten met ontwerpen op basis van "use cases" die vaak gebruikmaken van IBM's Rational Unified Process (RUP). Er zijn geen ISO-normen voor use cases. Gebruik case-punten zijn dubbelzinnig en kunnen per over 200% van bedrijf naar bedrijf en project naar project. Het is duidelijk dat use-cases waardeloos zijn voor het meten van projecten die geen use-cases gebruiken, dus ze hebben heel weinig benchmarkgegevens.

Softwareproductiviteit definiëren

Voor meer dan 200 jaar is de standaard economische definitie van productiviteit geweest:, “Goederen of diensten geproduceerd per eenheid van arbeid of kosten.”Deze definitie wordt in alle industrieën gebruikt, maar was moeilijk te gebruiken in de software-industrie. Voor software is er onduidelijkheid over wat onze “goederen of diensten.”

De oudste eenheid voor software “goederen” was een “regel code” of LOC. Meer recentelijk zijn softwareproducten gedefinieerd als "functiepunten”. Nog recentere definities van goederen omvatten “verhaal punten" en "gebruik case-punten”. De voors en tegens van deze eenheden zijn in grote mate besproken in de literatuur.

Een ander belangrijk onderwerp uit de productie-economie heeft een grote impact op: software productiviteit dat is nog niet goed begrepen, zelfs in 2014: vaste kosten.

Een basiswet van de productie-economie die geldig is voor alle industrieën, inclusief software, is de volgende:: “Wanneer een ontwikkelproces een hoog percentage vaste kosten heeft, en er is een daling van het aantal geproduceerde eenheden, de kosten per eenheid gaan omhoog.”

Wanneer een "regel code” is geselecteerd als de productie-eenheid en er is een omschakeling van een taal op een laag niveau, zoals assemblage, naar een taal op een hoog niveau, zoals Java, er zal een vermindering zijn van het aantal ontwikkelde eenheden.

Maar de niet-codetaken van vereisten en ontwerp werken als vaste kosten. Daarom zullen de kosten per regel code stijgen voor talen op hoog niveau. Dit betekent dat LOC geen geldige maatstaf is voor het meten van economische productiviteit.

Voor software zijn er twee definities van: productiviteit die overeenkomen met standaard economische concepten:

1. Een specifieke hoeveelheid leverbare eenheden produceren voor het laagste aantal werkuren.
2. Het grootste aantal leverbare eenheden produceren in een standaard werkperiode, zoals een uur, maand, of jaar.

in definitie 1 leverbare goederen zijn constant en werkuren zijn variabel.

in definitie 2 leverbare goederen zijn variabel en werkperioden zijn constant.

Softwarekwaliteit definiëren

Zoals we allemaal kennen, is het onderwerp “kwaliteit” is in elke branche enigszins dubbelzinnig. Definities voor kwaliteit kunnen subjectieve esthetische kwaliteit omvatten en ook precieze kwantitatieve eenheden zoals het aantal defecten en hun ernstniveaus.

In de loop der jaren heeft software een aantal alternatieve definities voor kwaliteit uitgeprobeerd die eigenlijk niet bruikbaar zijn. Een definitie voor softwarekwaliteit was bijvoorbeeld:conformiteit met eisen.”

Vereisten zelf zijn gevuld met bugs of fouten die bestaan ​​uit ongeveer 20% van de algemene gebreken gevonden in softwaretoepassingen. Kwaliteit definiëren als overeenstemming met een belangrijke bron van fouten is cirkelredenering en duidelijk ongeldig. We moeten fouten in de vereisten opnemen in onze definitie van kwaliteit.

Een andere definitie voor kwaliteit is “geschiktheid voor gebruik.Maar deze definitie is dubbelzinnig en kan niet worden voorspeld voordat de software wordt vrijgegeven, of zelfs goed gemeten na vrijgave.

Een andere definitie voor softwarekwaliteit is een reeks woorden die eindigen op "... ility", zoals betrouwbaarheid en onderhoudbaarheid. Hoe prijzenswaardig deze attributen ook zijn, ze zijn allemaal dubbelzinnig en moeilijk te meten. Verder, ze zijn moeilijk te voorspellen voordat applicaties zijn gebouwd.

Een effectieve definitie van softwarekwaliteit die zowel kan worden voorspeld voordat applicaties worden gebouwd als gemeten nadat applicaties zijn opgeleverd, is:: “Softwarekwaliteit is de afwezigheid van defecten die ervoor zouden zorgen dat de applicatie niet meer werkt, of ervoor zorgen dat het onjuiste resultaten oplevert.”

Omdat geleverde defecten van invloed zijn op de betrouwbaarheid, onderhoudbaarheid, bruikbaarheid, geschiktheid voor gebruik, conformiteit met eisen, en ook klanttevredenheid, elke effectieve definitie van softwarekwaliteit moet het centrale belang erkennen van het bereiken van lage hoeveelheden geleverde defecten. Softwarekwaliteit is onmogelijk zonder lage niveaus van geleverde defecten, ongeacht welke definitie wordt gebruikt.

 

Over de auteur:

Kappertjes Jones is CTO van Namcook Analytics, een bedrijf dat geavanceerde risico's opbouwt, kwaliteit, en kostenramingstools. Deze blogpost is oorspronkelijk gepost op de Namcook Analytics-blog.

Een blogpost vertegenwoordigt de persoonlijke mening van de auteur
en hoeft niet noodzakelijkerwijs samen te vallen met het officiële Nesma-beleid.