Bewerken van Dynamic systems development method

[[Image:DSDM Development Process.svg|thumb|320px|Model van het DSDM software development proces.]]
'''Dynamic Systems Development Method''', of kortweg '''DSDM''', is een ([[Agile software-ontwikkeling|agile]]) methode voor het ontwikkelen van [[software]]. 

==Geschiedenis==
De methode ontstond rond [[1994]] in het [[Verenigd Koninkrijk]], als een leverancier-onafhankelijke methode, wat inhoudt dat er geen specifiek [[Computer-aided software engineering|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 [[requirement]]s 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 [[Paretoprincipe|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 [[softwareontwikkelmethode]]n te gebruiken zoals [[Rational Unified Process|RUP]] of [[EXtreme Programming|XP]]. Een [[Agile software-ontwikkeling|agile]] methode die overeenkomsten heeft met de processen en het concept van DSDM is [[Scrum (softwareontwikkelmethode)|Scrum]].

== Kenmerken ==
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-methode|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.

== Gebruik ==
DSDM wordt gebruikt: 
*Als het een interactief systeem is;
*Als er een gedefinieerde gebruikersgroep aanwezig is;
*Als het systeem rekenkundig complex is kan dat deel worden opgesplitst of worden geïsoleerd;
*Als het systeem groot is kan het worden opgesplitst in kleinere functionele delen de ontwikkeling is sterk tijdsgebonden;
*Als de eisen aan het systeem kunnen worden geprioriteerd;
*Als de eisen aan het systeem onduidelijk of aan verandering onderhevig zijn.

Veel systeemontwikkelingsprojecten blijken niet aan de verwachtingen van eindgebruikers te voldoen. Dit is te voorkomen door met name op de volgende zaken te letten: 
*Het systeem voldoet niet aan de functionele behoefte vanuit het bedrijf, waarvoor het systeem was ontwikkeld. 
*Het systeem wordt niet gebruikt of er vinden dure aanpassingen op plaats. 
*Het systeem voldoet niet aan de performance-eisen, waardoor het niet bruikbaar is voor de gebruikers.
*Het systeem bevat fouten, wat kan resulteren in onverwachte problemen. 
*Gebruikers wijzen de invoer van het systeem af om politieke redenen. Dit kan komen door gebrek aan betrokkenheid bij de ontwikkeling of vanwege gebrek aan draagvlak. 
*Systemen worden wel geaccepteerd, maar na verloop van tijd neemt het onderhoud enorm toe, waardoor het systeem niet meer gebruikt wordt.

== Basisprincipes ==

DSDM heeft 9 basisprincipes. Dit zijn:
* Actieve deelname van gebruikers is essentieel;
* Design groepen zijn bevoegd om beslissingen te nemen op het vlak van systeem development;
* Vaak en regelmatig opleveren van componenten is een prioriteit;
* Het belangrijkste acceptatiecriterium voor een systeem of component is zijn geschiktheid voor business doelen;
* De businessoplossing is het doel, en iteratieve en incrementele ontwikkeling is noodzakelijk om tot die oplossing te komen;
* Alle veranderingen die worden gemaakt tijdens ontwikkeling, kunnen worden teruggedraaid;
* Initiële eisen zijn erg algemeen opgesteld;
* Testen is niet een aparte fase, het gebeurt gedurende het hele traject;
* Het is essentieel dat er samenwerking is tussen alle project participanten.

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.

== Fasering ==

* haalbaarheidsstudie (feasibility study), om te bepalen of het systeem, met de gekozen technische realisatie, kosten en duur, geschikt is voor het bedrijf;
* business study, om de belangrijkste functies van het systeem te bepalen en de gewenste betrouwbaarheid en prestaties;
* functional model iteration (fmi), met [[prototype|prototyping]] om gebruikerseisen te bepalen, informatie te verzamelen, de functionaliteit te tonen en niet-functionele eisen te achterhalen. Deze fase wordt net zo vaak herhaald als dat nodig is;
* design and build iteration (dbi), deze kan al beginnen voor de fmi-fase voorbij is, om het functionele prototype verder uit te werken, met het doel om een design prototype op te leveren dat voldoet aan de functionele en niet-functionele eisen. Deze fase wordt vaker uitgevoerd;
* [[implementatie]] (implementation), waarin het systeem wordt opgeleverd naar de eindgebruikers voor evaluatie en een project audit wordt uitgevoerd, waardoor het systeem ofwel definitief wordt opgeleverd ofwel teruggaat naar een eerdere fase.

== Timeboxing ==
[[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-methode|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.

== MoSCoW ==
De afkorting [[MoSCoW-methode|MoSCoW]] staat voor de relatieve gewenstheid van de diverse onderdelen van het gewenste systeem:
* Must have - moeten worden gerealiseerd;
* Should have - zouden eigenlijk moeten worden gerealiseerd;
* Could have - kan eventueel worden gerealiseerd (bijvoorbeeld als must en should onderdelen eerder zijn gerealiseerd dan verwacht);
* Won't have this time but would like in the future - worden waarschijnlijk niet gerealiseerd binnen het betreffende project.
: (ook bekend als 'Would like to have')
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.

== Externe link ==
*[https://web.archive.org/web/20161002055756/https://www.dsdm.org/ DSDM Consortium website]
{{Commonscat|Dynamic Systems Development Method}}

[[Categorie:Agile-softwareontwikkeling]]