Het Waterfall Model (Watervalmodel) of de Waterfall (Waterval) is een designmethode waarbij de volgorde waarin de dingen gebeuren (sequentie) van belang is. Daarom noemt men het een sequentiële methode. Meer bepaald loopt de sequentie hier naar beneden, zoals bij een waterval. Doorgaans stroomt die als volgt:

• Conceptie;
• Initiatie;
• Analyse;
• Design;
• Constructie;
• Testen;
• Productie en implementatie;
• Onderhoud.

Als dusdanig speelt de Waterfall een grote rol in de (historische) positionering van software testen in de ontwikkelingsketen. Een goed begrip van dit model is dan ook voornaam voor een beter begrip van de software tests die u gaat ondernemen. Hieronder nemen wij daarom even de tijd om de Waterfall wat nader te introduceren.

Ontstaan van het Waterfall Model

Als ontwikkelingsmodel ontstaat de Waterfall in de fabrieks- en constructie-industrie. In deze uiterst hiërarchische, fysieke omgevingen wordt het aanbrengen van veranderingen ‘na de feiten’ almaar duurder en moeilijker, zo niet onmogelijk, naarmate het productieproces vordert. Dit creëert de noodzaak om zo vroeg mogelijk fouten vast te stellen en te herstellen.
Aangezien de softwareontwikkeling als jonge wetenschap niet over eigen methodes beschikte, werd deze ‘hardware’ benadering al snel overgedragen op de aanpak van software. Officieel mag Herbert D. Benington deze vondst op zijn naam schrijven. Hij bracht de Waterfall naar de software. Dat gebeurde op 29 juni 1956, tijdens een symposium over ‘geavanceerde programmeer methoden voor digitale computers’.

Voordelen van het Waterfall Model

De vondst van Benington is niet zonder rechten. Tijd is inderdaad nog steeds goedkoper in de vroege stadia van een productontwikkeling, ook wanneer het software betreft. De factor van vermenigvuldiging kan daarbij zelfs oplopen tussen 50 en 200. Hoe later een fout gevonden wordt, hoe duurder hij dus wordt.
In de praktijk blijft het Waterfall Model alleen al daarom nog steeds relevant. Het bepaalt nog steeds grotendeels de tijdverdeling van een gemiddeld project. Hierbij gaat 20 tot 40% van de tijd naar de eerste ontwikkelingsfases, 30 tot 40% wordt besteed aan codering, en de rest van de tijd wordt geïnvesteerd in testen en implementeren.
Het model noopt zo ook meteen tot een erg strikte timing en structurering van het werkproces. Bovendien legt het veel nadruk op de aanwezigheid van juiste documentatie en het gebruik van consequente broncode. Dit kan voornaam zijn om onderweg geen kennis te verliezen, bijvoorbeeld door personeelswissels.

Kritiek op het Waterfall Model

De strikte methodologie van het Waterfall Model blijft echter ook vaak een ideaaltype. Strikt gezien is het model hooguit toepasbaar bij eindproducten die stabiel zijn, aan vaste eisen moeten voldoen een vaste doelen moeten bereiken. Het zal duidelijk zijn dat dit niet altijd het geval is voor softwareontwikkeling of -beheer, laat staan voor software testen. Hier kan het namelijk gebeuren dat men nog niet alle eisen en doelen kent wanneer men ze ontwikkelt. Veranderende eisen en doelen leiden bovendien tot het herzien van ontwerp en ontwikkeling, leidend tot nieuwe testen.
Om deze en andere problemen te counteren werden al snel verschillende modificaties van het Waterfall Model geïntroduceerd, zoals de Sashimi, een Waterfall waarin de verschillende fases elkaar overlappen. Ook bestaan er modellen die gebruik maken subprojecten of die zich concentreren op risicobeperking.

Het Waterfall Model en software testen

Het is deze laatste soort van gemodificeerde, flexibele watervallen die het meest relevant zijn wanneer het aankomt op de (hedendaagse) positionering van software testen in het grotere software ontwikkelingsproces. Feedback tussen fasen is misschien zelfs wel de voornaamste functie en techniek van het testen. Bovendien gebeurt software testen sowieso op meerdere niveaus en met verschillende doelen. Software testers in ontwikkeling testen de werking van een programma, het gebruiksgemak, de gebruikersinteresse… Software testers in beheer testen de gevolgen van software op de werkomgeving (en omgekeerd). De Waterfall kan dan moeilijk strikt worden toegepast (praktisch noch theoretisch). Wel helpt deze beproefde methode om het (test-)proces in zijn geheel zo te organiseren dat maximale efficiëntie en kostenreductie wordt bereikt.

Wilt u weten of de waterfall methode wat voor uw organisatie is? Neem dan contact met ons op.