Reader Projectmatig

Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
2-35
ALGEMENE GEGEVENS
Jaar
Hoofdfase
Code
Vaardigheden niveau 2
Beginvereisten
Vaardigheden niveau 1
Versie 3.0
Februari 2011
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
VOORWOORD
Projectmanagement is een "vak" apart. Het managen van projecten houdt in dat men
flexibel te werk gaat, pro-actief reageert op wat er gebeurt en steeds het te bereiken
resultaat voor ogen houdt. Net zoals een timmerman of elektricien heeft ook een
projectmanager, naast zijn persoonlijke vakkennis en kwaliteiten, een “gereedschapskist”
nodig voor het uitvoeren van zijn taak. In het geval van een projectmanager bestaat de
gereedschapskist ondermeer uit een of meer projectmanagementmethoden, technieken
(voor plannen en begroten), standaards en richtlijnen (documentatie en rapportage) en tools
(planningsoftware, documentatietemplates). Het is belangrijk dat deze gereedschapskist
goed gevuld is (wat kan een timmerman immers zonder de juiste hamer en spijkers?), maar
een goede gereedschapskist maakt nog geen goede projectmanager (niet iedereen met
een hamer en spijkers is immers ook een goede timmerman!).
De laatste jaren is er steeds meer aandacht gekomen voor het gebruik van specifieke
projectmanagementmethoden. Een methode kan hier opgevat worden als het geheel van
afspraken, werkwijzen, procedures en hulpmiddelen op grond waarvan projecten worden
3-35
opgestart, uitgevoerd en afgerond.
Voor de start van de ICA hoofdfase projecten willen we alle studenten inzicht bieden in een
aantal gangbare methoden en technieken voor projectmanagement. Dit dictaat geeft van
een aantal geschikte methoden voor projectmanagement een beknopte inleiding. Het
bestaat hoofdzakelijk uit een bundeling van Nederlandse Wiki-teksten (Wikipedia),
aangevuld met ‘ICA’ inzichten.
Het dictaat is samengesteld door Sander Leer, Carel Sicherer en Peter Schuszler.
Versie 2.0 is afgesloten op @@ augustus 2009.
Versie 3.0: februari 2011
PS: dit dictaat is géén officiële bron, en daarom kan naar deze bron niet worden
verwezen.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
INHOUDSOPGAVE
4-35
1
INLEIDING
5
2
PROJECTMATIG WERKEN
7
ProjectmatiG creëren
8
3
9
PRINCE2
Kenmerken
Processen
9
10
4
13
PROCESMODELLEN
Processen en meta-processen
Procesactiviteiten
Procesmodellen
13
13
15
5
17
DE WATERVALMETHODE
Fasen
Voordelen
Nadelen
Vernieuwde watervalmethoden
18
18
19
20
6
21
RATIONAL UNIFIED PROCESS
Totstandkoming RUP
Filosofie achter RUP
Fasering
21
21
22
7
24
EXTREME PROGRAMMING
Ontwikkelprincipes
Best practices
Nadelen
24
25
25
8
27
SCRUM
Geschiedenis
Doelstellingen
Werkwijze
Voordelen
9
DYNAMIC SYSTEMS DEVELOP-MENT METHOD (DSDM)
27
27
2727
28
29
Inleiding
Wat is DSDM
Toepassing van DSDM
Kenmerken van DSDM
Wanneer kan men DSDM gebruiken?
MoSCoW
29
29
30
30
30
31
10
32
EVO
Karakteristieken
32
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
Werkwijze
Procedures
32
32
11
33
BEST PRACTICES, TOOLS EN TECHNIEKEN
Wanneer welke methode?
33
BRONNEN
35
5-35
1 INLEIDING
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
De meeste ICA projecten leveren uiteindelijk een werkend stuk software op.
Maar het hele traject van softwareontwikkeling wordt lang niet in elk ICAkeuzesemester doorlopen. Vaak is dat traject gelet op de tijd niet haalbaar,
en sommige semesters en projectopdrachten lenen zich er simpelweg niet
voor. Toch zullen bij heel veel projecten analyseren, ontwerpen, realiseren
en testen wèl aan bod komen. Vóór de start van het eerste project in de
hoofdfase willen we jullie daarom inzicht bieden in een aantal gangbare
projectmethoden en technieken.
De gangbare eis bij ICA-projecten is dat er binnen één à twee weken een goedgekeurd
Plan van Aanpak (Project Initiation Document (PID), Product Backlog, EVO plan) ligt,
waarna een groep verder gaat met analyseren en ontwerpen. Afhankelijk van de gekozen
methode leidt dat dan bijvoorbeeld tot geplande mijlpaalproducten in een bepaalde week
(watervalmethode) of tot een reeks prototypes of incrementen (iteratieve methoden).
In overleg met de ICA-begeleider en/of de opdrachtgever wordt voor een bepaalde aanpak
6-35
gekozen. Belangrijk is dat je al vroegtijdig bent doordrongen van het verschil tussen
Projectmatig werken (planning, risico’s; oa Hummel) en Procesmodellen (waterval, enz.).
In het eerste deel (hoofdstukken 2-3) gaat het over Projectmatig werken en bespreken we
de meest gebruikte methode: PRINCE2.
In het tweede deel komen de procesmodellen aan bod. Na een inleidend hoofdstuk (4)
volgen specifieke hoofdstukken over Waterval-methoden (5), RUP (6), XP (7), Scrum (8),
DSDM (9) en EVO (10).
We sluiten dit dictaat af met een hoofdstuk over best practices, tools en technieken en een
tabel waarin de hamvraag aan bod komt: wanneer is welke methode het meest geschikt?
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
2 PROJECTMATIG WERKEN
Projectmanagement is - algemeen geformuleerd - het beheersen van projecten. Het is
de manier waarop projecten georganiseerd, voorbereid, uitgevoerd, en afgerond
worden [2] [4] [10] .
Een mogelijke definitie van projectmanagement is de volgende:
Het, door middel van projecten, integreren van mensen, afdelingen, organisaties, middelen
en technische mogelijkheden tot het op een gestructureerde wijze oplossen van een
gemeenschappelijk onderkende probleemstelling, daarbij rekening houdend met de
belangen van de betrokkenen.
Projectmanagement omvat de aansturing van projectleiders en de beheersing van
meerdere deelprojecten, terwijl projectleiding de aansturing van teamleiders binnen een
project omvat.
7-35
Bij projectmanagement worden, in het algemeen, de volgende stappen doorlopen:

Opstart van het project
Bepaling van de omvang/scope van het project

Planning van het project
Opdeling van het project in verschillende fasen, te beschrijven in een Plan van
Aanpak (PvA), ook wel Project Initiation Document (PID) genoemd.

Uitvoering van de verschillende fasen

Opvolging van de projectvoortgang

Besluitvorming en creatie van het eindproduct
Het gebruik van een projectmanagementmethode moet de kans op projectsucces vergroten
en veel voorkomende faalfactoren zien te voorkomen zoals [10] :

Onduidelijkheid over de opdrachtgever.

Geen (goed) projectplan wat betreft opzet en inhoud.

Geen goede definiëring van het doel en het beoogde projectresultaat.

Slechte en (veel) te optimistische planning van resources, activiteiten en middelen.

Oorspronkelijke uitgangspunten en eisen die (voortdurend) tijdens het project
veranderen.

Gebrek aan controle over voortgang (in tijd, geld en resultaat) waardoor tijdige
bijsturing niet lukt.

Onvoldoende meet- en beslispunten waardoor het overzicht ontbreekt.

Gebrek aan kwaliteitscontrole waardoor opgeleverde producten niet voldoen aan
de verwachtingen van gebruikers en het eindresultaat niet gebruikt wordt.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
Er bestaan verschillende projectmanagementmethoden (die al dan niet een
certificeringsprogramma kennen), waaronder: Projectmatig creëren, IPMA, PRINCE2,
PMW, PMBoK, OPEN. Prince2 komt hierna nog in een apart hoofdstuk aan bod.
PROJECTMATIG CREËREN
De meeste projectmanagementmethoden leggen vooral de nadruk op de strakke
beheersing van projecten en dan met name de aspecten tijd (time controle), geld (cost
control) en kwaliteit (quality control). Nieuwe methoden die de afgelopen jaren ontwikkeld
werden, zoals beschreven in het boek “Projectmatig Creëren”, leggen vooral de nadruk op
het managen van chaos, energie, creativiteit en het scheppend vermogen van het
projectteam (“als je het wilt, dan lukt het ook”). Dit vanuit de filosofie dat een eenzijdige
focus op “harde” projectmanagementaspecten ook geen garantie is voor succes. Vanuit
deze visie passen de mensen zich niet aan een bestaande projectstructuur, maar creëren
de betrokkenen voor zichzelf een maatwerk projectstructuur. Projectmedewerkers worden
daarbij volledig op hun creativiteit en commitment aangesproken waardoor de
projectverantwoordelijkheid maximaal gedelegeerd kan worden. Anders dan de bedenkers
willen doen geloven, is deze methode vooral een aanvulling op bestaande methodieken, die
zich veelal alleen maar concentreren op de harde aspecten van projectmanagement.
8-35
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
3 PRINCE2
De bekendste en belangrijkste projectmanagementmethode is Prince (Projects In
Controlled Environments). Deze methode is in 1989 opgesteld door het Britse Central
Computer and Telecommunications Agency (CCTA). In 1996 is een verbeterde versie
uitgebracht met de naam “Prince2”. Prince2 is geschikt voor alle typen projecten, van
klein tot groot. De methode is gebaseerd op praktijkervaringen met verschillende
projectmanagement-methoden en praktijkvoorbeelden. Prince2 is een proces
georiënteerde methode in tegenstelling tot bijvoorbeeld lineaire methoden als de
watervalmethode. Prince2 is ook een productgerichte aanpak. Door duidelijke
productbeschrijvingen worden risico’s met het gewenste eindresultaat of de op te
leveren producten verminderd. Prince2 is in Nederland op dit moment de meest
gebruikte en meest onderwezen projectmanagementmethode.
KENMERKEN
9-35
PRINCE2 is toepasbaar op alle projecten, en kent een grote flexibiliteit. Aspecten van de
methode die niet van toepassing zijn op (of niet nuttig voor) een bepaald project, kunnen
overgeslagen worden.
PRINCE2 ziet als grondbeginselen van goed projectmanagement:

Een project is een eindig proces met een duidelijk begin en eind.

Projecten moeten altijd worden beheerst om succesvol te zijn.
De belangrijkste kenmerken van PRINCE2 zijn:

Business Case: de zakelijke rechtvaardiging van het project (welke voordelen heeft het
project voor de organisatie?; in hoeverre draagt het project bij aan de
bedrijfsdoelstelling?; wegen de opbrengsten van het project op tegen de kosten
ervan?).

Product Based Planning (zie 5.1.): een planning die de oplevering van de producten
(tussentijds en aan het eind) centraal stelt.

Organisation: gedefinieerde organisatiestructuur voor het project (projectmanager,
opdrachtgever, stuurgroep, enz.).

Stages: beheersbare en controleerbare managementfasen.

Management by Exception: de stuurgroep (Project Board) komt alleen bij elkaar als dat
echt nodig is.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
PROCESSEN
Fasering bij PRINCE 2:
Starting Up a project (SU)
Starting Up a Project is de fase waarin het project voorbereid wordt. Hierin wordt
onderzocht of het zinvol is om een project te beginnen. In de praktijk is dit een korte,
krachtige fase, waar de projectmanager intensief samenwerkt met de opdrachtgever.
SU start door het geven van een projectmandaat van de opdrachtgever aan de beoogde
projectmanager, die in deze fase onder andere de samenstelling van de projectorganisatie
vaststelt.
Initiating a project (IP)
De eerste fase binnen een project wordt de Initiation Stage genoemd. Deze fase is verplicht
in elk PRINCE2 project en is erop gericht om een goede fundering onder het project te
leggen (eerst denken, dan doen). In de initiatiefase worden de beoogde resultaten, plannen,
taken en verantwoordelijkheden vastgelegd, waarmee een draagvlak wordt gecreëerd voor
het project. Het belangrijkste product van deze fase is het Project Initiation Document (PID).
10-35
Initiating a project (IP) bestaat uit zes onderdelen (IP1 t/m IP6):
Planning Quality (IP1)

Opstellen van een Quality Plan.

Afstemming met kwaliteitsprocessen in de organisatie.

Benoemen:

o
Technieken en methoden.
o
Betrokkenen.
Maken van kwaliteitsprotocol (Quality Log)
Planning a Project (IP2)

Het opstellen van een projectplan conform Planning (PL).
Refining the Business Case and Risks (IP3)

Het bijwerken van de Business Case (BC), het 'waarom' van het project.

Projectmanager legt deze vast.

Totstandkoming is in nauw overleg met Project Board.

Vertrek vanuit projectbrief en project approach.

Verdere uitwerking risico’s

Evaluatie eerder geïnventariseerde risico’s.

Besluitvorming noodzaak tot noodplannen.

Inschatting haalbaarheid a.d.h.v. risico’s
Setting up Project Controls (IP4)
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten

Het organiseren van beheersmechanismen (controls) om stuurgroep/projectmanager
zelf in staat te stellen het project te sturen.

Het definiëren van toleranties op verschillende niveau’s in projectorganisatie (top down
vertaling van grenzen).

Het opstellen van een Communication Plan.
Setting up Project Files (IP5)

Het opzetten van het projectdossier (deliverables registry):
o
Directorystructuur.
o
Toegangsrechten.
Assembling a Project Initiation Document (IP6)

Het samenstellen van het Project Initiation Document (PID)
Management of Risk
Een belangrijk beheersaspect voor het projectteam is management of Risk
(risicomanagement). Risicomanagement heeft als doel het opsporen van risico's die het
project bedreigen en deze vervolgens te beheersen. Het is niet per sé nodig om het
11-35
elimineren van een risico (of alle risico's) na te streven, dat zal waarschijnlijk onevenredig
veel inspanning kosten.
Risico kan worden omschreven als het product van de Kans dat een dreiging zich voordoet
en de Schade die dat tot gevolg heeft: R = K * S
Een kleine kans met een grote schade levert een laag risico op. Een grote kans
gecombineerd met een hoge schade zal een groot risico vormen voor het project. Een
leverancier die in het verleden grote moeite heeft gehad op tijd te leveren kan dus
bijvoorbeeld een groot risico opleveren, zeker als de schade die optreedt als er niet op tijd
geleverd wordt groot is. De projectmanager moet zich vanaf het begin van het project
(initiatiefase) bewust zijn van de risico's en dient zich niet te beperken tot 1 fase, maar heeft
zijn blik steeds vooruit gericht tot het einde van het project. Doordat er beslissingen worden
genomen, nemen de risico's in de loop van het project af. Echter kan er in elke fase zich
een nieuw risico voordoen, die ook moet worden beheerst. Risicomanagement houdt dus in
dat de risico's die het project bedreigen beheerst worden en het inspelen op deze risico's
indien nodig. De schade die het eindproduct kan oplopen heeft vaak betrekking op één van
de drie beheersaspecten tijd, geld en kwaliteit. Omdat deze aspecten elkaar beïnvloeden
worden ze ook wel de duivelsdriehoek genoemd. Er zijn vijf soorten acties die ondernomen
kunnen worden m.b.t. de risico's: acceptatie, preventie, reductie, overdracht en calamiteit.
Enkele veel voorkomende projectrisico's zijn:

geen duidelijke opdrachtgever

een onduidelijk doel

geen goed projectplan
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
Certificering
PRINCE2 kent een officiële certificering op twee niveaus: Foundation en Practitioner. Het
Foundation niveau is bedoeld voor projectmedewerkers, die niet noodzakelijkerwijs
projectleiding doen. Het Practitioner niveau is specifiek voor projectleiders. Verschillende
opleidingsinstituten bieden cursussen aan die voorbereiden op één van beide niveaus.
12-35
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
4 PROCESMODELLEN
Een ontwikkelmethode voor software is een structuur die je oplegt aan het
ontwikkelen van softwareproducten. Synoniemen hiervoor zijn ook wel
softwarelevenscyclus en softwareproces. Er zijn vele verschillende modellen voor dit
soort processen, waarbij elke een bepaalde aanpak beschrijft tot een bepaald aantal
taken of activiteiten die plaats vinden tijdens het proces [4] . Onderstaande
aandachtspunten spelen bij het kiezen van een “software development lifecycle
model” een belangrijke rol:

weet de klant precies wat hij wil?

is er veel kans dat requirements door het project heen (ingrijpend) zullen
veranderen?

is er veel kans dat de architectuur door het project heen vaak zal worden
aangepast?
13-35

moeten er tussentijdse opleveringen gebeuren?

wat is de verwachte doorlooptijd van het project?

wat is de grootte van het projectteam?
PROCESSEN EN META-PROCESSEN
Een groeiend aantal bedrijven implementeert softwareontwikkelmethodes. Veel van deze
bedrijven bevinden zich in de defensiesector, met name in de Verenigde Staten, waar deze
bedrijven een 'waardering' dienen te hebben om contracten te verkrijgen. ISO 12207 is een
standaard voor het omschrijven van een methode om een levenscyclus voor een project te
selecteren, implementeren en te controleren.
ISO 9000 omschrijft standaarden om processen formeel te organiseren en documenteren.
PROCESACTIVITEITEN
Software-engineeringprocessen zijn opgemaakt uit vele verschillende activiteiten,
voornamelijk de volgende.

Requirements Analyse
Het achterhalen van de vereisten van een benodigd softwareproduct is de eerste stap van
het maken ervan. Hoewel klanten waarschijnlijk denken te weten wat de software moet
doen, is er misschien vaardigheid en ervaring in software-engineering nodig om incomplete,
dubbelzinnige en tegenstellende requirements te herkennen.

Specificatie
Specificatie is de taak van het in detail beschrijven van de te schrijven software, op een
mathematisch rigoureuze wijze. In de praktijk, zullen de meest succesvolle specificaties
geschreven worden voor het begrijpen en optimaliseren van applicaties die reeds redelijk
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
doorontwikkeld waren, hoewel veiligheidskritieke software systemen meestal zeer doordacht
worden gespecificeerd alvorens het ontwikkelen van de applicatie.

Software Architectuur
Met de architectuur van een software systeem wordt een abstracte representatie van dat
systeem bedoeld. Architectuur houd zich bezig met het vaststellen van of een systeem de
requirements haalt van het op te leveren product, alsook zorgen voor het mogelijk maken
dat toekomstige requirements voldaan kunnen worden. De architectuur spreekt ook
interfaces aan tussen het systeem en andere software systemen, alsook de onderliggende
hardware en besturingssysteem.

Implementatie (of Programmeren)
Het reduceren van een ontwerp tot code mag misschien de meest voor de hand liggende
onderdeel zijn van een baan als software engineer, maar het hoeft niet noodzakelijk het
grootste onderdeel te zijn.

Testen
Het testen van (onderdelen van) software, met name wanneer twee of meer verschillende
ontwikkelaars samen werken, is een taak van de software engineer.

Documentatie
Een heel belangrijke (en vaak onderschatte en over het hoofd geziene) taak is het
documenteren van het interne ontwerp van software met als doel bij te staan bij toekomstig
14-35
onderhoud en verbeteringen. Documentatie is het meest belangrijke bij externe interfaces.

Software Training en Support
Een groot percentage van de software projecten gaan verkeerd omdat de ontwikkelaars niet
inzien dat het niet uit maakt hoeveel tijd en planning een team stopt in het maken van
software, als niemand in de organisatie het uiteindelijk ook daadwerkelijk gaat gebruiken.
Mensen zijn af en toe resistent tegen verandering en gaan het zich begeven op onbekend
terrein uit de weg. Dus als onderdeel van de Implementatie fase is het zeer belangrijk om
trainingen te geven aan de meest enthousiaste gebruikers (om opwinding en vertrouwen op
te bouwen), en deze training te verschuiven naar de neutrale gebruikers, gemengd met
gretige aanhangers, en als laatste de rest van de organisatie mee te krijgen om de nieuwe
software te accepteren. Gebruikers zullen vele vragen hebben en software problemen
tegenkomen wat leid tot de volgende fase van software.

Onderhoud
Onderhouden en verbeteren van software om om te kunnen gaan met nieuwe problemen of
nieuwe requirements kan veel meer tijd nemen dan de initiële realisatie van de software.
Het is niet alleen dat je misschien code moet toevoegen dat niet helemaal past in het
originele design, maar alleen al het bepalen hoe de software werkt en zich gedraagt nadat
het opgeleverd is en eventueel al veranderingen heeft ondergaan kan al veel moeite kosten
voor een ontwikkelaar. Ongeveer ⅔ van alle software ontwikkeling werk is onderhoud, maar
deze statistiek kan misleidend zijn. Een klein deel hiervan is maar het repareren van bugs.
Het meeste onderhoudswerk is het uitbreiden van systemen met nieuwe dingen, welke vaak
gezien kunnen worden als nieuw werk. Ter vergelijking, ongeveer ⅔ van alle civiele
techniek, architectuur en constructies werk is ook onderhoud op een vergelijkbare manier.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
PROCESMODELLEN
Al tientallen jaren probeert men voorspelbare processen te vinden voor het verbeteren van
productiviteit en kwaliteit. Sommige modellen proberen de onhandelbare taak van het
software proces te systematiseren en formaliseren. Anderen passen project management
technieken toe op het schrijven van software . Zonder project management kunnen software
projecten makkelijk te laat of buiten budget opgeleverd worden. Het feit dat veel software
projecten niet voldoen aan de eisen op het gebied van functionaliteit, budget en/of planning
bewijst dat project management erg lastig is.
Watervalmodellen
Het bekendste en oudste model is de Watervalmethode (uitgebreider in het volgende
hoofdstuk), waarbij ontwikkelaars (ongeveer) de volgende stappen achter elkaar uitvoeren:
15-35

Requirements opstellen en analyseren

Opstellen van een aanpak

Opstellen van een raamwerk voor de oplossing

Code schrijven

Testen

Uitrollen en onderhouden
Na elke stap wordt doorgegaan met de volgende stap. Net als bij het bouwen van een huis
wordt na het bouwen van de muren niets meer gedaan aan de fundering. Als er geen
iteratie in de planning is opgenomen kan er in principe niet meer teruggegaan worden naar
een eerdere stap om fouten te verbeteren. Op deze manier worden fouten pas opgelost in
de eindfasen van een project, waar het oplossen veel meer tijd, moeite en geld kosten.
Iteratieve methoden
Iteratieve ontwikkeling omschrijft een methodiek om de stappen van een project op te delen
in kleine stukken, om zo te voorkomen dat een project uitloopt in een ramp door problemen
of foute aannames.
Iteratieve processen hebben de voorkeur bij (commerciële) ontwikkelaars, omdat het de
mogelijkheid biedt om de juiste beslissingen te maken voor een klant die goed kan
omschrijven wat hij wil.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
Agile software ontwikkelings processen zijn gebaseerd op de grondbeginselen van iteratief
ontwikkelen. Bovenop deze basis hebben ze een meer op mensen gerichte blik dan
traditionele aanpakken. Agile processen gebruiken feedback in plaats van planning als
basis. De feedback word geleverd door regelmatige tests en het evolueren van de software.
Agile processen lijken efficiënter te zijn dan oudere 'traditionele' aanpakken, ze hebben
minder programmeertijd nodig om een product van hogere kwaliteit af te leveren, maar ze
hebben als nadeel dat het niet goed mogelijk is een lange-termijn planning te maken met
zulke procesmodellen. Het komt erop neer dat ze het meeste waar voor je geld bieden,
maar dat je nooit weet wanneer je je waar krijgt…
Extreme Programming (XP) is de bekendste Agile methode. Bij XP worden de fases in
extreem kleine stappen uitgevoerd in tegenstelling tot andere non-Agile modellen. De eerste
keer dat de stappen doorlopen worden kan een dag of een week duren, in tegenstelling tot
bijvoorbeeld het waterval model, waar een stap maanden of jaren kan duren. Als eerste
worden er automatische tests geschreven, om zo concrete doelen te hebben om naar te
ontwikkelen. Daarna wordt er, door programmeurs in paren, ontwikkeld totdat alle tests
doorlopen zijn en de ontwikkelaars geen nieuwe tests meer kunnen bedenken. Design en
architectuur komen voort uit refactoring en komen na het coderen. Het designen wordt
gedaan door dezelde mensen die ook ontwikkelen. Het werkende, maar incomplete
16-35
systeem wordt uitgerold en gedemonstreerd aan de gebruiker(s). Pas als het deel is
goedgekeurd door de gebruiker, wordt er doorgegaan met ontwikkelen aan het volgende
stuk van de software.
TDD is een softwareontwikkeltechniek die inhoudt dat er in een herhaling steeds een test
case wordt opgesteld en dan de code geschreven wordt die getest moet gaan worden.
TDD ontstond als een aspect van XP, maar is uitgegroeid tot een aparte ontwerpmethode.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
5 DE WATERVALMETHODE
17-35
De watervalmethode is een methode voor softwareontwikkeling (een proces voor de
verwezenlijking van software), waarin de ontwikkeling regelmatig vloeiend naar
beneden loopt (als een waterval). De ontwikkeling loopt door een aantal fasen
namelijk, Definitiestudie/analyse, basisontwerp, Technisch ontwerp/detailontwerp,
Bouw, Testen, implementatie en beheer en onderhoud. Over de oorsprong van de
term "waterval" wordt vaak gezegd dat W. W. Royce deze in 1970 introduceerde, maar
Royce zag zelf meer in de herhaalde benadering voor software ontwikkeling en
gebruikte zelfs niet de term "waterval". Royce beschreef het watervalmodel als een
methode die hij gewaagd en zelfs een uitnodiging voor mislukking vond [5] .
Voorheen was het ontwikkelen van vooral grote softwareprojecten een groot
onoverzichtelijk breiwerk. Met de komst van deze nieuwe methode hoopten de
informaticabedrijven meer duidelijkheid te krijgen in hun projecten.
Het watervalmodel is afgeleid van de traditionele manier van werken in grote projecten in de
constructiebouw. De bedoeling van deze manier van werken is dat je het project in
verschillende fasen opdeelt. Je begint met fase 1 en begint niet eerder met fase 2 dan
wanneer je fase 1 hebt afgesloten. En wanneer je in een van de fasen een fout ontdekt
moet je helemaal terug om die fase te corrigeren en de daaropvolgende stappen opnieuw
uitvoeren.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
FASEN
Het watervalmodel bestaat uit de volgende fasen:

Definitiestudie/analyse. Er wordt onderzoek gedaan naar en gebrainstormd over
de software om duidelijk te krijgen wat het doel is van de software.

Basisontwerp. Er wordt duidelijker uitgewerkt wat er tijdens de eerste fase naar
boven is gekomen. In deze fase worden de wensen van de klant op papier gezet
en wordt er al gedacht aan de vorm van het programma. In deze fase wordt
vastgelegd wat het op te leveren systeem moet doen.

Technisch ontwerp/detailontwerp. Aan de hand van het basisontwerp kan er een
werkelijk programma uitgedacht worden. In deze fase wordt vastgelegd hoe de in
het basisontwerp vastgelegde functionaliteit gerealiseerd gaat worden. Nu vindt
ook een onderverdeling plaats in technische eenheden zoals programma's,
modules en functies.

Bouw/implementatie. Hier wordt de broncode van de programma's geschreven.

Testen. Er wordt gecontroleerd of de software goed volgens de ontwerpen is
gebouwd. Ook kunnen er in deze fase fouten boven water komen die al in eerdere
stadia gemaakt zijn.
18-35

Integratie. Het systeem is klaar en getest. Toch zal het nog in het bedrijf in gebruik
genomen moeten worden. Dat wordt gedaan in deze fase.

Beheer en onderhoud. Om er voor te zorgen dat het systeem het blijft doen zal er
onderhoud verricht moeten worden.
Schematisch overzicht van de watervalmethode
Het waterval model bestaat uit verschillende fasen. Iedere fase heeft een eigen niveau dat
tevens de volgorde bepaald. Het hoogste niveau wordt als eerste uitgevoerd en vervolgens
de lagere fasen. Dit is gelijk aan de natuurlijke werking van een waterval en vandaar ook de
naam. Hierboven is goed te zien dat de verschillende fasen van boven naar beneden lopen.
VOORDELEN

Wanneer in het begin van het project fouten worden ontdekt, kost het minder
inspanning (en dus tijd en geld) om deze fout te herstellen. Bij het watervalmodel
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
wil men alle fasen eerst goed afsluiten voordat men verder gaat met de volgende
fase. Men gaat er vanuit dat de fasen altijd goed zijn voordat men verder gaat met
een volgende fase.

Bij het watervalmodel legt men de nadruk op documentatie. In de nieuwere
software ontwikkelingsmethoden maakt men minder documentatie. Dit heeft tot
gevolg dat als er nieuwe mensen in het project opgenomen worden en er mensen
weggaan het lastig is om de kennis over te dragen. Dit nadeel heeft de klassieke
watervalmethode niet.

Het is een rechttoe-rechtaan methode. De manier van werken zorgt ervoor dat er
zich concrete fasen vormen. Hierdoor weet men in welke fase zij zit.

Men kan in deze methode gebruikmaken van mijlpalen. Mijlpalen kunnen worden
gebruikt om de voortgang van het project in te schatten.

De watervalmethode is erg bekend. Veel mensen hebben er ervaring mee, dus
kunnen er gemakkelijk mee gaan werken.
NADELEN
Er zijn een aantal nadelen van deze manier om software te ontwikkelen.

Veel softwareprojecten zijn afhankelijk van externe factoren. De opdrachtgever is
een hele belangrijke externe factor. Vaak zullen de requirements gedurende de
19-35
loop van het project wijzigen, omdat de opdrachtgever iets anders wil. Het is dus
een nadeel dat de watervalmethode er van uit gaat dat de requirements niet
veranderen tijdens het project. Wanneer in de bouwfase een requirement
verandert, moeten een heel aantal fases opnieuw gemaakt worden.

Het is erg moeilijk om de benodigde tijd en de kosten te schatten. De fasen zijn erg
groot, het is daarom erg lastig om in te schatten hoeveel elke fase kost.

Bij veel softwareprojecten werken verschillende mensen aan de verschillende
fasen van het project. Bijvoorbeeld: de ontwerpers en de bouwers. Ze hebben
allemaal een andere kijk op het project: zo kijken ontwerpers anders tegen het
project aan dan de bouwers. Omgekeerd zullen de bouwers ook vaak anders
tegen het ontwerp van de ontwerpers aankijken dan de ontwerpers zelf. Vaak is
het zo dat het ontwerp weer aangepast zal moeten worden. Hier is de
watervalmethode niet voor gemaakt.

Binnen het project zijn de verschillende teamleden vaak gespecialiseerd. Het ene
teamlid zal zich alleen in de eerste fase bezig houden met het ontwerpen, terwijl
de bouwers alleen in bouwfase helpen aan het bouwen van het project. Dit kan
leiden tot verspilling van verschillende bronnen. De belangrijkste bron is wel de tijd.
Een voorbeeld: de ontwerpers zijn bezig met het perfectioneren van het ontwerp.
De bouwers kunnen in principe al beginnen met bouwen, maar omdat ze werken
met het watervalmodel moeten ze wachten totdat de eerste fase is afgesloten. Dit
een typisch voorbeeld van tijdsverspilling.

Wanneer frequent gedeelten van het software product worden opgeleverd geeft dit
de klant vertrouwen, maar ook het software ontwikkelingsteam.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten

Het testen gebeurt pas in één van de laatste fasen van het project. Bij veel andere
softwareontwikkelingsmethoden wordt er getest zodra er één bepaald deelproduct
klaar is en ook wordt er op het laatst een integratietest gedaan.

Doordat er zoveel nadruk wordt gelegd op documentatie, is de watervalmethode
niet efficiënt voor kleinere projecten. Er zit dan te veel werk om het project zelf
heen qua documentatie.
VERNIEUWDE WATERVALMETHODEN
Om zoveel mogelijk gebruik te maken van de voordelen en zo weinig mogelijk last te
hebben van de nadelen zijn er een aantal vernieuwde watervalmethoden ontwikkeld.
Hieronder worden er een aantal genoemd.
Het "sashimi" model
20-35
Schematisch overzicht van de sashimi watervalmethode met overlappende fasen.
Het sashimi model is opgezet door Peter Degrace. De fasen zijn hetzelfde als in het
traditionele watervalmodel, alleen nu overlappen de fasen elkaar ook. Door gebruik te
maken van deze methode worden er veel minder bronnen verspild. (Zie een nadeel.) De
afbeelding hierboven geeft weer hoe de fasen elkaar overlappen. Dit is echter een illustratie
en dit geeft dus niet de werkelijke overlapping weer qua verhouding! Het verschil met het
schematische overzicht van de standaard waterval methode is dat de fasen deze keer
tegen de doorlooptijd afgedrukt zijn. Dit betekent dat men bijvoorbeeld al begint met het
ontwerp terwijl de analyse nog bezig is. Dit betekent ook dat men terug kan vallen op de
analyse in de ontwerpfase.
Het AORTA lifecycle model
Het Aorta lifecycle-model is een software ontwikkelmethode volgens de watervalmethode,
maar na elke cyclus vindt een terugkoppeling naar de klant plaats.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
6 RATIONAL UNIFIED PROCESS
RUP is een uitgebreide verfijning van het generieke Unified Process (UP) en is
ontwikkeld door Rational Software Corporation welke nu een divisie is van IBM.
De wortels van het Rational Unified Process (RUP) liggen in het originele
spiraalmodel van Barry Boehm. Ken Hartman, één van de belangrijkse RUPbedenkers, ging samenwerken met Boehm op grond van praktijk- en
literatuuronderzoek. De eerste versie van Rational Unified Process V5 werd
uitgegeven in 1998. [4]
TOTSTANDKOMING RUP
De bedenkers en ontwikkelaars van RUP hebben zich gefocust op het analyseren van de
karakteristieken waardoor projecten mislukken. Hierdoor konden ze de hoofdproblemen
herkennen waardoor projecten vaak mislukken. Op deze lijst staan bijvoorbeeld:
21-35

Ad hoc requirements

Vage, dubbelzinnige en onduidelijke requirements

Overmatige complexiteit

Onvoldoende testen
De uitkomst van hun onderzoek was een verzameling van best practices die ze hadden
afgeleid van de projecten die wel slaagden. Deze best practices samengevoegd is wat het
nu genoemd wordt: Rational Unified Process.
FILOSOFIE ACHTER RUP
RUP is gebaseerd op een aantal principes en best practices, zoals:

Ontwikkel software incrementeel/iteratief
Gezien de tijd die het kost om grote softwaresystemen te bouwen, is het niet
mogelijk om een heel systeem in één keer te maken. Requirements kunnen
veranderen in de loop van het traject door technische beperkingen, veranderende
eisen/wensen of een beter begrip van het daadwerkelijke probleem. Iteratief
ontwikkelen stelt je in staat om het project op te delen in een aantal deelproducten
en deze afzonderlijk van elkaar op te leveren. Dit verkleint het risico dat het
eindproduct niet is wat de klant wil en de klant kan nu per deelproduct zijn
feedback geven wat je weer kunt meenemen tijdens de ontwikkeling van het
volgende deelproduct.

Management van software requirements
Requirements management heeft te maken met het achterhalen, vastleggen en
beheren van de behoeften van de klant. Daaronder vallen de volgende activiteiten:
o
Analyseer het probleem
o
Definieer wat de klant wil
o
Definieer het op te leveren systeem
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten

o
Beheer de randvoorwaarden van het systeem
o
Verfijn de systeemeisen/systeemomschrijvingen
o
Beheer de wijzigende requirements
Maak gebruik van op component gebaseerde architectuur
Systemen met een op componenten gebaseerde architectuur zijn eenvoudig uit te
breiden, inzichtelijk, begrijpbaar en bevorderen het hergebruik van bepaalde delen
code. Aangezien de systemen steeds groter worden neemt de belangrijkheid van
een goede architectuur toe. RUP is erop gericht de basisarchitectuur in een vroeg
stadium te bepalen, en naarmate het systeem groter wordt zal de architectuur zich
verder uitbreiden. Bij iteratief ontwikkelen is het mogelijk de componenten
geleidelijk aan in kaart te brengen om ze vervolgens te ontwikkelen, te kopen of te
hergebruiken.

Maak prototypes
Door de gebruiker een grafische voorstelling te geven van het product
(prototyping), verkleint de faalkans van het project. Een globale, grafische
oplossing voor het probleem is door de gebruiker beter te begrijpen dan pagina's
vol broncode. Het is een versimpeling van de complexiteit. Naast prototypes
komen in deze fase ook use cases, klassediagrammen en andere objecten naar
voren.
22-35

Test het systeem
Het bepalen van de kwaliteit van een systeem gebeurt op basis van testen. Dit is
een van de punten waarop software projecten vaak falen omdat het testen vaak
aan het einde van het project wordt gedaan, soms helemaal niet en soms door
andere teams. RUP vangt dit probleem af door het testen in het gehele proces
terug te laten komen en daarbij alle stakeholders te betrekken (zowel
programmeurs als klanten). RUP gaat er vanuit dat elke stakeholder
verantwoordelijk is voor de kwaliteit gedurende het gehele project.

Maak gebruik van versiebeheer tijdens de software ontwikkeling.
Zoals bij alle andere softwareprojecten zijn veranderingen in de software
onvermijdelijk. RUP beschrijft een aantal methoden om deze veranderingen te
beheersen en nauwkeurig te volgen. RUP beschrijft ook beveiligde werkruimtes,
hierin staat bijvoorbeeld dat het systeem van een programmeur niet aangetast
mag worden door veranderingen in een ander systeem.
FASERING
Het RUP voorziet een verdeling van elk project in 4 hoofdfases :
1.
Inceptiefase (Aanvang)
De haalbaarheid van het project, de inhoud (scope) en de begrenzingen
worden bepaald. Gedurende de inceptiefase wordt het oorspronkelijke idee
omgezet in een produktvisie (vision). De business drivers worden gereviewed
om ze helder te krijgen. De globale kostprijs en de verwachte baten van het
project worden geschat. De belangrijkste risico's worden geïdentificeerd en
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
ingeschat. Het uiteindelijke doel van deze fase is een haalbaarheidsstudie
(business case) voor het project.
2.
Elaboratiefase (Detaillering)
Het merendeel van de functionele requirements (use cases) wordt
gespecificeerd en de systeemarchitectuur wordt ontworpen. De focus ligt op
de technische haalbaarheid van het project. Uiteindelijke doel van deze fase
is een projectplan, waarin o.m. de gedetailleerde inhoud (scope), timing
(schedule) en kostenraming (estimations) voor het project zijn opgenomen.
3.
Constructiefase (Bouw)
Het product wordt ontwikkeld vanaf de architectuur tot een systeem dat
compleet genoeg is om te testen.
4.
Transitiefase (Overgang)
Via testen wordt het product gevalideerd door de stakeholders. Andere
activiteiten in deze fase zijn: voorbereiding en inproductiestelling (deploy),
nazorg, en overdracht van de verantwoordelijkheden. Deze fase wordt
afgesloten met een inventarisatie van de opgedane ervaringen (lessons
learned) voor volgende projecten.
23-35
RUP is een iteratief proces wat inhoud dat testen in verschillende fasen van het project
kunnen plaatsvinden. Dit maakt het mogelijk om fouten in een vroeg stadium van het project
op te sporen en zorgt ervoor dat de kosten voor herstelling zo laag mogelijk blijven. Hoe
later een fout wordt ontdekt, hoe hoger de kosten voor herstelling.
De meeste testen zullen in principe plaatsvinden in de constructiefase.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
24-35
7 EXTREME PROGRAMMING
eXtreme Programming (ook wel XP genoemd) is een
softwareontwikkelingsmethodiek en een vorm van agile software-ontwikkeling. De
belangrijkste grondleggers van eXtreme Programming zijn Kent Beck, Ken Auer,
Ward Cunningham, Martin Fowler en Ron Jeffries. Zij omschrijven XP als "a
humanistic discipline of software development, based on principles of simplicity,
communication, feedback, and courage".
ONTWIKKELPRINCIPES
XP is een methodiek die vooral geschikt is voor projecten waarbij de exacte applicatie-eisen
niet bij voorbaat vastliggen. EXtreme Programming dankt zijn naam aan het feit dat een
aantal beproefde ontwikkelprincipes tot in het extreme worden door gevoerd. Voorbeelden
zijn:

Als het goed is dat ontwikkelaars code bij elkaar reviewen, doe het dan
voortdurend: ontwikkel alle software in koppels. Met andere woorden, twee
mensen achter één computer.

Als testen goed is, schrijf dan unit tests en voer ze iedere keer uit als er ook maar
een regel code is veranderd.

Als ontwerpen goed is, maak het dan onderdeel van ieders dagelijks werk:
verbeter het ontwerp stapsgewijs, zodra de noodzaak zich voordoet.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten

Als eenvoud goed is, houd dan het ontwerp zo simpel mogelijk. XP werkt veel met
het KISS (Keep It Simple Stupid!) principe.

Als architectuur zo belangrijk is, laat dan iedereen werken aan het ontwikkelen van
de architectuur.

Als integratietesten belangrijk is, integreer de code dan zo vaak mogelijk, liefst
meerdere keren per dag.

Als korte iteratieslagen goed zijn, maak ze dan werkelijk heel erg kort: seconden,
minuten, uren, in plaats van weken, maanden, jaren.
Geen van deze `best practices' zijn uniek voor XP. Stuk voor stuk zijn ze decennia geleden
al vele malen toegepast.
BEST PRACTICES
De optimale kracht van XP komt voort uit het in samenhang toepassen van twaalf best
practices, doordat deze elkaar versterken. Elke andere softwareontwikkelmethode zal ook
voordeel hebben bij het toepassen van één of meerdere genoemde best practices.
XP is gebaseerd op de volgende twaalf best practices:
25-35
1.
gebruik een zo simpel mogelijk ontwerp dat werkt;
2.
schrijf eerst de testcode ('unit test') voordat je functionaliteit codeert;
3.
continue herstructurering ('refactoring') van de programmacode;
4.
continue integratie van alle programmacode;
5.
iedere ontwikkelaar heeft gelijke rechten over alle programmacode;
6.
iedere ontwikkelaar gebruikt dezelfde codeerstandaard;
7.
programmeurs werken in paren ('pair programming');
8.
de klant is onderdeel van het ontwikkelteam en moet dus continu voor vragen
beschikbaar zijn;
9.
de software wordt in een vaste regelmaat in releases van beperkte omvang aan de
klant opgeleverd voor beoordeling;
10. ontwikkelaars plannen aan de hand van kleine brokjes functionaliteit ('user
stories');
11. alle teamleden (ontwikkelaars en de klant) delen een gemeenschappelijk beeld
van het systeem ('metafoor');
12. overwerken is een uitzondering.
NADELEN
Er worden vanuit de praktijk ook nadelen van XP onderkend:
1.
De belangrijkste is misschien wel dat het niet eenvoudig is XP in te voeren. Omdat de
verschillende elementen van XP zo op elkaar ingrijpen, wordt er alleen een goed
resultaat bereikt als ze allemaal worden toepast.
2.
Er is nog relatief weinig ervaring met XP.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
3.
Code ontwikkelen met enkel oog voor de wensen van de gebruikers kan problemen
geven wanneer een einddoel in het oog moet worden gehouden. Het einddoel kan
ondersneeuwen met de tijdelijke doelen van de te realiseren iteraties. Dit leidt
gemakkelijk tot uitloop van de oplevering van het uiteindelijke systeem. Veel aandacht
van de projectleider is vereist om dit nadeel van XP te managen.
4.
Bovenstaande heeft ook zijn weerslag op de verwachtingen van de opdrachtgever.
Deze dienen eveneens aandacht te krijgen zolang XP nog geen bekende
ontwikkelmethodiek is.
5.
Niet elke ontwikkelaar is een teamspeler. Om volgens de principes van XP te werken
zal zorgvuldig een team moeten worden samengesteld. Twee junior ontwikkelaars bij
elkaar of twee eigenwijze ontwikkelaars zullen niet de beoogde programmatuur
opleveren.
6.
Er dienen strakke afspraken gemaakt te worden omtrent de gebruikersparticipatie om
enige vorm van vrijblijvendheid in de kiem te smoren. Het schrijven van unit test moet
de uitgangsituatie zijn en blijven voor het ontwikkelen van programmatuur. Wanneer
gebruikers niet in staat zijn geweest unit tests te schrijven en ontwikkelaars toch
doorgaan met ontwikkelen, onstaat een systeem waar niet door de gebruikers over is
nagedacht.
26-35
7.
Verwachte problemen bij het ontwikkelen van standaardpakketten en in combinatie met
legacy-code.
Er is een aantal zeer succesvolle projecten bekend, maar er wordt betwijfeld of deze
projecten succesvol waren vanwege de kwaliteiten van de mensen die er aan mee deden of
vanwege de kwaliteit van XP.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
8 SCRUM
Scrum is een framework voor het agile managen van softwareontwikkeling. Je werkt
in multidisciplinaire teams die in korte sprints (iteraties) werkende software
opleveren. Samenwerking, communicatie en teamspirit zijn hierbij sleutelwoorden.
Scrum is een term die afkomstig is uit de rugbysport, hierbij staan de spelers in een
grote groep en proberen ze al duwend de bal naar de overkant van het veld te
brengen. Er wordt dus niet afgewacht of de vorige fase afgelopen is maar er wordt
tegelijkertijd gewerkt.
GESCHIEDENIS
Scrum werd geïntroduceerd in een onderzoek door Ikujiro Nonaka en Hirotaka Takeuchi dat
begin 1986 in de Harvard Business Review gepubliceerd is. In dit onderzoek wordt
beschreven dat projecten met kleine (cross-functional) teams historisch gezien het beste
resultaat leveren. Naar aanleiding van dit onderzoek ontwikkelde Jeff Sutherland in 1993 het
scrum-proces, terwijl Ken Schwaber een eigen benadering bij zijn bedrijf toepaste. Samen
27-35
werkten ze dit verder uit en in 1995 formaliseerde Ken Schwaber scrum als software
ontwikkelmethode.
DOELSTELLINGEN





Verhogen van de effectiviteit van het team
Het bewaken van de vooruitgang van het team
Het oplossen van blokkades
Het bewaken van de projectvoortgang
In kaart brengen en minimaliseren van de risico's
WERKWIJZE
Bij de watervalmethode heeft iedere fase experts. Die voeren hun taak uit en dragen het
resultaat over naar de experts voor de volgende fase. Bij scrum zet je de experts uit de
verschillende fasen bij elkaar in één team. Een Scrum team bestaat uit maximaal zeven
spelers.
Het team wordt geleid door de Scrum-master en houdt dagelijks bij aanvang van de
werkdag een zogenaamde scrum-meeting (ook wel standup-meeting genoemd). In deze
meeting, die maximaal 15 minuten duurt, beantwoordt elk teamlid de volgende drie vragen:

Wat heb je gedaan?

Wat ga je doen?

Wat zijn je problemen?
Daarna gaat men weer aan het werk om de opdracht te volbrengen. De personen werken
veel samen en pakken het project aan met zijn allen en zullen er voor zorgen dat het project
ook slaagt.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
Een project volgens de Scrum principes begint met een ‘fase 0’ (ook wel Pre-game Planning
& Staging), waarin de product backlog wordt samengesteld. Daarna wordt in overleg met de
opdrachtgever / product owner de eerste iteratie afgesproken, in de vorm van een (eerste)
Sprint Backlog. Een ‘Sprint’ duurt twee tot vier weken. Iedere Sprint levert een ‘potentially
28-35
shippable product’ op.
VOORDELEN

Doordat er iedere dag een scrum-meeting is en er veel communicatie is zal de teamspirit
hoog zijn en zal iedere persoon voor elkaar willen werken.

Doordat er veel tegelijk gebeurt zal de tijd waarin het project zal worden afgerond korter zijn
dan bij andere methodes.

Omdat iedereen weet wat er speelt en wat eventueel een probleem is, kan iedereen elkaar
ook direct helpen, zonder eerst te wachten op een andere fase.
In het boek van Craig Larman, Agile & Iterative development. A Manager’s Guide, komt in
hoofdstuk 7 Scrum uitgebreid aan bod.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
9 DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)
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.
INLEIDING
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
29-35
aangepast kunnen worden. Verder wordt de 80/20 implementatie regel 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 is 80% gedaan door de
implementatie van de belangrijkste 20% van de requirements. In sommige gevallen is het
mogelijk om practices van andere softwareontwikkelmethoden te gebruiken zoals RUP, XP
of PRINCE2. Een agile methode die overeenkomsten heeft met de processen en het
concept van DSDM is Scrum.
De slogan van DSDM is dan ook:
Not all projects will be full DSDM...but
You can use SOME of DSDM ALL of the time
You can use ALL of DSDM SOME of the time
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
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
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.
TOEPASSING VAN 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.”
KENMERKEN VAN DSDM
Een kenmerk van DSDM is dat het volledig onafhankelijk is van leveranciers,
30-35
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.
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:
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten

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.
DSDM richt zich op elk van de bovengenoemde situaties, en probeert deze te voorkomen.
MOSCOW
De afkorting MoSCoW staat voor de relatieve gewenstheid van de diverse onderdelen van het
gewenste systeem:
31-35

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..
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.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
10 EVO
Evolutionary Project management (EVO) is misschien wel de oudste sofwareontwikkelmethode gebaseerd op Agile principes en adaptieve kwaliteiten. Al in de
jaren ’60 kwam de methode voor, en vanaf 1976 werd voor het eerst over Evo
gepubliceerd.
KARAKTERISTIEKEN
EVO kent de volgende karakteristieken:





32-35
Zeer korte iteraties (één, maximaal twee, weken).
Evolutionaire requirements en ontwerp
Adaptieve, klantgestuurde, planning
Kwantificeerbare meetresultaten (‘performance requirements’)
Kwalitatieve requirements met numerieke metingen
WERKWIJZE
EVO onderscheidt een aantal niveaus waarop wordt gewerkt. Al deze niveaus hebben hun
eigen cyclus.
Het eerste niveau is op het Strategisch management. Op dit niveau worden doelen
geformuleerd, naar oplossingen gezocht en een volgende iteratie afgesproken.
Het tweede niveau is de Productiecyclus. Hierbij wordt onderscheid gemaakt in de frontroom
en de backroom. In de frontroom worden producten klaargemaakt voor directe oplevering
aan het einde van de iteratie. In de backroom vinden grotere taken, integratie en
ontwikkelingen plaats, die niet direct, maar pas in een latere fase worden opgeleverd.
Het derde niveau is de opleveringscyclus: iedere week bevindt zich iets in de Frontroom, dat
na afloop van een iteratie ook daadwerkelijk wordt opgeleverd.
Het vierde en laatste niveau is de ontwikkelingscyclus. Dit zijn de zogenaamde backroomactiviteiten.
PROCEDURES
In tegenstelling tot bijvoorbeeld Scrum, kent EVO weinig voorgeschreven procedures, en
weinig documentatie. Het belangrijkste document is het adaptieve Evo Plan, waarin een top
10 van Function requirements specs en Performance requirements specs wordt
opgenomen en bijgehouden.

One page summaries
Wel documentatie, maar nooit meer dan één A4, is de filosofie.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
11 BEST PRACTICES, TOOLS EN
TECHNIEKEN
Wanneer je een projectmanagementmethode gekozen hebt en een procesmodel
blijven er soms nog keuzes over voor bepaalde best practices, tools en technieken.
Dit hoofdstuk geeft een kleine bloemlezing van bruikbare hulpmiddelen die vaak niet
afhankelijk zijn van een bepaald model of methode [4] .
WANNEER WELKE METHODE?
Na alles gelezen en bekeken te hebben moet je op een gegeven moment zelf de keuze maken voor
een model. In het onderstaande overzicht hebben we voordelen, nadelen en toepasbaarheid van een
aantal modellen nog eens op een rijtje gezet [11] .
33-35
Methode
Voordelen
Nadelen
Waterval


Maakt het plannen een stuk
makkelijker en de personele
bezettingen zijn makkelijk te


Klantwensen moeten bijna volledig
bekend zijn en niet meer wijzigen.

De functionele en
organiseren.
ontwerpbeslissingen worden
Beperkt het aantal
genomen op een moment dat er
veranderingsmogelijkheden aan
nog het minst bekend is over het
het ontwerp van het project.
product.
Specificaties van testcases zijn

bekend voordat het daadwerkelijke
testen begint.
Testen van product kan pas laat in
ontwikkelproces.

Er is geen weg terug, als er een
keuze gemaakt is kan deze in de
testfase moeilijk terug worden
gedraaid daardoor is het mogelijk
dat opgeleverde systemen niet
bruikbaar zijn voor de klant.

Wanneer de ontwikkeling uitloopt
wordt vaak testtijd opgeofferd, dit
komt vaak niet ten goede aan het
systeem.

Naarmate het project vordert
neemt het risico toe.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
Methode
Voordelen
Nadelen
Incrementeel


Klant kan al gebruik maken van
Globale klanteisen moeten van te
een deel van de functionaliteit
voren duidelijk zijn. Detailwensen
tijdens duur van het gehele project.
van increment één moeten wel

Flexibeler dan watervalmodel.

Maakt het plannen relatief
duidelijk zijn.

Aan het eind van een increment
makkelijk en de personele
moet klant wel weten wat de detail
bezettingen zijn makkelijk te
eisen zijn voor het volgende
organiseren.
increment.

Project moet wel op te delen zijn in
incrementen/brokken functionaliteit

Goede planning noodzakelijk,
incrementen hebben onderlinge
afhankelijkheid dus moeten op
elkaar afgestemd worden.
Wannneer dit niet gebeurd is extra
inspanning nodig om zaken op
elkaar te laten aansluiten.

34-35
Eindgebruiker heeft vaak geen
behoefte aan veranderingen of
aanpassingen.
Evolutionary

Prototyping

Klant kan al gebruik maken van

een deel van de functionaliteit
hoeveelheid inspanning om een
tijdens duur van het project.
bepaald resultaat te bereiken
Feedback van klant kan tijdens de
onzeker is.
ontwikkeling verwerkt worden in

Vaak geen goede architectuur.
het systeem en sluit daardoor beter

Weinig tot geen documentatie “op
papier”.
aan bij wat de klant wil.

Moeilijk om te plannen omdat de
Energie dat in een prototype

Kan uitmonden in een “Build and
gestoken wordt is niet voor niks.
Fix” applicatie met slechte

Sneller dan het waterval model.
structuur in de code

Klant is al erg betrokken in een

vroeg stadium van het project.

Management ziet eerder het nut
in.

klantwensen.

Talen die zich goed lenen voor
Problemen kunnen al vroeg
prototyping zijn niet altijd geschikt
gesignaleerd worden en dit is dus
voor de uiteindelijke applicatie.
risico verlagend.

“Einde” project moeilijk te bepalen
door eventueel steeds wijzigende
Testen speelt een grote rol in het
ontwikkelingsproces

Onderhoud kost vaak meer
inspanning en dus ook geld.
Projectmatig werken
en Procesmodellen 2.0
Dictaat op basis van Wikipedia teksten
BRONNEN
[1]
CAP GEMINI ACADEMY
http://academy.capgemini.nl/Clusters.aspx?menuid=16&clusterid=31
[2]
HANS HUMMEL E . A., “PROJECTWIJZER ”, ISBN 9789001577964
[3]
GRAIG L ARMAN , “APPLYING UML AND P ATTERNS ”, ISBN 9780131489066
[4]
WIKIPEDIA
http://nl.wikipedia.org
[5]
EDWIN DE GROOT, “SOFTWAREKWALITEIT VAN MDA TOOLS ”, AFSTUDEERSCRIPTIE
UV A, 2005
http://homepages.cwi.nl/~paulk/thesesMasterSoftwareEngineering/EdwinDeGro
ot.pdf
[6]
DARTS, ftp://ftp.sei.cmu.edu/pub/education/cm22.ps
[7]
GOOMA, H. “A S OFTWARE DESIGN M ETHOD FOR REAL TIME S YSTEMS .” COMM . ACM
27, 9 (SEPT. 1984), 938-949.
[8]
GOOMA, H. “SOFTWARE DEVELOPMENT OF REAL TIME S YSTEMS .” COMM . ACM 29, 7
(J ULY 1986), 657-668
35-35
[9]
GOOMA, H. “USING THE DARTS SOFTWARE DESIGN M ETHOD FOR REAL TIME
SYSTEMS .” PROC. 12 TH S TRUCTURED M ETHODS CONF. C HICAGO : STRUCTURED
TECHNIQUES ASSOCIATION , AUG. 1987, 76-90
[10]
INDORA AUTOMATISERING , PROJECTMANAGEMENTMETHODEN OP EEN RIJ ,
http://www.indora.nl/mambo/images/stories/Downloads/WPP3%20Projectmanag
ementmethoden%20op%20een%20rij.PDF
[11]
LUC TIEMESSEN & TOM VAN G ESSEL, 2003, SOFTWARE E NGINEERING,
AFSTUDEERSCRIPTIE
[12]
TOM GILB, 1976, SOFTWARE METRICS