Rol van de IT auditor bij agile systeemontwikkeling

Rol van de IT auditor bij agile systeemontwikkeling Auteurs Jan Rodenburg & Vincent Vlaanderen Versie 1.1 Datum Mei 2009 Instituut Vrije universiteit Amsterdam Team 911

Colofon Titel Rol van de IT auditor bij agile systeemontwikkeling Auteurs Drs. Ing. J. (Jan) Rodenburg & V. (Vincent) Vlaanderen Opleiding Postgraduate IT (EDP)-audit opleiding Scriptiebegeleider Drs. R. (Rob) Christiaanse RA Faculteit Faculteit der Economische Wetenschappen en Bedrijfskunde (FEWEB) Universiteit Vrije Universiteit Amsterdam Werkgevers Collis Achmea Vastgoed Bedrijfsbegeleiders Ir. D.J. (Derk-Jan) de Grood drs. J.H. (Hans) Evers File Name 911_Rol_IT_auditor_bij_agile_systeemontwikkeling_Rodenburg_Vlaanderen_v1.1 Status Definitief Distributie Scriptiecoordinator VU, secretariaat VU PGO IT-audit, scriptiebegeleider, Achmea Vastgoed, Collis Versie historie Versie Datum Status Auteurs 1.0 30 maart 2009 Definitief Jan Rodenburg Vincent Vlaanderen 1.1 29 mei 2009 Definitief Jan Rodenburg Vincent Vlaanderen 2009 Jan Rodenburg & Vincent Vlaanderen Het is toegestaan (gedeelten van ) dit document te verveelvoudigen mits voorzien van een uitdrukkelijke bronvermelding. Status: Definitief 2/60 Versie: 1.1

SAMENVATTING IT-projecten hebben de naam om onbeheersbaar te zijn, in de zin van het niet voldoen aan de verwachtingen of een substantiële overschrijding van tijd en middelen mee te brengen. Een van de belangrijkste oorzaken hiervoor is dat het inherent is aan systeemontwikkeling dat de requirements pas gedurende het project exact bepaald kunnen worden. De traditionele, watervalgebaseerde, ontwikkelmethoden hebben hier onvoldoende antwoord op gevonden. Agile systeemontwikkeling gaat er wel bij voorbaat van uit dat requirements gedurende het ontwikkelproces zullen evolueren. Daarnaast wordt bij Agile door middel van korte iteraties, beheerst door middel van expliciete timeboxes, steeds een release van hoge kwaliteit opgeleverd die direct valideerbaar is voor de acceptant van het systeem. Op basis van deze validatie kunnen vervolgens verbeteringen worden voorgesteld. Om deze korte cycli mogelijk te maken en toch een hoge kwaliteit te kunnen leveren wordt voornamelijk gesteund op de kracht van geoliede samenwerking tussen gekwalificeerde mensen, processen en ondersteunende tools in één team. Daarbij is voortdurende samenwerking met de acceptanten vanuit de opdrachtgever essentieel en heeft het projectmanagement voornamelijk een faciliterende rol, in plaats van een controlerende rol. De organisatie zal echter al een bepaald niveau van volwassenheid moeten hebben om Agile ontwikkeling succesvol te kunnen implementeren in organisatie en processen. In dit referaat zetten wij de verschillen tussen de processen van traditionele watervalmethode en Agile ontwikkeling uiteen. Aangezien IT-systemen en systeemontwikkelingsprojecten een steeds substantiëler deel van de kosten van een organisatie vormen is beheersing ervan belangrijk. Het verschaffen van zekerheid aan het management omtrent de beheersing van de systeemontwikkelingsprojecten zal dan ook voor ITauditors een belangrijker werkveld worden. Daarbij beoordeelt de auditor de beheersing van het proces dat ten grondslag ligt aan de totstandkoming van het softwareproduct en de effectiviteit van de beheersing. Vanuit de traditionele systeemontwikkeling is er een referentiemodel opgesteld, dat de auditor een handreiking geeft in het opstellen van het normenkader voor het uitvoeren van een audit. Gezien het grote verschil tussen de processen en bijbehorende risico s van traditionele ontwikkeling en die van Agile ontwikkeling, is het bestaande referentiemodel van het IT-Governance Institute ontoereikend om te hanteren bij een IT audit ten aanzien van een Agile ontwikkelingsproject. Belangrijkste vraag voor IT-auditors is of Agile ontwikkelingsprocessen te beheersen en te beoordelen zijn. Wij hebben de beheersingsmaatregelen geformuleerd die benodigd zijn voor de toetsing of het Agile ontwikkelingsproject adequaat beheerst wordt en de randvoorwaarden vervuld zijn om dit proces te faciliteren. Het Agile ontwikkelproces kan dan optimaal tot zijn recht komen. De auditor zal zich daarbij ook voornamelijk richten op de afweging van de juiste mix aan randvoorwaarden voor het Agile ontwikkelproject. Dit wordt onder meer bepaald door de typologie van de organisatie en de wijze waarop de organisatie in staat is de Agile werkwijze toe te passen. De door ons voorgestelde beheersingsmaatregelen voor een Agile ontwikkelproject kunnen door auditors worden gebruikt in hun referentiemodel. Ook uit de praktijktoetsing door middel van interviews onder IT-managers en ITauditors worden de beheersmaatregelen voor een groot deel onderschreven. Wel blijven er vragen over ten aanzien van standaardisatie en brede toepasbaarheid, wat een benadering vanuit een typologie gedachte bevestigt. Verder hebben de interviews ook aanvullende aandachtspunten opgeleverd, die bijdragen aan een verdere vergroting van inzicht ten aanzien van de beheersing van agile ontwikkelingsprojecten. Tenslotte zouden auditors moeten proberen om de audit zo aan te pakken dat de efficiency en effectiviteit van het Agile ontwikkelproces zo min mogelijk wordt verstoord. Status: Definitief 3/60 Versie: 1.1

VOORWOORD Voor u ligt onze scriptie waarin verslag wordt gedaan van ons onderzoek naar de rol van de IT-auditor in systeemontwikkelingsprojecten die gebruik maken van Agile ontwikkelmethoden. Deze scriptie is het resultaat van de afronding van onze postdocorale IT (EDP)-audit opleiding aan de Vrije Universiteit te Amsterdam. Vanuit onze professie zijn wij beide geïnteresseerd in de moderne methoden van systeemontwikkeling en vanuit het IT-audit vakgebied tevens naar de maatregelen tot beheersing van systeemontwikkelingsprojecten. Deze componenten samen hebben tot ons onderzoek geleid. Het referaat is mede mogelijk gemaakt door onze werkgevers, Collis B.V. en Achmea Vastgoed B.V. Graag willen wij zowel Collis als Achmea Vastgoed hiervoor bedanken. In het bijzonder willen wij de begeleiders vanuit onze werkgevers, Derk-Jan de Grood en Hans Evers, bedanken voor het adviseren en meelezen. Verder bedanken wij Sara Schüttenhelm voor de tekstuele review. Gedurende de onderzoeksperiode hebben wij een buitengewoon goede samenwerking gehad met onze scriptiebegeleider vanuit de Vrije Universiteit: Rob Christiaanse. Wij willen Rob dan ook bijzonder bedanken voor zijn inspanningen en goede begeleiding en adviezen met betrekking tot ons onderzoek en deze scriptie. Verder bedanken we een ieder die ons geïnspireerd heeft tot het volgen en volbrengen van de postdoctorale IT (EDP)-audit opleiding. Veel leesplezier! Amsterdam, maart 2009 Jan Rodenburg Vincent Vlaanderen Status: Definitief 4/60 Versie: 1.1

INHOUDSOPGAVE SAMENVATTING...3 VOORWOORD...4 INHOUDSOPGAVE...5 1 KADER EN VRAAGSTELLING...7 1.1 INLEIDING...7 1.2 PROBLEEMSTELLING...7 1.3 VRAAGSTELLING EN ONDERZOEKSVRAGEN...8 1.4 AFBAKENING...8 2 LITERATUURONDERZOEK...10 2.1 INLEIDING...10 2.2 REFERENTIE...10 2.2.1 BELANG VAN REQUIREMENTS...10 2.2.2 KWALITEITSMODELLEN...12 2.2.3 RAAMWERK ONTWIKKELPROCESSEN...14 2.3 ONTWIKKELMETHODEN...17 2.3.1 TRADITIONELE ONTWIKKELMETHODE...17 2.3.2 AGILE ONTWIKKELMETHODE...18 2.3.3 DE HUIDIGE TREND IN TOEPASSING VAN AGILE...23 2.4 REFERENTIEMODEL SDLC...24 2.4.1 ASSURANCE ROL...24 2.4.2 SDLC RISICO S...26 2.5 CONFRONTATIE...27 2.5.1 TYPOLOGIEBEPALING...27 2.5.2 MANAGEMENT CONTROL RAAMWERK...28 2.5.3 RANDVOORWAARDEN VOOR AGILE ONTWIKKELING...30 2.5.4 GENERAL IT CONTROLS...32 2.5.5 GEVOLGEN VOOR RISICO S SYSTEEMONTWIKKELING...34 3 REFERENTIEMODEL AGILE ONTWIKKELING...36 3.1 INLEIDING...36 3.2 RISICOANALYSE...36 3.3 BEHEERSINGSMAATREGELEN...37 3.4 INTERPRETATIE VAN BEHEERSINGSMAATREGELEN...38 3.5 AANDACHTSPUNTEN VOOR DE AUDIT...40 4 TOETSING IN DE PRAKTIJK...41 4.1 INLEIDING...41 4.2 VRAGENLIJST...41 4.3 RESULTATEN INTERVIEWS...41 5 ANALYSE VAN DE INTERVIEW RESULTATEN...45 Status: Definitief 5/60 Versie: 1.1

5.1 INLEIDING...45 5.2 THEORIE...45 5.3 PRAKTIJK...45 5.4 ANALYSE...46 6 CONCLUSIE...47 6.1 INLEIDING...47 6.2 CONCLUSIE...47 6.3 AANBEVELINGEN...48 6.4 DISCUSSIE...48 REFERENTIES...50 BIJLAGEN...53 A.1 SDM...53 A.2 EXTREME PROGRAMMING...56 A.3 SCRUM...58 Status: Definitief 6/60 Versie: 1.1

1 KADER EN VRAAGSTELLING 1.1 Inleiding Systeemontwikkelingsprojecten lopen uit of leveren niet altijd het gewenste resultaat. In die zin mislukt een groot deel van de systeemontwikkelingsprojecten. Naar de oorzaak van dergelijke mislukkingen zijn vele onderzoeken gedaan, waaruit blijkt dat de uitkomst van een systeemontwikkelingsproject door velerlei factoren wordt bepaald. Uit een onderzoek van Capers Jones (Capers Jones, 1994), genaamd Assessment and Control of Software Risks blijken de volgende oorzaken van het falen van systeemontwikkelingsprojecten; de grootste oorzaak is het onvoldoende of op niet heldere wijze definiëren van eisen aan het eindproduct. De tweede oorzaak is het verschuiven van de scope en de producteisen gedurende het project. Gevolg van beide bovengenoemde oorzaken is dat het opgeleverde softwareproduct niet voldoet aan de verwachtingen in de geplande eindfase. Deze bevindingen worden ook ondersteund in recentere onderzoeken van onder andere Forrester, waarin gesteld wordt dat 71% van de fouten het gevolg zijn van slechte requirements (Schwaber et al., 2006). Door herstelwerkzaamheden vallen de kosten hoger uit dan begroot en wordt het project op een later moment afgerond dan gepland. In het ergste geval wordt het project voortijdig gestaakt. Om een eind te maken aan bovengenoemde problematiek, is men vanaf het begin van de éénentwintigste eeuw meer evolutionaire ontwikkelmethoden gaan benoemen en gebruiken. Deze staan nu bekend onder de naam Agile. De term Agile, die onder meer alert, levendig en behendig betekent, verwijst naar de snelle, flexibele wijze waarop ingespeeld wordt op tijdens het ontwikkelproces gewenste veranderingen. De Agile filosofie en methodiek met haar verschillende varianten worden steeds meer ingezet in plaats van de traditionele ontwikkelmethoden, omdat deze methoden de producteisen gedurende het systeemontwikkelingsproject inzichtelijk maken. De traditionele ontwikkelmethode wordt ook wel de watervalmethode genoemd. Waar traditionele systeemontwikkeling wordt gekenmerkt door een strikte overgang van fasen binnen de systeemontwikkeling, richt de Agile ontwikkelmethodiek zich op het tot stand te brengen softwareproduct, waarbij directe communicatie belangrijker is dan het opstellen van documentatie. De verantwoordelijkheid voor het eindproduct ligt bij het individu binnen het projectteam. Een Agile ontwikkelproject wordt opgedeeld in kleine eenheden met een eigen planning en levenscyclus en een specifieke timebox om de voortgang te bewaken. De Agile ontwikkelmethodiek promoot een klein projectteam samengesteld uit verschillende functies, zoals ontwerpers, programmeurs, testers en een vertegenwoordiger van de opdrachtgever. Deze laatste ziet erop toe dat elke deeloplevering voldoet aan de eisen van de opdrachtgever. Voorbeelden van de Agile ontwikkelmethoden zijn Extreme Programming (XP)en Scrum. Een voorbeeld van traditionele systeemontwikkeling is de methodiek SDM. 1.2 Probleemstelling De auditor is in staat om zekerheid te verschaffen ten aanzien van het proces door de inrichting van interne controlemaatregelen vast te stellen en de effectiviteit ervan vast te stellen. Door de groeiende complexiteit en grootte van IT projecten is er een toenemende behoefte aan zekerheid en daarmee is een belangrijke rol weggelegd voor de IT-auditor. De IT-auditor moet in staat zijn om tijdens systeemontwikkelingsprojecten aanvullende zekerheid te verschaffen ten aanzien van de beheersing van het project en met name ook het beoordelen in hoeverre risico s gerelateerd aan systeemontwikkeling, onderkend en gemitigeerd worden. De IT-auditor kan ingezet worden gedurende het systeemontwikkelingsproject, zodat tijdens dat traject bijsturing kan plaatsvinden. De IT-auditor kan ook gevraagd worden om vlak voor of na de release datum van het systeem een onderzoek uit te Status: Definitief 7/60 Versie: 1.1

voeren om daarmee de opdrachtgever aanvullende zekerheid te verschaffen. IT-auditors hebben ook de toename van het gebruik van Agile ontwikkelmethoden opgemerkt. Agile ontwikkelmethoden worden toegepast in een organisatie met een op vertrouwen gebaseerde omgeving in contrast met een op controle gebaseerde omgeving. Onduidelijk is of deze nieuwe methodiek invloed heeft op de wijze waarin de IT-auditor zijn werkzaamheden uitvoert om tot een oordeel te kunnen komen. 1.3 Vraagstelling en onderzoeksvragen De volgende vraag staat in dit onderzoek centraal: Wat betekenen de Agile ontwikkelmethoden voor de Assurance rol van de IT-auditor bij een systeemontwikkelingsproject? De centrale vraag van dit onderzoek is of de aandachtspunten voor een IT-auditor veranderen indien er bij systeemontwikkeling een Agile ontwikkelmethodiek wordt toegepast. De doelstelling van dit onderzoek is om een raamwerk te verschaffen als handvat voor de IT-auditor bij een opdracht tot verschaffing van zekerheid over de kwaliteit van een ontwikkelproces dat gekenmerkt wordt door een Agile ontwikkelmethodiek. Uit voornoemde vraagstelling volgen de volgende onderzoeksvragen: 1.1 Wat is een systeemontwikkelingmethode? 1.2 Wat zijn de kenmerken van een traditionele ontwikkelmethode? 1.3 Wat zijn de kenmerken van een Agile ontwikkelmethode? 1.4 Welke rol heeft de IT-auditor bij het verschaffen van zekerheid omtrent systeemontwikkeling? 1.5 Welke aandachtspunten staan centraal in een IT-audit op een systeemontwikkelingsproject dat gekenmerkt wordt door een traditionele ontwikkelmethode? 1.6 Welke aandachtspunten staan centraal in een IT-audit op een systeemontwikkelingsproject gekenmerkt door een Agile ontwikkelmethode? 1.7 Wat zijn de belangrijkste verschillen tussen de aandachtspunten voor een IT-audit bij systeemontwikkeling gekenmerkt door een Agile ontwikkelmethode in vergelijking met een traditionele ontwikkelmethode? 1.4 Afbakening In het hiernavolgende onderzoek wordt ingegaan op het kader waarbinnen software wordt ontwikkeld. Met methoden voor systeemontwikkeling wordt bedoeld de processtructuur die is gericht op de ontwikkeling van software. De processen binnen de levenscyclus van systeemontwikkeling zijn methoden en standaarden voor het verbeteren en het beheersen van ontwikkelprocessen, ondersteunen van processen en het managen van processen gedurende de levencyclus van systeemontwikkeling. Wij hanteren breed geaccepteerde normen zoals ISO/IEC 12207, een standaard voor het ontwikkelproces van software. Bij ontwikkelmethoden maken we onderscheid tussen de traditionele systeemontwikkeling en agile systeemontwikkeling. Wij beperken ons daarbij tot de meest gebruikte traditionele ontwikkelmethode SDM en Agile ontwikkelmethoden Extreme Programming (XP) en SCRUM. Daarnaast laten we de problematiek die speelt bij uitbesteding van systeemontwikkeling buiten het onderzoek. Er zijn meerdere soorten opdrachten die een IT-auditor met betrekking tot systeemontwikkeling en softwareproducten kan uitvoeren. De opdracht kan zijn een technische audit waarbij ontwikkelde softwareproducten een test ondergaan. Anderzijds kan de auditor ook een belangrijke adviesfunctie of een Quality Assurance functie vervullen gedurende het ontwikkelproject. In dit onderzoek beperken wij ons tot de volgende opdrachtvorm; de assurance rol van de IT-auditor ten aanzien van de benoeming en beheersing van risico s binnen een systeemontwikkelingsproject. Wij richten ons uitsluitend op de beoordeling van de beheersing van het proces van tot stand komen dat ten grondslag ligt aan het van het softwareproduct binnen het systeemontwikkelingsproject. Primaire kwaliteitsaspecten voor toetsing van de auditor zijn beheersbaarheid, efficiency en effectiviteit, waarbij secundair ook de Status: Definitief 8/60 Versie: 1.1

kwaliteitsaspecten beschikbaarheid, integriteit en vertrouwelijkheid en controleerbaarheid, worden meegenomen Als uitgangspunt voor het formuleren van normatief kader hanteren wij de richtlijn voor reviews op de System Development Life Cycle (SDLC) van Information Systems Audit and Control Association (ISACA, 2003). Status: Definitief 9/60 Versie: 1.1

2 LITERATUURONDERZOEK 2.1 Inleiding In dit hoofdstuk wordt ingaan op de theoretische aspecten van onze vraagstelling en de bijbehorende onderzoeksvragen. In paragraaf 2.2 gaan wij nader in op raakvlakken van normenkaders en kwaliteitsmodellen met systeemontwikkeling. Daarin laten we allereerst zien dat de eisen die de opdrachtgever aan de software stelt (hierna: de requirements) een belangrijke invloed hebben op het slagen van een systeemontwikkelingsproject. Ook worden besproken de verschillende normenkaders die bij systeemontwikkeling van toepassing zijn. Voorts worden drie aspecten van systeemontwikkelingsprojecten besproken: de programmastrategie, het projectmanagement en het proces van de systeemontwikkeling. In dit onderzoek gaan wij in op het derde aspect: de systeemontwikkeling. Wij bespreken de verschillen maar ook de overeenkomsten tussen traditionele ontwikkelingmethode en Agile ontwikkelmethoden. In de daaropvolgende paragraaf wordt de rol van de IT-auditor in systeemontwikkelingsprojecten besproken en we stellen het kader vast waar de auditor gebruik van maakt in de beoordeling volgens de traditionele ontwikkelmethode. Wij starten met het belang van requirements voor de uiteindelijke slagingskans van een project. 2.2 Referentie 2.2.1 Belang van requirements De kwaliteit van de requirements bepaalt in hoge mate het succes van IT-projecten. Deze conclusie blijkt uit diverse onderzoeken. Zo stelt Forrester dat 71 procent van de fouten het gevolg zijn van slechte requirements (Schwaber et al., 2006). Ook uit eerdere onderzoeken zoals die van Capers Jones (Capers Jones, 1994) blijkt dat de voornaamste reden voor het falen van systeemontwikkelingsprojecten slecht gedefinieerde en incomplete software-eisen zijn. De Standish Group doet in zijn Chaos Report sinds 1994 elke twee jaar onderzoek naar de oorzaken van het falen van systeemontwikkelingsprojecten. Dit onderzoek geeft aan dat gemiddeld 50 procent van de fouten gerelateerd zijn aan de requirements (Standish Group, 2004). Daarnaast heeft het Software Engineering Institute van Carnegie Mellon University uit Californië, een autoriteit op het gebied van systeemontwikkeling, onderzoek gedaan naar de oorzaken van fouten in software. Daaruit blijkt dat 42 tot 64 procent van de fouten ontstaan door slechte requirements (Firesmith, 2003). Voorbeelden van slechte kwaliteit van requirements (Easterbrook et al., 1998): Onjuistheden; Weglating; Inconsistentie; Dubbelzinnig taalgebruik; Verkeerde aannames; Ontoereikendheid; Slechte traceerbaarheid. In bovenstaande opsomming wordt echter niet gesproken over voortdurend veranderende requirements gedurende het project. Deze zijn enerzijds ook het gevolg van slechte requirements, aan de andere kant hebben requirements de neiging om veel veranderingen te ondergaan, voornamelijk Status: Definitief 10/60 Versie: 1.1

ook als de ontwikkeling een lange doorlooptijd kent en daarmee de buitenwereld met zijn behoeften en verwachtingen ook mee verandert. Wanneer de requirements niet goed zijn opgesteld heeft dit effect op de volgende activiteiten in het systeemontwikkelingsproces. Ongeacht hoe goed er gewerkt wordt in het vervolgtraject, als de requirements, de allereerste input, onjuist, onvolledig of niet consistent zijn, is de kans dat het eindproduct voldoet klein (Arendsen et al, 2008). Slechte requirements hebben hoge herstelkosten en uitloop van projecten tot gevolg. Onder meer Boehm heeft onderzoek gedaan naar de gevolgen van fouten in een project en de gevolgen van de fouten in de levenscyclus van een softwareproduct. Boehm geeft in zijn onderzoek uit 1988 aan dat het oplossen van fouten uit requirements in de bouwfase tien keer duurder is dan in de requirementsfase en in onderhoud vijftig tot tweehonderd keer duurder (Boehm, 1988). Ook McConnell stelt dat het tien tot honderd keer duurder is een fout in de requirements na de requirementsfase te herstellen (McConnell, 2004). Het opstellen van requirements is een losstaand proces. The Booch Methode is de objectgeoriënteerde methode in systeemontwikkeling voor het analyseren, modelleren en documenteren van systeem eisen (Booch, 1994). Deze methode is een leidraad om te komen van de gestelde eisen tot een implementatie. De methode onderscheidt twee verschillende fasen. De eerste fase is de analyse, waarbinnen het probleem geanalyseerd wordt en een object georiënteerd model wordt gepresenteerd van het probleem gebied. Daarna volgt een ontwerpfase, waarbij gekeken wordt op welke manier alle functies van het systeem kunnen worden uitgevoerd. De ontwerpfase leidt tot een uiteindelijke architectuur die nodig is om het systeem te implementeren. In dit proces zijn meerdere belanghebbenden betrokken in het te realiseren systeem die ieder hun eigen referentiekader bezitten. Er zijn meerdere niveaus van requirements te onderkennen waarbij ieder niveau bedoeld is voor een groep belanghebbenden. De requirements van verschillende belanghebbenden zijn in drie types te onderscheiden: gebruikers eisen (quality in use); product eisen (external quality attributes); product component eisen (internal quality attributes). Deze requirements worden gedurende het requirementsproces steeds concreter. De requirements zijn dus een belangrijk aandachtspunt voor het zorgdragen dat ook daadwerkelijk het gewenste product gebouwd gaat worden in een ontwikkelproject. Als antwoord op de geconstateerde lage requirements kwaliteit is er een verschuiving gaande van de traditionele ontwikkelmethode naar Agile ontwikkelmethoden. De Agile ontwikkelmethoden zijn voorbereidend in die zin dat requirements gedurende de ontwikkelingsfase van een product veranderen en pretenderen er voor te kunnen zorgen dat het systeem wordt ontwikkeld waar de eindgebruiker daadwerkelijk tevreden mee is. De manier waarop invulling wordt gegeven aan de input van requirements is een wezenlijk andere bij Agile ontwikkelmethoden, dan bij de traditionele ontwikkelmethode. Voor de IT-auditor is het van belang te weten wat het gebruik van de Agile ontwikkelmethoden betekent voor de interne controlemaatregelen in het ontwikkelproces en de effectiviteit van het stelsel van maatregelen. Als gevolg van slechte requirements en falende projecten bestaat een toenemende behoefte aan zekerheid verschaffing gedurende het systeemontwikkelingsproject, vooral bij de grote IT projecten. Het is de IT-auditor die deze rol op zich moet nemen. Echter de IT-auditor wordt momenteel bij grote ITprojecten nog nauwelijks ingeschakeld (Matthijse, 2009). Dus op dat gebied is er voor de IT-auditor nog veel te winnen. Status: Definitief 11/60 Versie: 1.1

2.2.2 Kwaliteitsmodellen Behalve slechte kwaliteit van requirements zijn er ook andere redenen voor het mislukken van systeemontwikkelingsprojecten. Bedrijven stellen daarom diverse beheersingsmaatregelen op om het risico van het mislukken van een systeemontwikkelingsproject tegen te gaan. Voor dergelijke beheersingsmaatregelen bestaan verschillende normenkaders. In 1987 is een comité opgericht door de International Organisation for Standardisation (ISO) en de International Electrotechnical Commission (IEC) voor het opstellen van een standaard voor software life cycle processen. De bedoeling was om met deze standaard te voorzien in een behoefte om dezelfde taal te spreken bij het ontwerpen en beheren van software. Enerzijds zijn er normen die de organisatie helpen om de productkwaliteit te verhogen, anderzijds zijn er normen die de organisatie meer controle over het proces geven met als resultaat een verhoogde kwaliteit van het product. Bij het confirmeren aan een norm geeft de organisatie een signaal in control te willen zijn. Voor het bepalen van de kwaliteit van het softwareproduct is er een kwaliteitsnorm ISO/IEC 25000 (2005). Een norm voor het inrichten van processen met de bijbehorende procesbeschrijvingen en levenscyclus is ISO/IEC 15288 (2007) en ISO/IEC 12207 (2007). Voor het beoordelen van het volwassenheidsniveau van systeemontwikkeling binnen een organisatie is er ook een ISO norm bekend onder ISO/IES 15504/SPICE en het CMMi model. In deze paragraaf zijn deze uiteengezet als referentiekader voor de IT-auditor. Kwaliteit softwareproduct ISO norm ISO/IEC 25000 Software product Quality Requirements and Evaluation (SQuaRE) is ontwikkeld als antwoord op de toenemende behoefte aan een verbeterde en uniforme normering van drie in elkaar overlopende kwaliteitsprocessen, te weten: specificatie van product eisen, meten en evalueren. Het doel van ISO/IEC 25000 is om degenen, die verantwoordelijk zijn voor het ontwerpen en ontwikkelen van softwareproducten, bij te staan met instrumenten voor het opstellen van specificaties en evaluatie van kwaliteitseisen (Suryn et al., 2003). ISO/IEC25000 is een vervolg op de ISO/IEC9126 (2001) en het QUINT model, waar in de literatuur naar verwezen wordt. ISO/IEC 25000 is een model dat de kwaliteit van softwareproducten bepaalt aan de hand van de volgende kwaliteitsaspecten. Functionaliteit; Betrouwbaarheid; Bruikbaarheid; Efficiency; Onderhoudbaarheid; Portabiliteit. Deze hoofdaspecten zijn onderverdeeld in subaspecten welke op hun beurt weer zijn onderverdeeld. De aspecten kunnen gecontroleerd worden en zijn meetbaar. Hiermee is een kwaliteitsmodel voor een softwareproduct op te zetten. De eisen die aan de hand van de kwaliteitsaspecten worden gesteld zijn zowel functioneel als niet-functioneel. De kwaliteit van de software die tot stand komt binnen het systeemontwikkelingsproject heeft invloed op de onderhoudbaarheid en het functioneren van het systeem later in de productiefase (van Biene- Hersey, 1996). General IT controls omvatten de algemene procedures rond toegangsbeveiliging en onderhoud van software voor specifieke toepassingen. Als het de software aan kwaliteit ontbreekt, kunnen de general IT controls niet goed werken, hetgeen risico s oplevert voor de betrouwbaarheid en continuïteit van de gegevensverwerking. Als er bijvoorbeeld in de ontwikkelfase van een softwareproduct onvoldoende aandacht is voor beveiliging aspecten kan dit consequenties hebben voor het beveiligingsmanagement binnen de productiefase van een systeem. Status: Definitief 12/60 Versie: 1.1

Kwaliteit ontwikkelproces ISO norm ISO/IEC 15288 Life Cycle Management System Life Cycle Processes is een raamwerk dat bestaat uit een beschrijving van de levenscyclus van systemen en procesbeschrijvingen met bijbehorende terminologie. De processen worden gedurende de levenscyclus gebruikt voor het beheer tijdens de verschillende levensfasen van het systeem. Systemen zijn door mensen gemaakt en worden door mensen gebruikt om diensten te bieden in gedefinieerde omgevingen ten behoeve van gebruikers en andere belanghebbenden. De levenscyclus van een systeem begint bij een concept van de behoefte voor een systeem en gaat door tot realisatie, productie, ingebruikname, ondersteuning en uiteindelijk het uit gebruik nemen van het systeem. In 1995 is de ISO/IEC international standaard 12207 gepubliceerd. De norm ISO/IEC 12207:2007, Software Life Cycle Processes is een compleet raamwerk dat alle processen beschrijft die een organisatie naar alle waarschijnlijkheid zal opstellen, ten behoeve van de bouw van een complete en efficiënte System Development Life Cycle. Volwassenheidsmodel voor ontwikkelprocessen Een ontwikkelproces voor software is een stelsel van goedgedefinieerde procedures dat leidt tot de ontwikkeling van softwareproducten (Zahran, 1998). Ontwikkelprocessen worden verbeterd door het toepassen van training, kwaliteitsbewaking, meting, ontwerp, code reviews en wijzigingenbeheer (Dekleva et al., 1997). ISO norm ISO/IES 15504 (Process Improvement and Capability determination, voorheen bekend onder de werknaam SPICE ) is een model voor de beoordeling van ontwikkelprocessen. Een ander belangrijk algemeen model voor de bepaling van volwassenheid van ontwikkelprocessen is CMMi (Capability Maturity Model Integration), ontwikkeld door het Software Engineering Institute (SEI) van de Carnegie Mellon University in de Verenigde Staten. CMMi beschrijft de principes en de praktijken die aan een volwassen bedrijfsproces ten grondslag liggen (Cannegieter et al, 2007). CMMi helpt organisaties hun processen te verbeteren door middel van een evolutionair pad. Dit pad vertrekt vanuit georganiseerde processen naar volwassen, gedisciplineerde processen. Net als ISO/IEC 12207:2007 richt CMMi zich op de levenscyclus van het proces. Het CMMi model wordt gebruikt voor een stapsgewijze verbetering van de procesvaardigheid. Het model onderkent vijf niveau s: Niveau Naam Criteria 1 Initieel Geen eisen, het ontwikkelproces verandert van moment tot moment. 2 Beheerst Basisbeheersing van processen en projecten zijn ingericht. 3 Gedefinieerd Processen zijn organisatiebreed gedefinieerd en onderhouden. 4 Kwantitatief Processen worden gestuurd op basis van kwantitatieve gegevens. beheerst 5 Optimaliserend De organisatie verbetert haar processen continue. Elk CMMi niveau heeft criteria die naarmate het niveau hoger wordt uitgebreider zijn. De procesvaardigheid van een organisatie wordt beter geacht naarmate aan meer criteria wordt voldaan. Dit resulteert in een vermindering in doorlooptijd en kosten van processen en resulteert in verhoogde productkwaliteit. In de systeemontwikkeling literatuur wordt vaak het verband gelegd tussen de mate van volwassenheid van het proces en de kwaliteit van het product (e.g., Harter et al. 2000, Harter et al. 2003, Krishnan et al. 2000, Herbsleb et al. 1997). In volwassen, gedisciplineerde processen zit meer consistentie en discipline omdat er bijvoorbeeld reviews zijn verricht op het ontwerp, de code en de configuratie (Krishnan et al., 1999). Reviews in het ontwerp zorgen voor minder fouten in de softwareproducten doordat op een eerder moment verschillen geconstateerd worden tussen de requirements, het functioneel ontwerp, het technisch ontwerp, de code zelf en de testontwerpen. Aldus worden inconsistenties of fouten tussen de verschillende tussenproducten en de uiteindelijke systeemeisen van de eindgebruikers eerder geïdentificeerd in de SDLC (Harter et al., 2003). Onderzoek (Harter et al., 2000) geeft aan dat een toename van proces volwassenheid leidt tot een hogere product kwaliteit in de vorm van minder fouten per geschreven code regels, zoals ook in onderstaande figuur wordt weergegeven; Status: Definitief 13/60 Versie: 1.1

Figuur: Mate van procesvolwassenheid ten opzichte van productkwaliteit (Harter et al., 2000) Indien procesverbetering leidt tot een hogere productkwaliteit van de software is de verwachting dat minder herstelwerk verricht hoeft te worden in de infrastructuur die ondersteunend is voor systeemontwikkeling. Met de daarmee te realiseren besparingen van de kosten van de infrastructuur worden de uitgaven voor procesverbeteringen ruimschoots gecompenseerd. 2.2.3 Raamwerk ontwikkelprocessen Het raamwerk voor ontwikkelprocessen voor software bestaat uit drie pijlers (Hettigei, 2007): Programmastrategie; Projectmanagement; System Development Life Cycle. Programmastrategie De programmastrategie bepaalt het programmamanagement. Een programma bestaat uit meerdere projecten die er samen op gericht zijn een of meerdere doelstellingen te bereiken. De programmastrategie houdt verder in: - Strategische keuze voor programmamanagement; - Sturingsfilosofieën; - Succesvol inrichten van programma s; - Relatie lijn- en programmaorganisatie. Daarnaast bepaalt het programmamanagement welke ontwikkelmethode er gebruikt wordt in een project. Projectmanagement De levenscyclus van het product begint bij een idee en eindigt bij het buitengebruikstelling van het product. Het systeemontwikkelingsproject maakt deel uit van deze levenscyclus. Hoe het product zich verhoudt tot het project is weergegeven in onderstaand figuur: Status: Definitief 14/60 Versie: 1.1

Figuur: OGC (2002) Een goede projectmanagementmethode richt zich op de onderdelen van de projectlevenscyclus van specificatie tot en met overdracht. De termen project en projectmanagement worden door Van Onna (Van Onna et al, 2008) als volgt omschreven: Een project is een tijdelijke organisatievorm die nodig is om een uniek en vooraf gedefinieerd product te maken of resultaat te behalen op een vooraf afgesproken tijdstip, gebruikmakend van vooraf gestelde middelen. Professioneel projectmanagement is het op projectbasis uitvoeren van die activiteiten die nodig zijn om de juiste mensen, op de juiste tijd, op basis van het verkrijgen van de juiste informatie, de juiste activiteiten te laten uitvoeren om te komen tot het juiste doel: de juiste producten die de businesscase ondersteunen. Dit zijn producten die voldoende bijdragen aan de doelstellingen van de organisatie. Een belangrijk aspect van projectmanagement is de inschatting van de projectrisico s. Maatregelen tegen dergelijke risico s zijn onder te verdelen in beheersingsmaatregelen en borgingsmaatregelen. Beheersingsmaatregelen richten zich op een goede procesgang van het project. Borgingsmaatregelen zorgen ervoor dat er voldoende kwaliteit in het product aanwezig is en dat de organisatie met het product uit de voeten kan. Borgingsmaatregelen staan ook bekend als Quality Assurance. Binnen een systeemontwikkelingsproject is een goede inrichting van het projectmanagement essentieel voor het slagen van een project. Best practices dienen daarvoor als leidraad. De IT-auditor kijkt naar de inrichting van het projectmanagement alvorens hij zal kijken naar de SDLC processen. In dit onderzoek gaan wij niet verder in op het projectmanagement aangezien daarover genoeg literatuur voor handen is. Wij beperken ons tot het schetsen van randvoorwaarden waar een goed projectmanagement voor systeemontwikkeling aan moet voldoen: Maatregelen ten aanzien van projectmanagement (Hettigei, 2007): Projectmanagement methodiek; Betrokkenheid van de business bij het project; Betrokkenheid van het projectmanagement met belanghebbende; Betrokkenheid IT medewerkers met de eindgebruikers; Monitoring gedurende het project op scope, planning en budget; Tussentijdse reviews. Aan de volgende aspecten ten aanzien project risico management zal invulling gegeven dienen te worden; Project risico management proces; Status: Definitief 15/60 Versie: 1.1

Organisatorische aansluiting op het project vanuit de business; Adequate training en communicatie; Service niveaus zijn gedefinieerd; Proces voor de project oplevering is gedefinieerd; Plan voor exceptie en roll back scenario. Wij benadrukken dat een goed ingericht projectmanagement en goed functionerende project monitoring, essentieel zijn voor het succes van een systeemontwikkelingsproject. Binnen dit onderzoek beperken we ons tot de beschrijving en verdieping van de ontwikkelmethodiek. System Development Life Cycle System Development Life Cycle (SDLC) is een geformaliseerde informatiesysteem ontwikkelmethode. Siau en Tan (Siau en Tan, 2005) definiëren dit als volgt: Een systematische benadering voor het uitvoeren van een fase in informatiesysteemontwikkeling bestaande uit aanbevolen fasen, technieken, procedures, tools en documentatie. SDLC is een van de eerste methoden die een geformaliseerde, gestructureerde methode voor het bouwen van informatiesystemen voorschrijft. De traditionele SDLC heeft zijn oorsprong in de 60er jaren bij het ontwikkelen van grootschalige informatiesystemen bij grote organisaties. Het SDLC concept is in latere jaren uitgewerkt in verschillende ontwikkelingsmethoden. SDLC heeft fundamentele fasen die van essentieel belang zijn voor een ontwikkelaar. De primaire procesfasen zijn o.a. planning, systeem analyse, ontwerp, invoering en onderhoud. Deze zijn weergegeven in onderstaande figuur. Figuur: weergave levenscyclus van een informatiesysteem Het management hanteert een SDLC als beheersingsmaatregel om controle te houden over de ontwikkeling. Het opdelen van een project in meerdere fasen vermindert de complexiteit van planning, monitoren en controle. SDLC is beschreven in ISO/IEC 12207. Er bestaan verschillende invullingen van een SDLC. De oudste SDLC, bekend als de waterval methode, gebruikt de output van een fase als input voor een opvolgende fase. Een bekend voorbeeld van de waterval methode is System Development Methodology (SDM) die in 2.3.1 en verder in bijlage A.1 wordt beschreven. De specifieke ontwikkelingsfase kan zich in de verschillende stadia van de SDLC bevinden: Nieuwbouw Toevoegen van nieuwe componenten Herbouw van een bestaand systeem Status: Definitief 16/60 Versie: 1.1

Voor de IT-auditor is dit van belang aangezien bij een productioneel systeem het aanpassen van de processen een intensievere taak is dan bij nieuwbouw waarbij meer tijd en middelen geïnvesteerd moeten worden om maatregelen, naar aanleiding van een IT audit, geïmplementeerd te krijgen (Van Biene-Hershey, 1996). 2.3 Ontwikkelmethoden In deze paragraaf beschrijven we de traditionele systeemontwikkelingen en Agile systeemontwikkeling. In de bijlagen wordt dat verder geïllustreerd aan de hand van beschrijving van verschijningsvormen van beide methoden. 2.3.1 Traditionele ontwikkelmethode De vormen van traditionele systeemontwikkeling die ook bekend staan als de watervalmethode bestaan uit de volgende meest voorkomende fasen: 1. Analysefase (met definitiestudies en analyserapporten als eindproduct); 2. Ontwerpfase (met functionele en technische ontwerpen als eindproduct); 3. Bouwfase (met broncode als eindproduct); 4. Testfase (met werkende broncode als eindproduct); 5. Integratiefase (eindgebruikers gaan ermee aan de slag); 6. Beheer en onderhoud fase (het systeem wordt draaiend gehouden). Figuur: Fasen van SDM systeemontwikkeling (college Christiaanse, april 2008) De systeemontwikkeling gaat volgens een watervalmethode, waarbij het ene proces het andere sequentieel opvolgt in een rechtlijnige beweging. Dit is als volgt te illustreren: allereerst worden de requirements opgesteld, wanneer deze volledig zijn afgestemd en geaccordeerd, gaat men over naar de volgende fase, het ontwerp. Waterval systeemontwikkeling houdt in dat pas naar een andere fase overgegaan kan worden indien de voorgaande volledig is afgerond en geperfectioneerd. Waterval systeemontwikkeling gaat ervan uit dat de tijd die aan de eerste fasen wordt gespendeerd tot een betere efficiency leidt verder in het proces. Immers een ontwerpfout leidt tot een niet werkend product waardoor er tijd opgaat aan herstelwerkzaamheden. Traditionele systeemontwikkeling benadrukt tevens het belang van documentatie, zoals requirements en ontwerp documentatie en source code. De reden hiervoor is dat teamleden gedurende het project het team kunnen verlaten met het gevaar dat kennis verloren gaat. Verder levert de traditionele systeemontwikkeling een gestructureerde aanpak van systeemontwikkeling, het model is lineair gericht, de fasering is eenvoudig te begrijpen en geeft duidelijke mijlpaalproducten. De verschillende fasen om tot een eindproduct te komen worden vaak ook in een V-model weergegeven. Status: Definitief 17/60 Versie: 1.1

In bijlage A.1 beschrijven wij in detail de traditionele systeem ontwikkelmethode SDM. Ervaringen met SDM In een artikel uit het Information Center Quarterly uit 1991 wordt Larry Runge als volgt geciteerd (Runge, 1991): De traditionele ontwikkelmethode werkte erg goed in de tijd dat wij processen automatiseerden voor kantoorpersoneel en accountants. Het werkt niet zo goed, of helemaal niet wanneer wij informatie systemen bouwen voor ontwikkelde gebruikers helpdesk personeel, experts die problemen proberen op te lossen of voor managers die een bedrijf in de Fortune 100 proberen te leiden. Uit dit citaat is af te leiden dat de traditionele ontwikkelmethode voor het ontwikkelen van bepaalde systemen niet geschikt is als beheersingsmaatregel. De traditionele ontwikkelmethode is een solide, goed begrepen model wat hoort bij een stabiel, herhaalbaar en lage complexiteit project. De software-eisen zijn stabiel en gefixeerd. Het ontwikkeltraject is precies te voorspellen. Problemen ontstaan indien er veranderingen optreden in de requirements gedurende het project. Het fundament van een traditionele ontwikkelmethode is namelijk de requirements waarop men trapsgewijs bouwt. Er is weinig tot geen speelruimte voor veranderingen in de uitgangspunten voor ontwikkeling. Elke fase wordt immers afgesloten met een "contract" voor de volgende fase. Indien de eisen veranderen moeten er dus stappen teruggezet worden wat een tijdsrovende zaak is. Een ander probleem met de watervalmethode is dat het opstellen van het functionele ontwerp en het technisch ontwerp een zodanig groot deel van de looptijd van het project in beslag nemen dat de gehele looptijd om tot een werkende applicatie te komen lang is, waardoor de kans groot is dat requirements achterhaald zijn. Verder is ook het voortschrijdend inzicht in het project moeilijk te verwezenlijken. 2.3.2 Agile ontwikkelmethode Agile is een geformaliseerde methode die ontstaan is uit ontevredenheid over de resultaten van veel systeem ontwikkelingtrajecten. De basis van de Agile methode is Iteratieve en evolutionaire systeemontwikkeling. Volgens Larman (Larman, 2005) is iteratieve systeemontwikkeling en evolutionaire systeemontwikkeling een ontwikkeling die al voor 1960 zijn oorsprong kent. Iteratieve systeemontwikkeling is een methode om software te bouwen. De levenscyclus van software bestaat uit een aaneenschakeling van iteraties, waarbij elke iteratie een miniproject is waarin met betrekking tot een afgebakende functionaliteit een groot aantal fasen uit de levenscyclus van software wordt doorlopen, zoals requirements analyse, ontwerp, ontwikkeling en testen. De doelstelling van één iteratie is dat de afgebakende functionaliteit compleet en foutvrij wordt opgeleverd en beschikbaar is voor de eindgebruiker. Elke iteratie beoogd een hoge mate van kwaliteit code op te leveren en elke iteratie is niet een prototype maar een onderdeel van het te ontwikkelen systeem. Een iteratie kan ook als doel hebben om functionaliteit te verwijderen of performance te verbeteren. Een voorbeeld van een iteratieve systeemontwikkeling is Rapid Application Development (RAD). Evolutionaire systeemontwikkeling houdt in dat requirements, de planning en de oplossing evolueren over de verschillende iteratieve releases. Dit is een andere insteek dan bij traditionele systeemontwikkeling, waarbij de requirements zoveel mogelijk van te voren zijn bepaald en deze vervolgens worden bevroren tijdens de ontwikkelingfase. Dit betekent overigens niet dat gedurende één iteratie de functionaliteit voortdurend aan verandering onderhevig is, maar na elke iteratie is het wel mogelijk om functionaliteit te wijzigen of toe voegen. Wanneer een iteratie is gestart worden er geen wijzigingen geaccepteerd van externe belanghebbenden in het project. Dit betekent dat aan het begin van elke iteratie de prioriteiten vastgesteld worden en hierbij wordt veelal een risicogebaseerde benadering gehanteerd. Lean Thinking Status: Definitief 18/60 Versie: 1.1

Lean Thinking heeft zijn oorsprong bij autofabrikant Toyota met haar Toyota Production System (TPS). Toyota is daarmee in staat kwalitatief hoogwaardige producten te maken en op tijd te leveren. Zij hanteren het principe van TPS in het zoveel mogelijk elimineren van uitgaven voor resources en activiteiten die geen waarde hebben voor het eindproduct. Toyota is daarmee zo succesvol dat het bedrijf is uitgegroeid tot één van de grootste autofabrikanten. Mede door het succes van Toyota worden de principes van Lean Thinking ook buiten de automobielindustrie toegepast. Lean Thinking kent 7 vormen van verspilling, die uit de processen geëlimineerd dienen te worden: 1. Overproductie 2. Wachten 3. Transport 4. Extra processtappen 5. Voorraad 6. Beweging 7. Correcties In feite staat Lean Thinking aan de basis van Agile (Harvey, 2004). Agile Manifesto Agile systeemontwikkeling is geformaliseerd in 2001 door 17 vooraanstaande ontwikkelaars die de toen bestaande afgeslankte methodieken gecombineerd hebben tot een methodiek Agile. De term Agile betekent onder meer alert, levendig en behendig. Dit verwijst naar de snelle, flexibele wijze waarop ingespeeld wordt op veranderingen tijdens het ontwikkelproces. De groep heeft een Agile Manifesto opgesteld voor Agile systeemontwikkeling. De groep onderscheidt vier niveaus van afspraken: 1) Er is behoefte aan een ontwikkelmethode voor software die is ontworpen om te reageren op veranderingen gedurende systeemontwikkelingsprojecten. Binnen het Manifesto is daarom voor de term Agile gekozen. De term Agile staat voor snel kunnen denken en reageren op een overwogen, gecoördineerde manier (Koch, 2005). 2) Het Agile Manifesto heeft de volgende kernwaarden: Belangrijk processen en tools gedetailleerde documentatie contractonderhandeling strikt het plan volgen Belangrijker individuen en interactie werkende software samenwerken met de klant Reageren en inspelen op verandering Het Agile Manifesto benadrukt dat zij de linker waarden zeker niet onbelangrijk vinden, maar de nadruk op de rechter kolom is om een statement te maken. Deze kernwaarden hebben echter wel gezorgd voor het ontstaan van misverstanden en verschillen van interpretatie. 3) Het Agile Manifesto gaat uit van een set principes die bovenstaande waarden verder uitdiepen: Onze hoogste prioriteit is het tevreden stellen van de klant door snelle en continue levering van waardevolle software. Sta open voor veranderende eisen, zelfs laat in de ontwikkeling. Agile processen benutten veranderingen om de concurrentiepositie van de klant te verstevigen; Lever regelmatig werkende software af, van eenmaal in de paar weken tot eenmaal in de paar maanden, met de voorkeur voor vaker afleveren; Medewerkers van het bedrijf en ontwikkelaars werken gedurende het project dagelijks samen; Bouw projecten rond gemotiveerde individuele personen en biedt ze de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze het werk gedaan krijgen; De efficiëntste en effectiefste methode voor het overdragen van informatie binnen een ontwikkelteam is directe communicatie; Werkende software is de belangrijkste maat voor voortgang; Status: Definitief 19/60 Versie: 1.1

Agile processen bevorderen duurzame ontwikkeling. De sponsors, ontwikkelaars en gebruikers moeten in staat zijn om langdurig een constant tempo aan te houden; Continue aandacht voor technische topkwaliteit en goed ontwerp vergroot de agiliteit; Eenvoud (de kunst om de hoeveelheid werk die niet hoeft te gebeuren, te maximaliseren) is het kenmerk van het ware; De beste architecturen, vereisten en ontwerpen komen voort uit zelforganiserende teams; Met enige regelmaat bekijkt het team hoe het effectiever kan zijn, stelt het werk bij en past zijn gedrag overeenkomstig aan. 4) Elke Agile methode mag zijn eigen inhoud bepalen De teamleden binnen een Agile project bepalen zelf hoe zij het proces vorm geven binnen de kaders die de specifieke ontwikkelvariant voorschrijft. De keuzes voor tools bepalen zij zelf. Net als Iteratieve systeemontwikkeling hanteert Agile een regelmatige oplevering van software om in te kunnen spelen op de veranderende requirements. Agile gebruikt echter timeboxen waarbij elke iteratie een gelijke duur heeft. Daarnaast is bij Agile de opdrachtgever permanent vertegenwoordigd in het project. De Agile Alliance [www.agilealliance.com] vertegenwoordigt de gebruikersgemeenschap die de belangen van Agile vertegenwoordigt en beheert. Toepassing Agile De mate van inzetbaarheid van Agile ontwikkeling hangt af van een aantal factoren. Een van de betrokkenen bij de totstandkoming van Agile, Alistair Cockburn (Cockburn, 2006) hanteert hiervoor een aantal principes: 1. Interactieve, directe en fysieke communicatie is de goedkoopste manier voor het uitwisselen van informatie; 2. Te strikte toepassing van de toegepaste methode is kostbaar; 3. Grotere teams hebben striktere discipline nodig; 4. Grotere plichtpleging is toepasbaar in projecten met een hogere kritieke factor; 5. Verhoging van feedback en communicatie verlaagt de behoefte aan tussentijdse opleveringen; 6. Discipline, vaardigheden en het begrijpen van de processen, formaliteit en documentatie; 7. Mogelijkheid van gelijktijdige ontwikkeling door verschillende teams. 1. Interactieve, directe en fysieke communicatie is het goedkoopste kanaal voor het uitwisselen van informatie Dit principe gaat er vanuit dat mensen die frequent bij elkaar zitten en overleggen makkelijker en efficiënter tot een ontwikkeld softwareproduct komen. Naarmate de omvang van het project groeit, zal interactieve en directe communicatie moeilijker worden waardoor de kosten voor communicatievoorzieningen stijgen, terwijl de kwaliteit daalt. Dit heeft vervolgens ook zijn uitwerking op de moeilijkheidsgraad van het ontwikkelen van de software. Uit een onderzoek van professor Allen (Allen, 1987) blijkt dat communicatie tussen partijen dramatisch daalt wanneer de fysieke afstand tussen partijen meer is dan 50 meter. Dit impliceert verder dat het management er naar zal moeten streven om kleine teams te formeren, waarbij persoonlijk contact voorop staat. 2. Te strikte toepassing van de toegepaste methode is kostbaar Alle activiteiten buiten het ontwikkelen van software hebben hun weerslag op de geïnvesteerde tijd en budget van de leden van het team. Wanneer een team een beperkte grootte heeft, volstaat een lichtere vorm van een methode en hardheid van werkwijze om tot een goed resultaat te komen. De activiteiten die uitgevoerd worden om de methode strikt te volgen kunnen aardig oplopen en dit neemt de aandacht weg van waar het eigenlijk om gaat; het komen tot een kwalitatief goed product dat voldoet aan de wensen van de business. 3. Grotere teams hebben striktere discipline nodig Status: Definitief 20/60 Versie: 1.1

Met elke verhoging van de bezetting van het ontwikkelteam is het moeilijker voor de teamleden om te bepalen waar anderen zich mee bezig houden en te zorgen dat hun activiteiten aansluiten. Dit betekent dat er behoefte ontstaat aan extra coördinatie en communicatie. De hoeveelheid tijd die daarin geïnvesteerd moet worden kan de activiteiten van systeemontwikkeling zelfs gaan overschrijden. 4. Grotere plichtpleging is toepasbaar in projecten met een hogere kritieke factor. Naarmate de potentiële schade groter wordt is het gerechtvaardigd om hogere ontwikkelkosten te maken om de kans op fouten te verkleinen. De genomen stringentere maatregelen beperken de toleranties waarbinnen het systeem ontwikkeld wordt. 5. Verhoging van feedback en communicatie verlaagt de behoefte aan tussentijdse opleveringen Tussentijdse opleveringen zijn producten zoals een project plan, requirements documentatie, ontwerpdocumentatie en testplannen. Deze documenten hebben het karakter dat ze allen binnen het projectteam gebruikt worden ter bevordering van de communicatie binnen het team. Een werkende release van software zegt vaak meer en op basis daarvan kan de business beter een oordeel geven over in hoeverre de software voldoet aan de eisen. Het projectteam profiteert daar op meerdere manieren van. Er zijn minder reviews nodig van de requirements; de ontwerpers kunnen snel het resultaat zien van hun ontwerpbeslissingen en testers kunnen per iteratie een korte test uitvoeren of steunen op de geïntegreerde testcases in de code. 6. Discipline, vaardigheden en inzicht in plaats van processen, formaliteit en documentatie Beheersingmaatregelen hebben pas echt toegevoegde waarde als deze ook effectief worden toegepast. Discipline betekent dat een persoon kiest ervoor om op een consistente manier te werken, terwijl het proces het volgen van instructies inhoudt. Discipline heeft de voorkeur aangezien het teamlid zelf kiest om op een consistente manier zijn werk te doen in plaats van voorgeschreven instructies uit te voeren. De kennis van teamleden in een project kan groot worden. Teamleden zijn op de hoogte van alle ins en outs, weten op welke wijze ze met elkaar communiceren, weten welke persoon welke informatie bezit en weten welke overwegingen hebben gespeeld bij bepaalde besluiten. Inzicht heeft dan ook meer om het lijf dan alleen documentatie. Documentatie is slechts een deel van de kennis. 7. Mogelijkheid van gelijktijdige ontwikkeling door verschillende teams. Het is afhankelijk van de situatie of ontwikkeling gelijktijdig door meerdere teams kan plaatsvinden, namelijk zolang de ontwikkeling zich niet in een kritieke fase bevindt. Het programmamanagement moet in de keuze van de ontwikkelmethode voor het project rekening houden met de verschillende aandachtspunten. Het is niet een kwestie van Agile tegen traditionele ontwikkeling, maar het is situatie afhankelijk welke methode het meest geschikt is. De consequenties van genoemde principes zijn; 1. Het toevoegen van mensen aan een project brengt extra kosten mee; 2. Het verhogen van de teamgrootte en de daarmee gepaard gaande aanvullende controlemaatregelen zorgen niet voor de effectiviteit die men zou verwachten; 3. Teams verbeteren, niet vergroten. Door toename van het aantal teamleden wordt de communicatie moeizamer, wat gecompenseerd moet worden door aanvullende procedures; 4. Verschillende ontwikkelmethoden zijn geschikt voor verschillende projecten; 5. Methoden en processen moeten steeds aangepast worden zodat ze passend zijn voor de specifieke situatie. Agile projectervaring De volgende factoren zijn van belang bij een succesvolle invoer van de Agile ontwikkelmethode; Teams zijn beperkt tot ongeveer tien mensen, bij een grotere groep worden deze opgedeeld in naast elkaar opererende teams; Status: Definitief 21/60 Versie: 1.1

Een betrokken opdrachtgever; Planning en evaluatie wordt beheerst door middel van time boxes ; Rolling Wave planning of continue planning; Teams bevinden zich op dezelfde locatie en kunnen verschillende rollen innemen; Alle teamleden zijn individueel competent en bekend met Agile. Figuur: de centrale plaats van een timebox in een Agile ontwikkelingsproject Net als bij traditionele ontwikkeling is Agile ontwikkeling niet succesvol indien: Er geen proces is; Er geen discipline is; Er geen planning is. Wanneer een organisatie geen ervaring heeft met Agile is het verstandig om een pilot te starten en te evalueren. Op deze manier kan de organisatie wennen aan de aanpassing aan de nieuwe werkmethoden, processen en verantwoordelijkheden. Koppeling beheersingsmaatregelen van Agile aan fasen uit de SDLC In een onderzoek van Pikkarainen (Pikkarainen, 2006) wordt door middel van een aantal case studies empirisch bewijs geleverd dat Agile systeemontwikkeling te spiegelen is aan de ISO/IEC 12207 standaard. Agile technieken zoals planning games en sprint planning kunnen volgens dit artikel vergeleken worden met de taak status management en requirements definitie activiteiten in het ontwikkelproces volgens ISO/IEC 12207. De post iteratie workshops, reflection workshops en Agile assessments bieden goede technieken om de Agile systeemontwikkeling te verbeteren. Ook geeft het artikel aan dat test driven development en pair programming mechanismen zijn voor test en implementatie activiteiten van het ontwikkelproces zoals beschreven in ISO/IEC 12207. Bij test driven development worden eerst testscenario s opgesteld voordat code wordt geschreven. In bijlage A.2 geven wij uitleg van het begrip pair programming. Uit een onderzoek van Sutherland (Sutherland et al, 2007) blijkt dat projecten die Agile methoden combineren met CMMi succesvol zijn in het verhogen van de softwarekwaliteit en effectief zijn in de aansluiting op de behoeften van de opdrachtgever. Succesvolle systeemontwikkeling wordt bepaald door de wijze waarop de business de complexiteit, technologische innovatie en veranderde requirements weet te managen. Agile en CMMi methoden zijn ontwikkeld om hier mee om te kunnen gaan maar verschillen in aanpak. Het beheersen van complexiteit vraagt om discipline in het proces wat CMMi voorschrijft terwijl Agile zorgt voor het beheersen van veranderingen. In het onderzoek van Sutherland wordt ingegaan op de praktijkervaringen bij een CMMi- niveau 5 organisatie. Het onderzoek Status: Definitief 22/60 Versie: 1.1

geeft 12 beheersingsmaatregelen die het volwassenheidsniveau van een organisatie positief beïnvloeden bij de invoering van Agile methode: 1. Stel een organisatorisch beleid op voor de uitvoer van Agile methoden; 2. Stel een plan op voor de uitvoer van Agile methoden en onderhoud dit plan; 3. Stel voldoende middelen beschikbaar voor de uitvoer van Agile methoden; 4. Stel een verantwoordelijkheid en autoriteit op voor de uitvoer van Agile methoden; 5. Verschaf training aan medewerkers die Agile methoden uitvoeren (kritische succes factor); 6. Plaats gedefinieerde producten van ontwikkeling onder een gepast niveau van configuratie management; 7. Identificeer en betrek de benodigde belanghebbenden volgens planning; 8. Monitor en beheers Agile methoden volgens het plan en neem indien nodig correctieve maatregelen; 9. Evalueer de striktheid waarmee de Agile methoden worden toegepast; 10. Bespreek de activiteiten, status en resultaten van de Agile methoden met het hoger management; 11. Stel een omschrijving op van Agile methoden en onderhoud deze; 12. Verzamel de resultaten van het gebruik van Agile methoden voor toekomstig gebruik en verbeter de toepassing van Agile methoden binnen de organisatie. Verschijningsvormen Agile heeft meerdere verschijningsvormen, de meest bekende en gebruikte zijn de onderling verschillende Scrum en Extreme Programming (XP). Beide hebben gemeen dat zij de onderliggende principes uit het Agile Manifesto onderschrijven. Het verschil is dat Scrum een Agile management methode is, terwijl XP een Agile ontwikkelmethode is. De doelstelling van beide is om meer zichtbaarheid te geven en betere aansluiting op de business te krijgen. Scrum staat voor een betere samenwerking in het team, XP voor een eenvoudiger requirements management en hoger product kwaliteit. SCRUM en XP zijn te combineren waardoor van beide invalshoeken wordt geprofiteerd. Zie bijlagen A.2 en A.3 voor nadere details met betrekking tot XP en Scrum. 2.3.3 De huidige trend in toepassing van Agile Uit enkele publicaties blijkt dat er een trend waarneembaar is van een groeiend gebruik van de Agile ontwikkelmethode. Daarnaast laten de publicaties zien dat er interpretatieverschillen bestaan over het gebruik van Agile. Voor de IT-auditor is het belangrijk ontwikkelingen op dit vlak te volgen. Agile ontwikkelmethoden zijn nog niet volwassen en op het moment van onderzoek zijn er wellicht nieuwe invalshoeken en aandachtspunten. Daarnaast zijn er ook verschijningsvormen en varianten van Agile met ieder hun eigen specifieke eigenschappen. Daarbij zijn Scrum en XP, en vooral in combinatie, breder geaccepteerd dan de andere varianten. De populariteit van Agile groeit. Het Forrester Research Instituut laat enerzijds zien dat meer dan de helft van de onderzochte organisaties aspecten en best practices van Agile ontwikkelmethodiek in gebruik hebben, anderzijds hebben organisaties voornemens Agile te gaan gebruiken. Echter voor de meeste organisaties is het niet precies duidelijk wat de adoptie van Agile precies inhoudt (Schwaber, 2007). Door de snelle opmars van Agile nemen ook de misverstanden over Agile toe en daarmee bestaat ook het risico dat de daadwerkelijke filosofie en beoogde doelen van de Agile ontwikkelmethode onduidelijk zijn en de methode niet echt begrepen wordt (Computable, 2008). Eind 2008 is eveneens bekend geworden dat het kabinet heeft besloten om Agile toe te passen bij de IT projecten. Het besluit betekent dat alle grote IT projecten van de overheid vanaf 2010 per projectfase worden beoordeeld op het resultaat van de afgeronde fase en op de gereedheid van de volgende fase (Computable, 2008). De overheid kan door het gebruik van iteraties sneller zien of het beoogde resultaat bereikt wordt. Het is echter de vraag wat precies bedoeld wordt met de verschillende projectfasen en het uiteindelijke resultaat. Het gebruik van de woorden fasen duiden namelijk nog steeds op een traditioneel ontwikkelmodel of op fasen zoals deze zijn gedefinieerd in projectmethodiek Prince2. Als dit een invulling is van incrementele en iteratieve ontwikkeling dan heeft dit zeker een Agile Status: Definitief 23/60 Versie: 1.1

karakter. Echter er zijn meer randvoorwaarden die moeten worden ingevuld, zoals we die in dit referaat onderkennen. Het bericht geeft aan dat Agile in populariteit wint, maar het is wel zorg dat hier de juiste interpretatie en invulling aan wordt gegeven. Feit blijft dat Agile wel degelijk bij bestuurders als kritische succesfactor wordt gezien. Een onderzoek van Shine Technologies geeft aan dat 96% van de ondernemingen bekend is met Agile en dat deze mogelijk van plan zijn Agile te gebruiken of het gebruik er van door te zetten (Shine, 2003). Ondanks de intentie van ondernemingen geeft de meerderheid van de respondenten aan dat zij denken dat niet alle projecten zich lenen voor de toepassing van Agile. Dit is de reden dat er onderzoeken lopen waarin de toepasbaarheid van de Agile ontwikkelingsmethodiek bij grotere IT projecten onderzocht wordt. Dat neemt niet weg dat steeds meer ondernemingen principes en waarden gebruiken uit het Agile Manifesto. Ook worden steeds vaker formele Agile methoden gebruikt. Grote ondernemingen zoals BT Group in UK en Ericsson hebben bekend gemaakt volgens een Agile ontwikkelingsmethode te werken. 2.4 Referentiemodel SDLC In deze paragraaf beschrijven we in grote lijnen de assurance rol van de IT-auditor en de richtlijn voor reviews van de SDLC van de Information Systems Audit and Control Association (ISACA, 2003). 2.4.1 Assurance rol Zoals beschreven in de afbakening van dit onderzoek richten wij ons tot de assurance rol van de ITauditor ten aanzien van het proces dat ten grondslag ligt aan het eindproduct van het systeemontwikkelproject. De auditor gaat na of er adequate controls aanwezig zijn in het proces en stelt tevens de effectiviteit vast van de controls. De doelstellingen voor de audit zijn tweeledig; Bescherming van kapitaalinvesteringen en aanbeveling van interne controlemaatregelen (Hettigei, 2005). De IT-auditor onderkent de risico s en bepaalt of de aanwezige beheersingsmaatregelen afdoende zijn. De audit is gericht op het proces en geeft geen garantie dat het juiste product ontwikkeld is, ook al wijst onderzoek uit dat het proces voldoet aan de gestelde eisen. De IT-auditor neemt dit expliciet op in de opdrachtomschrijving. Tevens merken we op, dat de IT-auditor ook binnen een systeemontwikkelingsproject meerdere rollen kan vervullen, zoals een adviesfunctie ten aanzien van specifieke vraagstukken of een Quality Assurance rol in het project. De opzet, het bestaan, als de werking kunnen onderwerp van onderzoek zijn voor de opdracht. In dit onderzoek gaan we er van uit dat de opdracht tot het uitvoeren van een IT audit bij een systeemontwikkelingsproject van buiten het project afkomstig is en dat aan het hoger management zekerheid wordt verschaft. Hiermee is de onafhankelijke positie van de IT-auditor gewaarborgd. De ITauditor moet altijd nagaan wat de positie van de opdrachtgever is ten aanzien van het audit proces. De integriteit van de opdrachtgever is belangrijk omdat bij het ontbreken hiervan het risico optreedt dat de IT-auditor tot onjuiste conclusies komt (Praat, Suerink, 2004). Status: Definitief 24/60 Versie: 1.1

IT Project Hoger management Kwaliteits bewaking Risico management Onafhankelijke verschaffing van zekerheid omtrent adequate beheersing Auditor Figuur: Rol van auditor ten aanzien van systeemontwikkelproject Audit Onderzoek Afhankelijk van in welke fase het IT project zich bevindt zijn er verschillende onderzoeken mogelijk: pre-implementatie fase De IT-auditor onderzoekt het door het programmamanagement beoogde SDLC model voor een project op geschiktheid. Tevens onderzoekt de IT-auditor potentiële risico s en de beheersingsmaatregelen om deze risico s tegen te gaan; parallelle/gelijktijdige fase De IT-auditor onderzoekt de SDLC fase waar het project zich momenteel in bevindt. Hij inventariseert risico s en stelt beheersingsmaatregelen vast om deze risico s tegen te gaan; postimplementatie fase De IT-auditor onderzoekt achteraf de doorlopen SDLC fasen en inventariseert opgetreden problemen, daarnaast stelt hij vast hoe deze problemen een volgende keer voorkomen kunnen worden. IT-Governance IT-Governance is een onderdeel van Corporate Governance dat zich richt op behoorlijk bestuur van de informatie voorziening. Hierbij is inbegrepen integer en transparant handelen, evenals goed toezicht hierop en het afleggen van verantwoording over het uitgeoefende toezicht. Binnen het raamwerk voor IT-Governance worden een ontwikkelmethodiek en bijbehorende processen geadresseerd. Systeemontwikkelingsprojecten moeten voldoen aan het beleid van de organisatie. Daarom is ook het algemeen raamwerk voor IT-Governance in dit kader relevant. Het bekendste uitgewerkte IT- Governance normenstelsel is COBIT (Control Objectives for Information and related Technology) van het Amerikaanse IT-GovernanceInstitute. Cobit Cobit is een door IT-auditors veel gebruikte toetsingsnorm voor IT-Governance. Inhoudelijk is Cobit gebaseerd op onderliggende standaarden en raamwerken zoals ITIL, BS7799, ISO en COSO. Cobit is geen vervanger van deze standaarden maar eerder een raamwerk dat als controlemodel over een IT organisatie en haar processen wordt gelegd. In het Cobit model worden 34 IT processen onderscheiden onderverdeeld over 4 aandachtsgebieden (domeinen) (Singleton, 2006). Voor dit raamwerk van 34 deelprocessen worden liefst 318 specifieke control objectives geformuleerd. Cobit draagt zorg dat de IT de bedrijfsstrategie ondersteund door invulling te geven aan onderstaande punten: 34 deelprocessen; 318 control objectives; Status: Definitief 25/60 Versie: 1.1

key performance indicatoren; key goal indicatoren; kritische succesfactoren; een volwassenheidsmodel. Het proces A12 acquire and maintain application structure uit Cobit geeft aan dat de volgende beheersdoelstellingen het meest relevant zijn voor de inrichting van General IT controls: - De organisatie heeft een SDLC methodologie inclusief beveiliging- en integriteiteisen; - De SDLC methode schrijft voor dat informatiesystemen worden ontwikkeld met application controls die een accurate en geautoriseerde transactieverwerking ondersteunen; - De organisatie verwerft of ontwikkelt informatiesysteem software in overeenstemming met de verwerving, ontwikkeling en planning processen. COBIT beschrijft 7 criteria waar informatie systemen aan moeten voldoen, te weten: effectiviteit, efficiency, vertrouwelijkheid, integriteit, beschikbaarheid, betrouwbaarheid en verantwoording. Ook vanuit de IT-Governance is het belangrijk om de doelstellingen van een organisatie te bereiken en niet alleen de procedures te volgen omdat dit noodzakelijk is aangezien de auditor eisen hieraan stelt met betrekking tot de controleerbaarheid (Woda, 2002). ISACA, wereldwijde organisatie voor IT-Governance specialisten, waaronder IT-auditors, hanteert een richtlijn voor de aanpak van een SDLC audit (ISACA, 2003). De richtlijn van deze organisatie concentreert zich feitelijk op een audit in het kader van breedgedragen traditionele systeemontwikkeling. In deze richtlijn is onder meer de rol van de IT-auditor beschreven, bij het verschaffen van zekerheid bij systeemontwikkeling. In de volgende subparagraaf gaan we hier nader op in. 2.4.2 SDLC risico s Bij de definitie van de SDLC gaat ISACA uit van het systeemontwikkeling proces bestaande uit verschillende fases van de levenscyclus zoals eerder beschreven in 2.2.3. De SDLC van een applicatie systeem is afhankelijk van de gekozen ontwikkelmethode. Enkele zaken uit het ISACA richtlijn voor SDLC reviews die relevant zijn voor dit onderzoek zetten we nader uiteen: SDLC Risico s Gedurende de levenscyclus zijn er risico s dat een project onvoldoende beheerst wordt en dat een project niet effectief en efficiënt tot het gewenste eindresultaat weet te komen. Vanuit het bovengenoemde ISACA richtlijn voor de beoordeling van systeemontwikkeling zijn risico geïdentificeerd die betrekking hebben op traditionele systeemontwikkeling. # Risico s traditionele ontwikkeling 1 het aannemen van een ongeschikte SDLC voor het applicatie systeem 2 onvoldoende beheersingsmaatregelen in het SDLC proces 3 het applicatie systeem voldoet niet aan de eisen van gebruikers 4 onvoldoende betrokkenheid van belanghebbenden 5 onvoldoende management ondersteuning 6 onvoldoende project management 7 ongepast gebruik van techniek en architectuur 8 scope variaties 9 tijd en budget overschrijdingen; 10 onvoldoende kwaliteit van het applicatie systeem 11 onvoldoende aandacht voor beveiligingsmaatregelen in het applicatiesysteem 12 niet voldoen aan performance criteria 13 onvoldoende documentatie 14 onvoldoende aandacht voor afhankelijkheden met andere applicaties en Status: Definitief 26/60 Versie: 1.1

processen 15 onvoldoende configuratie management De auditor zal bij zijn beoordeling ten aanzien van traditionele systeemontwikkeling af moeten wegen of er voldoende beheersingsmaatregelen ten aanzien van de risico s genomen zijn. Onderstaande, door de ISACA aangedragen zijn, zijn volgens ISACA aspecten die de IT-auditor zou kunnen hanteren om vast te kunnen stellen of beheersingsmaatregelen in het proces geborgd zijn. # Beheersmaatregel 1 Business case 2 project plan 3 project structuur inclusief rollen en verantwoordelijkheden 4 ontwikkelmethode; en gekozen gereedschap; 5 opzet van controle processen in het te beoordelen SDLC model 6 verslagen van relevante vergaderingen, zoals bv. van stuurgroepvergaderingen 7 mijlpalen in het SDLC model beoordeling, validatie (verificatie en testen), goedkeuring met afmelding bij de verschillende SDLC fasen 8 project verslagen bv. over de voortgang en eventuele escalatie 9 configuratie management en versiebeheer 10 Risicomanagement 11 Kwaliteitmanagement 12 Wijzigingenbeheer 13 data conversie en migratie 14 project gerelateerde documentatie zoals bv een testplan 15 voorgaande SDLC onderzoeken 16 voorgaande onderzoeken met als object een voorgaande SDLC fase 17 relevante jurisprudentie Daarnaast verwijzen de richtlijnen van ISACA naar het gebruik van COBIT voor het beoordelen van systeemontwikkeling. Opvallend in het normenkader zijn de regelgebaseerde benadering in plaats van een op principe gebaseerde benadering. Een artikel van ISACA (Singleton, 2007) benadrukt de functie van vastlegging gedurende de fasen van de SDLC als potentieel bewijsmateriaal voor de IT-auditor. Het artikel onderscheidt 8 SDLC fasen en benoemt per fase de documenten die het proces moet voortbrengen. Dit is te vergelijken met de mijlpaalproducten die SDM levert. Zo dient de SDLC niet alleen als beheersingsmaatregel, maar biedt het ook mogelijkheden, in de vorm van documentatie, voor de IT-auditor om zekerheid te verkrijgen over de effectiviteit en efficiency van het SDLC systeem. Naast interviews en controlelijsten is ook hier SDLC documentatie het aangewezen verificatie middel. 2.5 Confrontatie In deze paragraaf zetten we traditionele systeemontwikkeling en Agile systeemontwikkeling tegenover elkaar. Wij laten eerst zien welke organisatietopologie passend is voor toepassing van Agile. Daarna, aan de hand van het management control raamwerk schetsen we de randvoorwaarden die ingevuld moeten worden om de Agile processen succesvol te kunnen toepassen. 2.5.1 Typologiebepaling In de literatuur zijn er ook modellen die aangeven in hoeverre de ontwikkelmethode past bij een organisatie. Een aantal factoren worden geïdentificeerd die bepalend zijn voor de toepassing van de systeemontwikkelmethode. Vinekar (Vinekar, 2006) geeft aan dat de ontwikkelstrategie van een Status: Definitief 27/60 Versie: 1.1

informatiesysteem afhankelijk is van twee factoren: Organisatiecultuur en de mate van voorspelbaarheid van een project. 1. Organisaties die een overwegend individualistische cultuur hebben vertrouwen meer op expliciete kennis dan die met een collectieve cultuur. 2. Naarmate een project minder voorspelbaar is wordt vaker gekozen voor een ontwikkelstrategie die gericht is op verandering. 3. Ook wordt bij minder voorspelbare projecten vaker gekozen voor een strategie van samenwerking met gebruikers. 4. Organisaties met een individualistische cultuur hanteren een meer proces gedreven ontwikkelstrategie ten opzichte van organisaties met een collectieve cultuur. Met deze stellingen kunnen op het kwadrant van organisatiecultuur en onzekerheid in het project vier ontwikkelstrategieën onderkend worden. Deze worden in onderstaande figuur weergegeven; Figuur 4; ontwikkelstrategieën afhankelijk van organisatiecultuur en zekerheid met betrekking tot de requirements (Vinekar, 2006) Ook Boehm en Turner (Boehm, 2003) opperen het toepassen van een risicoanalyse om te kiezen tussen adaptieve (Agile) en voorschrijvende (traditionele) methoden. Volgens hen hebben beide uiteinden van het continuüm hun eigen bestaansgrond. Volgens dit artikel wijst de praktijk uit dat de Agile methode het best gedijt in een situatie waarin requirements voortdurend en snel veranderen. Hierbij zijn onderstaande kenmerken te onderscheiden, waarbij die van Agile ontwikkeling gelden als randvoorwaarden in deze scriptie; Agile ontwikkeling Grote oplossingsruimte Senior ontwikkelaars Zeer veranderlijke projecteisen Beperkt aantal ontwikkelaars in een team Cultuur die in chaos gedijt Traditionele ontwikkeling Scherpe specificaties Junior ontwikkelaars Vaststaande projecteisen Groot aantal ontwikkelaars Cultuur die orde vereist De auditor zal na moeten gaan of bovengenoemde aspecten in de gegeven situatie aanwezig zijn en of daarmee de randvoorwaarden zijn ingevuld om te komen tot een beheerste omgeving. In de volgende paragraaf bespreken we het management control raamwerk dat als vertrekpunt dient voor de beschrijving van randvoorwaarden die gelden bij Agile processen. 2.5.2 Management Control raamwerk Het onderzoeksobject verandert bij Agile ontwikkeling niet. De IT-auditor voert de onafhankelijke attest functie uit en komt tot een oordeel om zekerheid te verschaffen of een systeemontwikkelingsproject in voldoende mate wordt beheerst en de maatregelen effectief zijn. De specifieke controle activiteiten die de IT-auditor uitvoert hebben een andere invulling bij Agile systeemontwikkeling dan bij traditionele ontwikkeling. De IT audit van een klassieke ontwikkelmethode is gebaseerd op de producten die gedurende het ontwikkelproces worden opgeleverd. Bij een audit worden voornamelijk de resultaten en tussenproducten van een proces getoetst en niet zozeer de totstandkoming (het procesverloop zelf). Status: Definitief 28/60 Versie: 1.1

Bij een traditionele ontwikkelmethode zijn de mijlpaalproducten, rapportages en besluitvorming het object van onderzoek. Bij Agile is een productgericht onderzoek beperkt mogelijk. Agile steunt niet op vastlegging maar steunt op menselijke factoren, feedback en ondersteunende tools. De IT audit van een Agile ontwikkelproject zal daarom voornamelijk op het proces gericht zijn. Procesgericht wil zeggen dat de controle gericht is op het toetsen van het proces zelf: is de opzet (inrichting) van een proces goed en wordt daadwerkelijk gewerkt zoals het proces is opgezet? De IT-auditor moet zich ervan bewust zijn dat naast de procesmatige inrichting goed ingevulde randvoorwaarden essentieel zijn voor het beheersen van een Agile project. Deze randvoorwaarden zijn onder andere de directe communicatie binnen een team en de interactie met de opdrachtgever. Het Agile proces heeft korte iteraties met feedbackcycli met als doel een zelflerend effect te bewerkstelligen waardoor continue procesverbetering optreedt. Hierdoor sluit Agile goed aan bij volwassenheidsmodellen zoals CMMi. De IT-auditor kan deze constatering gebruiken in zijn onderzoek naar het volwassenheidsniveau van het proces in een organisatie. Figuur: Aandachtspunten voor beheersing Agile ontwikkeling vanuit het perspectief van de IT-auditor Samenvattend is het onderzoeksgebied van de rol van de IT-auditor bij een systeemontwikkelingsproject te illustreren in onderstaande figuur. Hierbij zijn de relaties binnen het management control raamwerk gevisualiseerd en wordt de relatie van de gehanteerde normen en de rol van IT audit aangeduid. Het management control raamwerk vertegenwoordigt het beleid en de procedures die ervoor zorgen dat resultaten behaald worden en doelstelling bereikt worden. Status: Definitief 29/60 Versie: 1.1