Hoofdstuk 17 Moeten de projectfases elkaar strikt opvolgen?

1 Inleiding en leerdoel

In een alsmaar complexer wordende omgeving met alsmaar grotere beperkingen qua budget en tijd, is er ook meer en meer vraag naar een flexibele invulling van de verschillende projectfases. Als antwoord daarop werden er verschillende strategieën opgesteld die elk op hun manier omgaan met de projectfases ontwerp, build (implementatie) en test. In het hoofdstuk ‘Ontwikkelt elk bedrijf agile of volgens de waterfall-methode? #tussenvormen’ gaan we dieper in op de factoren en de omstandigheden die een invloed kunnen hebben op de keuze van de ontwikkelstrategie, maar in dit hoofdstuk gaan we eerst dieper in op de evolutie van en de verschillen tussen de ontwikkelstrategieën.

Een ontwikkelstrategie omvat de wijze waarop ontwerp, ontwikkeling en testen opgezet en ingepland zullen worden. Afhankelijk van de ontwikkelstrategie verlopen de verschillende fases sequentieel dan wel iteratief.

Op het einde van dit hoofdstuk: … onderscheid ik de verschillende ontwikkelstrategieën en kan ik de voor- en nadelen van elke strategie benoemen; begrijp ik het verschil tussen sequentieel, incrementeel en iteratief ontwikkelen.

2 Beschrijving en doel

In dit boek werd al duidelijk dat elk project, afhankelijk van interne en externe invloeden, anders ingevuld zal worden. De basisstructuur met de verschillende uitvoeringsfases (planning, analyse, implementatie, test en turnover) blijft geldig voor bijna elk project, maar het inplannen van die fases kan sterk verschillen. Historisch zijn er een aantal ontwikkelstrategieën ontstaan die proberen om te gaan met de verschillende invloeden die een project kan ondervinden en waarin bijgevolg een plan van aanpak werd uitgewerkt om de verschillende fases op een zo goed mogelijke manier in te plannen en in te vullen. Het spreekt voor zich dat door de jaren heen ook verschillende variaties werden gemaakt op de verschillende ontwikkelstrategieën. Grote ondernemingen gebruiken veelal een ontwikkelstrategie als uitgangspunt en verfijnen die dan verder binnen de eigen context. Zoals altijd is het ook noodzakelijk om flexibel om te gaan met die strategieën en de projectspecifieke of klantspecifieke omgeving niet uit het oog te verliezen. Veelal is de strategie van ‘het gezond verstand’ de beste aanvulling op eender welke ontwikkelstrategie.

In de volgende paragrafen zullen volgende ontwikkelstrategieën worden besproken:

– build and fix; waterfall (lineair/ sequentieel);

– rapid prototyping; incrementeel

– iteratief; continuous delivery.

De volgorde van de verschillende strategieën wordt min of meer historisch bepaald, waarbij het build and fi x-model het oudste is en het iteratief ontwikkelen vooral de laatste jaren veel aanhangers heeft gekregen. In het hoofdstuk ‘Welke agile manieren van werken zijn er? #agile’ bespreken we iteratief ontwikkelen daarom ook nog meer in detail.

3 Build and fix

Een van de eerste ontwikkelstrategieën is het build and fi x-model. In die strategie gaat men ervan uit dat de testen uitgevoerd werden door de klant die het product ging gebruiken. Er is helemaal geen feedback tussen de verschillende fases, en fouten in de software of in de functionaliteit komen pas aan het licht wanneer een klant een probleem ondervindt en dat meldt aan de maker van de software. Als er zich een probleem voordoet, wordt er een oplossing gemaakt die dan naar alle klanten wordt doorgestuurd onder de vorm van een support package of upgrade.

Dit type van strategie is zeer reactief en zal enkel proberen de schade te beperken wanneer die zich voordoet. Het spreekt voor zich dat dat enkel werkt in een markt met heel weinig spelers waar klanten zeer geduldig zijn. In de vroege dagen van softwareontwikkeling waren er slechts enkele ontwikkelaars en werd software nog niet gebruikt voor alle aspecten van het dagelijks leven. Klanten waren dus gebonden aan de verkopers van de software en moesten wachten tot het probleem was opgelost. De verwachtingen van de gebruikers lagen helemaal anders dan vandaag. Heel af en toe wordt dat type van strategie nog gebruikt, bijvoorbeeld als startende bedrijven een bepaald product op de markt brengen en goedkoop ter beschikking stellen van gebruikers in ruil voor het testen van het product zoals meestal het geval is bij crowdfunding. Door de mogelijkheid om te beschikken over de nieuwste technologie voor een lage prijs, zijn de verwachtingen van de gebruikers minder hoog en kan men op die manier werken. Het gaat dan ook veelal om technologie die slechts door één aanbieder kan worden gemaakt, waardoor ook de andere voorwaarde om dat model te kunnen gebruiken vervuld is.

4 Waterfall

Het waterfall-model, ook wel lineair of sequentieel model genoemd, werd ontwikkeld in de jaren 70 en is gebaseerd op de principes van de constructie van grote bouwwerken zoals bruggen en wolkenkrabbers:

1 Probleemstelling: er moeten auto’s van de ene kant van de rivier naar de andere geraken.

2 Men maakt een bouwplan op voor een brug.

3 Men bouwt de brug.

4 Men test de brug.

5 De brug wordt opengesteld voor verkeer.

In dit model is er wel een mogelijkheid om feedback te geven tussen twee opeenvolgende fases maar kan men niet meer teruggaan naar een vorige fase. Als de brug is gebouwd, kan men het plan immers niet meer aanpassen zonder de brug terug volledig af te breken en opnieuw te beginnen. Dit model heeft zijn nut bewezen in de ontwikkeling van bouwwerken omdat het gebaseerd is op duizend jaren ervaring maar het bleek niet altijd afdoende in de nieuwe discipline van digitale ontwikkelingen.

Het waterfall-model wordt gekenmerkt door sequentiële fases waarbij er slechts een beperkte feedback mogelijk is tussen twee opeenvolgende fases. Om de overgang van de ene naar de andere fase vlot te laten verlopen wordt er gebruik gemaakt van zeer uitgebreide documentatie. Die ontwikkelstrategie werd ook wel eens de traditionele ontwikkelstrategie genoemd, hoewel we de laatste jaren kunnen zeggen dat agile werken die fakkel volledig heeft overgenomen.

Het waterfall-model is bruikbaar bij zeer eenvoudige software-implementaties, maar kan heel moeilijk worden gebruikt als het om complexe projecten gaat. Toch wordt het in de praktijk nog gebruikt. De eenvoud van de sequentiële fases maakt het veelal eenvoudiger om zeer langdurige projecten goed te plannen en op te volgen. Het grote gevaar van die aanpak is dat men pas gaat testen op het einde van het project. Als men tijdens het testen grote fouten ontdekt, kan dat nefast zijn voor de kosten van het project. Men loopt immers het risico dat men een jaar werk (deels) opnieuw moet doen als de uiteindelijke oplossing niet correct blijkt te zijn of niet voldoet aan de eisen van de klant. Vooral het laatste is een reëel probleem in projecten die op basis van het waterfall-model werden uitgevoerd. Omdat de klant pas laat in het project een afgewerkt product krijgt en dus feedback kan leveren (tijdens de testen), is het goed mogelijk dat het ontwikkeld product niet volledig voldoet aan de vereisten. In het hoofdstuk ‘Ontwikkelt elk bedrijf agile of volgens de waterfall-methode? #tussenvormen’ gaan we dieper in op de keuze tussen waterfall en de andere strategieën.