TE LAAT OPGELEVERD, IS DUURDER DAN GEPLAND OF BIEDT NIET DE GEWENSTE FUNCTIONALITEIT EN KWA- VAN ZIJN TERUG TE VOEREN OP EEN ONJUISTE PLANNING

Transcriptie

1 SOFTWARETOOLS VOOR PROJECTNAVIGATIE CIJFERMATIGE ONDERBOUWING NOG STEEDS ONMISBAAR IN ICT-PROJECTEN Auteur: Ernst van Waning ZO N ZEVENTIG PROCENT VAN ALLE ICT-PROJECTEN WORDT TE LAAT OPGELEVERD, IS DUURDER DAN GEPLAND OF BIEDT NIET DE GEWENSTE FUNCTIONALITEIT EN KWA- LITEIT. DE OORZAKEN HIER- VAN ZIJN TERUG TE VOEREN OP EEN ONJUISTE PLANNING EN HET ONVERMOGEN OM TIJDENS DE UITVOERING BIJ TE STUREN. OP ZICH NIET VERWONDERLIJK. ONTWIKKELING EN IMPLE- MENTATIE VAN BEDRIJFSSOF- TWARE KENMERKT ZICH BIJ UITSTEK DOOR EEN ONZEKERE WEG NAAR EEN DOEL DAT NOG WEL EENS VERANDERT. DES TE MEER REDEN OM ZO N PROJECT GOED VOOR TE BEREIDEN EN GOED TOEGERUST UIT TE VOEREN. MET OP FUNCTIEPUNTANALYSE GEBASEERDE TECHNIEKEN EN SOFTWARETOOLS ZIJN BETROUWBARE SCHATTINGEN TE MAKEN VAN DE OMVANG VAN ICT-PROJECTEN EN DE INSPANNING DIE NODIG IS OM DE DOELEN ERVAN TE BEREIKEN. ZE BIEDEN TEVENS DE BENODIGDE INFORMATIE VOOR TIJDIG BIJSTUREN EN HERPLANNEN. METEN IS WETEN, MAAR DAT GEBEURT IN SOFTWAREONTWIKKE- LINGSPROJECTEN NOG STEEDS TE WEINIG EN NIET ACCURAAT GENOEG. De bedrijfsmatige ontwikkeling van software is nauwelijks op het oog te doen. Je hebt iets nodig waarmee je precies kunt zien hoe het met het ontwikkelingsproces gesteld is; zowel in de voorbereiding (in vergelijking met anderen op de markt) als tijdens de uitvoering (ten opzichte van de planning). Het begeleiden van een project waarin veel software ontwikkeld wordt, lijkt op het oversteken van een oceaan. Navigeren dus. Dat doe je niet op gevoel, maar met instrumenten die je vertellen waar je bent, waar je naar toe gaat en wat voor weer je kunt verwachten onderweg. FUNCTIONALITEIT Die instrumenten zijn er. Ze maken gebruik van Functie Ernst van Waning (ernst_van_waning@qsm.com), Senior Consultant bij QSM Europe Punt Analyse (FPA), een methode voor het meten van de functionele omvang van informatiesystemen. Deze is gebaseerd op het aloude principe van tellen van relevante aspecten en factoren van ontwikkelingsprocessen. Op basis van de aldus verkregen cijfers is het mogelijk met behulp van statistische methoden en technieken verwachtingen te formuleren. Functionaliteit blijkt in softwareontwikkelingsprojecten een goede maat voor het begroten van de duur en kosten ervan en daarmee ook voor het plannen van de uitvoering. Hoe meer functiepunten of coderegels het te ontwikkelen softwareprogramma bevat, des te groter de omvang van het project. De functiepunt is de meeteenheid voor functionaliteit, waarvan de waarde is vastgesteld op basis van een internationale telrichtlijn. Een groot voordeel van FPA is dat het toegepast kan worden in de vroegste stadia van een project; functiepunten zijn te tellen op basis van ontwerpdocumenten. In dit kader ontwikkelde het Amerikaanse softwarebedrijf Quantitative Software Management (QSM) een set softwareproducten onder de naam Software Lifecycle Management (SLIM). Het betreft programma s voor het inschatten van ICT-projecten op doorlooptijd, medewerkers en kwaliteit (Estimate), het volgen, bijsturen en herplannen van het ontwikkelingsproces (Control) en het vergelijken van de eigen projectprestaties met die van de markt (Metrics). Meer dan zevenduizend projecten in de VS, Europa en Japan waarin software ontwikkeld is, vormen de grondslag van deze programma s. En deze database (benchmark) groeit nog steeds. Met SLIM Control worden de eigen projectprestaties en de daarmee gepaard gaande risico s gemeten. Dit levert de nodige kennis op van het functioneren van de eigen organisatie. Hoe meer kennis van de eigen organisatie, des te beter kunnen bedrijven plannen en offreren. Die kennis is tevens de basis voor het systematisch verbeteren van de organisatie. Wezenlijk kenmerk van de SLIM-producten is dan ook dat enerzijds wordt uitgegaan van een database aan externe projectgegevens en anderzijds de mogelijkheid wordt geboden eigen pro- 5

2 jectgegevens te verzamelen (Control) en te gebruiken (Estimate en Metrics). Belangrijke indicatoren van eigen projectprestaties zijn de PI (Productivity Index), een maat voor de productiviteit van de projectgroep (bijvoorbeeld in uren per functiepunt), en de MBI (Manpower Buildup Index), een maat voor de inzet van resources op het project in de tijd en daarmee een maat voor de stress in het project. Deze maten zijn direct vergelijkbaar met de marktgegevens die in de producten Estimate en Metrics verwerkt zijn. SCHATTEN Zodra het idee voor een softwareproject geboren is, komen er opmerkingen in de vorm van gelijkenissen met andere projecten. Dat is, hoe onnauwkeurig ook, een eerste schatting. Een eerste serieuze schatting van de omvang van het project is snel gemaakt. Het projectteam besluit bijvoorbeeld dat het opstellen van eisen en functioneel ontwerp daarvoor voldoende is. Resterende fouten kunnen na oplevering verbeterd worden. Men verwacht dat het systeem voor 80% aan business-code, 5% aan telecomcode en 15% aan systeemcode zal bevatten. Het systeem zal uit ongeveer regels C bestaan (in dit geval was er geen functiepuntanalyse gedaan) en er zijn maximaal zeven medewerkers beschikbaar. Om te kunnen vaststellen hoeveel tijd, geld en menskracht voor de Afbeelding 1 Tabel 1 realisatie hiervan nodig is, valt SLIM-Estimate terug op gegevens van vergelijkbare projecten in de QSM-database. Zo wordt rekening gehouden met een Productiviteitsindex (PI) van 18.3 en een Manpower Buildup Index (MBI) van 2.9. In afbeelding 1 zien we het aantal medewerkers gedurende de geplande loop van het project, een tabel met Tabel 2 verwachte waarden, een grafiek die de waarschijnlijkheid toont dat het project randvoorwaarden haalt (leeg, geen randvoorwaarden gesteld) en (manipuleerbare) wijzers die de PI, piekstaf en het aantal regels code aangeven. Het is de meest waarschijnlijke oplossing: Er is 50% kans dat minder, maar ook 50% kans dat meer nodig zal blijken te zijn. Tabel 1 geeft de cijfers voor het gehele traject bij 50% en 80%. Naar aanleiding van deze tabel stelt iemand dat het project hooguit een jaar mag duren en de productie al direct na de C&T-fase moet beginnen. Het bedrijf kan hierdoor dan als eerste met het product de markt op. Tabel 2 laat zien wat dat voor de planning betekent. Het bedrijf zou vier maanden eerder de markt op kunnen, maar het kwaliteitsniveau van het product komt daarmee wel sterk onder druk. Om die vier maanden te winnen, moet verder rekening gehouden worden met drie- tot viermaal hogere inspanningen 6

3 Afbeelding 2 en investeringen. Wat zijn deze planningen nu eigenlijk waard op de markt? We kunnen ze vergelijken met de trendlijnen die QSM regelmatig aan haar klanten verstuurt. De grafieken in afbeelding 2 zetten het aantal regels code af tegen doorlooptijd, inspanning, aantal fouten en de piekstaf (van de constructiefase). De trendlijn in deze Afbeelding 3 grafieken geeft de meetgemiddelden van soortgelijke projecten in de QSMdatabase. De stippellijnen zijn standaardafwijkingen boven en beneden het gemiddelde. De planningen zien er redelijk uit wat betreft doorlooptijd en aantal fouten. Maar de planningen waarin het project in één jaar afgerond moet zijn (rode, vierkant omlijnde stip) vragen bijzonder veel inspanning en een hoge piekstaf, althans vergeleken met de markt. VERGELIJKEN Een bedrijf dat programmatuur ontwikkelt voor de telecommarkt kreeg klachten dat het relatief duur was en er nogal wat fouten in de geleverde programmatuur zaten. Met behulp van SLIM-Metrics werd onderzocht hoe code en manier van werken zich verhielden tot die van anderen op de markt. Sterke kanten van het bedrijf bleken de hoge motivatie en kennis van de medewerkers, effectief management en een algemeen gevoel werkelijk deel uit te maken van het bedrijf. Minder sterk was de hoge tijdsdruk op de projecten. Men kwam nauwelijks toe aan het testen van de code, laat staan het documenteren ervan. De ontwikkelafdeling was gescheiden van de afdeling verantwoordelijk voor de productkwaliteit. Verder waren de trainingsbudgetten voor medewerkers aan de krappe kant. De grafieken in afbeelding 3 tonen weer trendlijnen van de markt waarop het bedrijf zich richt. 7

4

5 Afbeelding 4 Op de horizontale as staan in alle grafieken het aantal regels code. In leesvolgorde tonen ze: Aantal gevonden fouten vóór oplevering Hoewel niet door de klant ontdekt, ligt het aantal fouten bij vier projecten hoog. Een indicatie dat de klant reden had tot klagen. Manpower Buildup Index Voor de meeste projecten eveneens aan de hoge kant. Een hoge MBI jaagt de projectkosten flink op en heeft nadelige gevolgen voor de kwaliteit na oplevering. Productiviteit per medewerker per maand De productiviteit neem af naarmate projecten groter worden, terwijl de markt op dit punt juist het omgekeerde laat zien. Er werd weinig aan documentatie gedaan en er werken vrij veel mensen aan een project. Men heeft waarschijnlijk veel tijd nodig voor informatie-uitwisseling, waardoor men minder aan coderen toekomt dan wenselijk is. Doorlooptijd van functioneel ontwerp Vier projecten laten zien dat men evenveel tijd besteedt aan het functioneel ontwerp, ongeacht de omvang van het af te leveren product. Het bedrijf heeft een aantal veranderingen doorgevoerd. Ten eerste heeft men ontwikkelaars en testers met elkaar laten samenwerken. Daarnaast heeft men geïnvesteerd in betere hulpmiddelen en is men gaan begroten op basis van ervaringscijfers. Het documenteren, ook in de ontwerpfase, wordt serieuzer aangepakt. Na verloop van tijd bleek men veel beter thuis in de code en kwam er meer rust in het werk. Men besefte dat de werkdruk omlaag kon. Het bedrijf maakte daardoor lagere operationele kosten en de klant kreeg betere kwaliteit. BIJSTUREN In de uitvoering van een project willen we regelmatig controleren of we op schema liggen. Is dat niet het geval, dan moeten we doelmatig kunnen bijsturen. Daarvoor hebben we dus tijdig de juiste informatie nodig en een systeem om de diagnose (op schema of niet) te kunnen stellen. Als bijsturen nodig is, moeten we natuurlijk ook een nieuwe betrouwbare planning kunnen maken. Voor het monitoren van de projectvoortgang biedt SLIM-Control de projectmanager een dashboard met meters die waarschuwen als het project in zwaar weer dreigt te geraken en die verwachtingen formuleren over einddatum, kosten en kwaliteit bij oplevering (zie afbeelding 4). Dit alles op basis van feitelijke gegevens over het gerealiseerde deel. De programmadisplays geven niet alleen informatie over de huidige projectstand, maar ook over te verwachten ontwikkelingen binnen het project. Dit gaat met verkeerslichten die op groen staan wanneer een aspect volgens plan verloopt, op geel wanneer er extra aandacht op dat punt nodig is en op rood wanneer er iets misloopt. Een instrument dus om te sturen op basis van feitelijke gegevens over hoeveel tijd is besteed aan welk projectonderdeel en wat er in die tijd is gerealiseerd. Bedrijven die hun ICT-projecten begeleiden op basis van metrieken en de hierboven beschreven instrumenten zijn daarover doorgaans zeer te spreken. Zij kunnen werk en tijd beter inschatten en de voortgang van het project nauwgezet volgen en zo nodig bijsturen; ze kunnen hun risico s beter beheersen. Betrouwbare voorspellingen op basis van het systematisch verzamelen en verwerken van adequate informatie blijken een stevige basis te vormen voor doelmatige en succesvolle projecten. Projecten die binnen budget, op tijd en met het gewenste kwaliteitsniveau worden opgeleverd. 9