Auteurs Tim Lansbergen Jan Los Richard Lagewaard Ruben van der Tas Datum 11-4-2012 Hogeschool Rotterdam, Business, IT & Management Opdrachtgever: B&S Dordrecht Begeleider B&S: Rik van Loo Begeleider school: Ed Monteiro Beheer wijzigingsproces Dordrecht, juni 2012
Voorwoord Op de Hogeschool Rotterdam vindt in het 2e jaar van de opleiding Bedrijfskundige Informatica (of tegenwoordig: Business, IT & Management) project 7/8 plaats. Tijdens dit project plegen wij onderzoek op de ICT-afdeling van het bedrijf B&S in Dordrecht. Dit adviesrapport is geschreven als projectopdracht. De aanleiding van dit project is het feit dat het proces voor verwerking van wijzigingsverzoeken (Request For Change, of RFC) niet vlekkeloos verloopt. Wij zullen aan de hand van een onderzoek een adviesrapport opstellen Onze opdrachtgever is de heer T. Vennema en begeleider de heer R. van Loo. De begeleider vanuit Hogeschool Rotterdam was de heer M. Er en is vervangen door de heer E. Monteiro. Deze personen zullen uiteindelijk het onderzoeks- en adviesrapport gaan keuren en hier een oordeel over geven. Wij willen R. van Loo en E. Monteiro expliciet bedanken voor hun ondersteuning en begeleiding De projectgroep wordt geleid door Tim Lansbergen. Ruben van der Tas is verantwoordelijk voor het projectdossier, Jan Los is proces- en financieel deskundige en Richard Lagewaard zorgt voor allround ondersteuning. De keuze is gevallen op B&S Dordrecht omdat B&S deskundige werknemers in dienst heeft die geïnteresseerd zijn in onze opdracht en daarbij ook een steentje hebben bijgedragen. Wij proberen de zaak vanuit verschillende oogpunten te bekijken om een zo goed en efficiënt mogelijk advies te kunnen aanbieden. Dordrecht, 12 april 2012 Tim Lansbergen, Ruben van der Tas, Jan Los, Richard Lagewaard 2
Managementsamenvatting Projectgroep SITA heeft voor B&S een onderzoeksrapport opgesteld waarin onderzoek werd gedaan naar het proces van het verwerken van een wijzigingsverzoek. Er werden 3 knelpunten gevonden. Deze knelpunten waren: Blauwdrukken komen niet op papier te staan` Meldingen blijven te lang in de wachtrij staan Communicatie met Delfzijl wat betreft integratie database Voor deze knelpunten zijn de volgende oplossingen bedacht: - Blauwdrukken Voor het knelpunt van de blauwdrukken adviseert SITA om het werk van de programmeur te verminderen en over te dragen aan andere partijen. In het nieuwe proces komt een functioneel ontwerper die voor elk wijzigingsvoorstel een analyse gaat uitvoeren. Uit een informatie- en business analyse wordt een functioneel ontwerp gemaakt. Dit ontwerp gebruikt de programmeur om de wijziging te programmeren. - Meldingen blijven lang in de wachtrij staan Er bestaan meldingen die al een aantal jaar in de wachtrij staan, daardoor zullen deze meldingen mogelijk niet meer relevant zijn en zullen wellicht niet meer worden behandeld. Door het maken van een functioneel ontwerp voor een wijzigingsvoorstel, bespaart dit de programmeur tijd. Deze extra tijd kan de programmeur gebruiken om meer wijzigingen te programmeren. Hierdoor zal de wachtrij voor wijzigingen reduceren en kunnen er meer wijzigingen worden doorgevoerd. Andere oplossingen zijn dat een wijzigingsformulier voortaan gestructureerd is. Een gebruiker kan een formulier invullen, zodat duidelijker wordt omschreven wat de gebruiker wil met de wijziging. Ook wordt een wijziging voortaan geïmplementeerd door de ICT medewerker. Dit scheelt de programmeur tijd die hij nodig heeft voor het programmeren van de wijziging. Als laatste oplossing wordt het proces aangepast. De functioneel ontwerper maakt bij zijn ontwerp een testplan. Aan de hand van dit testplan kan de programmeur beter de geprogrammeerde wijziging testen en controleren of het voldoet aan de gestelde eisen. - Integratie met Delfzijl Na onderzoek is gebleken dat B&S locatie Dordrecht weinig integratie heeft met de werkzaamheden binnen Holland Trading Group Delfzijl. Hierdoor is het niet mogelijk ons advies door te voeren op locatie Delfzijl. 3
Inhoud 1. Inleiding... 5 1.1 Methode... 5 1.2 Leeswijzer... 5 2. Functieprofiel... 6 2.1 Functies... 6 2.2 Organigram... 7 2.3 Stakeholders... 7 3. Verbetering knelpunten... 8 3.1 Blauwdrukken worden niet uitgewerkt op papier... 8 3.2 Meldingen blijven te lang in de wachtrij staan... 8 3.3 Structureren van wijzigingsformulieren... 8 3.4 Implementeren door ICT-medewerker... 9 3.5 Testen aan de hand van testplan... 9 3.6 Integratie met Delfzijl... 9 4. Nieuw proces RFC... 10 5. Nieuw procesbeschrijving RFC... 12 6. Conclusie / aanbeveling... 14 7. Literatuurlijst... 16 4
1. Inleiding In dit adviesrapport zal een advies geformuleerd worden voor het verbeteren van het proces van verwerking van de wijzigingsverzoeken (vanaf hier genoemd als: RFC (Request For Change)), dit wordt geschreven naar aanleiding van het onderzoeksrapport. Met behulp van de in het onderzoeksrapport beschreven knelpunten zullen verbeteringen worden geformuleerd. De onderzoeksvraag luid: Hoe kan het proces van verwerking van wijzigingsverzoeken worden geoptimaliseerd? Het doel van dit rapport is duidelijk neerzetten wat de verbeteringen inhouden en wat er moet gebeuren om de verbeteringen te kunnen implementeren. Dit moet gebeuren om een duidelijk overzicht hiervan te krijgen. 1.1 Methode Voor het maken van dit rapport hebben wij onderzoeken uitgevoerd op de ICT-afdeling van B&S Dordrecht. Door middel van de onderzoeken en interviews zijn er oplossingen gevonden voor de knelpunten die beschreven staan in het onderzoeksrapport. Er is gesproken met Belinda van het wijzigingsbeheer, Rik van het applicatiebeheer en met de programmeur. 1.2 Leeswijzer Hieronder staat een overzicht met wat er per hoofdstuk te verwachten is: - Functieprofiel; Hier wordt een overzicht gegeven van de betrokken partijen met een omschrijving van hun werkzaamheden. - Verbetering knelpunten; In dit hoofdstuk zullen de verbeteringen voor de knelpunten worden omgeschreven. - Nieuw proces RFC; Hier zal het vernieuwde proces voor het verwerken van RFC s worden uitgelegd. - Conclusie / aanbeveling; In dit hoofdstuk zal een conclusie worden gegeven in de vorm van een samenvatting van de verbeteringen en welke baten het bedrijf hierbij al hebben. Het uiteindelijke rapport is bestemd voor B&S Dordrecht. 5
2. Functieprofiel 2.1 Functies In dit hoofdstuk wordt een functieprofiel beschreven van alle betrokken partijen in dit proces. Er wordt toegelicht wat de taken zijn van elke functie. Gebruikersorganisatie Het functieprofiel van de gebruikersorganisatie van het nieuwe proces zal weinig verschillen met het functieprofiel van het nieuwe proces. De gebruiker voert nog steeds een gebruikerstest uit. Echter communiceert hij niet door via de mail wat er gewijzigd moet worden. De gebruiker vult nu een basisformulier in. Dit basisformulier bevat vragen die het voor een programmeur of functioneel ontwerper makkelijker maken om een wijziging te begrijpen. ICT-medewerker De ICT-medewerker is in het nieuwe proces alleen nog maar verantwoordelijk voor het uitvoeren van een gebruikerstest en het implementeren van de wijziging in het nieuwe systeem. De ICTmedewerker vult geen wijzigingsverzoeken meer in het systeem. Dit wordt gedaan door wijzigingsbeheer. Wijzigingsbeheer Het wijzigingsbeheer is verantwoordelijk voor het registeren van alle RFC s. Zij vraagt de tijdsduur op van zowel het functioneel ontwerp als het realiseren van de aanpassing. Aan de hand van de opgegeven tijdsduur van de functioneel ontwerper en de programmeur maakt zij dan een planning voor beide partijen. Als laatste houdt zij de status bij van alle wijzigingenverzoeken zodra er aanpassingen zijn gemaakt. Functioneel ontwerper De functioneel ontwerper bepaalt of een wijziging wel reëel is. Daarna bepaalt de functioneel ontwerper of het een grote wijziging betreft. Is dit niet het geval dan vult de functioneel ontwerper een ontwerpformulier in voor kleine wijzigingen. De programmeur programmeert dan aan de hand van het ontwerpformulier aan de wijziging. Als het wel een grote wijziging betreft, wordt de wijziging ingepland voor het uitwerken van een functioneel ontwerp. De functioneel ontwerper zal nu een business & informatie analyse uitvoeren waarna er een functioneel ontwerp wordt opgemaakt. Programmeur De programmeur bepaalt aan de hand van het functioneel ontwerp de benodigde tijd die nodig is om de wijziging te realiseren. Hij heeft ook nog de mogelijkheid om een functioneel ontwerp af te blazen. Als hij het wel goedkeurt gaat hij het functioneel ontwerp uitwerken. De programmeur zal nog wel de wijziging installeren in een testomgeving omdat hij daarna zijn wijziging als eerste zal testen. Een programmeur wil natuurlijk zijn eigen werk ook testen. 6
2.2 Organigram Op deze afdeling is het onderzoek verricht en zal het advies invloed hebben als het wordt doorgevoerd. 2.3 Stakeholders Ton Vennema: Dit is de belangrijkste stakeholder omdat hij de manager van de ICT afdeling. Hij bepaalt uiteindelijk of het advies in behandeling zal worden genomen. Wijzigingsbeheer: Als het advies wordt doorgevoerd zal het wijzigingsbeheer de grootste veranderingen ondervinden. De programmeur wordt werk uit handen genomen en er komt een extra functie bij; de Functioneel ontwerper. Programmeur: De programmeur zal werk worden ontnomen door de functioneel ontwerper, hierdoor houdt hij meer tijd over voor zijn primaire werk, namelijk programmeren. Functioneel ontwerper: De functioneel ontwerper is de nieuwe functie binnen de ICT afdeling van B&S. Deze persoon zal de wijzigingen gaan beoordelen en classificeren en daarna de informatie zal doorgeven aan de programmeur. Het is belangrijk dat de functioneel ontwerper en programmeur elkaar goed leren kennen omdat er tussen deze twee functies erg veel communicatie zal zijn. Personen die de meldingen insturen: De personen die de meldingen insturen zullen sneller resultaat krijgen omdat het proces van verwerken van wijzigingsverzoeken sneller zal verlopen. 7
3. Verbetering knelpunten 3.1 Blauwdrukken worden niet uitgebreid uitgewerkt op papier De wijzigingen die worden aangevraagd door een gebruiker van het systeem Impuls of Codeless worden niet uitgebreid uitgewerkt op papier. Er wordt een kleine beschrijving gegeven door de gebruiker zelf. Wijzigingsbeheer mailt deze wijziging door naar de programmeur. De programmeur moet aan de hand van een kleine beschrijving zelf bepalen hoe de wijziging eruit moet zien. In het vernieuwde proces komt er tussen wijzigingsbeheer en de programmeur een functioneel ontwerper die de programmeur gaat ondersteunen. De functioneel ontwerper gaat voor elke wijziging een business&informatie analyse uitvoeren. Vanuit de business&informatie analyse maakt hij dan een functioneel ontwerp. Het functioneel ontwerp is in feite dus een blauwdruk van de aangevraagde wijziging. Het voordeel hiervan is dat de programmeur niet meer hoeft na te denken over het ontwerp van het programma. Betreft het maar een kleine wijziging dan wordt er geen business&informatie analyse uitgevoerd. Dat zou namelijk niet efficiënt zijn om een business&informatie analyse uit te voeren voor een kleine wijziging. Dit zou in sommige gevallen zelfs meer tijd kosten om een functioneel ontwerp te maken. Wijzigingsbeheer is verantwoordelijk voor het maken van een planning voor de functioneel ontwerper. Eigenlijk dezelfde planning als voor de programmeur wordt gemaakt. Het volgende figuur geeft de plek van de functioneel ontwerper aan in de nieuwe situatie. 3.2 Meldingen blijven te lang in de wachtrij staan Doormiddel van het uitwerken van blauwdrukken door de functioneel ontwerper en het structureren van wijzigingsformulieren wordt de gebruiker en de functioneel ontwerper gedwongen om na te denken over de technische kant van de wijziging. De programmeur kan zich hierdoor volledig richten op het programmeren van de wijziging. Doordat taken van de programmeur over worden genomen door de gebruikers van de systemen en de functioneel ontwerper 3.3 Structureren van wijzigingsformulieren De wijzigingsformulieren worden in het leven geroepen om een duidelijkere omschrijving te geven over de wijziging. Zodra de gebruikersorganisatie een wijziging wil indienen moet er een basisformulier worden ingevuld. Op dit formulier moet worden ingevuld wie er betrokken zijn bij de wijziging en welke afdeling(en). Een globale omschrijving van deze wijziging is ook nodig. Ook geeft de gebruiker aan hoe hoog de prioriteit voor diegene is. Vervolgens wordt dit formulier naar het wijzigingsbeheer gestuurd. Na het indienen van het verzoek wordt door de Functioneel ontwerper/business analist gecheckt of het een grote of kleine wijziging betreft. Aan de hand hiervan wordt een technisch formulier ingevuld. Bij een kleine wijziging zal een klein ontwerpformulier worden ingevuld waarin een kleine omschrijving van de wijziging worden gegeven, bij een grote wijziging zal het een groter formulier worden ingevuld, ook wel het functioneel ontwerp genoemd. 8
3.4 Implementeren door ICT-medewerker Momenteel wordt de wijziging geprogrammeerd, getest en geïmplementeerd door de programmeur. Om de programmeur werk uit handen te nemen wordt het implementeren van de wijziging verzorgd door de ICT-medewerker. Als er na het testen een akkoord is gegeven door zowel de ICTmedewerker als de gebruikersorganisatie wordt de status veranderd in Goedgekeurd en kan de wijziging worden geïmplementeerd. 3.5 Testen aan de hand van testplan Als de programmeur klaar is met programmeren en de wijziging in de testomgeving heeft geïnstalleerd gaat hij de wijziging testen aan de hand van het testplan. Hierin staan verschillende tests omschreven die de programmeur succesvol zou moeten kunnen uitvoeren. Mocht de programmeur tijdens het testen fouten ontdekken dan worden deze direct opgelost en opnieuw getest totdat deze succesvol zijn. Dit testplan wordt gemaakt door de functioneel ontwerper. Door dit testplan hoeft de programmeur niet meer na te denken over welke testen hij gaat uitvoeren. Dit scheelt tijd. 3.6 Integratie met Delfzijl Locatie B&S Dordrecht heeft erg weinig integratie met de werkzaamheden binnen Holland Trading Group Delfzijl. Hierdoor is het onmogelijk om ons advies door te integreren op locatie Delfzijl. Dit komt door zowel Dordrecht als Delfzijl gebruik maken van een eigen informatiesysteem. Als Delfzijl dezelfde capaciteitsproblemen heeft als in Dordrecht dan kan er in Delfzijl ook geadviseerd worden om een functioneel ontwerper te plaatsen in het wijzigingsproces. 9
4. Nieuw proces RFC Hieronder staat het nieuwe proces afgebeeld in een Visio Flowchart. 10
11
5. Nieuw procesbeschrijving RFC Algemeen De beschrijving van het gewenste nieuwe proces van de RFC zal worden ingedeeld in verschillende fasen. Elke fase zal omschreven worden inclusief de partijen die bij elke fase van het proces betrokken zijn. Uiteindelijk zal door middel van een stroomdiagram het proces samenvattend uitgelegd worden. Fase 1: Door communiceren gewenste wijziging Betrokken partijen: Gebruikersorganisatie Wijzigingsbeheer Een medewerker van de gebruikersorganisatie wil dat er een wijziging wordt doorgevoerd in het systeem Codeless of Impuls Unix. Een medewerker van de gebruikersorganisatie communiceert de gewenste wijziging door aan het wijzigingsbeheer door middel van een basisformulier. Het wijzigingsbeheer registreert een melding in een Accesdatabase. De melding omvat een korte omschrijving en een prioritering. Fase 2: Plannen en ontwikkelen functioneel ontwerp Betrokken partijen: Wijzigingsbeheer Functioneel ontwerper Nadat de melding voor een wijziging is binnen gekomen en geregistreerd, moet de functioneel ontwerper eerst bepalen of het uitvoeren van de wijziging reëel is. Doet dit hij door middel van een analyse. Als uit de analyses blijkt dat het wijzigingsvoorstel niet reëel is, wordt de status van het verzoek op afgekeurd gezet. Als het verzoek wel reëel is, gaat de functioneel ontwerper na of de wijziging groot is of niet. De wijziging wordt als groot beschouwd als er voor de wijziging meer dan 7 uur geschat wordt om aan te brengen. Als de wijziging groot is voor de organisatie, gaat de functioneel ontwerper bepalen hoeveel tijd hij nodig heeft voor het maken van het functioneel ontwerp. Dit wordt gestuurd naar het wijzigingsbeheer en deze afdeling maakt de planning voor de functioneel ontwerper. In deze planning wordt vermeld wat de functioneel ontwerper per week moet maken voor bepaalde meldingen. Vervolgens gaat de functioneel ontwerper een business en informatie analyse maken voor de wijzigingsmeldingen en wordt aan de hand van deze analyses een functioneel ontwerp gemaakt. Als het wijzigingsvoorstel klein is, kan de functioneel ontwerper ervoor kiezen om een klein ontwerp formulier in te vullen voor de melding. Hierbij wordt geen business en informatie analyse gemaakt, maar er wordt gebruik gemaakt een standaard ontwerpformulier. 12
Fase 3: Plannen en ontwikkelen wijziging Betrokken partijen: Wijzigingsbeheer Functioneel ontwerper Programmeur Als het functioneel ontwerp of standaard ontwerpformulier is opgeleverd, wordt er door de functioneel ontwerper een testplan gemaakt. Hierin komt te staan hoe de wijziging getest moet worden aan de hand van het ontwerp dat ervoor gemaakt is. Vervolgens levert de functioneel ontwerper zijn testplan op en verandert het wijzigingsbeheer de status van de wijziging naar Klaar voor programmeren. Het wijzigingsbeheer stuurt na het aanpassen van de status een bericht naar de programmeur met de vraag hoeveel tijd hij nodig heeft voordat een bepaalde melding kan worden getest. De programmeur analyseert het functioneel ontwerp en gaat hierna de tijd bepalen die hij nodig heeft. Als de programmeur akkoord gaat met het functioneel ontwerp, meldt hij dit aan het wijzigingsbeheer wederom maakt deze afdeling de planning voor de functioneel ontwerper. Als de programmeur niet akkoord gaat met het ontwerp, dan moet het functioneel ontwerp worden aangepast of opnieuw gemaakt worden. Aan de hand van de planning die gemaakt wordt door het wijzigingsbeheer gaat de programmeur het ontwerp uitwerken, welke door de functioneel ontwerper is gemaakt. Als de programmeur zijn uitwerking heeft voltooid, installeert hij de wijziging in de testomgeving en kan er getest worden. Fase 4: Testen wijziging Betrokken partijen: Wijzigingsbeheer Programmeur ICT medewerker Gebruikersorganisatie Nadat de gemaakte wijziging van de programmeur is geïnstalleerd op de testomgeving, kan de programmeur zijn werk testen aan de hand van het testplan dat opgesteld is door de functioneel ontwerper. Na deze test wordt door het wijzigingsbeheer de status van de wijziging aangepast naar klaar voor gebruikerstest. Vervolgens wordt het gemaakte werk van de programmeur getest door de gebruikersorganisatie en door de ICT medewerker. Beide partijen moeten akkoord gaan met deze wijziging. Als er bij één van de partijen of allebei de partijen niet akkoord gaat met de wijzigingen, wordt de status van de wijziging door het wijzigingsbeheer op afgekeurd gezet en moet er opnieuw een functioneel ontwerp gemaakt worden. Gaan beide partijen wel akkoord, dan wordt de status van de wijziging door het wijzigingsbeheer gezet op Goedgekeurd. Fase 5: Implementatie wijziging Betrokken partijen: ICT medewerker Wijzigingbeheer Zodra de wijziging is goedgekeurd, kan de implementatiefase beginnen. De ICT medewerker implementeert de wijziging op de draaiende applicatie. Vervolgens past het wijzigingsbeheer de 13
status aan naar afgehandeld. Uiteindelijk volgt alleen nog de nazorg van de wijziging, dit houdt in dat er een controle plaatsvind of de applicatie werkt zoals het zou moeten werken, of de gebruiker tevreden is met de applicatie en of er nog eventuele updates benodigd zijn. Daarna wordt het proces afgerond. 6. Conclusie / aanbeveling De studentengroep SITA heeft afgelopen maanden voor B&S onderzoek gedaan naar de mogelijkheden om het proces van Request for Change te verbeteren. De onderzoeksvraag luidt dan ook: Hoe kan het proces van verwerking van wijzigingsverzoeken worden geoptimaliseerd? Hierover is een onderzoeksrapport gemaakt. Naar aanleiding van het onderzoeksrapport is de adviesgroep SITA in dit adviesrapport ingegaan op de knelpunten die zijn gevonden: Blauwdrukken komen niet op papier te staan` Meldingen blijven te lang in de wachtrij staan Communicatie met Delfzijl wat betreft integratie database De belangrijkste bevinding is dat uit het gevoerde onderzoek bleek dat de programmeur onvoldoende capaciteit heeft om alle wijzigingsverzoeken te verwerken. In de huidige situatie moet de programmeur bij een wijzigingsvoorstel een informatie analyse uitvoeren, zijn plan gaan programmeren en vervolgens zijn gemaakte werk testen en implementeren. Dit kost de programmeur teveel tijd en dit zorgt ervoor dat de wachtrij voor wijzigingen alleen maar groeit. Uit het onderzoek heeft SITA een aantal adviezen opgesteld. 1. Ten eerste adviseert adviesgroep SITA om een functioneel ontwerper in het proces te plaatsen. De functioneel ontwerper maakt aan de hand van business- en informatie analyse een ontwerp, zodat de programmeur dit niet meer hoeft te doen. Vervolgens stelt hij een testplan op zodat de programmeur niet zijn eigen testplan hoeft op te stellen om te gaan testen. Hierdoor wordt er een deel van het werk van de programmeur overgenomen zodat hij zich meer kan focussen op het programmeer werk. Kosten en baten functioneel ontwerper. Dit is een indicatie van de kosten die de functionele ontwerper met zich mee zal brengen en de opbrengsten/besparingen die deze extra functie zal opleveren. Het verwachte uurloon dat de functioneel ontwerper zal ontvangen is een modaal uurloon van 20,- per uur. Aangezien het een full-time functie betreft zal dit 4x38x20 = 3040,- per maand kosten. Door deze extra ingebrachte functie zullen de wijzigingen in een kortere tijd kunnen worden verwerkt. Verwacht wordt dat de tijd voor het verwerken van wijzigingen met 35% zal afnemen. In de toekomst, als functioneel ontwerper en programmeur goed op elkaar zijn ingespeeld kan de verwerkingstijd wellicht nog verder worden teruggeschroefd. 14
2. Ten tweede adviseert SITA om een standaard formulier in te voeren voor de gebruikersorganisatie waarop wijzigingsverzoeken kunnen worden ingevoerd. Hiermee kan de gebruiker meer gespecificeerd aangeven welk onderdeel in het systeem veranderd moet worden en wat er precies veranderd moet worden. 3. Ten derde adviseert SITA om na verzoekbeoordeling (Prioritering, realiseerbaarheid, grootte) de verzoeken aan de hand van grootte op te delen in een ontwerpformulier voor kleine wijzigingen, of een volledig functioneel ontwerp. Dit kan bij kleine wijzigingen de functioneel ontwerper tijd besparen, omdat deze persoon dan geen volledig functioneel ontwerp hoeft te maken. 4. Ten slotte adviseert SITA de taak van implementatie van de wijzigingen uit handen van de programmeur te nemen. Dit zal dan worden gedaan door de ICT medewerker. SITA hoopt dat de gegeven oplossingen zullen bijdragen aan het oplossen van de genoemde knelpunten. 15
7. Literatuurlijst Geraadpleegde schriftelijke bronnen Janssen, P. (2008), IT-service management volgens ITIL(3 de druk). Amsterdam: Pearson Education. Kroenke, D. M. (2007), Databases beginselen, ontwerp en implementatie. Amsterdam: Pearson Education. Geraadpleegde digitale bronnen B&S, Dordrecht (geraadpleegd vanaf 1 maart 2012 tot 30 mei 2012); http://www.bs-gg.com/ Gertjan Schop, Klaverbladmodel (geraadpleegd op 11 maart 2012); http://www.gertjanschop.com/modellen/klaverbladmodel.html Database Requests For Change, B&S, Dordrecht (geraadpleegd van 24 april 2012 tot 30 mei 2012); Fedor Wagenaar, SQL (geraadpleegd van 24 april 2012 tot 30 mei 2012); http://med.hro.nl/wagfa/birdtb03/dtb03_pagina.htm Mumin Er, Modulewijzer (geraadpleegd van 8 februari tot 30 mei 2012); Geïnterviewde personen Rik van Loo Verkregen informatie: o Voorbeeld wijziging o Voorbeeld programmeursplanning o Huidig proces o Feedback Belinda Bakker Verkregen informatie: o Database o Huidig proces 16