EEN watervalmodel , is het zesfasenmodel een watervalmodel. Met andere woorden, de stadia vinden opeenvolgend plaats. Net zoals stroomopwaarts zwemmen tegen een waterval onmogelijk is, sluit de pure watervaltechniek uit om terug te keren naar een fase nadat deze is afgelopen.
Het is niet ideaal om tijdens de uitvoeringsfase te besluiten het ontwerp te wijzigen en zo de uitvoering stil te leggen. De watervalbenadering is om verschillende redenen vaak minder geschikt voor softwareontwikkelingsprojecten.
- Softwareontwikkeling is een artistieke onderneming; het is vrijwel moeilijk om op alle behoeften (functionaliteiten) te anticiperen.
- Het inschatten van de tijd die nodig is om een functie te ontwikkelen is een hele uitdaging.
- Gedurende de levenscyclus van het project moeten gebruikers in staat zijn om alle tussentijdse resultaten te testen.
Softwareontwikkeling is een artistieke onderneming #
Voor niet-ingewijden lijkt softwareontwikkeling meer te gaan over engineering dan over uitvindingen. Het heeft echter op een aantal manieren betrekking op uitvinden. Tijdens het scheppingsproces weet men nooit precies wat er zal gebeuren.
De ontwerpers en programmeurs die verantwoordelijk zijn voor het ontwikkelen van nieuwe software moeten met antwoorden komen op de vraagstukken die hen worden voorgelegd. Ongeacht de vele technieken en voorschriften voor werk, is het maken van computercode nog grotendeels onbekend en daardoor onvoorspelbaar. Programmeurs kunnen kiezen uit miljoenen oplossingen die zijn geschreven in tientallen programmeertalen en die werken op duizenden verschillende hardwarecombinaties en softwareplatforms. Hoewel deze flexibiliteit veel voordelen heeft, maakt het het project ook uitdagender om te beheren dan meer conventioneel project management (zoals bouw- of bouwprojecten).
Implementatie instellen #
De watervalbenadering vereist dat eisen worden gedefinieerd als gevolg van de de bepalende fase van het project . Idealiter zou er voor de rest van het project een minimale extra afwijking van deze criteria moeten plaatsvinden. De watervalbenadering van softwareontwikkeling vereist een initiële inzet van aanzienlijke inspanning bij het analyseren van de vereiste functionaliteit (vereisten). Dit resulteert in een functioneel ontwerp (zie I voor meer informatie over functioneel ontwerpen). De software architect maakt gedurende het gehele ontwerpproces een technisch ontwerp met het functionele ontwerp als referentie. Verder geeft het technisch ontwerp instructies voor het uitvoeren van de vereiste functionaliteit.
Hoewel dit een eenvoudig probleem lijkt, kunt u het volgende scenario overwegen. Als onderdeel van een project wordt een nieuw voertuig ontwikkeld. Als actieve automobilist heb je de taak om automotive behoeften te ontwikkelen. Je overlegt met andere automobilisten en stelt een uitputtende lijst op:
- De auto moet plaats bieden aan vier personen;
- De auto moet een stuur aan de linkerkant van de bestuurder hebben; • De auto moet een rempedaal, een gaspedaal en een handrem hebben.
- De koplampen van de auto moeten wit zijn en de achterlichten moeten rood zijn. (uiteraard zou de echte lijst enorm zijn)
Ontwerp en modellering #
De ontwerpers maken een nieuw ontwerp met uw lijst als richtlijn, die vele maanden later wordt opgesteld. Als je door de straat loopt, zie je dat er een voertuig tot stilstand is gekomen. Je realiseert je dat je remlichten van je lijst hebt weggelaten! Je neemt snel contact op met de monteur van de autofabrikant, die bijna barst van je telefoontje. U beweert dat het een kleine aanpassing is. Het is echter een ramp voor autofabrikanten. Reeds geproduceerde auto’s moeten volledig worden gedemonteerd, de kabels van de rempedalen naar de achterkant moeten worden verlengd, de achterkant van het voertuig moet volledig opnieuw worden ontworpen om op de remlichten te passen, en reeds vervaardigde kofferklepluiken moeten worden gesloopt, en de lijst gaat maar door.
Hoewel het bovenstaande scenario belachelijk lijkt, vertegenwoordigt het een bijna dagelijkse gebeurtenis in softwareontwikkeling. Programmeurs gaan er ten onrechte van uit dat de klanten, klanten of gebruikers van het product dat wordt gemaakt, precies begrijpen wat ze willen. Klanten geloven ten onrechte dat softwareontwikkelaars alles kunnen maken (en wijzigen) in de kortst mogelijke tijd. Dit is de belangrijkste oorzaak van onenigheid tussen consumenten en softwareontwikkelaars.
