Hoe schat u een project van softwareontwikkeling?
Projecten van softwareontwikkeling gaan dikwijls over tijd en budget. Eén van de meest voor de hand liggende redenen is dat de benodigde tijd niet goed werd ingeschat. Maar hoe kan het dan wel? En hoe maak je een geloofwaardige schatting?
Waarom is het zo moeilijk om voor een project van softwareontwikkeling de benodigde tijd accuraat te schatten? We vroegen het aan Sander Hoogendoorn, principal technology offi – cer bij Capgemini Nederland en verantwoordelijk voor innovatie van softwareontwikkeling bij dat bedrijf. Eind 2006 gaf hij een seminar over het thema ‘Estimating and Planning with Smart Use Cases’ bij IT Works.
HET PROBLEEM
Hoogendoorn geeft diverse redenen aan voor het mislukken van zo’n schatting: ‘Eerst en vooral is het zo dat de requirements veranderen in de loop van het project. Tijdens het project leren de (toekomstige) gebruikers bij; ze krijgen een duidelijker beeld van de mogelijkheden van de toepassing en passen hun wensen en eisen daaraan aan.’ Een andere reden ligt volgens hem bij de technologie: ‘Als je een toepassing gaat bouwen met nieuwe technologie, waarvan je de mogelijkheden en valkuilen nog niet kent, hoe kan je dan een goede schatting maken?’
Wat ook meespeelt is dat ontwikkelaars optimisten zijn; ze schatten de benodigde tijd standaard zo’n 20% te kort in. Nog een reden, volgens Hoogendoorn: de keuze voor een bepaalde technologie maakt wel degelijk verschil. En tenslotte worden projecten te weinig geëvalueerd. Vaak zijn er geen betrouwbare cijfers over de snelheid van ontwikkelen op voorgaande, vergelijkbare projecten.
DE TECHNIEKEN
Om aan die problemen te verhelpen heb je een aantal mogelijkheden. Functiepuntanalyse is volgens Hoogendoorn de bekendste techniek om voor een project van softwareontwikkeling de nodige tijd te schatten. ‘De functiepuntanalyse werd oorspronkelijk ontworpen voor de ‘watervalaanpak’, waarbij de fasen van analyse en ontwerp afgesloten zijn vóór de ontwikkeling begint.
Men schat aan de hand van het ontwerp. De totale omvang van de te ontwikkelen toepassing wordt bepaald op basis van input, output, queries, fi les en interfaces met de buitenwereld’, aldus Hoogendoorn.
Een aantal bedrijven rekent ook met het aantal regels code in een programma. Ze weten uit het verleden hoeveel (correcte) regels code hun ontwikkelaars per uur produceren, en schatten het aantal regels in de toekomstige toepassing.
In de wereld van Extreme Programming en Scrum werkt men met user stories. Hoogendoorn: ‘Die worden door toekomstige gebruikers zelf geschreven. Schatten is dan moeilijk, omdat de user stories onderling sterk verschillen qua omvang en complexiteit.’ Capgemini zelf gebruikt de Unified Modeling Language en het Rational Unifi ed Process. ‘Wij werken met use cases,’ aldus Hoogendoorn, ‘maar ook die zijn niet zo gemakkelijk te schatten, omdat ze vaak erg uiteenlopen qua omvang en complexiteit.’
Daarom pleit hij voor het gebruik van zogenaamde smart use cases: ‘Als je het werk op een goede manier versnijdt, dan werk je voor schatting en ontwikkeling met dezelfde eenheid, die heel gelijkmatig van aard is.’
Maar er zijn nog andere technieken. Een aantal ontwikkelaars telt klassen, entiteiten, attributen en operaties, maar dergelijke technieken steunen sterk op de gegevens die een toepassing verwerkt. Tenslotte is er nog de work breakdown structure. Het uit te voeren werk wordt opgedeeld, en elk deel wordt geschat. Hoogendoorn: ‘Die werkwijze is niet slecht, soms gebruiken we ze als een tweede methode, om het resultaat te vergelijken met het resultaat van de schatting aan de hand van functiepunten of smart use cases.’
SCHATTEN MET SMART USE CASES
‘Use cases kan je defi niëren op verschillende niveaus,’ vertelt Hoogendoorn, ‘Er zijn use cases op strategisch niveau, en use cases op tactisch niveau. Meestal kiezen organisaties voor het gebruik van use cases op gebruiksniveau. Die zijn vergelijkbaar met elementaire bedrijfsprocessen uit de procesmodellering.’ ‘Plaats bestelling’ en ‘boek vliegticket’ zijn bijvoorbeeld use cases op dit niveau. Dan zijn er nog use cases op subfunctieniveau, zoals ‘kies product’ of ‘betaal vliegticket’.
Die laatste twee niveaus vallen onder de naam smart use cases. ‘Met zo’n smart use cases kan je al vroeg in een project beginnen’, zegt Hoogendoorn, ‘de richtlijnen zijn vrij eenvoudig en het modelleren is niet zwaar. Bovendien wordt de visuele voorstelling goed begrepen door gebruikers.’
De volgende stap is het vaststellen van een schaal om de moeilijkheidsgraad van de smart use cases te bepalen. Capgemini hanteert een schaal van 1 tot 5, 8 of 10, waarbij een programma van niveau 1 eenvoudig is, en een programma van niveau 10 zeer complex. Door die complexiteit voor ieder van de smart use cases vast te stellen, bepaal je de totale omvang van een project.
Een tweede factor, de ontwikkelsnelheid, kan het best worden afgeleid uit gegevens van vergelijkbare projecten in het verleden. Met de combinatie van die twee elementen, omvang en ontwikkelsnelheid, schat men de duur van het nieuwe project.
Christiane Vandepitte is zelfstandig consultant.
Sander Hoogendoorn is consultant, lesgever en auteur voor software development.
