Bij softwareontwikkeling blijft het een probleem om de beloofde programmatuur op tijd en binnen het budget op te leveren. Er is een methode nodig die de beste elementen van het klassieke v-model en de jongere ‘agile’ benaderingen combineert, en zaken die in beide richtingen ontbreken toevoegt. Effective and Efficient Enterprise Systems Development ofwel 3ESD moet dat realiseren.
Slechts één op de vijftig softwareontwikkelprojecten is een succes: op tijd en binnen het afgesproken budget opgeleverd, en uitvoerend wat in de offerte was toegezegd. Dit is niet zomaar een boude bewering, maar de conclusie van onderzoeksbureau Forrester na uitgebreid onderzoek. Concurrent Gartner schat de jaarlijkse wereldwijde kosten hiervan op vijfhonderd miljard dollar. Ter vergelijking: dat is ongeveer twee keer de Nederlandse staatsschuld.
Gebagatelliseerd
Software ontwikkelen is het experimentele stadium voorbij. Het is niet langer voorbehouden aan enkele bevoorrechte wetenschappers of kleine groepen pioniers. Integendeel, softwareontwikkeling vormt al enkele decennia een industrie op zich. Het wordt voortdurend ondersteund door onderzoek naar de wijze waarop je software het best kunt ontwikkelen. Toch wekken de onderzoeksresultaten van Forrester en Gartner geen verbazing op, maar herkenning en berusting. De resultaten worden zelfs enigszins gebagatelliseerd. Zou het in andere branches dan beter zijn? Die één op de vijftig, is dat niet een wat al te pessimistische schatting?
Het blijft echter een feit dat de prestaties van ‘de ict-branche’ op het gebied van softwareontwikkelprojecten bedroevend zijn. Ook in Nederland: de Stichting Geschillenoplossing Organisatie en Automatisering meldt dat het aantal geschillen en de omvang ervan toeneemt. Exacte gegevens geeft de stichting niet om privacyredenen. De grootste schikking tot nu toe bedraagt “meer dan honderd miljoen”.
Stapsgewijs
Hoe je software moet ontwikkelen is toch onderzocht en bekend? Iedereen die zich ermee bezighoudt kent toch ten minste het waterval- of v-model? Dat valt tegen. ‘Kennen’ moeten we hier lezen als ‘zoals geleerd op de cursus’. Dat is meestal een verregaande vereenvoudiging van het oorspronkelijke model, zodanig dat het wel in een paar bijeenkomsten te leren valt, maar een aantal essentiële elementen niet aan bod komt. Bovendien passen ontwikkelaars dat wat ze onthouden hebben van de cursus vaak niet eens (correct) toe.
Het v-model – de ‘klassieke’ benadering – leert ons stapsgewijs te werken: eerst een functioneel ontwerp en dan een technisch ontwerp schrijven, daarna programmeren, dan het programma testen tegen eerst het technisch ontwerp en vervolgens het functioneel ontwerp, en tot slot het programma opleveren. Wanneer de ontwikkelaars het v-model op deze wijze toepassen in projecten van enige omvang schieten de ontwerpen op detailniveau vaak tekort, omdat ze proberen het hele gewenste systeem in één keer te ontwerpen. De ontbrekende details moeten ze dan tijdens het programmeren alsnog invullen. Dat kost tijd boven op de geplande tijd en kan leiden tot afwijkingen van het bedoelde systeem.
Daarnaast zorgt de brede opzet voor een lange doorlooptijd per stap, zodat het erg lang duurt voordat het systeem wordt opgeleverd. Het past daardoor vaak niet goed meer bij de – inmiddels veranderde – behoefte van de opdrachtgever. Het v-model biedt in deze vorm ook weinig gelegenheid voor het aanbrengen van wijzigingen gedurende het proces, omdat je voor elke verandering eigenlijk alle stappen opnieuw moet doorlopen.
In het diepe
Op die manier steken ontwikkelaars dus veel tijd in ontwerpen zonder dat er goede ontwerpen zijn als ze gaan programmeren. Daarnaast steken ze veel tijd in testen zonder dat duidelijk is wat het systeem precies moet doen. Alles bij elkaar duurt het lang voordat ze een systeem opleveren. Als reactie hierop ontstond de ‘agile’ ofwel vlugge benadering, die onder meer is toegepast in RAD en DSDM (Rapid Application Development, Dynamic Systems Development Methodology).
Bij de vlugge benadering duik je meteen in het diepe. De ontwikkelaars hakken het beoogde systeem in delen op en beginnen per deel meteen met programmeren aan de hand van een gesorteerd lijstje functionele eisen. Ontwerpen en testen gebeurt gelijktijdig door voortdurend proberen, schaven en uitbreiden. Mochten de eisen wijzigen, dan kan je gewoon doorwerken met de gewijzigde eisen. Is de beschikbare tijd op, dan is het programmadeel klaar. Zijn alle delen gereed, dan is de applicatie klaar.
Om de doorlooptijd kort te houden is er de 80/20-regel als stok achter de deur. Binnen de vlugge benadering geldt dat 80 procent van een systeem te ontwikkelen is in 20 procent van de tijd die nodig zou zijn om het volledige gewenste systeem te bouwen. Omdat elk gewenst systeem voor 20 procent uit ‘franje’ zou bestaan, valt met de vlugge benadering een volledig, zij het sober, systeem te ontwikkelen in 20 procent van de tijd en voor 20 procent van het budget die bij de klassieke benadering nodig zouden zijn.
Wel succesvol
Snel, goedkoop en flexibel, maar geen succes. De ontwikkelaars proberen namelijk niet eens om meer dan 80 procent van de gewenste functionaliteit te bouwen, en die 80 procent komt in het gedrang doordat ze met de bouw van een programmadeel beginnen zonder dat dit ontworpen is. Bij de ontwikkeling van de delen kijken ze daardoor niet of nauwelijks naar de koppeling met andere nog te ontwikkelen delen. Reeds ontwikkelde delen moeten vaak aangepast of herontwikkeld worden voor een goede koppeling met het huidige deel.
Verder worden de delen ontwikkeld volgens de ideeën en het begrip van een klein team, in plaats van dat de ontwikkelaars in een goed gespecificeerde behoefte van de opdrachtgever voorzien. Daarbij wordt de functionaliteit vaak herontwikkeld of aangepast als gevolg van voortschrijdend inzicht binnen het team. Aan het eind van het project moet daardoor extra tijd en geld worden geïnvesteerd om het geheel verder te ontwikkelen tot een voor de opdrachtgever acceptabel product.
Op zich zijn met beide aanpakken goede resultaten te behalen, mits ze worden toegepast door intelligente mensen met een goed begrip van de te volgen methode en grote vakbekwaamheid. In de praktijk hangt het gros van de softwareontwikkelaars tussen mbo- en hbo-niveau en is hun begrip en bekwaamheid ongeveer gelijk aan het niveau van de gevolgde cursussen. Om in de praktijk succesvol te zijn is dus een methode nodig die niet alleen de beste elementen van beide benaderingen combineert, maar ook zo valt in te richten dat de medewerkers zich uitsluitend op hun primaire taak hoeven te richten. Verder moet de methode het management in staat stellen het verloop van een project te sturen en de doorlooptijd en kosten te beheersen. 3ESD (Effective and Efficient Enterprise Systems Development) is een methodologie die dat alles realiseert.
Beheersbaar
3ESD is opgesteld in het kader van het onderzoek naar maatwerk bij erp-systemen (enterprise resource planning) binnen het erp-lectoraat (een initiatief van Avans Hogeschool en de Hogeschool voor Economische Studies (HES) Amsterdam, waarin de Universiteit van Tilburg en Atos Consulting participeren). De auteur heeft de methodologie 3ESD ontwikkeld als afstudeerproject. De oplossing schuilt in de combinatie van een aantal elementen van de bestaande benaderingen: fouten voorkomen, gestructureerd werken, gestructureerd testen en de omvang van de werkzaamheden beperkt houden.
Allereerst worden fouten voorkomen door uit te gaan van de behoefte van de opdrachtgever, in plaats van zijn specificaties direct over te nemen. Software specificeren is immers niet de expertise van de opdrachtgever. Wanneer zijn behoefte duidelijk is, kan een ontwerper een passend systeem specificeren. Dat verkleint de kans op functionele wijzigingen gedurende het project substantieel. Verder worden fouten voorkomen door ontwerpen op elk niveau terug én vooruit te koppelen voor verificatie. Zo wordt vastgesteld dat een ontwerp een goede ‘vertaling’ is van het ontwerp van het voorgaande niveau en dat het aansluit bij de behoefte van het volgende niveau.
Het werk wordt gestructureerd door de werkzaamheden in niveaus in te delen en per niveau uniform te werk te gaan. Een niveau bestaat uit een verwerking, en een test opstellen en uitvoeren, zodat ook alle tests structureel worden uitgevoerd en gereed zijn als ze gedaan moeten worden. Doordat elk niveau apart wordt aangestuurd kunnen de ontwikkelaars autonoom werken, bijvoorbeeld in India. Dat maakt ook de kosten beheersbaar.
Tot slot wordt de omvang van de werkzaamheden beperkt door het gewenste systeem te verdelen in logische eenheden en per eenheid te ontwikkelen. Doordat de werkzaamheden behoorlijk autonoom worden uitgevoerd en aangestuurd is het ook mogelijk om verschillende eenheden parallel te laten ontwikkelen. Je kunt bijvoorbeeld tegelijkertijd eenheden laten ontwikkelen in India en in Vietnam. Dat maakt ook de totale doorlooptijd van een project beheersbaar.
Voor Groenevelds afstudeerscriptie over 3ESD zie: http://www.3esd.org
Philip Groeneveld, senior software engineer bij scm-specialist Quyntess (supply chain management)
