Dynamic Systems Development Method, of kortweg DSDM, is een (agile) methode voor het ontwikkelen van software.
De methode ontstond rond 1994 in het Verenigd Koninkrijk, als een leverancier-onafhankelijke methode, wat inhoudt dat er geen specifiek CASE tool of adviesbureau achter zit. In plaats daarvan zit er een consortium van geïnteresseerde bedrijven en individuen achter.
De eerste versie van DSDM kwam in februari 1995 uit, de tweede in december 1995, de derde in oktober 1997 en de huidige versie (4.2) dateert van mei 2003.
DSDM erkent dat projecten door tijd en resources beperkt worden en dat requirements aangepast kunnen worden. Verder wordt de 80/20 implementatieregel gehanteerd en wordt ervan uitgegaan dat niets de eerste keer perfect is. Dit betekent niet dat er een onvolledig product wordt afgeleverd, maar volgens het Pareto principe kan 80% van het totale werk gedaan worden in 20% van de totale tijd. In sommige gevallen is het mogelijk om best practices van andere softwareontwikkelmethoden te gebruiken zoals RUP of XP. Een agile methode die overeenkomsten heeft met de processen en het concept van DSDM is Scrum.
In de traditionele benadering van systeemontwikkeling staan de specificaties vast en moeten deze gerealiseerd worden. Tijd en resources variëren tijdens de ontwikkeling. DSDM is een methode die de ontwikkeling van IT-systemen vastlegt in een raamwerk van een tijdsplanning (timeboxes). De duur van het project en de te gebruiken resources worden vastgelegd. Dit betekent dat de specificaties die gerealiseerd zullen gaan worden, in het verloop van het project kunnen variëren. In het begin van het project worden op globaal niveau zowel de functionele als de niet-functionele specificaties ingedeeld op prioriteiten (MoSCoW). Tijdens de ontwikkeling komen steeds meer gedetailleerde specificaties boven water. Deze gedetailleerde specificaties worden vervolgens ook weer op basis van prioriteiten ingedeeld. Binnen deze tijdsplanning (timeboxes) worden in nauwe samenwerking met de klant eerst de zaken opgeleverd, die het belangrijkst zijn voor de bedrijfsbehoeften van de klant.
DSDM beoogt een ICT-project flexibeler te maken dan met de daarvoor veel gebruikte (traditionele) watervalmethode zoals SDM mogelijk is. Door het nieuwe systeem op te delen in zelfstandige eenheden, wordt het aanbrengen van tussentijdse veranderingen eenvoudiger voor de ontwikkelaar.
Een kenmerk van DSDM is dat het volledig onafhankelijk is van leveranciers, ontwerpmethodes en van ontwikkelomgevingen. Verder is het kenmerkend dat het in deze ontwikkelmethode heel belangrijk is dat de eindgebruiker zeer actief deelneemt aan het ontwikkelingsproces. De oplevering is opgedeeld in deelproducten. Het is dan vaak zo dat essentiële onderdelen van het nieuwe systeem gelijk al afgemaakt kunnen worden.
DSDM wordt gebruikt:
Veel systeemontwikkelingsprojecten blijken niet aan de verwachtingen van eindgebruikers te voldoen. Dit is te voorkomen door met name op de volgende zaken te letten:
DSDM heeft 9 basisprincipes. Dit zijn:
Het principe van timeboxing bepaalt dat een bepaalde tijd wordt gesteld, waarbinnen de ontwikkeling van een (deel van een) systeem moet gebeuren. Als deze tijd verstreken is, mag er geen tijd meer in worden gestoken, onafhankelijk van hoever het systeem is.
Timeboxing is de techniek die zorgt voor de tijdige oplevering en realisatie van het project. Binnen DSDM projecten is de opleverdatum gefixeerd en de productiecapaciteit is daardoor duidelijk te benoemen (op basis van beschikbare tijd en resources).
Timeboxing zorgt ervoor dat tijd en geld worden gefixeerd, en dat de functionaliteit wordt gevarieerd. Het managen van functionaliteit gebeurt door middel van prioriteitstelling (MoSCoW). Er wordt een lijst met eisen opgesteld waaraan vervolgens prioriteiten worden gekoppeld. Deze lijst wordt gebruikt om een begroting te maken. Bij het optreden van verschuiving wordt deze lijst gebruikt om te bepalen wat binnen de grenzen blijft horen.
De afkorting MoSCoW staat voor de relatieve gewenstheid van de diverse onderdelen van het gewenste systeem:
De bovenstaande gradaties kunnen door voortschrijdend inzicht door bijvoorbeeld gebruikers of ontwikkelaars tijdens het proces worden gewijzigd. Must's (en Should's in mindere mate) staan echter in principe vast en mogen dus niet zomaar worden veranderd door de ontwikkelaars zelf, zonder overleg hierover te hebben met eindgebruikers en opdrachtgevers.