Productiviteitsmeting

In andere industrieën dan de software-industrie, productiviteitsmeting is een normale activiteit die het succes van een bedrijf drijft. Laten we eens kijken naar bijvoorbeeld een one man schildersbedrijf. Voor een schilder, het zou logisch zijn om zijn productiviteit in te meten inspanningsuren per vierkante meter. Waarschijnlijk wil hij de meting differentiëren in enkele categorieën,zoals gebruikte tools (bv. rol / borstel / spray / enz.) en kenmerken van verfobjecten (bv. muur / trap / deur / etc.). Wanneer de schilder een database opbouwt met productiviteitscijfers, hij kan gemakkelijk citeren voor nieuwe schilderklussen, simpelweg door het verfoppervlak in vierkante meters te meten, vermenigvuldig met het juiste productiviteitstarief en vermenigvuldig het resultaat met het uurtarief dat hij vraagt. Als er een is (Internationale) database beschikbaar met de productiviteitsniveaus van verfopdrachten uitgevoerd door andere bedrijven in de industrie, de schilder begrijpt hoe hij gemiddeld presteert tegen de industrie en voor het geval hij niet al de beste in zijn klasse is, hij begrijpt dat hij zijn productiviteit moet blijven verbeteren om nieuwe verfklussen te winnen (omdat het verlagen van het uurtarief meestal geen goed idee is).

Hij kan dit allemaal doen, maar alleen wanneer:

  • Hij gebruikt een standaard meeteenheid, bv. vierkante meter. Alleen door gebruik te maken van standaarden, productiviteitsniveaus kunnen worden vergeleken (gebenchmarkt) en gebruikt voor schatten;
  • Hij gebruikt een standaardmanier om de inspanningsuren vast te leggen. Bijvoorbeeld, is de lunchpauze inbegrepen of uitgesloten, is het moment om met de klant te praten om zijn inbegrepen / uitgesloten vereisten te begrijpen?
  • Hij gebruikt mgrote categorieën die productiviteit differentiëren. Voor een schilder, het maakt misschien niet zoveel uit als de verf het voorwerp is (laten we zeggen een muur) is in een villa of in een vissershuis. Het type huis is misschien geen zinvolle categorie. Echter, de tool die hij gebruikt, is waarschijnlijk een belangrijke factor voor de productiviteit.

Nu, laten we eens kijken naar de software-industrie.

De software-industrie en productiviteitsmeting

helaas, de IT (en software) de industrie is nog vrij onvolwassen als het gaat om het gebruik van standaarden en om productiviteit (prestatie) meting, benchmarking en continue verbetering. De industrie kwam daar lang mee weg, omdat:

  • Het is moeilijk te meten output (software is niet iets fysieks, kan niet worden aangeraakt en gemeten met conventionele meetinstrumenten).
  • Softwareprojecten lijken veel meer op een R&D project dan het vervaardigen van een product. R&D is ongelooflijk moeilijk te meten. Het meten van de inputs is relatief eenvoudig, maar de output is moeilijk te meten en van nature onvoorspelbaar.

Nu, langzaamaan wordt de branche steeds transparanter en vragen klantenorganisaties potentiële leveranciers steeds meer om hun prestaties te kwantificeren op basis van historische gegevens. Op deze manier, het wordt mogelijk om de beste leverancier voor de klus te selecteren. Houd er rekening mee dat de beste keuze meestal niet de goedkoopste is (vaak resulterend in mislukte projecten…of zelfs rampen).

Standaarden

Hoewel het misschien eenvoudig lijkt om een ​​productiviteitsmeetproces in een organisatie te implementeren, de realiteit toont aan dat het moeilijker is dan men misschien denkt. In principe, net als de schilder, het volstaat om meet inputs (meestal inspanning uren) en uitgangen (Meeteenheden, HE) per softwareproject, terwijl zinvolle categorieën gebruiken om de projecten te onderscheiden, zoals technologie (Java / .Net / Oracle / Enz.), project type (nieuwe ontwikkeling / verbetering) en / of implementatie (Pakket implementatie / wijziging / maatwerk software).

Om te kunnen bouwen zinvolle en vergelijkbare productiviteit metrics, het is cruciaal dat (Internationale) normen worden gebruikt. Er moeten een aantal keuzes worden gemaakt:

Ingangen meten

Enkele beslissingen die moeten worden genomen:

  • Inspanning uren in / uit meetbereik, bijvoorbeeld
    • Technisch ontwerp, codering, hoofdstuk toets, systemen testen, andere leverancier proeven, overhead in omvang;
    • functioneel ontwerp, ondersteuning acceptatietest, implementatieactiviteiten buiten bereik.
  • Overuren in / uit meetbereik;
  • Travel uur, vergaderuren, overhead uren in / uit bereik;
  • In het geval van pakketten, Portals / CMS of andere configureerbare software, het kan nodig zijn om afzonderlijke activiteiten voor inspanningsregistratie te hebben voor maatwerk, het instellen van parameters en op maat gemaakte software maken geen deel uit van het pakket.

De productiviteit van een leverancier kunnen analyseren, afdeling of team, het inspanningsregistratiesysteem moet op een standaardmanier worden geïmplementeerd. Als de keuze is gemaakt dat functionele ontwerpuren buiten de scope vallen, alle projecten dienen hun inspanning van functioneel ontwerp apart van de andere inspanningsuren te registreren. Het wordt sterk aanbevolen om een ​​standaard ‘Work Breakdown Structure 'op te stellen (WBS)’ per projecttype en implementeer deze WBS in het inspanningsregistratiesysteem. Iedereen die inspanningsuren registreert, dient zich bewust te zijn van het belang van het correct boeken van de inspanning in het systeem.

Uitgangen meten, methoden die moeten worden vermeden

Het meten van outputs is iets moeilijker dan het meten van de inputs, vanwege de immateriële aard van software. Veel organisaties meten de geleverde broncode-regels (slocs) van het softwareproduct dat na voltooiing wordt geleverd en gebruik productiviteitsstatistieken zoals inspanninguren per 1000 slocs. Dit lijkt een goede manier om te gaan, maar in feite zijn er veel redenen waarom dit geen aanbevolen praktijk is:

  • Er is geen (ISO of andere) standaard voor broncode regels. Het resultaat is dat verschillende automatische tools voor het tellen van codes produceren (heel) verschillende resultaten voor dezelfde code.
  • Het is niet duidelijk of meer code ‘goed is’ of slecht'. Bronregels met code zijn niet van waarde voor de klantorganisatie. Functionaliteit is van waarde. Klanten zeggen nooit:”Geef me alsjeblieft 100000 broncode regels”. Nee, het is functionaliteit in termen van functies die ze nodig hebben. Meer functionaliteit is beter en kost meer, meer slocs is misschien niet beter.
  • Verschillende programmeertalen (en mengsels hiervan) resulteren in zeer verschillende bronregels met coderesultaten.

Amerikaanse 'software metrics-goeroe'’ Capers Jones schreef in een paper ‘Software Defect Origins and Removal Methods (2013) dat sloc-metingen zo onnauwkeurig zijn, dat het gebruik van slocs bij softwaremeting in feite is ‘Professionele wanpraktijken’.

Andere maatafmetingen die vaak in de industrie worden gebruikt, maar zijn ook niet aangeraden te gebruiken bij productiviteitsmeting:

  • Story punten (SP) in agile projecten: Een zeer subjectieve maatstaf die alleen waarde heeft binnen één team. Vergelijking met andere teams, afdelingen en organisaties is niet mogelijk. Houd er rekening mee dat SP handig is om sprints te plannen en om snelheid bij te houden voor één team, maar voor productiviteitsmeting zijn SP bijna nutteloos.
  • Usecase-punten (UCP): Alleen van toepassing als de documentatie uit usecases bestaat. UCP is ook een zeer subjectieve methode, vooral als het gaat om het vaststellen van de technische complexiteitsfactor en de omgevingsfactor. Ook, er is geen standaardmanier om usecases te schrijven, zie bijvoorbeeld vijf mogelijke granulariteitsniveaus zoals beschreven hier.
  • Complexiteitspunten: Subjectieve en niet gestandaardiseerde methode om de complexiteit van een applicatie te meten.
  • IBRA-punten: Geen gestandaardiseerde methode om de bedrijfsregels in een applicatie te meten. Indien aangebracht volgens de handleiding, het resultaat is nul voor alle toepassingen.
  • Snelle functiepunten (FFPA) (door Gartner): Een door Gartner toegepaste meetmethode die niet te vergelijken is met de ISO gestandaardiseerde functiepuntanalysemethoden. FFPA wordt gezien als een commerciële methode die een theoretische basis mist en deels subjectief is. De methode is niet sneller gebleken dan de door Nesma geschatte methode en is ook niet nauwkeuriger gebleken. Helaas wordt het vaak op hoger managementniveau gepusht zonder de steun van de specialisten die ermee moeten werken.

Output meten – sterk aanbevolen methoden

Het is een sterk aanbevolen praktijk om een ISO / IEC-standaard voor het meten van functionele afmetingen bij Productiviteitsmeting van softwareprojecten. Er zijn vijf meetmethoden voor functionele afmetingen die voldoen aan de ISO / IEC-norm:

  • NESMA functiepunten (ISO / IEC 24570);
  • IFPUG functiepunten (ISO / IEC 20926);
  • COSMIC functiepunten (ISO / IEC 19761);
  • Mark II functiepunten (ISO / IEC 20968);
  • FiSMA functiepunten (ISO / IEC 29881).

Voordelen van het gebruik van een van deze functionele meetmethoden voor productiviteitsmeting zijn:

  • Doelstelling, herhaalbare, verifieerbaar, verdedigbare manier om de grootte van de software te bepalen;
  • Een duidelijke relatie tussen functionele omvang en inspanning die nodig is om de applicatie te realiseren, is al vele malen onderzocht en geverifieerd;
  • De maatregel is duidelijk voor beide organisaties klant en leverancier organisaties. Meer functionaliteit betekent meer waarde, meer inspanning nodig en een hogere prijs;
  • Functionele omvang is onafhankelijk van de technische oplossing en / of de niet-functionele eisen. Een toepassing van 500 NESMA functiepunten gerealiseerd in Java is net zo groot als een Wordpress website van 500 FP. Dit maakt vergelijking en benchmarking van technische domeinen en het gebruik van historische projectgegevens mogelijk (indien correct geclassificeerd) bij het schatten van nieuwe softwareprojecten.

Handige categorieën voor het verzamelen van gegevens

Om te kunnen vergelijken en te benchmarken uw productiviteit, het is belangrijk om standaardcategorieën te gebruiken om gegevens van uw projecten te verzamelen. Nesma raadt ten zeerste aan om de definities en categorieën dat te gebruiken de International Software Benchmarking Standards Group (ISBSG) gebruikt in hun gegevensverzamelingsactiviteiten.

De International Software Benchmarking Standards Group (ISBSG) is een ‘not-for-profit’ organisatie die gegevens uit de software-industrie verzamelt en die groeit, onderhoudt en exploiteert twee repositories: ‘Nieuwe ontwikkelingen en verbeteringen’ en onderhoud & Ondersteuning'. ISBSG kan dit alleen doen als gegevens op een standaardmanier worden verzameld. De ‘Vragenlijsten voor gegevensverzameling’ kan worden gedownload van het ISBSG-site en laat al veel definities en categorieën zien. Ook de woordenlijsten die bij de repositories worden geleverd, zijn nuttig.

Implementeren van softwareproductiviteitsmeting

Zo, net als de schilder uit bovenstaand voorbeeld, het is mogelijk om de productiviteit van softwareprojecten te meten. Zie deze pagina voor enkele voorbeelden.

Succesvol implementeren van softwareproductiviteitsmeting, het wordt sterk aanbevolen om het document ‘Basis of Measurements’ die wordt vermeld in de lijst met publicaties.