Sharing IT Best Practices with youSharing IT Best Practices with you
Waterval methode
Het waterval ontwikkelmodel is een manier om software te ontwikkelen volgens een lineaire methode. Project managers zien deze methode vaak als de klassieke aanpak voor de levenscyclus en ontwikkeling van applicaties.
De watervalmethode is een opeenvolgend model, dat we gebruiken om verschillende soorten software te creëren. De projectmanager deelt de werkzaamheden op in fases die elkaar stroomafwaarts opvolgen (zoals een waterval). De globale verdeling van de ontwikkeling over de fases is als volgt: 1. requirements analyse, 2. Ontwerp, 3. software implementatie, 4. project verificatie en 5. software onderhoud.
Er zijn verschillende varianten van de waterval methodiek waarbij de daadwerkelijke verdeling van de werkzaamheden over de fases kan verschillen. Het proces zelf kan de projectmanager weer in verschillende subfases verdelen. Dit is afhankelijk van het IT-project of andere ontwikkelingseisen.
Het hoofdgedachte achter het watervalmodel is dat softwareontwikkeling op een gecontroleerde manier van de ene fase naar de volgende fase gaat. De informatie-analisten stellen bijvoorbeeld eerst de requirements op. Als deze deze volledig zijn vastgelegd, gereviewd en goedgekeurd, gaat het ontwerp-team verder naar de ontwerpfase, enzovoort.
In het watervalmodel betekent dit dat de programmeurs pas aan hun fase kunnen beginnen als de vorige fase is voltooid en alles is goedgekeurd.
Het belangrijkste voordeel van de waterval methode is dat de afdelingen en de project managers het proces onder controle kunnen houden. In de praktijk maken we een schema met deadlines voor elke fase van de projectontwikkeling en kan een project voortgaan volgens het gecreëerde schema.
Het volgende argument voor het waterval ontwikkelingsmodel is dat het solide eisen stelt op de projectdocumentatie (ontwerpen en requirements), evenals aan de broncode. Als een van de teamleden het project verlaat, gaat er minder kennis verloren dan bij een project dat volgens een methode waarbij er minder gedocumenteerde ontwerpen maken.
Het watervalontwikkelingsmodel impliceert dat er een volledig uitgewerkt ontwerpdocument aanwezig moet zijn. Zodoende kan een nieuw teamlid of zelfs een heel nieuwe team het project gemakkelijk overnemen door de documenten te lezen.
De OTAP omgeving (Ontwikkel, Test, Acceptatie en Productie) is gebaseerd op het watervalmodel. Deze omgeving sluit nauw aan op de procedures van deze methode. Iteratieve en incrementele werkprocessen zoals Agile Scrum werken in kleinere stappen maar sluiten ook aan op OTAP voor de borging van de kwaliteit van de deliverables.
In de praktijk resulteren watervalmethoden in het volgende projectschema:
De projectorganisatie moet zeer gestructureerd zijn. Middelgrote en grote projecten bevatten een gedetailleerde reeks aan procedures en controles, die elk proces van het project regelen.
In theorie leidt dit proces ertoe dat we het project op tijd kunnen opleveren volgens een gedetailleerd plan dat voor elke fase is gemaakt.
In de praktijk is het vaak onmogelijk om het pure watervalmodel te volgen. Dat komt omdat het geen rekening houdt met de onvermijdelijke veranderingen en herzieningen die nodig zijn tijdens het ontwikkelingsproces. Ook voeren veel specialisten aan dat het watervalmodel in de praktijk slecht werkt. De reden is doorgaans de onmogelijkheid om een deliverable te perfectioneren nadat een volgende fase is gestart.
Gebruikers zijn bijvoorbeeld niet zeker van welke requirements ze precies nodig hebben. Pas als ze een werkend prototype zien en erop kunnen reageren voelen ze zich zekerder. Zij kunnen hun verwachtingen constant veranderen na het zien van een oplevering. Project managers hebben hier weinig of geen controle over. Als gebruikers hun requirements veranderen nadat het ontwerp is afgerond, moeten we dat document aanpassen om aan de nieuwe eisen te voldoen.
Ook kan het gebeuren dat ontwerpers zich bij het ontwerpen van nieuwe software niet bewust zijn van toekomstige implementatie- of programmeerproblemen. Tijdens het programmeren kan het bijvoorbeeld duidelijk worden dat bepaalde functionaliteit buitengewoon moeilijk te realiseren is.
In zo’n situatie is het beter om het ontwerp aan te passen in plaats van door te gaan met het gebruiken van een ontwerp dat is gebaseerd op onjuiste aannames en dat geen rekening houdt met de nieuw ontdekte problemen. Dit is een van de redenen waarom we de waterval methodiek niet gebruiken voor de iteratieve aanpak zoals Agile Scrum software-ontwikkeling.
Het belangrijkste risico van het waterval ontwikkelingsmodel is de kans dat we een verkeerde ontwerpbeslissing niet ontdekken tot de laatste fase van testen.
De kans dat dit gebeurt zal toenemen als de duur en de omvang van het project oplopen. Zelfs bekwame IT professionals maken simpele fouten. Gezien het strakke tijdschema van de methodiek, ontdekken we fouten in het ontwerp of de requirements te laat. Soms pas als we na een half jaar programmeren het systeem gaan testen.
Het watervalmodel in zijn pure vorm kunnen we succesvol gebruiken voor projecten waar alle requirements vooraf bekend zijn en niet zullen veranderen tijdens het project.
Bij de ontwikkeling van mobiele games worden alle requirements bijvoorbeeld gewoonlijk beschreven en geperfectioneerd voordat het project begint. Daardoor kan het ontwikkelteam volgens het pure watervalmodel werken. Het waterval model niet het beste model om mee te werken. Zelfs als er maar een kleine kans is dat er niet-ingevulde requirements zijn.
Discussieer mee op LinkedIn.
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.