Ontwikkelmethoden

Veel organisaties hebben moeite om hun softwareontwikkeltrajecten binnen tijd en budget af te ronden. Eén van de verklaringen die in de literatuur wordt genoemd is het gebruik van een verkeerde ontwikkelmethode. Een softwareontwikkelmethode wordt gebruikt om het ontwikkelproces systematisch aan te pakken. Alle softwareontwikkelingsmethoden maken daarbij gebruik van de vier basisstappen in softwareontwikkeling; specificeren, ontwerpen, programmeren (bouwen) en testen. De methoden verschillen doordat zij de verschillende stappen anders vorm geven. Of omdat de verschillende methoden meer een iteratief of planmatig karakter hebben.  

Watervalmethode

De Watervalmethode is gebaseerd op het beeld van een waterval. Je kunt niet terugkomen op eenmaal genomen stappen. De stappen volgen op elkaar en het proces wordt van boven naar beneden doorlopen. De Watervalmethode kent de volgende stappen: Na elke stap wordt er doorgegaan met de volgende stap. Net als bij het bouwen van een huis wordt er na het bouwen van de muren niks meer gedaan aan de fundering. Als er geen iteratie in de planning is opgenomen kan er in principe niet meer teruggegaan worden naar een eerdere stap om fouten te verbeteren. Nadelen van deze methode is dat het lang duurt voor er resultaten zichtbaar zijn, en als ze dan zichtbaar zijn, zijn ze moeilijk te herstellen. Het is een goede methode als de (interne)klant / gebruiker in de analyse goed kan vertellen wat ze wil. 

V-model

Het V-model is een goed voorbeeld van een watervalmethode. In het V-model worden de faseovergangen binnen softwareontwikkeling goed weergegeven. Deze faseovergangen bieden een mogelijkheid voor kwaliteitsborging. Voor iedere faseovergang worden door de leverende partij en ontvangende partijen afspraken gemaakt over de kwaliteit (van bijvoorbeeld de ontwerpen).

• Functionele projectteam; bij het V-model (en de watervalmethode) is sprake van een functionele indeling van het projectteam. Er is een team die de ontwerpen maakt, een team dat aan het bouwen/programmeren is en een team dat aan het testen is. Als de bouwers klaar zijn leveren ze de gemaakte software(componenten) met bijbehorende documentatie op aan het testteam die er vervolgens mee aan de slag gaat. Etc..
• Opdrachtgever / opdrachtnemer; het V-model geeft de taak en verantwoordelijkheid van de opdrachtgever (VRAAG) en de opdrachtnemer (AANBOD) duidelijk weer. De opdrachtgever specificeert de opdracht en accepteert het geleverde product. De opdrachtnemer, de IT-organisatie of een externe leverancier, ontwikkelt en test de programmatuur. 

Zoals gezegd is het nadeel van deze methode dat het lang duurt voor er resultaten zichtbaar zijn. En mochten de specificaties in de tijd wijzigen of mocht blijken dat er iets niet goed is gegaan dan duurt het lang voordat er een nieuwe oplevering wordt gedaan. Met als gevolg een lange doorloopijd van het project. Maar in een stabiele omgeving kan het V-model wel degelijk een toegevoegde waarde hebben. Op de pagina Software ontwikkelmethoden worden criteria opgesomd op basis waarvan de juiste ontwikkelmethode kan worden gekozen.