Watervalmethode: definitie, proces & voorbeelden

Waar draait de watervalprojectmanagementmethodologie om?

Waterval vertegenwoordigt het concept van het beheren van ontwikkelingsprojecten door ze op te splitsen in afzonderlijke fasen en elke fase opeenvolgend af te handelen.

Hoewel het opdelen van grote hoeveelheden werk in kleinere stukken een concept is dat mensen al sinds het begin der tijden gebruiken, vond de formele “geboorte” van de watervalmethodologie veel later plaats—in 1970, toen Dr. Winston W. Royce, een prominente computerwetenschapper uit die tijd, deze beschreef in zijn boek “Het beheer van grote softwaresystemen”.

Sindsdien is dit de belangrijkste manier geworden waarop softwarebedrijven hun projecten beheerden, totdat de wereld zich begin jaren 2000 naar Agile begon te richten.

Hoe de softwareontwikkelingslevenscyclus (SDLC) eruitziet met de watervalmethode

In tegenstelling tot de iteratieve en incrementele structuur van Agile heeft de SDLC voor waterval zowel een duidelijk begin als een duidelijk einde. De volledige softwarecreatie wordt opgedeeld in vijf verschillende fasen of mijlpalen, en het werk aan één fase begint pas wanneer de vorige fase is voltooid. Visueel ziet dit er als volgt uit:

Het werk stroomt van de ene fase naar de andere, waarna het de bodem bereikt en het project als “voltooid” wordt beschouwd—waardoor het visueel lijkt op een waterval (vandaar de term).

Laten we nu elke fase in deze lineaire aanpak bekijken en begrijpen waaruit deze bestaat.

Fase #1: Vereisten verzamelen

Alles begint met het verzamelen van de vereisten voor het project bij alle belanghebbenden. Tijdens de vereistenfase maken projectmanagers een uitgebreid en zeer gedetailleerd document waarin elk aspect van het project wordt beschreven, van functionele vereisten tot het budget- en risicoplan.

Fase #2: Oplossingsontwerp

Op basis van de vereisten die in de vorige fase zijn verzameld, begint het projectteam de oplossing uit te werken en te ontwerpen. De term “ontwerp” verwijst hier naar de technische structuur van het product (systeemontwerp), het visuele ontwerp en interactieontwerp van het product (UI/UX-ontwerp) en het fysieke ontwerp (als het om een fysiek product gaat).

Fase #3: Implementatie

Dit is het moment waarop het daadwerkelijke programmeren plaatsvindt. De leden van je ontwikkelteam beginnen met het bouwen van het product op basis van de op te leveren resultaten die je in de ontwerpfase hebt opgesteld.

In tegenstelling tot Agile, waarbij je vrij bent om de reikwijdte en het ontwerp van je project voortdurend te wijzigen, gaat waterval ervan uit dat je het ontwerpdocument volgt en je product tijdens de implementatiefase niet “evolueert”.

Fase #4: Testen

Zodra het software-engineeringteam klaar is met het bouwen van het product, kunnen we doorgaan naar de volgende fase van ons projectplan—het testen. Je team begint je product te controleren op bugs, beveiligingsproblemen en problemen met de gebruikerservaring.

Tijdens de testfase controleer je ook of de functionaliteit en het ontwerp van het eindproduct overeenkomen met de projectvereistendocumenten die je tijdens de eerste twee fasen hebt opgesteld.

Fase #5: Implementatie en ondersteuning na de release

Ervan uitgaande dat je team alle belangrijke problemen in je product heeft gevonden en opgelost, is het tijd om een release uit te brengen en je oplossing over te dragen aan je klanten en eindgebruikers. 

Je programmeurs gaan nu verder met de onderhoudsfase door voortdurend feedback van klanten te verzamelen, de nodige reparaties uit te voeren en nieuwe patches en updates van je product uit te brengen.

Dat is alles: je project is voltooid en je kunt doorgaan naar het volgende!

Dus, moet je de watervalmethode gebruiken?

Als jij, de Agile-georiënteerde projectmanager (althans, dat neem ik aan), denkt dat deze methodologie uit de mode is en je het gebruik ervan nooit zou moeten overwegen, dan ben ik het (met alle respect) niet met je eens. Ik betoog dat de watervalaanpak voor specifieke soorten projecten eigenlijk de betere keuze is.

Laat me een paar voorbeelden met je doornemen om mijn punt te bewijzen.

Casestudy's: de watervalmethode in actie

Zoals bij elk complex concept kunnen enkele concrete voorbeelden helpen om te begrijpen hoe de methodologie in de praktijk werkt. Daarom volgen hier enkele voorbeelden op basis van echte projecten (waar ik zelf wel of niet aan heb gewerkt) om je te helpen helder voor ogen te krijgen hoe de watervalaanpak in de praktijk werkt.

Casus 1: een platform voor douaneafhandeling voor de Egyptische overheid

Stel je voor dat je deel uitmaakt van een bedrijf dat het contract heeft gewonnen om de systemen voor internationale handel en douaneafhandeling van een relatief groot land, bijvoorbeeld Egypte, te moderniseren.

Wat de Egyptische overheid wil, is een systeem voor de havenautoriteit dat de manifesten van alle schepen beheert (een douanedocument met informatie over alle vracht en passagiers aan boord van dat schip) die de verschillende havens van Egypte binnenkomen.

Bovendien willen ze dat dit systeem rechtstreeks wordt geïntegreerd met een ander product dat ze je willen laten bouwen en dat alle douaneaangiften (ook wel SAD's ofwel administratieve documenten genoemd) in het land zal afhandelen. Het formulier is behoorlijk complex voor gewone mensen om in te vullen, dus willen ze dat je het voor hen automatiseert.

Egypte heeft een complex systeem voor belastingen en douanerechten waarvan de tarieven veranderen op basis van het type goederen dat je importeert, de hoeveelheid en andere factoren. Omdat gewone burgers geen idee hebben van deze tarieven, wil de Egyptische overheid dat je app alles automatisch voor haar burgers berekent op basis van wat ze hebben aangegeven en hen online laat betalen met hun creditcards.

Dit lijkt een enorme onderneming, nietwaar? Welnu, bij het afronden van de implementatiedetails zullen je leidinggevenden (en misschien zelfs de Egyptische overheid) naar jou, de projectmanager, komen en vragen hoe je de implementatie van dit project wilt organiseren.

Waarom en hoe je in dit scenario de watervalmethode moet gebruiken:

Wat je ook bouwt voor een nationale overheid, het zal hoogstwaarschijnlijk gebaseerd zijn op een wet of een besluit dat door het parlement is bekrachtigd. Deze besluiten bevatten alles, van de algemene voorwaarden van het project (bijvoorbeeld de kosten en planning) tot de kleinste details van hoe alles zal werken.

Het klinkt en ziet eruit als een eisendocument uit de eerste fase van de waterval, toch? Dat is inderdaad zo, en het betekent ook dat je implementatiedetails, ontwerp en eisen niet zomaar gaandeweg kunt wijzigen zoals bij Agile-softwareontwikkeling.

Ik heb ooit leidinggegeven aan zo'n product. Op een dag ontdekten we dat we de gebruikerservaring aanzienlijk konden verbeteren door een paar kleine aanpassingen in de bedrijfslogica te doen. We deelden ons idee onmiddellijk met de vertegenwoordiger van de douaneautoriteit die met ons samenwerkte.

Welnu, hij zei nee. Je zou denken dat het een slecht idee was om zo'n aanbod af te wijzen, maar hij had een goede reden waarom ze het niet konden doen.

Onze kleine aanpassingen zouden een wijziging betekenen in de formule die de overheid gebruikte om belastingen voor een bepaald product te berekenen. De formule lag vast in de wet, dus wijzigen ervan zou betekenen dat het volledige nationale parlement bijeen moest komen en erover moest stemmen.

Casus 2: het vluchtcontrolesysteem van de Ingenuity-helikopter

Ingenuity is de naam die NASA gaf aan de hightechhelikopter die ze in 2021 bouwden en naar Mars stuurden. Zo ziet het kleine toestel eruit.

Stel je voor dat je een van die gelukkige projectmanagers bent die verantwoordelijk is voor de ontwikkeling van de software voor dit ongelooflijke stukje technologie. In het bijzonder moest je team de code schrijven die de vlucht van de helikopter zou besturen.

Een vluchtcontrolesysteem voor een vliegtuig maken (vooral voor een helikopter) is erg moeilijk. Je moet rekening houden met alle natuurkundige wetten die tijdens de vlucht op je vliegtuig inwerken en de benodigde rotatiesnelheid van je bladen, de hoek van de bladen en nog een miljoen andere zaken berekenen.

Maar jouw taak is nog complexer. Je helikopter moet boven het oppervlak van een andere planeet vliegen, met een atmosfeer die 100 keer minder dicht is dan die op aarde.

Waarom en hoe je in dit scenario de watervalmethode moet gebruiken:

Naar mijn mening is watervalontwikkeling hier je enige optie. In tegenstelling tot Agile-projectmanagement, waarbij je iets kleins bouwt (je MVP), het implementeert, het in de praktijk gebruikt, feedback verzamelt en je oplossing geleidelijk verbetert op basis van die feedback, zijn de belangen bij een project als dit veel te groot.

Kun je echt het risico nemen om een gebrekkige MVP van Ingenuity te maken en die 140 miljoen mijl naar Mars te laten vliegen? Er is gewoon geen enkele manier waarop iemand daarmee zou instemmen.

Je zult dus de definitieve versie moeten bouwen en vervolgens alle systemen ervan grondig moeten testen voordat je er voldoende vertrouwen in hebt om die in een raket te plaatsen die naar de rode planeet vliegt.

Het watervalmodel leeft nog volop!

In feite is het veel populairder dan je zou verwachten: de helft van alle projecten wereldwijd gebruikt deze ontwikkelmethode nog steeds.

Hoewel de opkomst van Agile de wereld voor veel projectmanagers beter heeft gemaakt doordat ze producten veel eerder kunnen lanceren en kunnen voortbouwen op de feedback van hun gebruikers, is de watervalmethode nog steeds een zeer waardevolle methode die je kunt inzetten voor projecten met beperkte flexibiliteit en een lage tolerantie voor fouten.

Ik hoop dat je onze bespreking van de watervalmethode interessant vond. Als je ook wat meer over Agile wilt lezen, kan ik het volgende aanraden:

• Onze gids over agile productmanagement.
• De verzameling beste praktijken voor agile portfoliomanagement.
• Onze samengestelde lijst met de beste tools voor agile productmanagement.

Dit zijn slechts drie van de vele gidsen en artikelen die we hebben over product- en projectmanagement. Abonneer je op onze nieuwsbrief voor meer informatie.