Watervalmethode: de uitleg

Watervalmethode: in dit artikel wordt de watervalmethode praktisch uitgelegd. Naast de uitleg van wat deze methode is, wordt ook de oorsprong toegelicht, de fasen, de Watervalmethode versus Agile, enkele voorbeelden uit de praktijk, voordelen en nadelen en kritiek op de de Watervalmethode. Na het lezen begrijp je de basis voor deze krachtige tool voor softwareontwikkeling, internet technologie en project management. Veel leesplezier

Wat is de watervalmethode?

De watervalmethode is een projectbenadering waarbij het project opgesplitst wordt in lineaire opeenvolgende fasen.

Elke fase moet met goed gevolg worden afgesloten voordat de volgende fase gestart kan worden. De methode wordt vaak ingezet bij projecten met een technisch ontwerp en is een vorm van Systems Development Life Cycle (SDLC).

Indien toegepast in softwareontwikkeling is het model een iteratieve en flexibele benadering waarbij de voortgang, zoals het water van een waterval, grotendeels in een enkele neerwaartse stroom door de fasen gaat.

De fasen zijn conceptie, initiatie, analyse, ontwerp, constructie, testen, implementatie en onderhoud.

De watervalmethode is het eerste procesmodel (SDLC) dat werd geïntroduceerd. Oorspronkelijk is de watervalmethode ontstaan in de bouwsector. Zeer gestructureerde en fysieke omgevingen zorgden ervoor dat ontwerpwijzigingen tijdens het bouwen resulteerden in torenhoge kosten.

Toen daarna de vraag naar software toenam, was er nog geen erkent alternatief voor het managen van deze projecten. Tegenwoordig bestaan er enkele zeer goed ontwikkelde alternatieven, zoals Rapid Applicatie Ontwikkeling (RAD), Joint application development (JAD), Agile Project Management (APM) en het spiraalmodel.

Oorsprong watervalmethode

De eerste formele introductie en beschrijving van de watervalmethode wordt toegekend aan een artikel van Winston W. Royce in 1970.

Royce zelf gebruikt echter het woordje waterval nog niet. De term waterval werd voor het eerst gebruikt in 1976 in een artikel van Bell en Thayer. Vanaf 1985 adapteerde bijvoorbeeld het Amerikaanse Ministerie van Defensie de methode voor hun contractanten die werken aan software.

De fasen van de watervalmethode

In het originele model van Royce werden de volgende fasen beschreven.

Figuur 1 – de fasen van de watervalmethode

1. Systeem en softwarevereisten

De eerste fase omvat het begrijpen van wat er precies moet worden ontwikkeld, wat het doel is, de functie enz. Het is in deze fase dat de vereisten, deadlines, richtlijnen en andere zaken worden vastgesteld. Het resultaat is meestal een document waarin de vereisten zijn opgenomen (Requirements Understanding Document).

• Vereisten vaststellen
• Brainstormen
• Levensvatbaarheidstest

2. Analyse

De informatie gewonnen in de eerste fase wordt hier gebruikt om productmodellen en logica te genereren. Dit is zeer belangrijk voor de sturing van de productie.

Ook aan het einde van deze fase wordt een haalbaarheidstest gedaan. Dit is van toepassing op de financiële en technische middelen.

3. Design

De derde fase is de designfase. In deze fase worden de specificaties uit de eerste fase bestudeerd en wordt het systeemontwerp voorbereid.

Het systeemontwerp helpt bij het vaststellen van systeem- en hardware vereisten. Daarnaast helpt het bij het definiëren van de algemene systeemarchitectuur.

Deze fase moet worden afgesloten voordat verder gegaan kan worden naar de coderingfase. De code die in de volgende fase ontwikkeld wordt, wordt in feite nu voorbereid. Het resultaat van deze fase is een High Level Design Document (HLD), of een Low Level Design Document (LLD).

• Designontwerp in overweging van alle vereisten
• Systeemvereisten vaststellen
• Designs documenteren

4. Codering

In de vierde fase wordt de code ontwikkeld aan de hand van de productmodellen, logica en vereisten uit de vorige fasen.

5. Testen

Nadat de codering is voltooid, wordt het systeemontwerp getest. Dit is om ervoor te zorgen dat er geen fouten in het systeem optreden wanneer de klant het in gebruikt neemt.

Er wordt afhankelijk van het project een verscheidenheid aan test toegepast. Denk hierbij aan kwaliteitsborging, systeemtests, betá-tests of eenheidstesten.

Als het systeem alle tests doorstaan, gaat de waterval verder naar beneden. Het resultaat van deze fase is doorgaans een testrapport, maar bestaat in sommige gevallen ook uit een gebruikersacceptatietest, oftewel User Acceptance Test (UAT). Hierbij wordt het systeem uitgeprobeerd door een groot gebruikers voordat het systeem voor het grote publiek beschikbaar komt.

• Integreren van codes
• Testactiviteiten
• Rapporteren bij afwijkingen
• Voortgang bijhouden

6. Implementatie (installatie, migratie, support en onderhoud)

De laatste fase bestaat uit het installeren, verhuizen en onderhouden van de nieuwe software(componenten). Implementatie kan op verschillende manier gebeuren.

Soms worden eerste kleinere eenheden geïntegreerd in een bestaand systeem. In dat geval is elke unit individueel getest en ontwikkeld. Dit wordt ook wel Unit Testing genoemd.

Zodra de functionele en niet-functionele tests uit de vorige fase met goed gevolg zijn afgesloten, wordt het product in de klantomgeving gebracht.

Hoewel door het testen fouten en bugs voorkomen worden, is onderhoud van het systeem wel gewenst. Onderhoud omvat in deze fase het aanbrengen van kleine wijzigingen aan het systeem of aan kleine onderdelen van het systeem om de prestaties te verbeteren.

Deze wijzigingen zijn ofwel het gevolg van klantverzoeken, ofwel van de systeemontwikkelaars. Het resultaat van deze fase is doorgaans een gebruikershandleiding.

Watervalmethode vs. Agile

Hoewel beide methoden worden toegepast in projectmanagement, is de watervalmethode zeer verschillend van een Agile benadering voor projectmanagement. Als eerste is Agile een continue cyclus en bestaat de watervalmethode uit sequentiële fasen.

De focus van de watervalmethode ligt op de ontwerpfase van het project, terwijl bij de Agile methode juist weinig tijd wordt gespendeerd aan de ontwerpfase.

De watervalmethode vereist daarnaast veel langere periodes voor het bouwen en testen van nieuwe softwarecomponenten dan Agile. Een van de krachten van de Agile methode is dat software constant getest en ontwikkeld wordt gedurende het project.

Zoals besproken is de watervalmethode een methodologie waarin het starten van een nieuwe fase afhankelijk is van de taken die moeten worden voltooid uit de vorige fase.

Voordat een fase volledig is afgerond, kan en mag er geen nieuwe fase gestart worden. Waar met de watervalmethode de resultaten als een rechte stroom naar beneden gaat, wordt Agile gezien als een beweging waarin een groot aantal afgeleide methoden worden toegevoegd die de waarden van de Agile methode en flexibiliteit optimaal benutten.

De watervalmethode is ideaal om in te zetten bij projecten die een verscheidenheid aan afhankelijkheden tussen taken en acties bevatten.

De Agile methode past beter bij projecten waarin de klant niet zeker is over het gewenste resultaat of afhankelijk is van toekomstfactoren.

Over het algemeen kennen Agile-projecten een kortere levertijd dan watervalprojecten. Bij het kiezen tussen verschillende methoden moet er een afweging gemaakt worden tussen kwaliteit en snelheid.

Voorbeelden watervalmethode

Tot de eeuwwisseling werd de methode voornamelijk gebruikt voor de ontwikkeling van software. Zelfs na de publicatie van het Agile-manifest in 2001 werd de watervalmethode door veel organisaties nog steeds gebruikt.

Tegenwoordig is de watervalmethode maar weinig populair. Vaak volgen projecten een Agile benadering, of een ander iteratief model, afhankelijk van de projectvereisten.

Succesvolle watervalmethode-projecten

Nadat de watervalmethode was geïntroduceerd voor de bouwsector, duurde het enige tijd voordat het werd aangenomen in het bedrijfsleven. Als eerste werd de methode gebruikt om bedrijfsapplicaties te ontwikkelen, zoals Customer Relationship Management (CRM)-systemen, Human Resource Management (HRM)-systemen, Supply Chain Management-systemen, Inventory Management Systemen en salessystemen voor winkels en groothandels.

Voor- en nadelen van de watervalmethode

Het gebruik van de watervalmethode kent enkele voordelen ten opzichte van andere projectbenaderingen.

Voordelen van de watervalmethode

• De methode is eenvoudig en gemakkelijk te begrijpen en in te zetten;
• Voor kleinere projecten werkt de watervalmethode goed en levert het kwalitatief goede resultaten;
• De watervalmethode is een benadering die relatief makkelijk te managen is omdat de fases een voor een worden uitgevoerd;
• De criteria voor zowel de entry als de exit van het project zijn goed gedefinieerd, dus is het makkelijker om goede kwaliteit te waarborgen;
• Resultaten en voortgang worden met de watervalmethode nauwkeurig gedocumenteerd;
• De watervalmethode versterkt goede coderingsgewoonten door deze vooraf te definiëren;
• De watervalmethode definieert duidelijke mijlpalen en deadlines;
• De watervalmethode vergemakkelijkt managementcontrole op basis van planning en deadlines.

Nadelen watervalmethode

Vanzelfsprekend kent het gebruik van de watervalmethode ook enkele nadelen ten opzichte van andere projectbenaderingen.

• Het design van de watervalmethode is niet adaptief. Als er een fout wordt gevonden in een latere fase moet het gehele proces opnieuw beginnen. Dit is tijdrovend en duur;
• De watervalmethode negeert de mogelijkheid om halverwege het ontwikkelproces de feedback en input van gebruikers en klanten te ontvangen en verwerken;
• De watervalmethode begint niet met testen tot het einde van het gehele proces;
• De watervalmethode houdt geen rekening met het corrigeren van fouten;
• De watervalmethode vermindert efficiëntie door processen niet te laten overlappen;
• Pas aan het einde van het ontwikkelproces is een eerst werkend product beschikbaar;
• De watervalmethode is minder geschikt voor complexe en risicovolle projecten.

Kritiek op de watervalmethode

Een groot nadeel van de watervalmethode is dat klanten niet precies weten wat en hoe er ontwikkeld wordt, en dus wanneer hun vereisten veranderen, het complete project een herontwerp nodig heeft, herontwikkeling, nieuwe tests en hogere kosten.

Aan de andere kant zijn de ontwerpers die aan het systeem werken zich mogelijk niet helemaal bewust van toekomstige problemen bij het ontwerpen van een softwaresysteem.

In dat geval is het beter om een nieuwe product te ontwerpen dan te volharden in een ontwerp dat geen rekening houdt met nieuwe beperkingen, vereisten of problemen.

Een manier om dit aan te pakken is door systeemanalisten in te zetten. Bij analyseren bestaande systemen om vast te stellen hoe deze kunnen worden vervangen of ontwikkeld.

In de praktijk is het echter zeer moeilijk om systeemanalyse en programmering van elkaar te scheiden. Dat komt omdat het implementeren van een systeem bijna onvermijdelijk leidt tot problemen die de analist vooraf niet in overweging heeft genomen.

Als reactie op bovenstaande kritiekpunten, werden aangepaste watervalmethoden geïntroduceerd. Voorbeelden hiervan zijn Sashimi (waterval met overlappende fasen), watervalmethoden met deelprojecten en watervalmethoden waarbij de nadruk gelegd wordt op risicovermindering.

Sommige organisaties hechten nog steeds veel waarde aan watervalmethode, zoals het Amerikaanse Ministerie van Defensie. Dit is met name omdat het controlelevel hoger is dan bij projectbenaderingsalternatieven.

Voorstanders van flexibele systeemontwikkeling beweren dat de watervalmethode zeer ineffectief is voor het ontwikkelen van software. Anderen beweren dat de watervalmethode puur wordt gebruikt om alternatieve ontwikkelingsmethoden op de markt te brengen voor commercieel gewin.

Een hybride, vergelijkbare vorm van softwareontwikkeling is de methode van het Rational Unified Process (RUP). Deze methode erkent de behoefte en noodzaak van mijlpalen in een project om het op schema te houden, maar moedigen tegelijkertijd iteratief aan binnen verschillende fases. Deze methode wordt ook wel waterval-achtig genoemd.

Samenvatting watervalmethode

De watervalmethode is een projectbenadering voor systeem- en ontwerpprojecten. De methode is opgesplitst in vijf fasen, waarbij elke fase moet zijn afgerond voordat het team begint met de volgende fase.

Een alternatieve term voor het managen van dit soort projecten is de Systems Development Life Cycle (SDLC).

De eerste fase bestaat uit het verzamelen van systeemvereisten. Het resultaat is een document waarin alle vereisten zijn opgenomen.

Daarna begint het projectteam met de analyse van deze vereisten om productmodellen en logica te genereren. Aan het einde van deze fase wordt een haalbaarheidstest gedaan.

In de derde fase vind de designspecificatie plaats. Het volledige design wordt in overweging genomen met integratie van alle vereisten.

In de daaropvolgende fase wordt gewerkt aan de codering van het nieuwe systeem. Nadat de codes voltooid zijn wordt het systeem getest, waarna het geïmplementeerd en onderhouden wordt.

In tegenstelling tot Agile benaderingen, is de watervalmethode een sequentieel proces. Dat wil zeggen dat er geen overlap bestaat tussen de verschillende fasen. Hoewel dit volgens sommigen leidt tot inefficiënties, vertragingen en extra kosten, zijn er ook bedrijven en organisaties die de voorkeur geven aan de watervalmethode.

Dit gaat met name over organisaties en projecten waarin controle een belangrijke rol speelt. Een ander kritiekpuntje is het feit dat met de watervalmethode de klant een zeer geringe rol speelt.

Het is pas aan het einde van het volledige ontwikkelproces dat de klant voor het eerst informatie en handleidingen krijgt over het nieuwe systeem. Indien het systeem dan herzien moet worden, bestaat de kans dat het gehele proces opnieuw uitgevoerd moet worden.

Om dit risico te beperkingen gebruiken veel projecten een hybride vorm van de watervalmethode en de Agile methode. Een voorbeeld hiervan is het Rational Unified Process (RUP). Deze methode integreert in tegenstelling tot de watervalmethode wel mijlpalen en iteratieve processen.

Nu is het jouw beurt

Wat denk jij? Herken jij de uitleg over de watervalmethode? Heb jij al eens aan een project gewerkt waarin de watervalmethode werd toegepast? Wat zijn jouw ervaringen met de watervalmethode? Met welke projectbenadering werk jij het liefst? Wat zijn volgens jou voor- en nadelen van deze methode? Heb jij tips of opmerkingen?

Deel jouw kennis en ervaring via het commentaar veld onderaan dit artikel.

Meer informatie

1. Alshamrani, A., & Bahattab, A. (2015). A comparison between three SDLC models waterfall model, spiral model, and Incremental/Iterative model. International Journal of Computer Science Issues (IJCSI), 12(1), 106.
2. Balaji, S., & Murugaiyan, M. S. (2012). Waterfall vs. V-Model vs. Agile: A comparative study on SDLC. International Journal of Information Technology and Business Management, 2(1), 26-30.
3. Laplante, P. A., & Neill, C. J. (2004). The demise of the waterfall model is imminent. Queue, 1(10), 10-15.

Citatie voor dit artikel:
Janse, B. (2020). Watervalmethode. Retrieved [insert date] from Toolshero: https://www.toolshero.nl/informatie-technologie/watervalmethode/

Oorspronkelijke publicatiedatum: 30/11/2020 | Laatste update: 09/10/2023

Wilt u linken naar dit artikel, dat kan!
<a href=”https://www.toolshero.nl/informatie-technologie/watervalmethode/”> Toolshero: Watervalmethode</a>

Article by:

Ben Janse

Ben Janse is een young professional en werkzaam als Content Manager bij Toolshero. Daarnaast houdt hij zich binnen zijn studie International Business aan de Hogeschool Rotterdam bezig met het analyseren en ontwikkelen van managementmodellen. Dankzij zijn theoretische en praktische kennis weet hij hoofd- en bijzaken goed te onderscheiden waardoor de essentie van elk artikel goed naar voren komt.