Watervalmethode

De watervalmethode is een methode voor softwareontwikkeling (een proces voor de verwezenlijking van software), waarin de ontwikkeling regelmatig vloeiend naar beneden loopt (als een waterval). De ontwikkeling loopt door een aantal fasen, namelijk: definitiestudie/analyse, basisontwerp, technisch ontwerp/detailontwerp, bouw, testen, integratie en beheer en onderhoud. Met deze methode hoopten de informaticabedrijven meer duidelijkheid te krijgen in hun software-projecten.

Het watervalmodel is afgeleid van de traditionele manier van werken in grote projecten in de constructiebouw. De bedoeling van deze manier van werken is dat het project in verschillende fasen wordt opgedeeld. Men start met fase 1 en begint niet eerder met fase 2 dan wanneer fase 1 is afgesloten. En wanneer in een van de fasen een fout ontdekt wordt, gaat men helemaal terug om die fase te corrigeren en de daaropvolgende stappen opnieuw uit te voeren.

Geschiedenis van de watervalmethode

Over de oorsprong van de term "waterval" wordt vaak gezegd dat Winston W. Royce deze in 1970 introduceerde, maar Royce zag zelf meer in de herhaalde benadering voor softwareontwikkeling en gebruikte zelf niet de term "waterval". Royce beschreef het watervalmodel als een methode die hij gewaagd en zelfs een uitnodiging voor mislukking vond.

In 1970 vond Royce dat de watervalmethode gezien moest worden als eerste concept, hij vond dat er in de methode nog fouten zaten. Hij bracht een document uit waarin onderzocht werd hoe het eerste concept tot een herhaalde methode doorontwikkeld kon worden, In dit nieuwe model zat tussen elke fase een terugkoppeling met de vorige fase, zoals we dat nu veel zien in de huidige methodes. Vervelend voor Royce kreeg alleen de aanvankelijke methode aandacht, de kritiek die hij had op deze methode werd grotendeels genegeerd.

Ondanks Royces intenties om de watervalmethode te veranderen in een herhaalde methode (iteratief model), is het gebruik van deze methode nog steeds zeer populair, maar de tegenstanders van de watervalmethode zien het als een naïeve en ongeschikte methode voor het gebruik in de "echte wereld".

Fasen

Het watervalmodel bestaat uit de volgende fasen:

• Definitiestudie/analyse. Er wordt onderzoek gedaan naar en gebrainstormd over de gewenste software om duidelijk te krijgen wat het doel ervan is, en wat de beperkingen en randvoorwaarden zijn.
• Basisontwerp (ook wel: functioneel ontwerp). Er wordt duidelijker uitgewerkt wat er tijdens de eerste fase naar boven is gekomen. In deze fase worden de wensen van de klant op papier gezet en wordt al gedacht aan de vorm van het programma. In deze fase wordt vastgelegd wat het op te leveren systeem moet doen.
• Technisch ontwerp/detailontwerp. Aan de hand van het basisontwerp kan er een werkelijk programma uitgedacht worden. In deze fase wordt vastgelegd hoe de in het basisontwerp vastgelegde functionaliteit gerealiseerd gaat worden. Nu vindt ook een onderverdeling plaats in technische eenheden zoals programma's, modules en functies.
• Bouw/implementatie. Hier wordt de broncode van de programma's geschreven.
• Testen. Er wordt gecontroleerd of de software goed volgens de ontwerpen is gebouwd. Ook kunnen er in deze fase fouten boven water komen die al in eerdere stadia gemaakt zijn.
• Integratie. Het systeem is klaar en getest. Toch zal het nog in het bedrijf in gebruik genomen moeten worden. Dat wordt gedaan in deze fase.
• Beheer en onderhoud. Om er voor te zorgen dat het systeem het blijft doen zal er onderhoud verricht moeten worden.

Het watervalmodel bestaat uit verschillende fasen. Iedere fase heeft een eigen niveau dat tevens de volgorde bepaalt. Het hoogste niveau wordt als eerste uitgevoerd en vervolgens de lagere fasen. Dit is gelijk aan de natuurlijke werking van een waterval en vandaar ook de naam. Hierboven is goed te zien dat de verschillende fasen van boven naar beneden lopen.

Pro en contra

Voordelen

• Wanneer in het begin van het project fouten worden ontdekt, kost het minder inspanning (en dus minder tijd en geld) om deze fout te herstellen. Bij het watervalmodel wil men alle fasen eerst goed afsluiten voordat men verdergaat met de volgende fase. Men gaat ervan uit dat de fasen altijd goed zijn voordat men verdergaat met een volgende fase.
• Bij het watervalmodel legt men de nadruk op documentatie. In de nieuwere softwareontwikkelingsmethoden maakt men minder documentatie. Dit heeft tot gevolg dat als er nieuwe mensen in het project opgenomen worden en er mensen weggaan het lastig is om de kennis over te dragen. Dit nadeel heeft de klassieke watervalmethode niet.
• Het is een rechttoe-rechtaan-methode. De manier van werken zorgt ervoor dat er zich concrete fasen vormen. Hierdoor weet men in welke fase men zit.
• Men kan in deze methode gebruikmaken van mijlpalen. Mijlpalen kunnen worden gebruikt om de voortgang van het project in te schatten.
• De watervalmethode is erg bekend. Veel mensen hebben er ervaring mee, dus kunnen er gemakkelijk mee gaan werken.

Nadelen

Er zijn een aantal nadelen aan deze manier om software te ontwikkelen.

• Veel softwareprojecten zijn afhankelijk van externe factoren. De opdrachtgever is een heel belangrijke externe factor. Vaak zullen de vereisten gedurende de loop van het project wijzigen, omdat de opdrachtgever iets anders wil. Het is dus een nadeel dat de watervalmethode ervan uitgaat dat de vereisten niet veranderen tijdens het project. Wanneer in de bouwfase een vereiste verandert, moet een groot aantal fases opnieuw doorlopen worden.
• Het is erg moeilijk om de benodigde tijd en de kosten in te schatten. De fasen zijn erg groot, het is daarom erg lastig om in te schatten hoeveel elke fase zal kosten.
• In een aantal nieuwe methoden zijn bijna alle aspecten van een softwareontwikkelingstraject opgenomen. Men kan denken aan planningstechnieken, projectmanagementmethoden en hoe de projectorganisatie ingericht moet worden.
• Bij veel softwareprojecten werken verschillende mensen aan de verschillende fasen van het project. Bijvoorbeeld: de ontwerpers en de bouwers. Ze hebben allemaal een andere kijk op het project: zo kijken ontwerpers anders tegen het project aan dan de bouwers. Omgekeerd zullen de bouwers ook vaak anders tegen het ontwerp van de ontwerpers aankijken dan de ontwerpers zelf. Vaak is het zo dat het ontwerp weer aangepast zal moeten worden. Hier is de watervalmethode niet voor gemaakt.
• Binnen het project zijn de verschillende teamleden vaak gespecialiseerd. Het ene teamlid zal zich alleen in de eerste fase bezighouden met het ontwerpen, terwijl de bouwers alleen in bouwfase helpen aan het bouwen van het project. Dit kan leiden tot verspilling van verschillende bronnen. De belangrijkste bron is wel de tijd. Een voorbeeld: de ontwerpers zijn bezig met het perfectioneren van het ontwerp. De bouwers kunnen in principe al beginnen met bouwen, maar omdat ze werken met het watervalmodel moeten ze wachten totdat de eerste fase is afgesloten. Dit is een typisch voorbeeld van tijdverspilling.
• Het testen gebeurt pas in een van de laatste fasen van het project. Bij veel andere softwareontwikkelingsmethoden wordt getest zodra er één bepaald deelproduct klaar is en ook wordt op het laatst een integratietest gedaan.
• Doordat er zoveel nadruk wordt gelegd op documentatie, is de watervalmethode niet efficiënt voor kleinere projecten. Er zit dan te veel werk om het project zelf heen qua documentatie.

Vernieuwde watervalmethoden

Om zo veel mogelijk gebruik te maken van de voordelen en zo weinig mogelijk last te hebben van de nadelen is er een aantal vernieuwde watervalmethoden ontwikkeld. Hieronder wordt er een aantal genoemd.

Model van Royce

Het model van Royce beschrijft dat het verkeerd is dat er bij de watervalmethode niet teruggegaan kan worden naar de vorige fase. Vaak zal er in een fase blijken dat er in een vorige fase iets verkeerd is gegaan, het moet dan mogelijk zijn om gemakkelijker naar een vorige fase terug te gaan.

Het "sashimi"-model

Schematisch overzicht van de sashimi-watervalmethode met overlappende fasen...

Het sashimi-model is opgezet door Peter Degrace. De fasen zijn hetzelfde als in het traditionele watervalmodel, alleen nu overlappen de fasen elkaar ook. Door gebruik te maken van deze methode worden er veel minder bronnen verspild. De afbeelding hiernaast geeft weer hoe de fasen elkaar overlappen. Dit is echter een illustratie en dit geeft dus niet de werkelijke overlapping weer qua verhouding. Het verschil met het schematische overzicht van de standaard watervalmethode is dat de fasen deze keer tegen de doorlooptijd afgedrukt zijn. Dit betekent dat men bijvoorbeeld al begint met het ontwerp terwijl de analyse nog bezig is. Dit betekent ook dat men terug kan vallen op de analyse in de ontwerpfase.

Aorta lifecycle-model

Het Aorta lifecycle-model is een vernieuwd model waarin na elke cyclus terugkoppeling wordt gegeven naar de klant.

V-model

Het V-model is een lineaire softwareontwikkelmethode waarbij evenwichtig aandacht aan ontwikkeling en verificatie besteed wordt.

Zie ook

• OTAP
• System Development Methodology
• Big Design Up Front
• Agile-software-ontwikkeling

Bronnen

• Dit artikel of een eerdere versie ervan is een (gedeeltelijke) vertaling van het artikel Waterfall model op de Engelstalige Wikipedia, dat onder de licentie Creative Commons Naamsvermelding/Gelijk delen valt. Zie de bewerkingsgeschiedenis aldaar.

Mediabestanden

Zie de categorie Waterfall models van Wikimedia Commons voor mediabestanden over dit onderwerp.