Softwareontwikkelmethode

De oudste en tot nog toe misschien wel de meest gebruikte methode is de watervalmethode. Deze is gebaseerd op het beeld van de waterval, waarbij je moeilijk terug kunt. De stappen volgen op elkaar en het proces wordt van boven naar beneden doorlopen. Het werkt met de hoofdstappen: Ontwikkeling, test, acceptatie en productie. In detail is dat:

• Informatieanalyse; analyse van de vereisten, requirements analyse
• ontwerp / documentatie.
• programmeren, bouw of ontwikkelen
• testen
• trainen
• conversie (Dataconversie)
• "Go-Live" vaak via een Big Bang, soms gefaseerd.
• Post live support
• Gebruik / productie met kleine aanpassingen via Beheer

Deze methode is waarschijnlijk overgenomen uit de Bouwwereld. Er wordt bijvoorbeeld ook gesproken over het "bouwen van een systeem" en er zijn bijvoorbeeld software-architecten. Niet elke stap hoeft even uitgebreid uitgevoerd te worden. 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 in principe niks meer gedaan aan de fundering, tenzij men alsnog besluit er een extra verdieping op te zetten.

Deze methode werkt uitstekend als men net als in de bouw jarenlange ervaring heeft, als er jarenlang weinig verandert in de gebruikte methoden en technieken en de klanten dus vooraf goed weten wat de mogelijkheden en onmogelijkheden zijn. De IT is echter niet de bouw. 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. Een van de 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 uitstekende methode als de (interne)klant / gebruiker net als bij een woningbouwproject in de analysefase goed kan vertellen wat ze wil, maar als men nog vrij laat zaken wil wijzigen is het minder geschikt. Een ander nadeel is dat het lang duurt voor het systeem opgeleverd wordt waardoor soms de situatie al zodanig is veranderd dat het systeem niet (meer) nodig is. Hiervoor zijn overigens wel gedeeltelijk oplossingen gevonden zoals het gebruik van prototyping om de wensen duidelijker boven tafel te krijgen. Ook het grote gebruik van standaardpakketten, zoals bijvoorbeeld SAP R/3 beperkt het probleem van het zelf moeten (laten) programmeren. Eigenlijk zijn er niet meer zoveel systemen die op deze manier gebouwd worden.

• SDM
• Jackson System Development
• Bottom Up
• Top-Down Model
• V-model

Iteratieve ontwikkeling of iterative application development (IAD) omschrijft een methodiek om niet in een groot project alles op te leveren, maar in kleinere gedeelten steeds een deel op te leveren en dus de stappen van een project herhaaldelijk te doorlopen, om zo te voorkomen dat een (groot) project uitloopt in een mislukking door problemen of foute aannames. Iteratieve methoden hebben de voorkeur bij een klant die niet precies kan omschrijven wat zij wil. Een oud voorbeeld van een iteratieve methode is rapid application development, dit is een voorloper van de agile softwareontwikkelingsmethoden.

Agile softwareontwikkelingsprocessen zijn gebaseerd op de grondbeginselen van iteratief ontwikkelen. Boven op deze basis hebben ze een meer op mensen gerichte blik dan traditionele aanpakken. Agile processen gebruiken feedback in plaats van planning als basis. De feedback wordt geleverd door het regelmatige opleveren van resultaten en het bespreken van het proces, waardoor het team leert van successen en steeds beter wordt.

Extreme Programming (XP), Scrum, Adaptive Software Development en Dynamic Systems Development Method (DSDM) zijn de bekendste agile-methoden.

Formele methoden zijn wiskundige aanpakken om soft- en hardware problemen op te lossen op het niveau van requirements, specificaties en ontwerpen. Voorbeelden van enkele formele methodes zijn petrinetten en Value driven maintenance (VDM).

• Feature Driven Development
• Rational Unified Process (RUP)
• Spiraalmodel
• Test-Driven Development