Dynamic systems development method
Dynamic Systems Development Method is een Rapid Application Development methode, die voornamelijk wordt gebruikt bij de ontwikkeling van gecomputeriseerde informatie systemen. De methode ontstond rond 1994 in het Verenigd Koninkrijk, als zijnde 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.
RAD is een methode die wordt gekarakteriseerd door korte iteraties, weinig documentatie en een bereidheid om de eisen uit te kunnen breiden, in te kunnen korten of te kunnen veranderen, in plaats van het wijzigen van budget of tijd. Dit is in schril contrast met traditionele methoden, zoals de "waterval"-methode.
DSDM basis-principes
DSDM heeft 9 basis-principe. 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 te 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.
DSDM fasen
- feasibility study fase, om te bepalen of het systeem, met de gekozen techinische 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 begin 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.
MoSCoW
De afkorting MoSCoW staat voor de relatieve gewenstheid van de diverse onderdelen van het gewenste systeem:
- Must have
- Should have
- Could Have
- Would like to have