Dynamic Systems Development Method
Van Wikipedia
Dynamic Systems Development Method, of kortweg DSDM, is een Rapid Application Development methode, die voornamelijk wordt gebruikt bij projecten voor ontwikkeling van gecomputeriseerde informatiesystemen. De methode ontstond rond 1994 in het Verenigd Koninkrijk, als een vendor-onafhankelijke methode, wat inhoudt dat er geen specifiek CASE tool of consultatiebureau achter zit. In plaats daarvan zit er een consortium van geïnteresseerde bedrijven en individuen achter.
Inhoud |
[bewerk] Wat is DSDM
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 dus dat juist 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 meest belangrijk zijn voor de bedrijfsbehoeften van de klant. Op deze manier kan sturend op tijd snel een bruikbaar resultaat worden bereikt en het IT-project beter worden beheerst.
DSDM maakt een ICT-project dus meer flexibel. Door het nieuwe systeem op te delen in zelfstandige eenheden, wordt het aanbrengen van tussentijdse veranderingen eenvoudiger voor de ontwikkelaar.
[bewerk] Wat kun je met DSDM
Het DSDM Consortium Benelux zegt over de toepasbaarheid van DSDM: "DSDM is goed toe te passen voor de ontwikkeling van alle mogelijke systemen. De meerwaarde van DSDM wordt echter ten volle benut bij de ontwikkeling van systemen met bepaalde kenmerken. Te noemen zijn goed visualiseerbare functionaliteit, via bijvoorbeeld schermen en rapporten. Prototypes kunnen middels deze zichtbare resultaten eenvoudig en goed geëvalueerd worden.”
[bewerk] Kenmerken van DSDM
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. DSDM heeft een iteratieve, incrementele opleverstrategie. Dit houdt in dat er telkens deelproducten worden opgeleverd, ook wel mijlpalen genoemd. Dit geeft de klant een beter gevoel, de klant ziet immers dat er telkens wat opgeleverd wordt. Het is dan vaak zo dat essentiële onderdelen van het nieuwe systeem gelijk al afgemaakt kunnen worden. Het is dus zo dat de DSDM ontwikkelmethode al vrij vroeg in het ontwikkelstadium een toegevoegde waarde kan bieden aan de klant.
[bewerk] Wanneer kan men DSDM gebruiken?
DSDM is een geschikte methode als de volgende aspecten aanwezig zijn:
- 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 naar verloop van tijd neemt het onderhoud enorm toe, waardoor het systeem niet meer gebruikt wordt.
DSDM richt zich op elk van de bovengenoemde situaties, en probeert deze te voorkomen.
[bewerk] DSDM basis-principes
DSDM heeft 9 basis-principes. 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 acceptatie-criterium voor een systeem of component is zijn geschiktheid voor business doelen.
- De business oplossing 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.
[bewerk] Principes
DSDM is gebaseerd op "best practice" ervaringen van organisaties met versnelde systeemontwikkeling. Het extract van al deze ervaringen heeft geleid tot de theorie. De basis wordt gelegd door 9 principes die in de hele theorie terug te vinden zijn
- Actieve betrokkenheid van gebruikers is noodzakelijk;
- DSDM-teams moeten gemachtigd zijn besluiten te nemen;
- De aanpak is gericht op het frequent opleveren van producten;
- Geschiktheid voor bedrijfsdoeleinden is het essentiële criterium voor de acceptatie van producten;
- Iteratieve en incrementele ontwikkeling is noodzakelijk om te convergeren tot een juiste bedrijfsoplossing;
- Alle wijzigingen tijdens de ontwikkeling zijn terug te draaien;
- Eisen worden op hoog niveau vastgelegd;
- Testen is geïntegreerd in de levenscyclus;
- Een samenwerkende en coöperatieve houding van alle belanghebbenden is essentieel
Bron: [1]
[bewerk] DSDM fasen
- feasibility study fase, om te bepalen of het systeem, met de gekozen technische realisatie, kosten en duur, geschikt is voor het bedrijf.
- business study fase, om algemeen de primaire functies van het systeem te bepalen en de gewenste betrouwbaarheid en prestaties.
- functional model iteration fase, met 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.
- system design/build iteration fase, 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.
- implementation fase, 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.
[bewerk] 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). 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.
[bewerk] MoSCoW
De afkorting 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);
- Want to have but will not have this time round - worden waarschijnlijk niet gerealiseerd binnen het betreffende project..
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.
