DSDM Dynamic Systems Development Method. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V

DSDM – Dynamic Systems Development Method Een introductie

Algemene informatie voor medewerkers van SYSQA B.V.

Organisatie Titel Onderwerp

SYSQA B.V. DSDM – Dynamic Systems Development Method Een introductie

Pagina Versie Datum

2 van 10 1.1 12-4-2011

Inhoudsopgave 1

INLEIDING .............................................................................................................................. 3 1.1 1.2

2

ALGEMEEN ......................................................................................................................... 3 VERSIEBEHEER .................................................................................................................. 3

DE FASERING VAN DSDM .................................................................................................... 4 2.1 2.2 2.3 2.4 2.5

HAALBAARHEIDSONDERZOEK (FEASIBILITY STUDY)............................................................... 4 BEDRIJFSANALYSE (BUSINESS STUDY) ................................................................................ 5 FUNCTIONEEL MODEL ITERATIE (FUNCTIONAL MODEL ITERATION) ......................................... 5 ONTWERP & BOUW (DESIGN AND BUILD ITERATION) ............................................................. 6 IMPLEMENTATIE (IMPLEMENTATION) ..................................................................................... 6

3

DE NEGEN BASISPRINCIPES VAN DSDM ........................................................................... 7

4

STUREN OP TIJD EN PRIORITEIT ........................................................................................ 9

5

DSDM EN TESTEN ............................................................................................................... 10

6

LITERATUURVERWIJZINGEN ............................................................................................. 10

Almere © 2000

Quality Assurance in ICT



Pagina Versie Datum

3 van 10 1.1 12-4-2011

1 Inleiding 1.1

Algemeen

Sinds begin jaren ‘90 zijn er nieuwe soorten systeemontwikkelingmethodes ontstaan. Reden hiervoor is dat de oude methodes, vaak genoemd onder de verzamelnaam watervalmethodes, niet opleverden wat ervan verwacht werd. Het uiteindelijke product was kwalitatief onder de maat, het ontwerpen, realiseren en testen duurde te lang, de bouwers en gebruikers begrepen elkaar niet en de kosten liepen uit de hand. De verzamelnaam voor de nieuwe systeemontwikkelingmethodes is Rapid Application Development (RAD). De methode RAD is ontwikkeld door James Martin. Zijn methode kent echter veel varianten die geavanceerder zijn dan RAD. De de facto standaard voor RAD is DSDM, Dynamic Systems Development Method. DSDM is ontwikkeld door het Britse DSDM Consortium. De doelstelling van het DSDM Consortium is het maken van een publiekelijke toegankelijke en algemeen aanvaarde methode, onafhankelijk van technische hulpmiddelen. Centraal staan de informatiebehoeften van een bedrijf en de daarvoor te leveren oplossingen, en wel zo snel en goedkoop mogelijk. DSDM probeert te voorzien in die aanpak voor het bouwen en onderhouden van systemen die voldoen aan een strakke tijdsplanning in een beheersbare projectontwikkeling. De filosofie achter DSDM: · Ontwikkeling is teamwerk: kennis van bedrijfsbehoeften van gebruikers wordt gecombineerd met de technische kennis van IT-specialisten; · Ontwikkeling kan een stapsgewijs (incrementeel) proces zijn: niet alles hoeft gelijktijdig te worden geleverd; · Wet van de afnemende meeropbrengsten: gebruik de middelen voor die voorzieningen, die voor het bedrijf het meest van belang zijn. Het doel van DSDM is om sneller systemen te leveren dan bij de watervalaanpak haalbaar is zonder in te leveren op ontwikkelingskosten en kwaliteit. Dit houdt in dat de werkwijze anders dient te zijn en dat de gebruikte technieken hierop toegespitst dienen te worden, om alle overhead zo veel mogelijk te beperken. Het belangrijkste stuurmiddel is de timebox: een korte tijdsperiode (enkele dagen of weken) binnen het project, waarin een product wordt opgeleverd volgens overeengekomen kwaliteitscriteria. Op basis van een groot aantal uitgevoerde projecten kunnen als voordelen worden genoemd: · Het systeem wordt sneller gebouwd; · De gebruikers zijn er meer toe bereid het systeem in eigen beheer te nemen; · Het risico van het bouwen van een onbruikbaar systeem wordt verminderd; · Het uiteindelijke systeem voldoet meestal beter aan de bedrijfsvereisten van de gebruikers; · De gebruikers zijn beter opgeleid; · De invoering van het systeem verloopt meestal soepeler. Het voorliggende document beschrijft de methode DSDM.

1.2 Versie 0.1 0.2 1.0 1.1

Versiebeheer Status Concept Concept Definitief Definitief

Datum 2 oktober 2000 28 augustus 2001 31 augustus 2001 12 april 2011

Almere © 2000

Auteur SYSQA SYSQA SYSQA SYSQA

Opmerkingen Eerste concept Tweede concept Definitieve versie Aanpassing aan nieuwe huisstijl




Pagina Versie Datum

4 van 10 1.1 12-4-2011

2 De fasering van DSDM Onderstaande figuur geeft het fasenmodel (vijf fasen) van DSDM weer. De donkere pijlen geven de voorwaartse richting aan, met de grijze pijlen wordt de mogelijke terugkoppeling tijdens het ontwikkelproces weergegeven. Vervolgens worden de vijf fasen in de respectievelijke paragrafen behandeld.

Feasibility Bedrijfsanalyse

Tijdschema afspreken Functioneel Prototype maken

Functioneel Model Iteratie Prototype evalueren

Implementeren

Functioneel Prototype identificeren

Bedrijf evalueren

Implementatie

Gebruikers opleiden

Gebruikersgoedkeuring en handleidingen

Ontwerpprototype identificeren Tijdschema afspreken

Ontwerp & bouw iteratie

Ontwerp prototype evalueren

Ontwerpprototype maken

2.1

Haalbaarheidsonderzoek (Feasibility Study)

Het gaat hier niet om een traditionele haalbaarheidsstudie, maar meer om een beoordeling of de aanpak met DSDM in dit project wel of niet de aangewezen methode is. De gebruikelijke overwegingen bij een haalbaarheidsstudie gelden ook hier, zoals de probleemdefinitie en het beantwoorden van vragen of het technisch haalbaar is; de invloed op de huidige bedrijfsprocessen acceptabel is; en of het alles de moeite waard is. De extra vraag is echter: Is DSDM de beste aanpak om dit systeem te bouwen? Het Haalbaarheidsonderzoek dient kort en krachtig te zijn. Het gehele proces duurt niet langer dan een paar weken. Naast het haalbaarheidsrapport dienen nog twee andere producten opgeleverd te worden: een globaal plan voor de verderde ontwikkeling en een snel prototype (optioneel en afhankelijk van het betreffende project). Beide producten ter ondersteuning dat het project (technisch) haalbaar is. DSDM gebruikt het woord “prototype” omdat het een bekend begrip is, maar eigenlijk gaat het niet om prototypen – het zijn systeemcomponenten. Een DSDM-prototype is niet een afgeleide, maar het wordt gebouwd op hetzelfde platform waarop al het ontwikkelwerk plaatsvindt en het voldoet aan alle vereiste standaards. Prototypen zijn dus een deel van de ontwikkeling en zeker geen wegwepproduct: zij groeien mee in het op te leveren systeem.

Almere © 2000



2.2


Pagina Versie Datum

5 van 10 1.1 12-4-2011

Bedrijfsanalyse (Business Study)

In deze fase gaat het in de eerste plaats om inzicht te verkrijgen in de te automatiseren bedrijfsprocessen en de bijbehorende informatiebehoeften. Nodig zijn enkele workshops met deskundig personeel, dat snel de aanwezige kennis kan uitwisselen en overeenstemming kan bereiken over de prioriteiten bij de ontwikkeling. Een goede methode om goed geinformeerde mensen bij elkaar te brengen is via JAD-workshops (Joint Application Design). De bedoeling bij een JAD-workshop is om gezamenlijk iets te maken en over de inhoud ervan overeenstemming te bereiken tussen alle deelnemers. Het resultaat van de workshops is: · Beschrijving bedrijfsgebied (Business Area Definition / BAD): identificatie van processen met bijbehorende informatie en gebruikersgroepen. Aan iedere globale functie uit de BAD wordt een prioriteit (vanuit bedrijfsbelang of technische beperkingen) toegekend, zodat de belangrijkste functionaliteit eerder ontwikkeld kan worden dan de minder essentiële delen. Deze kunnen altijd later nog worden toegevoegd. Bij prioritering worden de MoSCoW-regels gehanteerd: - Must have: “eisen, die essentieel voor het systeem zijn”; - Should have: “belangrijke eisen, waar het systeem echter zonodig buiten kan”; - Could have: “eisen, die eenvoudig weggelaten kunnen worden”; - Want to have but will not have this time round: “eisen, die wel even kunnen wachten”. · Beschrijving Systeemarchitectuur (System Architecture Definition / SAD): beschrijving welke platforms voor ontwikkeling en bouw gebruikt gaan worden en de globale architectuur van de software in termen van hoofdcomponenten en interfaces. · Globale Prototyping Plan / GPP: Uitwerking van het globale plan uit de vorige fase, waarin alle prototyping activiteiten in de hierna volgende fasen van Functioneel Model Iteratie en Ontwerp en Bouw Iteratie worden omvat.

2.3

Functioneel Model Iteratie (Functional Model Iteration)

Deze en de volgende fase omvatten beide een cyclus met vier stappen: 1. Identificeer wat gedaan dient te worden in deze cyclus; 2. Spreek af hoe het gaat gebeuren; 3. Voer het uit; 4. Controleer of het goed is uitgevoerd (documenten beoordelen, prototype demonstreren, testen van een deel van de software). Het Functioneel Model bestaat zowel uit analysemodellen als uit softwarecomponenten die de belangrijkste functionaliteit beiden en voldoen aan bepaalde niet-functionele eisen, met name ten aanzien van gebruikersgemak. De software componenten en analysemodellen worden gelijktijdig gemaakt, waarbij aanvankelijk het accent op de modellen ligt. Bij iedere stap in de cyclus worden de ervaringen tijdens de prototyping activiteiten teruggekoppeld naar de analysemodellen. Aangezien de modellen steeds verder worden verfijnd, komen de prototypen steeds dichter in de buurt van de uiteindelijk op te leveren software. Het is essentieel dat de softwarecomponenten van het Functioneel Model worden getest tijdens de productie ten aanzien van wat de diverse onderdelen doen en hoe ze onderling samenwerken. Andere producten in deze fase zijn de verfijning van de geprioriteerde functies, evaluatiedocumenten van de functionele prototypen, niet-functionele eisen, en risicoanalyse voor toekomstige ontwikkeling.

Almere © 2000



2.4


Pagina Versie Datum

6 van 10 1.1 12-4-2011

Ontwerp & Bouw (Design and Build Iteration)

Tijdens de iteratieve ontwerpen bouwfase wordt het systeem geconstrueerd volgens een voldoende hoge standaard. Het belangrijkste product in deze fase is het geteste systeem. In het figuur op de vorige pagina wordt testen niet als een aparte activiteit aangegeven, omdat testen doorlopend gebeurt, zowel tijdens de vorige als de huidige fase. In sommige omgevingen of bij contractuele verplichtingen zijn aparte testfasen vereist aan het einde van elke ontwikkelingsstap, maar dit is niet de omvangrijke activiteit zoals bij de watervalaanpak. Bij DSDM is testen net zo belangrijk en er wordt evenveel energie in gestoken, maar het is uitgespreid over het gehele ontwikkelingstraject.

2.5

Implementatie (Implementation)

De fase Implementatie betreft de overdracht vanuit de ontwikkelomgeving naar de operationele omgeving. Dit omvat ook de opleiding van gebruikers en het overhandigen van het systeem aan hen. Het product van deze fase is natuurlijk het opgeleverde systeem,inclusief alle benodigde documentatie. Andere producten zijn de gebruikershandleiding en een opgeleide gebruikersgroep. Tevens wordt er een Project Evaluatie Document / PED (Project Review Document / PRD) opgesteld onmiddellijk nadat het systeem als compleet wordt beschouwd. Het PRD wordt gebruikt om aan te geven wat er in het project is bereikt ten aanzien van de korte termijn doelstellingen. Er wordt met name bekeken welke eisen tijdens de ontwikkeling naar voren zijn gekomen en of het nieuwe systeem voldoet in relatie tot deze eisen.

Almere © 2000




Pagina Versie Datum

7 van 10 1.1 12-4-2011

3 De negen basisprincipes van DSDM De hele methode is gebaseerd op negen principes, die allen dienen te worden toegepast, wil het werken met DSDM een succes worden. De eerste vier bepalen de fundamenten waarop DSDM is gebouwd en de overige vijf leveren de uitgangspunten voor de structuur van de methode. 1. Actieve betrokkenheid van gebruikers is noodzakelijk Dit is het belangrijkste principe. De betrokkenheid is niet slechts actief, maar zelfs proactief. Bij DSDM is de inbreng van gebruikers gelijkmatig. Slechts een paar kundige gebruikers worden bij het project betrokken, ter ondersteuning of als deelnemer in het team. De ervaring heeft geleerd dat de inspanningen van de gebruikersgemeenschap als geheel niet veel groter en vaak zelfs net zo groot of minder zijn. 2. DSDM-teams dienen gemachtigd te zijn besluiten te nemen Teamleden dienen in staat zijn om snel beslissingen te nemen over de te volgen route. Kenmerkend voor DSDM is immers een strak tijdschema. Er is geen tijd voor lange besluitvormingsprocedures. De teamleden dienen duidelijkheid te hebben over de grenzen, waarbinnen ze kunnen opereren. Een belangrijke beperking is uiteraard het budget. 3. Frequente oplevering van producten is van wezenlijk belang Door regelmatige oplevering van producten (modellen, software) kan het management de besluitvorming binnen een team voldoende controleren. Door het plannen van een regelmatige oplevering (zeg wekelijks) van iets tastbaars en zichtbaars creëert men een vangnet voor het terugdraaien van verkeerde beslissingen zodat managers niet het gevoel hebben de besturing kwijt te zijn. De producten hoeven niet volledig te zijn, zolang ze maar voortgang in de juiste richting laten zien. 4. Geschiktheid voor bedrijfsdoeleinden is essentieel voor de acceptatie van producten Het principe houdt in dat de ontwikkelaar niet op een bepaald punt blijft steken omdat hij een goudomrande oplossing wil leveren. Door de geschiktheid voor het bedrijfsdoel als uitgangspunt te nemen, kunnen bepaalde technische aspecten worden uitgesteld. Door bij de controle van te leveren producten te letten op de geschiktheid voor het bedrijfsdoel, wordt valideren belangrijker dan verifiëren. Met andere woorden: vooruit kijken naar het gebruik van het systeem is beter dan achterom kijken om consistentie te controleren. 5. Iteratieve en incrementele ontwikkeling is noodzakelijk om te convergeren tot juiste oplossing Als het team gebruikers bevat die vrijwel direct feedback geven op het werk van de ontwikkelaars, is het mogelijk om systeemontwikkeling stap voor stap uit te voeren in plaats van in één keer. Doordat systemen stukje bij beetje worden ontwikkeld, zorgt DSDM ervoor dat fouten vroeg ontdekt worden, waardoor men kostbare herstelprocedures achteraf kan voorkomen. 6. Alle wijzigingen tijdens de ontwikkeling zijn terug te draaien Dit houdt in dat er sprake dient te zijn van een vlekkeloos beheer van alle softwarecomponenten en de bijbehorende documentatie.

Almere © 2000




Pagina Versie Datum

8 van 10 1.1 12-4-2011

7. Eisen worden op hoog niveau vastgelegd Eisen die tijdens de Bedrijfsanalyse zijn verzameld bepalen de reikwijdte van het project. Deze eisen dienen duidelijk en goed vastgelegd te zijn. 8. Testen is geïntegreerd in de levenscyclus De filosofie van DSDM is: “testen terwijl je bezig bent”. Alle testen, inclusief acceptatietesten, worden gedurende het traject geleidelijk uitgevoerd. 9. Een samenwerkende en coöperatieve houding van alle belanghebbenden is essentieel Niet alleen samenwerken en meewerken zijn belangrijk, het is evenzeer van belang dat alle deelnemers bij deze aanpak betrokken raken. Eventueel bestaande kunstmatige scheidingswanden tussen verschillende en binnen afdelingen werken vooral bij DSDM contraproductief.

Almere © 2000




Pagina Versie Datum

9 van 10 1.1 12-4-2011

4 Sturen op tijd en prioriteit Leven met tijdslimieten door timeboxes wil niet zeggen dat er harder gewerkt dient te worden of dat er meer uren gedraaid worden dan normaliter het geval is. Op het niveau van het team gelden de prioriteiten van de functionele en niet-functionele eisen om te beslissen wat het team gaat doen en wanneer. Als een zelfstandige opererende groep kunnen zij zelf besluiten wie welke werkzaamheden op welk moment doet. De teamleden werken samen om aan de eisen met de hoogste prioriteit te werken. Op het niveau van het individu dienen ontwikkelaars en gebruikers te accepteren dat het niet mogelijk is om alles te doen. Enkele kernpunten ten aanzien van timeboxes: · Korte timeboxes binnen de alomvattende timebox van het project zijn het middel om de kwaliteit van tussenproducten te controleren en om te voorkomen dat er tijdens de ontwikkeling verschuivingen in bereik en omvang optreden; · Korte timeboxes maken een schatting van de benodigde inspanningen eenvoudiger; · Een timebox heeft drie fasen: onderzoek, verfijning en consolidatie; · Alle eisen worden geprioriteerd om ervoor te zorgen dat als eerste aan de belangrijkste eis wordt voldaan; · De producten van een timebox worden bij voorkeur getest en/of herzien tijdens de timebox en niet daarna; · Activiteiten binnen timeboxes worden gedefinieerd in termen van producten en niet van taken. De projectplanning wordt gebaseerd op timeboxes. Functionele en niet-functionele eisen worden geclusterd en toegewezen aan timeboxes. De speelruimte bij timeboxes zit in de eisen met lage prioriteit. Deze worden zo nodig (nog) niet geleverd. Het gehele team is betrokken bij de schatting van de lengte van een timebox. Een team dient uit maximaal zes personen te bestaan (inclusief de ambassadeurs). Er zijn speciale rollen en verantwoordelijkheden voor zowel de ontwikkelaars als de gebruikers. Kenmerkende sleutelrollen zijn de visionair (een ervaren gebruiker, die zorgt voor het vasthouden aan de bedrijfsdoelstellingen), de ambassadeur (verantwoordelijk voor verspreiding van informatie van het team naar de rest van de gebruikers en voor inbreng van gebruikerskennis in het team), en de technisch coördinator, die ervoor zorgt dat al het werk in de systeemarchitectuur past en dat het aan de technische standaards voldoet. De doorlopende inzet van ambassadeurs is essentieel voor het succes van DSDM. Ambassadeurs dienen een goede bedrijfskennis te bezitten en dienen gerespecteerd te worden door hun collega’s op alle niveaus.

Almere © 2000




Pagina Versie Datum

10 van 10 1.1 12-4-2011

5 DSDM en testen De IT-managers zijn altijd bang dat het testen erbij inschiet in de race tegen de deadline bij (bijvoorbeeld) RAD-projecten. Een van de principes van DSDM is dat testen plaatsvindt tijdens de gehele levenscyclus en niet alleen aan het eind, als alle besluiten over de inhoud van de programma’s al zijn genomen. Dankzij timeboxes is testen een doorlopende activiteit gedurende het ontwikkelproces. Binnen een timebox wordt het testen op een aantal niveaus gelijktijdig uitgevoerd, van moduletest via integratie- en systeemtest tot acceptatietest. En niet te vergeten de regressietest, die bijzonder belangrijk is bij een iteratieve ontwikkelaanpak. Moduletesten verloopt nagenoeg op dezelfde manier als bij ontwikkelen volgens de traditionele aanpak. Een extraatje is dat als een gebruiker uit het team een bepaald onderdeel al kan bekijken of proberen, dit dan ook gebeurt. Integratietesten gebeurt ook binnen een timebox, tenminste als de onderdelen geïntegreerd worden met producten uit een vorige timebox. Op deze wijze gebeurt integratietesten dus stapsgewijs tijdens de ontwikkeling. Naarmate het aantal componenten groeit en het geheel dichter bij de uiteindelijke functionaliteit komt, verschuift de aandacht bij het integratietesten van technische integratie van globaal opgezette interfaces naar gecombineerde functionaliteit van het totale product. Met andere woorden, integratietest verschuift naar systeemtest. De aanwezigheid van gebruikers in het team zorgt voor een vroegtijdige nadruk op validatie, het al vroeg in het project kijken naar toekomstige levensvatbaarheid van het systeem wat betreft het gebruik in plaats van de vraag of de code wel overeenkomt met de specificatie (verificatie). Dit verlaagt de kosten voor het herstellen van die fouten die vaak ontdekt worden tijdens de traditionele acceptatietest of nadat het systeem in gebruik is genomen. Een terugkerend probleem bij acceptatietesten is dat gebruikers niet goed weten hoe ze testscripts moeten maken. De ambassadeurs zijn de ideale mensen om de formele acceptatietest samen te stellen, die later desgewenst door de grote gebruikersgroep uitgevoerd kan worden. Er is een grote verscheidenheid aan testtools te verkrijgbaar en DSDM pleit sterk voor het gebruik van dit soort ondersteuning. Het in korte tijd produceren van een getest systeem is alleen mogelijk door het inzetten van effectieve hulpmiddelen.

6 Literatuurverwijzingen DSDM Dynamic Systems Development Method. De methode in de praktijk – Jennifer Stapleton – 90 395 1091 1

Almere © 2000


DSDM Dynamic Systems Development Method. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V

Recommend Documents