Rol van de IT auditor bij agile systeemontwikkeling

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding

Auteurs Versie Datum Instituut Team

Jan Rodenburg & Vincent Vlaanderen 1.1 Mei 2009 Vrije universiteit Amsterdam 911


Colofon Titel Auteurs Opleiding Scriptiebegeleider Faculteit Universiteit Werkgevers Bedrijfsbegeleiders File Name Status Distributie

Rol van de IT auditor bij agile systeemontwikkeling Drs. Ing. J. (Jan) Rodenburg & V. (Vincent) Vlaanderen Postgraduate IT (EDP)-audit opleiding Drs. R. (Rob) Christiaanse RA Faculteit der Economische Wetenschappen en Bedrijfskunde (FEWEB) Vrije Universiteit Amsterdam Collis | Achmea Vastgoed Ir. D.J. (Derk-Jan) de Grood | drs. J.H. (Hans) Evers 911_Rol_IT_auditor_bij_agile_systeemontwikkeling_Rodenburg_Vlaanderen_v1.1 Definitief Scriptiecoordinator VU, secretariaat VU PGO IT-audit, scriptiebegeleider, Achmea Vastgoed, Collis

Versie historie Versie 1.0

Datum 30 maart 2009

Status Definitief

1.1

29 mei 2009

Definitief

Auteurs Jan Rodenburg Vincent Vlaanderen 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 1.2 1.3 1.4

INLEIDING ...................................................................................................................................7 PROBLEEMSTELLING ......................................................................................................................7 VRAAGSTELLING EN ONDERZOEKSVRAGEN ..........................................................................................8 AFBAKENING ...............................................................................................................................8

2

LITERATUURONDERZOEK ......................................................................................................10

2.1 2.2

INLEIDING .................................................................................................................................10 REFERENTIE ..............................................................................................................................10 2.2.1 BELANG VAN REQUIREMENTS ............................................................................................... 10 2.2.2 KWALITEITSMODELLEN ........................................................................................................ 12 2.2.3 RAAMWERK ONTWIKKELPROCESSEN....................................................................................... 14 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 REFERENTIEMODEL SDLC.............................................................................................................24 2.4.1 ASSURANCE ROL ................................................................................................................ 24 2.4.2 SDLC RISICO’S................................................................................................................... 26 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

2.3

2.4

2.5

3

REFERENTIEMODEL AGILE ONTWIKKELING............................................................................36

3.1 3.2 3.3 3.4 3.5

INLEIDING .................................................................................................................................36 RISICOANALYSE..........................................................................................................................36 BEHEERSINGSMAATREGELEN .........................................................................................................37 INTERPRETATIE VAN BEHEERSINGSMAATREGELEN ...............................................................................38 AANDACHTSPUNTEN VOOR DE AUDIT ..............................................................................................40

4

TOETSING IN DE PRAKTIJK .....................................................................................................41

4.1 4.2 4.3

INLEIDING .................................................................................................................................41 VRAGENLIJST .............................................................................................................................41 RESULTATEN INTERVIEWS .............................................................................................................41

5

ANALYSE VAN DE INTERVIEW RESULTATEN...........................................................................45

Status: Definitief

5/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 5.1 5.2 5.3 5.4

INLEIDING .................................................................................................................................45 THEORIE...................................................................................................................................45 PRAKTIJK ..................................................................................................................................45 ANALYSE ..................................................................................................................................46

6

CONCLUSIE ............................................................................................................................47

6.1 6.2 6.3 6.4

INLEIDING .................................................................................................................................47 CONCLUSIE ...............................................................................................................................47 AANBEVELINGEN ........................................................................................................................48 DISCUSSIE.................................................................................................................................48

REFERENTIES.......................................................................................................................................50 BIJLAGEN ............................................................................................................................................53 A.1 A.2 A.3

SDM ......................................................................................................................................53 EXTREME PROGRAMMING ............................................................................................................56 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 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 BieneHersey, 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 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 lijnen 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding • • • • •

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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 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. 2. 3. 4. 5. 6.

Analysefase (met definitiestudies en analyserapporten als eindproduct); Ontwerpfase (met functionele en technische ontwerpen als eindproduct); Bouwfase (met broncode als eindproduct); Testfase (met werkende broncode als eindproduct); Integratiefase (eindgebruikers gaan ermee aan de slag); 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding ‘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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding Hoger management IT Project

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 ITGovernance 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding • • • •

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. # 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Risico´s traditionele ontwikkeling het aannemen van een ongeschikte SDLC voor het applicatie systeem onvoldoende beheersingsmaatregelen in het SDLC proces het applicatie systeem voldoet niet aan de eisen van gebruikers onvoldoende betrokkenheid van belanghebbenden onvoldoende management ondersteuning onvoldoende project management ongepast gebruik van techniek en architectuur scope variaties tijd en budget overschrijdingen; onvoldoende kwaliteit van het applicatie systeem onvoldoende aandacht voor beveiligingsmaatregelen in het applicatiesysteem niet voldoen aan performance criteria onvoldoende documentatie onvoldoende aandacht voor afhankelijkheden met andere applicaties en

Status: Definitief

26/60

Versie: 1.1


15

processen 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. # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Beheersmaatregel Business case project plan project structuur inclusief rollen en verantwoordelijkheden ontwikkelmethode; en gekozen gereedschap; opzet van controle processen in het te beoordelen SDLC model verslagen van relevante vergaderingen, zoals bv. van stuurgroepvergaderingen mijlpalen in het SDLC model – beoordeling, validatie (verificatie en testen), goedkeuring met afmelding bij de verschillende SDLC fasen project verslagen bv. over de voortgang en eventuele escalatie configuratie management en versiebeheer Risicomanagement Kwaliteitmanagement Wijzigingenbeheer data conversie en migratie project gerelateerde documentatie zoals bv een testplan voorgaande SDLC onderzoeken voorgaande onderzoeken met als object een voorgaande SDLC fase 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding informatiesysteem afhankelijk is van twee factoren: Organisatiecultuur en de mate van voorspelbaarheid van een project. 1. 2. 3. 4.

Organisaties die een overwegend individualistische cultuur hebben vertrouwen meer op expliciete kennis dan die met een collectieve cultuur. Naarmate een project minder voorspelbaar is wordt vaker gekozen voor een ontwikkelstrategie die gericht is op verandering. Ook wordt bij minder voorspelbare projecten vaker gekozen voor een strategie van samenwerking met gebruikers. 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

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 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


Figuur: Management Control Raamwerk Agile ontwikkeling

2.5.3

Randvoorwaarden voor Agile ontwikkeling

In deze paragraaf gaan wij in op de randvoorwaarden voor Agile ontwikkelmethode. Alleen aspecten relevant voor de IT audit worden hier in opgenomen. In §2.3 constateren wij dat de wijze van beheersing van het proces anders is bij Agile. Waar bij een traditionele ontwikkelmethode voornamelijk de output in de vorm van documentatie wordt opgeleverd om een meer op controle gebaseerd proces te faciliteren, wordt bij de Agile ontwikkelmethode voornamelijk vertrouwd op de kunde van de mensen die gezamenlijk tot een resultaat wensen te komen. In het kader van beheersing van het ontwikkelproces spelen in belangrijke mate de processen en procedures een rol en de ondersteuning in de vorm van tooling. We gaan hier verder op in waarbij de principes van Agile dienen als vertrekpunt: Mensen Bij Agile is de beheersing en de planning van het project voor een groot deel in handen van het gehele team. De rol van de manager is zuiver coachen, zorgen voor middelen, het vasthouden van de visie en zorgen voor de invulling van randvoorwaarden die zich lenen voor toepassing van de op Agile gebaseerde systeemontwikkeling (Larman, 2005). De scheiding tussen de rol van de manager en de teamleden is niet zo strikt als binnen traditionele systeemontwikkeling. Binnen Agile ligt de nadruk meer op kracht van mensen in plaats van op standaardprocedures, dit betekent dat teamleden meer ruimte hebben voor eigen invulling binnen het gegeven proces. Processen

Status: Definitief

30/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding Agile benadrukt dat de factor mens en de factor ondersteunende processen en procedures in balans moeten zijn. Goede mensen en een goed proces presteren beter dan goede mensen zonder proces (Booch, 1996). Elke Agile variant heeft daarom een processtructuur, een processtroom, verschillende rollen en worden de te volgen stappen binnen het project uiteengezet (Larman, 2005). In vergelijking met de traditionele ontwikkelmethoden is de procesinrichting minder gedetailleerd. Bij Agile moet het proces gedisciplineerd gehanteerd worden, waarbinnen de mensen de ruimte krijgen voor eigen inbreng en continue verbetering om optimaal te kunnen profiteren van de gepretendeerde voordelen van Agile. Documentatie Door intensieve samenwerking en veelvuldige opleveringen is er bij Agile minder behoefte om documentatie aan te leggen. Mocht de opdrachtgever behoefte hebben aan specifieke documentatie dan kan hij deze als requirement in het project inbrengen. Documentatie in de vorm van functionele specificaties, test specificaties en vastgelegde implementatie keuzes is noodzakelijk omdat het project op een zeker moment overgedragen wordt aan een gebruikersorganisatie, maar heeft dus geen functie voor communicatie binnen het team. Daarnaast zorgt voldoende documentatie in de programmacode er voor dat code wijzigingen en testen efficiënt kunnen verlopen. Voorspelbaarheid De traditionele ontwikkelingmethode stelt dat een systeem voorspelbaar te ontwikkelen is (Cockburn, 2006). De praktijk wijst uit dat een ontwikkelproces niet binnen een voorspellend kader valt en dat sofware ontwikkelingsprojecten vaak niet tot de gewenste resultaten leiden. Zoals in §2.2.1 aangegeven zijn requirements lastig te verwoorden en worden zij pas later, op basis van voortschrijdend inzicht, concreet. Door alleen de initieel opgestelde requirements te gebruiken zoals bij traditionele ontwikkeling bestaat er een grote kans dat het systeem uiteindelijk niet voldoet. De procesinrichting bij Agile is adaptief aan veranderende requirements, waardoor ingespeeld wordt op de veranderingen die onmiskenbaar plaats gaan vinden. Planning Budgettering vindt bij traditionele ontwikkeling plaats over de periode van het gehele project. Bij Agile worden de budgetten afgestemd per iteratie. Bij Agile variant Scrum is dit op een goede manier inzichtelijk. In de zogenaamde Scrum Product Backlog staan alle requirements die voor ontwikkeling in aanmerking komen. Alle requirements zijn opgenomen in de ‘Scrum ‘ Product backlog’ waarbij de functionaliteit wordt voorzien van een (ruwe) inschatting en een prioriteit. Het prioriteren wordt gedaan door het toekennen van een uniek business value getal, waarbij een hoger getal een hogere prioriteit aangeeft. Bij de start van een iteratie wordt uit de ‘Product Backlog’ de functionaliteit met de hoogste prioriteit ontwikkeld. Agile gebruikt de techniek ‘timeboxing’ in plaats van budgettering. Nadeel is dat vooraf geen concrete schatting van de hoeveelheid werk gegeven kan worden, omdat de hoeveelheid werk aan verandering onderhevig is. Per iteratie is planning goed mogelijk. Dit gebeurt op basis van ‘burn down charts’, waarbij de voortgang van het onderhanden werk wordt gemeten. Daarnaast is er een moment waarop een eerste release moet worden geïmplementeerd, hierover kunnen afspraken gemaakt worden door een limiet te stellen aan het aantal iteraties voor in productie name. Agile zal initieel achterlopen met requirements ten opzichte van traditionele systeemontwikkeling. Na enkele iteraties zal Agile inlopen en zelfs meer functionaliteit geïmplementeerd hebben. Bij traditionele systeemontwikkeling is het gevaar dat in de tijd de functionaliteit afneemt omdat in die fase geen validatie is geweest tussen ontwikkelaar en eindgebruiker.

Status: Definitief

31/60

Versie: 1.1


Figuur: verloop van geïmplementeerde requirements ten opzichte van de doorlooptijd Overigens ontstaat bij Agile wel het gevaar van ‘scope creep’. Doordat de opdrachtgever actief deelneemt aan het proces kan deze zo enthousiast worden en verbeterpunten blijven aandragen zonder dat dit leidt tot nieuwe requirements. Het gevaar ontstaat dat het ontwikkelteam met het inwilligen van deze aanpassingen de grote lijn luit het oog verliest en dat het project uitloopt. Het is van belang dat Agile alle wensen van de opdrachtgever blijft vertalen in requirements en daar consequenties in de vorm van invloed op de doorlooptijd (in aantal iteraties) aan verbindt. Volwassenheid Bij Agile zijn in tegenstelling tot traditionele ontwikkelmethode belangrijke aspecten zoals feedback en communicatie verwerkt in het proces. Dit is tevens een manier om het volwassenheidsniveau te verhogen. In een goed verbetertraject staat communicatie centraal, is er feedback ten aanzien van de resultaten, zijn er coaches die de verandering begeleiden en worden de prestaties erkend en gewaardeerd (Linders, 2007). Dit betekent dus dat de feedback en verbetercyclus in het proces verweven zit. Aangezien dit ook een belangrijk kenmerk is van een verhoging van de volwassenheid zal daarmee de huidige volwassenheid van de organisatie in zekere mate bepalen in hoeverre de organisatie bereid is om een Agile proces te adopteren.

2.5.4

General IT controls

Wijzigingenbeheer Bij een organisatie die reactief is ten opzichte van veranderingen is het toepassen van Agile methoden een uitdaging aangezien Agile een proactieve houding eist. Het projectplan en de initiële requirements worden bij Agile vaak als schatting gebruikt in de veronderstelling dat gedurende de ontwikkelfase kennis en kunde wordt opgebouwd om het project tot een succesvol einde te brengen. Vaak gebruikt Agile het concept van ‘timeboxing’ om de voortgang te bewaken en wordt van de gebruiker verwacht om prioriteiten aan te geven in de functionaliteit op basis waarvan het ontwikkelteam de volgorde van de ontwikkeling kan bepalen. Het is dus essentieel dat de gebruiker meedenkt over prioriteiten en over acceptatiecriteria. Hiermee legt Agile veel druk op de gebruiker en wordt deze een succesfactor in het project. Een traditioneel systeem ontwikkelproject veronderstelt dat specificaties voor aanvang van de ontwikkeling vrijwel compleet uit te specificeren zijn tot een baseline. Traditioneel systeem ontwikkeling gaat er vervolgens vanuit dat de baseline niet meer verandert gedurende het project. Agile ziet de requirements specificatie als een vertrekpunt. De initiële requirements zijn in een Agile ontwikkelproject minder gedetailleerd en omvangrijk. De requirements zijn abstract gedefinieerd. Zowel

Status: Definitief

32/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding de gebruikers als de ontwikkelaars komen gedurende het project tot betere inzichten. Daarmee bestaat meer ruimte voor interpretatie en eigen invulling door het gehele team. Net als bij traditionele ontwikkelingsprojecten ligt bij Agile systeemontwikkeling de eindverantwoordelijkheid voor het goedkeuren van de aanpassingen in het systeem bij de eindgebruiker. Het wijzigingenbeheer draagt verder zorg dat het systeem ook daadwerkelijk in de behoeften van de opdrachtgevers en gebruikers voorziet. Dit geeft risico’s met betrekking tot het mandaat en de expertise van de gebruikers die als afgevaardigde van de senior user bij het project betrokken zijn. Er dient communicatie te zijn tussen gebruikers en het ontwikkelteam, waarbij het van belang is dat de gebruikers vrijgemaakt zijn voor het project. Dan kan een goede relatie ontstaan tussen het ontwikkelteam en eindgebruikers zodat men efficiënt en effectief tot het gewenste resultaat kan komen. Ten behoeve van de samenwerking is het van belang dat bij Agile gedurende de looptijd van het project in één en dezelfde teamformatie wordt gewerkt en dat de gebruiker het gehele traject betrokken is. Bij Traditionele ontwikkeling zijn teamleden vervangbaar en is de gebruiker alleen bij de beginfase en eindfase van het project betrokken. Doordat bij Agile de gebruiker het gehele proces betrokken is bij het project is hij mede verantwoordelijk voor het resultaat. Bij traditionele systeem ontwikkeling wordt de IT organisatie verantwoordelijk gehouden voor het resultaat. Informatiebeveiliging Algemeen is Agile systeemontwikkeling gericht op het leveren van software op met een goede kwaliteit. Met het implementeren van testen voordat de code is geschreven kunnen fouten die bijvoorbeeld tot beveiligingslekken kunnen leiden, in ontwerp al worden voorkomen. Verder kan het ontwikkelde systeem, net als bij traditionele systeemontwikkeling, onafhankelijk geverifieerd en gevalideerd worden, zodat extra zekerheid met betrekking tot de beveiligingsaspecten verkregen wordt. Veel gebruikte methoden zijn een ‘code review’ en een penetratietest. Informatiebeveilingsaspecten moeten in voldoende mate aandacht krijgen binnen een systeemontwikkelingsproject, zodat het systeem overeenkomstig met de beveiligingseisen conform de risicokwalificatie ontwikkeld wordt en in gebruik genomen kan worden. De gebruikersorganisatie is verantwoordelijkheid voor de acceptatiecriteria en verificatie van de indirecte eisen die vaak niet in specifieke functionele eisen gevat kunnen worden, zodoende worden deze ook wel niet-functionele requirements genoemd. Een specialist of een IT-auditor kan hier een rol in vervullen. In de bestaande literatuur van Agile ontwikkeling hebben wij hier geen specifieke aandacht voor kunnen vinden. Configuratie management Configuratie management wordt niet expliciet genoemd binnen de Agile ontwikkelvarianten. Wel kunnen we afleiden dat organisaties hun processen zodanig moeten inrichten zodat zij in staat zijn Agile iteraties te faciliteren. Het is zeer belangrijk dat de tools aanwezig zijn die het proces van continue releases en bijbehorend versiebeheer ondersteunen. Gebruikers moeten voldoende getraind moeten zijn om met deze ondersteunende software om te gaan (Schwaber 2004). Onafhankelijke systeem- en systeemintegratietesten De Agile aanpak voor testen is anders dan in traditionele ontwikkeling. Traditioneel voert de tester een verificatie en validatie functie uit op basis van de gedetailleerde specificaties. Bij Agile hebben de specificaties nog niet het gewenste concrete niveau bereikt om volledige testspecificaties en testen af te kunnen leiden. In vergelijking met een traditioneel testtraject zal in een Agile testtraject voor een deel gesteund worden op de verwachte bovengemiddelde kwaliteit van de code, door de focus op geïntegreerde unit- en integratietesten. Door middel van ‘test driven development’ (TDD) worden testen gedefinieerd voordat de code geschreven wordt wat een grotere testdekking van zowel functionele als regressietesten in de code zelf waarborgt. Systeem en systeemintegratietesten zijn vervolgens wel nodig om vast te stellen dat de systemen en modules in combinatie met andere systemen doen wat er van wordt verwacht en in samenhang tot de gewenste resultaten leidt, maar hier kan dan worden volstaan met een steekproef uit alle testen.

Status: Definitief

33/60

Versie: 1.1


Veel testtrajecten zijn tegenwoordig gebaseerd op businessrisico’s en projectrisico’s. Het risico bij ingebruikname van de software binnen een organisatie bepaalt dan de testaanpak (Grood, 2007). Een testrisicoanalyse wordt gebruikt voor het bepalen van de risico´s en de te volgen teststrategie. Aangezien in het begin van een Agile project de functionaliteit niet compleet is zal deze gedurende het project aangepast moeten worden en een continue verandering moeten ondergaan. In het begin van het traject vult de tester zijn rol in met story testen waarbij doelstellingen van de acceptanten zoveel mogelijk worden nagestreefd door middel van het doorlopen van scenario’s. De tester ondersteunt vervolgens ook de eindgebruiker bij validatie van de software die regelmatig opgeleverd wordt. Ook in het vakgebied testen worden initiatieven genomen op de veranderende werkwijze die kenmerkend is voor Agile. Een van de aspecten is het definiëren van acceptatietesten voordat de ontwikkeling plaatsvindt. Binnen zogenaamde ‘acceptance test driven development’ (ATDD) worden acceptatietesten gedefinieerd en geautomatiseerd op basis van voorbeeld scenario’s van de eindgebruiker, van waaruit de testen over componenten en systemen plaats kunnen vinden. Het blijft overigens belangrijk dat de tester een onafhankelijke rol uitoefent, zodat controle uitgeoefend wordt op de kwaliteit van de oplevering. Voor de auditor dus de taak om te verifiëren of de onafhankelijke rol van de tester voldoende gewaarborgd is binnen het project.

2.5.5

Gevolgen voor risico’s systeemontwikkeling

Wanneer we de risico’s van de SDLC genoemd in §2.4.2 naast het management control raamwerk leggen, kunnen we constateren dat dit raamwerk niet aansluit op de risico’s die voortkomen uit de SDLC. De risico’s liggen bij agile ontwikkeling dan ook op een ander niveau. Een belangrijk aandachtspunt voor beheersing van een agile systeemontwikkelingsproject zijn dan ook met name de randvoorwaarden waaronder het ontwikkelproces plaatsvindt. In onderstaande schema geven wij dan ook aan of in welke mate de risico’s van traditionele ontwikkeling ook van toepassing zijn binnen agile systeemontwikkeling. #

Risico´s traditionele ontwikkeling

1

het aannemen van een ongeschikte SDLC voor het applicatie systeem onvoldoende beheersingsmaatregelen in het SDLC proces

2

3

5

het applicatie systeem voldoet niet aan de eisen van gebruikers onvoldoende betrokkenheid van belanghebbenden onvoldoende management ondersteuning

6

onvoldoende project management

7

ongepast gebruik van techniek en architectuur

8

scope variaties

9

tijd en budget overschrijdingen;

4

Status: Definitief

Van toepassing binnen Agile systeemontwikkeling De topologie bepaalt of Agile geschikt is. Agile veronderstelt andere beheersingsmaatregelen en heeft andere aandachtspunten dan een traditionele methode. Inherent aan Agile is dat er wordt ontwikkeld wat de gebruiker wil. Agile vereist betrokkenheid van belanghebbenden. Zeer belangrijk bij Agile is voldoende draagkracht en bewustzijn bij het management. Speelt in mindere mate bij Agile. Project management heeft slechts een ondersteunende en faciliterende rol. Het Agile ontwikkelteam is in staat de ontwikkeltools te kiezen die het beste passen bij het team en product architectuur. Dit is inherent aan Agile en wordt beheerst per iteratie. Agile ontwikkelt alleen de requirements die nodig zijn, niet meer of minder.

34/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 10 11

onvoldoende kwaliteit van het applicatie systeem onvoldoende aandacht voor beveiligingsmaatregelen in het applicatiesysteem

12 13

niet voldoen aan performance criteria onvoldoende documentatie

14

onvoldoende aandacht voor afhankelijkheden met andere applicaties en processen onvoldoende configuratie management

15

Agile levert hogere kwaliteit door TDD en capabel ontwikkelteam. Dit is afhankelijk van de betrokken stakeholders in het acceptatie team. Indien beveiligingsmaatregelen niet als requirements worden opgevoerd worden ze ook niet ontwikkeld. Idem Door sterke communicatie mechanisme binnen Agile is minder documentatie benodigd. Door inzet van multidisciplinaire teams wordt risico hierop beperkt. Agile propageert intensief gebruik van effectieve tooling.

Het belangrijkste verschil tussen de risico’s van SDLC en Agile ontwikkeling is dat de afwijkingen binnen de Agile ontwikkeling inherent in het Agile proces onderkend worden en verbeteringen in volgende iteraties snel geïmplementeerd en geëvalueerd kunnen worden. Dit mechanisme is binnen de SDLC minder aanwezig en vergt eveneens een in essentie langere doorlooptijd door het volledig doorlopen van de verschillende fasen. De risico’s die specifiek bij Agile systeemontwikkeling spelen zullen wij in het volgende hoofdstuk uiteenzetten.

Status: Definitief

35/60

Versie: 1.1


3

REFERENTIEMODEL AGILE ONTWIKKELING 3.1

Inleiding Dit hoofdstuk gaat in op de risico’s en beheersingsmaatregelen die relevant zijn voor de IT-auditor bij Agile systeemontwikkeling. Daarbij dient onderstaande deelvraag uit het onderzoek beantwoorden te worden: “Welke aandachtspunten staan centraal in een IT audit op een systeemontwikkelingproject gekenmerkt door een Agile ontwikkelmethode?” In hoofdstuk 2 zijn de kenmerken besproken van de traditionele ontwikkelmethode SDM en de Agile ontwikkelmethoden XP en Scrum. Ook is er ingegaan op de rol van de IT-auditor bij systeemontwikkeling en is het bestaande referentiemodel besproken dat de IT-auditor kan gebruiken bij de toetsing van de beheersing van een project gekenmerkt door een traditionele ontwikkelmethode. Vervolgens hebben wij een management control raamwerk (Zie §2.5.2) opgesteld voor Agile systeemontwikkelingsprojecten. Vervolgens hebben wij uiteengezet in hoeverre de SDLC risico’s zich verhouden tot een agile ontwikkelingsproject. Gezien de geconstateerde afwijkingen beschrijven wij zowel de risico’s als de beheersmaatregelen voor een agile ontwikkelingsproject volgens het management control raamwerk.

3.2

Risicoanalyse Aan de hand van het management control raamwerk voor Agile ontwikkelingsprojecten werken wij de risico’s en de daaruit volgende beheersingsmaatregelen verder uit. Processen en randvoorwaarden spelen een grote rol bij een succesvolle Agile werkwijze. De risico´s liggen onder meer in het onjuist inrichten van de processen en onjuist invullen van de randvoorwaarden. # 1 2 3 4 5 6 7 8 9 10 11

Risico De keuze voor de ontwikkelmethode en het ontwikkelproces is gebaseerd op onjuiste afwegingen. De processen binnen de organisatie zijn onvoldoende afgestemd op het Agile ontwikkelproces. Agile wordt ingevoerd met een big bang scenario en de organisatie krijgt onvoldoende tijd om zich aan te passen aan nieuwe werkmethoden, processen en verantwoordelijkheden. De ontwikkelteamleden hebben onvoldoende kennis van de Agile methode. De ontwikkelteamleden zijn onvoldoende voorbereid om de regiefunctie naar zich toe te trekken. De projectmanagementorganisatie is niet in staat om op de Agile manier te werken (een minder centrale rol in het ontwikkelproces te vervullen) . De business is zich onvoldoende bewust van zijn rol binnen het ontwikkelproces. De acceptanten zijn onvoldoende toegewijd aan de releases die door het ontwikkelteam worden opgeleverd. De acceptanten van de releases hebben onvoldoende mandaat om wijzigingen en aanvullingen te doen op de requirements. Het te ontwikkelen product wordt onvoldoende opgedeeld in incrementen en in korte release iteraties per increment. De programmeurs en de andere functies binnen het project (analist, architect, tester) zijn onvoldoende in één team geïntegreerd en bevinden zich te ver van elkaar.

Status: Definitief

36/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding 12 13

14 15 16 17 18 19

Er wordt onvoldoende gebruik gemaakt van ondersteunde tooling zoals configuratie management tooling. De planning van het Agile ontwikkelproject is onduidelijk, timeboxes worden onvoldoende gehanteerd en voortgangsrapportage blijft van een te laag niveau waardoor te weinig sturingsinformatie voor het management beschikbaar is. Er vinden onvoldoende evaluaties plaats gedurende het project waardoor verbeteringen in het Agile proces achterwege blijven. De opdrachtgever heeft onvoldoende controle op de indirecte eisen (niet-functionele requirements) en acceptatie criteria. Er wordt onvoldoende documentatie opgeleverd aan het einde van het project ter naslag voor functioneel beheer en vervolgprojecten. De ontwikkelteamleden zijn onvoldoende toegewijd . Er is onvoldoende overeenstemming over de te implementeren requirements. Het management geeft onvoldoende ondersteuning voor agile ontwikkeling in de organisatieinrichting

De bovenstaande lijst met risico’s is tot stand gekomen op basis van literatuuronderzoek en is bovendien niet volledig. Ieder project heeft haar eigen, specifieke risico’s.

3.3

Beheersingsmaatregelen De risico’s uit de voorgaande paragraaf worden in deze paragraaf vertaald naar concrete beheersingsmaatregelen welke kunnen gelden als richtlijn voor een IT audit. De maatregelen zijn gegroepeerd naar de aard van de getroffen maatregelen, te weten technische, organisatorische en procedurele maatregelen (TOP benadering). In deze paragraaf is onder andere een selectie van top maatregelen van Ambler (Ambler, 2008) gebruikt. Bij elke beheersingsmaatregel noemen we vervolgens het daarmee te beheersen risico uit de vorige paragraaf. Organisatorische maatregelen Organiseren is een vorm van beheersen. Organisatorische maatregelen zijn onder meer: O1. Het begint met het personeelsbeleid. Zo zullen voor Agile projecten vaak senior ontwikkelaars worden ingezet (risico 5); O2. De introductie van Agile ontwikkeling binnen de organisatie gaat via een pilot (risico 3); O3. De belanghebbenden uit de gebruikersorganisatie zijn bekend met Agile en hebben hun processen hierop aangepast (risico 2, 15); O4. Afgevaardigden van de acceptanten (Business, IT, Audit) worden beschikbaar gesteld om deel uit te maken van de ontwikkelingsprojecten (risico 8); O5. Het ontwikkelteam is zelforganiserend, is afgestemd in aantal en heeft een juiste verdeling van competenties (risico 4, 11); O6. De leden van het ontwikkelteam zijn op elkaar ingespeeld en voeren hun werkzaamheden uit in een gemeenschappelijke ruimte (risico 11); O7. Ontwikkelteams zijn zoveel mogelijk met één project belast gedurende de kritische ontwikkelfase (risico 17); O8. De ontwikkelorganisatie sluit aan op het beleid en de strategie van de organisatie en de prioriteiten die daarmee samenhangen (risico 1, 19); O9. Er is een specifiek proces voor het opstellen van de niet-functionele requirements (risico 15); O10. Het projectmanagement geeft vertrouwen en vrijheid aan het ontwikkelteam (risico 5). Procedurele maatregelen De volgende procedurele maatregelen zijn nodig: P1. Het management moet het gebruik van de Agile methode accorderen (risico 19); P2. Systeemontwikkeling geschiedt volgens een vooraf vastgesteld iteratief en incrementeel model (risico 10);

Status: Definitief

37/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding P3. P4. P5. P6. P7. P8. P9. P10.

P11. P12.

Het management bepaalt de frequentie van opleveringen en rapportages (risico 13); De ontwikkelprocessen sluiten aan op het volwassenheidsniveau van de organisatie (risico 1); De afgevaardigde vanuit de business heeft voldoende mandaat om te beslissen (risico 9); Het Agile proces is aangepast aan de organisatie, qua omvang van het systeem, grootte van het ontwikkelteam, ervaring, competenties etc. (risico 1); Periodieke evaluatie momenten zijn in het ontwikkelproces geïntegreerd, teneinde te zorgen voor procesverbeteringen (risico 14); Het projectmanagement houdt zich slechts bezig met de randvoorwaarden en kritische activiteiten van het ontwikkelproject (risico 6); Bij elke release wordt er structureel getest (door eindgebruikers) om de kwaliteit van de opleveringen per release te waarborgen (risico 8); In de afrondingsfase van het project worden functionele specificaties en test specificaties opgeleverd door het project voor overdracht naar functioneel beheer en toekomstige projecten (risico 16); De opdrachtgever stelt vóór de start van een iteratie de prioriteiten van requirements vast (risico 18). Frequent (vrijwel dagelijks) is er een teammeeting (risico 11).

Technische maatregelen Onder technische maatregelen vallen maatregelen in of rond de hardware en software waaruit het informatiesysteem is opgebouwd. Met de volgende technische maatregelen kunnen een aantal van bovengenoemde risico’s worden beheerst: T1. Programmeerstandaarden, data conventie standaarden en raamwerken zijn gedefinieerd en gecommuniceerd naar de betrokkenen binnen het ontwikkelteam (risico 12); T2. Het gebruik van flexibele architecturen maakt het mogelijk om te anticiperen op veranderende behoeften (risico 18); T3. Bij Agile ontwikkelmethodes worden configuratie management tools inclusief versiemanagement en wijzigingenbeheer actief gebruikt (risico 12); T4. Testen zijn geïntegreerd in programma code (risico 8); T5. Het opleveren van programmatuur vindt frequent (dagelijks) plaats (risico 8); T6. Verschillende tools zijn effectief ingezet ter ondersteuning gedurende de levenscyclus van de software (risico 12);

3.4

Interpretatie van beheersingsmaatregelen In deze paragraaf gaan wij nader in op een aantal van bovengenoemde beheersingsmaatregelen, ten einde deze nader te interpreteren. Bepaling toepassing ontwikkelmethode Verschillende ontwikkelmethoden vinden aansluiting bij verschillende projecten. Zoals in §2.5 is aangegeven zijn het type organisatie en het ontwikkelteam kritische factoren voor de succesvolle toepassing van Agile ontwikkeling. Afhankelijkheden zijn de hoeveelheid te coördineren werknemers, de kritieke functie van het systeem en de prioriteiten en onzekerheid binnen het project. Het is voornamelijk een taak van het programmamanagement om te bepalen welke methode in welke specifieke situatie het best toepasbaar is. ‘Lessons learned’ sessies van afgeronde projecten kunnen het programmamanagement inzicht verschaffen. Functiescheiding ontwikkelaar/opdrachtgever Het belangrijkste aandachtspunt is de functiescheiding tussen de verantwoordelijken vanuit de opdrachtgever, vaak vertegenwoordigd door key users en eindgebruikers, en het ontwikkelteam. De opdrachtgever bepaalt de kwaliteit en is verantwoordelijk voor de beoordeling of het product aan de

Status: Definitief

38/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding directe en indirecte kwaliteitseisen voldoet. Deze toetsing is onafhankelijk ten opzichte van opgeleverde releases. Iteratief en incrementeel karakter van ontwikkeling Verifieer of er gelijktijdig ontwikkeld, getest en aan de klant opgeleverd wordt. Dit geeft zekerheid dat requirements die tot dan toe geen grote invloed op de voortgang hadden inzichtelijk worden gemaakt en alsnog in de planning worden opgenomen. Agile heeft een hoge frequentie van opleveringen. Stel vast of dit gebeurd, of feedbackmomenten zijn ingepland en stel vast hoe dit gebeurd. Prioriteiten stellen in requirements De opdrachtgever legt voor de start van een iteratie de prioriteiten van requirements vast. Na elke release worden de openstaande requirements en eventuele nieuw bepaalde requirements voorzien van een nieuwe prioriteit. Dit is een samenspel van opdrachtgever en ontwikkelteam. De IT-auditor verschaft zich inzicht in de requirements lijsten. Samenstelling ontwikkelteam Het team dient multidisciplinair samengesteld te zijn. De ontwikkelaars dienen de principes van de Agile methode te kennen en op elkaar te zijn ingespeeld. Een team start vaak met een bepaalde vorm van instabiliteit. Naarmate een team meerdere iteraties heeft doorlopen zijn zij steeds beter op elkaar ingespeeld. Het streven is maximale stabiliteit binnen een project. Team in gezamenlijke ruimte Het ontwikkelteam dient zich zoveel mogelijk in één ruimte te bevinden. De communicatie is dan direct en meer effectief. Ook hoeft hierdoor minder documentatie opgesteld te worden om mogelijke interpretatie verschillen te compenseren. Frequente teammeeting Frequent (vrijwel dagelijks) is er een teammeeting met zowel ontwikkelaars als vertegenwoordigers van de opdrachtgever. Naast het feit dat teamleden elkaar informeren over voortgang, worden knelpunten besproken, zodat het team daar direct op kan reageren. De betrokken teamleden zullen in ieder geval bij deze dagelijkse meeting aanwezig moeten zijn. Continue verbetering van het proces Na elke iteratie is er een moment van feedback. Er is terugkoppeling over het ontwikkelde product maar ook terugkoppeling over de werking van het proces. Dit kan de basis zijn voor verbeteringen in de volgende cycli. De ‘lessons learned’ sessies van de diverse projecten kunnen vervolgens ook op andere Agile ontwikkelingsprojecten toegepast worden. Voortgang en planningsrapportage Bij Agile wordt voortgang gemeten op basis van de hoeveelheid requirements die geïmplementeerd zijn ten opzichte van het aantal nog te implementeren requirements. Overigens vindt per iteratie wel een specifieke voortgangsrapportage plaats volgens de planning voorafgaand aan de iteratie. Essentieel is dat er gedurende een iteratie geen wijzigingen zijn in de reeds vastgestelde requirements, zodat de doelstellingen en doorlooptijd onder controle zijn. Pas na het opleveren van een iteratie is er gelegenheid voor de opdrachtgever om veranderingen in requirements aan te dragen. Rol van projectmanagement Het projectmanagement geeft vertrouwen en vrijheid aan het ontwikkelteam. Het projectmanagement zorgt dat de randvoorwaarden goed geadresseerd zijn zodat het ontwikkelteam ongestoord naar het einddoel kan werken. Het is van belang dat het projectmanagement zich niet als vertragende factor opstelt, dit belemmert de kracht en het ontwikkelproces van het ontwikkelteam. De projectmanager is vooral bezig de externe invloeden op het project af te vangen en bottlenecks in kaart te brengen en de

Status: Definitief

39/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding impact hiervan te beperken. Het ontwikkelteam daarentegen moet blijven focussen op kritische componenten en moet zich niet laten verleiden om minder interessante activiteiten voor zich uit te schuiven, terwijl deze wel een kritieke component zijn binnen het project.

3.5

Aandachtspunten voor de audit Aandachtspunten voor de IT-auditor bij een audit op een ontwikkelproces zijn de controleerbaarheid en de volwassenheid van de ontwikkelorganisatie. Controleerbaarheid (auditability) De auditor zal zich voornamelijk baseren op inlichtingen van de gecontroleerde en eigen waarneming. Daarnaast moeten bewijsstukken verzameld worden. De IT-auditor stelt eveneens eisen ten aanzien van vastlegging, en probeert daarbij de efficiency van het Agile proces zo min mogelijk aan te tasten. Het is belangrijk dat de IT-auditor hierbij ‘principle based’ te werk gaat en zich realiseert dat meer dan noodzakelijke vastleggingen de kracht van het Agile proces aantasten. Met betrekking tot de Agile varianten XP en Scrum kunnen de volgende bewijsstukken zekerheid verschaffen of de beheersingsmaatregelen over een periode gewerkt hebben: • Project plan; • ‘Project backlog’; • ‘User stories’ (fotomateriaal van schetsen op whiteboards); • ‘Big visible charts’ (XP), ‘Backlog Graph’ (Scrum) per increment; • Requirements per ‘timebox’ (XP), ‘Sprint log’ (Scrum); • ‘Release management tooling’, ‘logfile’; • ‘Release notes’ per iteratie; • Notulen ‘timebox’ review bijeenkomst (product en proces verantwoording aan opdrachtgever); • Notulen einde increment bijeenkomst (product en proces verantwoording aan opdrachtgever). Rol van de mate van volwassenheid van het proces op de audit In hoofdstuk 2 hebben wij beschreven dat een organisatie die in het algemeen een model hanteert voor procesverbetering (CMMi) inherent betere uitgangspunten biedt voor het toepassen van de Agile ontwikkelmethode. Het implementeren van door CMMI voorgeschreven processen in een bestaande Agile organisatie is minder eenvoudig. In een organisatie gericht op procesverbetering is het naar alle waarschijnlijkheid eenvoudiger om tot een oordeel te komen, omdat de verbetercyclus zelf aanknopingspunten biedt voor controlewerkzaamheden. Overigens heeft een organisatie die werkt volgens de traditionele ontwikkelmethode, naar ons inzicht, minder waarborgen voor een adequate proces inrichting dan een organisatie die gebruik maakt van Agile en op hetzelfde volwassenheidsniveau opereert, aangezien een Agile proces de ‘Deming circel” in zich herbergt doordat het gebruik maakt van iteratieve en incrementele feedbackmechanismen.

Status: Definitief

40/60

Versie: 1.1


4

TOETSING IN DE PRAKTIJK 4.1

Inleiding Om de theorie te toetsen aan de praktijk gebruiken wij het onderzoeksinstrument interview. Het blijkt dat niet vaak een audit wordt gedaan op systeemontwikkelingsprojecten en voorts dat IT-auditors niet goed bekend zijn met Agile. Daarom bleek enige mate van inlevingsvermogen van de geïnterviewde noodzakelijk. Wij kozen voor een semi-gestructureerd interview zodat naast de vragenlijst ruimte bestond om eigen invulling te geven aan de geschetste problematiek. De doelstelling van de interviews was om vast te stellen of in de literatuur genoemde risico’s en beheersingsmaatregelen bij Agile ontwikkelprojecten ook onderkend worden door IT-managers, IT-auditors en experts. We hebben hiervoor vijf personen geïnterviewd met verschillende achtergronden, allen met affiniteit met het vakgebied IT -audit. In de afronding van ieder gesprek zijn de belangrijkste aandachtspunten samengevat en geverifieerd. Van ieder gesprek is een verslag gemaakt waarvan interessante elementen in deze scriptie zijn verwerkt. In paragraaf 4.3 vindt u onze vragen met daarachter een samenvatting van de antwoorden van alle geïnterviewden tezamen. De geïnterviewden ontvangen een afschrift van deze scriptie. Aangezien in de interviews ook vertrouwelijke informatie gedeeld is, geven wij geen expliciete informatie over de geïnterviewde personen en hun werkgevers.

4.2

Vragenlijst Het interview vangt aan met een schets van de problematiek. De volgende punten worden hierbij besproken: • Betrokkenheid van de IT-auditor bij systeemontwikkelingsprojecten; • Beheersingsmaatregelen bij systeemontwikkelingsprojecten; • Rol van IT-auditor in ontwikkelorganisatie bij de organisatie van geïnterviewde; • Verwachte beheersmaatregelen bij een Agile ontwikkelproject; • Randvoorwaarden voor Agile systeemontwikkeling. Vervolgens dient de onderstaande vragenlijst als leidraad in het gesprek. • Wat zijn volgens u de belangrijkste risico’s bij systeemontwikkelingsprojecten?; • Wat zijn volgens u de belangrijkste beheersingsmaatregelen bij systeemontwikkelingsprojecten; • Welke rol speelt het volwassenheidsniveau van het proces (bv. CMMi) bij systeemontwikkeling?; • Wat is volgens u de rol van de IT-auditor bij een systeemontwikkelingsproject?; • Hoe wordt deze rol in uw organisatie op dit moment ingevuld?; • In de rol van de IT-auditor: waarop beoordeelt u de keuze voor een ontwikkelmethode?; • In de rol van de IT-auditor: welke maatregelen zou u willen zien bij een systeemontwikkelingsproject?; • Wat is in dit kader uw visie op de Agile ontwikkelmethode?; • Welke maatregelen zou u willen toetsen bij een Agile systeemontwikkelingsproject?; • Zijn er wat u betreft specifieke randvoorwaarden bij toepassing van Agile in systeemontwikkelingsprojecten?; • Heeft u aanvullende opmerkingen ten aanzien van de rol van de auditor op systeemontwikkelingsprojecten?

4.3

Resultaten interviews Hieronder beschrijven wij de resultaten van de interviews volgens de bovengenoemde vragen;

Status: Definitief

41/60

Versie: 1.1


Wat zijn volgens u de belangrijkste risico’s bij systeemontwikkelingsprojecten?; Als belangrijkste risico’s worden genoemd dat niet het gewenste eindproduct wordt opgeleverd en de onbeheersbaarheid van tijd en middelen. Een incapabel projectmanagement wordt vaak ook als risico aangemerkt. Wat zijn volgens u de belangrijkste beheersingsmaatregelen bij systeemontwikkelingsprojecten; Het indelen in strikte SDLC fasen wordt aangemerkt als een belangrijke beheersingsmaatregel. Een andere belangrijke beheersingsmaatregel die wordt genoemd is de inrichting en inzet van een capabel programmamanagement en projectmanagement. Voorts het bepalen van een duidelijke einddatum van het project, waartoe de frequentie en het aantal iteraties bij iedereen bekend dienen te zijn. Tenslotte is aangegeven dat de invulling van het projectmanagement resultaat gedreven dient te zijn (in de vorm van iteraties) in plaats van aanpak gedreven. Het beoogde resultaat is namelijk door het gebruik van iteraties inzichtelijk. Welke rol speelt het volwassenheidsniveau van het proces (bv. CMMi) bij systeemontwikkeling? Bij een hoger volwassenheidsniveau van het ontwikkelproces wordt de voorspelbaarheid van het proces groter. Het blijkt echter dat dit niet per se hoeft te leiden tot het gewenste resultaat. Hiervoor zijn namelijk ook de randvoorwaarden belangrijk. Volgens de geïnterviewden is een positieve relatie tussen CMMi en Agile tot niveau 3 zeker te leggen. Een van de geïnterviewden gaf aan dat niveau 5 niet haalbaar lijkt aangezien de vergaande functiescheiding van verantwoordelijkheden op dit niveau niet Agile eigen zijn. Wat is volgens u de rol van de IT-auditor bij een systeemontwikkelingsproject? De geïnterviewden geven aan dat de IT-auditor tijdens het project aanwezig moet zijn om vroegtijdig problemen in het project (proces) te signaleren en te escaleren. Een audit achteraf heeft volgens hen een beperkte toegevoegde waarde. De wijze waarop de audit wordt uitgevoerd en de toegevoegde waarde van een audit op een ontwikkelproces is mede afhankelijk van de doelstelling van het management. Dit geldt dus generiek voor de systeemontwikkelingsprojecten. Hoe wordt deze rol in uw organisatie op dit moment ingevuld? Het merendeel van de geïnterviewden had binnen de eigen organisaties weinig ervaring met audits op systeemontwikkelingsprojecten. Vaak komen naar aanleiding van de financiële verantwoording geen vragen over software aan de orde. Organisaties die een substantieel onderdeel van hun omzet steken in systeemontwikkeling zouden op dit gebied wel ge-audit moeten worden, maar dit hangt ook af van de doelstellingen van het management. Een geïnterviewde had wel een audit uitgevoerd op een project gekenmerkt door ‘timeboxing’ (DSDM), dat bepaalde Agile kenmerken heeft. In de rol van de IT-auditor: waarop beoordeelt u de keuze voor een ontwikkelmethode? Een door ons geïnterviewde IT-manager merkte op dat bedrijven zich steeds meer moeten confirmeren aan interne en externe regelgeving. In dat kader zijn er meerdere belanghebbenden die ieder een audit uitvoeren naar hetzelfde object. Indien het onderzoeksobject Agile systeemontwikkeling kun je verwachten dat audits meer tijd in beslag nemen. Het beeld bestaat dat bij Agile de IT-auditor voornamelijk kan steunen op eigen waarneming waardoor resultaten van andere audits niet overgenomen kunnen worden. Bij traditionele systeemontwikkeling kan dit met de mijlpaalproducten wel. In de rol van de IT-auditor: welke maatregelen zou u willen zien bij een systeemontwikkelingsproject? In het algemeen wordt de rol van programma en projectmanagement door de geïnterviewden als essentieel gezien. Projectmanagement moet volgens hen adequaat ingericht zijn op basis van de algemeen bekende ‘best practices’ zoals Prince II. Een van de geïnterviewden vindt het hebben van documentie belangrijk voor de continuïteit. Het proces komt dan niet in gevaar wanneer een belangrijk teamlid wegvalt. Daarnaast is het belang van

Status: Definitief

42/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding documentatie door de geïnterviewden ook genoemd in het kader van standaardisatie binnen projecten bij grote organisaties en daarmee de beheersing van de projecten organisatiebreed. Wat is in dit kader uw visie op de Agile ontwikkelmethode? Agile wordt gezien als mogelijkheid voor verbetering van de systeemontwikkeling, de methode heeft haar waarde al bewezen in verschillende projecten. Men ziet Agile voornamelijk bij in-house ontwikkeling en minder bij outsourcing. Een geïnterviewde vroeg zich af hoe de vrijheid van de Agile ontwikkelaar zich verhoudt tot vaststaande architectuur, uniforme manier van code schrijven en gebruik van gestandaardiseerde tooling. Eén geïnterviewde kan zich geen projecten meer voorstellen zonder de toepassing van Agile ontwikkeling in licht van een kritieke ‘time-to-market’. Het beeld bij de geïnterviewden is dat met name projecten op kleine schaal hiervan profijt van hebben. Bij toepassing van Agile over een groot aantal projecten en standaardisatie binnen een organisatie zijn nog een aantal hindernissen te nemen zoals de invoering van Agile binnen een organisatie. Ervaringscijfers en verdere evolutie van de Agile ontwikkelmethode kunnen daarbij helpen. Binnen een grote financiële organisatie is geprobeerd een vorm van Agile ontwikkeling in te voeren, maar dit is na enkele pilots weer gestaakt omdat onvoldoende successen werden geboekt. Welke beheersingsmaatregelen zou u toetsen bij een project gekenmerkt door een Agile ontwikkelmethode? Geïnterviewden geven aan dat dit afhangt van de aard van het proces. Eén van de geïnterviewden merkt op dat Agile past binnen het kader van ‘Witdrukdenken’ van het verandermanagement zoals dit onderkend wordt in het 5-kleurenmodel van sociaal psycholoog en hoogleraar aan de Vrije Universiteit Léon de Caluwé. Daarbinnen wordt veel vrijheid gegeven aan zelforganisatie. Maatregelen ten aanzien van beheersing binnen het ‘Witdrukdenken’ kunnen gebruikt worden als referentiekader voor een audit. Verder is controle op het consequent hanteren van de ‘timebox’ volgens een geïnterviewde een belangrijke beheersingsmaatregel en is het belangrijk dat er een grens is gesteld aan het totale aantal iteraties. In Agile projecten wordt specifiek het managen van de ‘scope creep’ gezien als een belangrijke beheersingsmaatregel. Het Paretoprincipe 80/20, een economische regel die opgesteld werd door Vilfredo Pareto in 1906, houdende dat 80% van de economie beheerst werd door 20% van de mensen, is hier onmiskenbaar van toepassing: De focus bij systeemontwikkeling moet liggen op de 20% inspanningen die leiden tot 80% resultaten en niet op de overige 80% inspanningen die maar verantwoordelijk zijn voor de overige 20% van het resultaat. Aandachtspunten voor de audit die de geïnterviewden hebben genoemd zijn: • Juiste mix van aandacht over 9 gebieden van projectmanagement; • Parameters voor timeboxen die gedefinieerd zijn voor de iteraties; • Na afloop evaluatieformulier voor eindgebruikers; • Geen verandering binnen de samenstelling van het ontwikkelteam; • Bepalen van volwassenheid van de organisatie; • Multidisciplinaire teams met gezamenlijke verantwoordheid voor het resultaat; • Eén aanspreekpunt uit de business; • Project management resultaat gedreven i.p.v. aanpak gedreven; • Beheersen van ‘scope creep’. Zijn er wat u betreft nog specifieke randvoorwaarden bij toepassing van Agile in systeem ontwikkelingsprojecten?; De geïnterviewden merken op dat Agile projecten vaak een kortere doorlooptijd kennen. De sturing op het productresultaat als resultaat van de iteratieve ontwikkeling wordt als effectief ervaren. Aldus is Agile ontwikkeling een manier om de doorlooptijden van de ontwikkeling en de ‘time-to-market’ te managen. Bij een bancaire omgeving zijn eisen ten aanzien van de general IT controls en informatiebeveiliging van groot belang. Een aparte risicoafdeling dient daar goedkeuring te geven voor

Status: Definitief

43/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding het in productie nemen van de software. In de praktijk ontstaat vertraging, veelal veroorzaakt door het niet betrekken van de risicoafdeling in de requirements definitiefase. Binnen het traditionele ontwikkelproces is er wel ruimte om requirements ten aanzien van de general IT controls mee te nemen. Verder wordt ook door meerdere geïnterviewden aangegeven dat tooling een belangrijke rol speelt bij een iteratief en incrementeel ontwikkelproces. De tooling bepaalt het succes en is daarmee ondersteunend aan een succesvol ontwikkelproces. Belangrijk is ook het inzetten van senior ontwikkelaars met kennis van zaken. Geïnterviewden noemen als voorbeeld de ontwikkelaar die een hypotheekproduct ontwikkelt: deze moet ook in staat zijn zelf renteberekeningen te maken. Hierop sluit aan de suggestie van een andere geïnterviewde dat bij Agile multidisciplinaire teams moeten worden ingezet, met een gezamenlijke verantwoordelijkheid voor het resultaat. Om te voorkomen dat de afstemming tussen de business en het ontwikkelteam over teveel schijven gaat zal één persoon uit de business verantwoordelijk moeten zijn en bevoegd moeten zijn om beslissingen te nemen. Volgens één van de geïnterviewden kan Agile ontwikkeling eigenlijk alleen floreren in een organisatie die het ontwikkelen verbeterproces al voor een groot deel onder de knie heeft. Aangezien het Agile proces ook een groeimodel omvat is het essentieel dat van elke iteratie geleerd wordt en dat verbeteringen worden doorgevoerd. Als een organisatie hier niet op ingespeeld is, zal daarmee de toegevoegde waarde van de korte feedbackcycli voor een groot deel teniet gedaan worden. Zodoende zal de organisatie dus al in belangrijke mate een volwassenheidsniveau bereikt moeten hebben om Agile succesvol te kunnen implementeren. •

Heeft u nog aanvullende opmerkingen ten aanzien van de rol van de auditor bij systeemontwikkelingsprojecten?

Door diverse geïnterviewden wordt opgemerkt dat de ‘mindset’ van de auditor in belangrijke mate bepaalt in hoeverre de audit de gewenste efficiency van Agile ontwikkelprojecten niet aantast. Immers, als de auditor op een traditionele manier de audit uitvoert dan vraagt hij om documentatie. Omdat het Agile proces niet zozeer steunt op documentatie als wel op communicatie, kan niet in de vraag om documentatie worden voorzien. Het vasthouden aan de eisen van documentatie zou het Agile proces frustreren. De auditor zal daarom zijn controleaanpak anders moeten invullen. Daarbij zal de auditor in grotere mate steunen op ‘soft controls’ in plaats van de meer hardere controls, zoals het referentiemodel voor de SLDC die biedt. Eén geïnterviewde gaf aan dat daarom een operational auditor initieel beter geschikt lijkt voor de audits van Agile processen dan een technische IT-auditor. Belangrijk voor de auditor is de relatie tussen een processtap en het eindresultaat. Deze relatie is binnen een Agile ontwikkelproject minder duidelijk. In een audit op een Agile ontwikkelproject zal de auditor gebruik moeten maken van ervaringscijfers of modellen van andere auditors.

Status: Definitief

44/60

Versie: 1.1


5

ANALYSE VAN DE INTERVIEW RESULTATEN 5.1

Inleiding In dit hoofdstuk analyseren wij onze voorlopige bevindingen en de resultaten van de door ons gehouden interviews in vergelijking met de theorie.

5.2

Theorie In §2.5 constateren wij dat het Agile ontwikkelproces voldoende waarborgen biedt om tot een beheerst proces te komen mits een aantal randvoorwaarden zijn ingevuld. Met multidisciplinaire teams wordt optimaal gebruik gemaakt van de kracht van de menselijke factor. Ook wordt de communicatie geoptimaliseerd door het werken in een gemeenschappelijke ruimte. In het Agile proces wordt de voortgang en het resultaat zichtbaar door een iteratieve en incrementele ontwikkeling en regelmatige en snelle valideerbare releases. De aanwezigheid van een feedbackcyclus binnen Agile maakt procesverbeteringen gedurende het project mogelijk. Agile sluit daarom goed aan bij volwassenheidsmodellen zoals CMMi. We hebben ook geconstateerd dat Agile ontwikkeling onder bepaalde omstandigheden goed functioneert, maar in meer controlerende omgevingen niet volledig tot zijn recht komt. In hoofdstuk 2 zijn wij tot het inzicht gekomen dat het Agile ontwikkelproces in combinatie met een goede invulling van de randvoorwaarden zorgt voor een beheersbaar ontwikkelproject. Verder hebben we in hoofdstuk 3 een conceptueel audit raamwerk opgesteld van beheersingsmaatregelen bij Agile. Deze kan de IT-auditor gebruiken bij het opstellen van zijn normenkader voor een audit op een Agile systeemontwikkelingsproject. Extra aandacht is besteed aan de mogelijkheden tot controleerbaarheid en de rol van volwassenheid van de organisatie bij het uitvoeren van de audit.

5.3

Praktijk De praktijktoetsing laat zien dat voor sommige organisaties geldt dat het inzetten van een ontwikkelmethode met Agile kenmerken leidt tot betere projectbeheersing, zowel ten aanzien van het verwachte resultaat als ook de doorlooptijd van het project. Dat desondanks Agile projecten nog niet efficiënt genoeg zijn, komt omdat de randvoorwaarden niet volledig zijn ingevuld. Dit is ook de reden waarom pilots met Agile niet het gewenste resultaat gaven. De praktijkstudie bevestigt dat de invulling van de randvoorwaarden een grote rol speelt in het succes en de beheersing van Agile. Wij zien ook dat het management een aantal vragen heeft bij Agile die in de literatuur nog niet zijn beantwoord. De audit-dienst staat open voor Agile maar men is sceptisch. Het traditionele ontwikkelmodel en bijbehorende werkprogramma’s zijn namelijk momenteel het voornaamste referentiemodel voor de audit dienst. Een operational auditor wordt als meer geschikt gezien om audits op Agile processen te doen dan een technische IT-auditor. Verder bestaat bij grote ondernemingen het vraagstuk ten aanzien van standaardisatie van het ontwikkelproces en beheersbaarheid bij grote projecten. De Agile beheersingsmaatregelen die wij in hoofdstuk 3 hebben opgesteld worden onderschreven. In één interview werd ook een normenkader vanuit het verandermanagement voorgesteld, waarbij Agile past binnen het ‘witdrukdenken’ binnen het kleurenmodel van De Caluwé. Op basis hiervan zouden ook een aantal beheersingsmaatregelen opgesteld kunnen worden.

Status: Definitief

45/60

Versie: 1.1


5.4

Analyse De conclusie van het praktijkonderzoek is dat referenties naar het traditionele ontwikkelproces worden gebruikt om een inschatting te maken of bij Agile sprake kan zijn van een beheersbaar proces. Zodoende is men niet in staat een goede afweging te maken. Uit de literatuur concluderen wij dat met een goede invulling van de randvoorwaarden er bij Agile een beheersbaar proces kan zijn. Indien bijvoorbeeld beveiligingsaspecten niet volledig geborgd zijn in het ontwikkelproces, leidt dit tot verstoring later in het ontwikkelproces. In hoofdstuk 3 komt het meenemen van beveiligingsaspecten in de requirements terug als beheersingsmaatregel. Duidelijk moet zijn dat het gebruik van Agile leidt tot een ander referentiemodel van beheersingsmaatregelen. In de praktijk constateren wij dat men nog niet zo bekend is met Agile ontwikkelprocessen. Pilots willen daarom nog wel eens niet succesvol zijn. Ook zijn organisaties nog onvoldoende in staat zich aan Agile aan te passen, dit speelt met name bij grote bedrijven die volgens strikte procedures werken. Men vraagt zich af of Agile, met haar kleine teams van 6 à 7 mensen ook gebruikt kan worden voor grote projecten. Scrum, met de ‘scrum of scrum’ (zie bijlage A.3) zou een manier kunnen zijn om met grote projecten om te gaan. Ook de typologie van de organisatie, zoals behandeld in §2.5, is bepalend voor het selecteren van de juiste ontwikkelmethode. Verder zijn er vragen ten aanzien van de controleerbaarheid, wat vooral te maken heeft met het referentiekader van de auditor, die regelmatig nog het traditionele referentiemodel voor ogen heeft bij een audit. Ook de IT-auditor zelf moet een verandering in zijn audit werkwijze toelaten om aan te kunnen sluiten op de evolutionaire methoden van systeemontwikkeling.

Figuur: er zal eerst een veranderingsproces in de organisatie moeten plaatsvinden in het referentiekader om tot een adequaat Agile ontwikkelproces te komen (randvoorwaarde).

Status: Definitief

46/60

Versie: 1.1


6

CONCLUSIE

6.1

Inleiding De centrale probleemstelling van de scriptie luidt: “Wat betekenen de Agile ontwikkelmethoden voor de assurance rol van de IT-auditor bij een systeemontwikkelingsproject?” Deze vraag hebben wij beantwoord met een literatuuronderzoek en een praktijktoetsing. In hoofdstuk 2 hebben wij onderzoek gedaan naar ontwikkelmethodes en referentiemodellen, waarbij ook de rol van de IT-auditor is beschreven. Aansluitend zijn wij tot een management control raamwerk gekomen voor Agile systeemontwikkeling, die input is geweest voor de risico’s en beheersingsmaatregelen in Hoofdstuk 3. Het referentiemodel in hoofdstuk 3 helpt de IT-auditor bij de uitvoering van een assurance opdracht op een Agile systeemontwikkelingsproject. Vervolgens hebben wij bovengenoemde vraag neergelegd in interviews met een aantal IT-managers en IT-auditors. De resultaten van die interviews hebben we in hoofdstuk 4 uiteengezet en in hoofdstuk 5 geïnterpreteerd om vast te stellen of de beheersingsmaatregelen reëel zijn en of er een juiste invulling is gegeven aan de risico’s zoals genoemd in hoofdstuk 3.

6.2

Conclusie Het gebruik van Agile ontwikkeling is groeiende omdat het bijdraagt aan het inzichtelijk maken van de requirements gedurende de gehele periode van systeemontwikkeling, waarbij veranderingen voordurend mogelijk zijn en omdat hiermee producten snel op de markt kunnen worden gezet. Agile ontwikkeling heeft voldoende waarborgen voor een adequaat en beheerst proces. Agile kan echter alleen gedijen wanneer voldaan is aan een aantal randvoorwaarden die specifiek gelden bij Agile, zoals het gebruik van multidisciplinaire teams en het gebruik van korte communicatie lijnen. Organisaties vinden het moeilijk en zijn niet altijd welwillend om veranderingen door te voeren in hun processen en beheersingsmaatregelen. Aangezien de gehele organisatie zich moet aanpassen aan de Agile werkwijze, heeft het heel wat voeten in de aarde voordat Agile algemeen geaccepteerd wordt. De volwassenheid van de organisatie speelt een belangrijke rol in de wijze waarop een organisatie in staat is om de nieuwe processen en randvoorwaarden in te bedden. Wanneer een organisatie een bepaald volwassenheidsniveau bereikt heeft en metingen en verbeteringen geïntegreerd zijn in het proces zal de organisatie de Agile ontwikkelmethodologie soepeler kunnen integreren en zullen de effecten van het toepassen van de Agile ontwikkelmethode eerder zichtbaar zijn. In dit referaat hebben wij beheersingsmaatregelen voorgesteld voor Agile ontwikkelprojecten, welke de IT-auditor kan gebruiken als uitgangspunt voor het opstellen van zijn referentiemodel. De door ons genoemde beheersingsmaatregelen zijn voortgekomen uit een management control raamwerk voor Agile ontwikkelprojecten. Wanneer de risico’s die binnen de SDLC onderkend worden, gestaafd worden aan de aanwezigheid binnen Agile ontwikkeling, zijn er duidelijke verschillen ten aanzien van de beheersingsmaatregelen volgend uit deze ISACA richtlijn voor SDLC reviews. Zodoende hebben wij vastgesteld dat de bestaande ISACA richtlijn voor SDLC reviews ontoereikend is voor het beoordelen van Agile systeemontwikkelingsprojecten. Geïnterviewden gaven aan dat er twijfels zijn over schaalbaarheid en standaardisatie, maar overwegend erkenden zij de kracht van Agile. Daarnaast hebben de interviews ons nieuwe inzichten gegeven voor uitbreiding van het conceptueel raamwerk van beheersingsmaatregelen, bijvoorbeeld met beheersingsmaatregelen vanuit de verandermanagement praktijk, maatregelen voor het voorkomen

Status: Definitief

47/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding van ‘scope creep’, extra nadruk op multidisciplinaire teams en controle op de verandering van samenstelling van teams gedurende het project. Een Agile systeemontwikkelingproject vraagt om een IT-auditor die bestaande referentiemodellen en werkprogramma’s los kan laten en die in staat is te beoordelen op ‘soft controls’ in relatie tot processen, mensen en tools. De IT-auditor kan immers minder steunen op de expliciete aanwezigheid van documentatie en faseovergangen en andere vastleggingen. Een operationele auditor lijkt daartoe beter in staat. De aanpak van de IT-auditor zou een verandering moeten ondergaan ten gunste van een betere beheersbaarheid en ‘time-to-market’ van Agile systeemontwikkelingsprojecten. Tenslotte achten wij het wenselijk de IT-auditor reeds bij aanvang van het Agile systeemontwikkelingsproject te betrekken, zodat risico’s bijtijds onderkend kunnen worden en beheersingsmaatregelen worden genomen zoals wij in dit referaat uiteen hebben gezet.

6.3

Aanbevelingen Wij bevelen IT-auditors aan om de in §3.3 voorgestelde beheersingsmaatregelen te hanteren als referentiemodel bij een audit op een systeemontwikkelingsproject gekenmerkt door een Agile benadering. Wij merken op dat het daar genoemde referentiemodel een selectie is van de beschikbare literatuur en dat het niet als volledig dient te worden beschouwd. Met de resultaten en interpretatie van ervaringscijfers uit audits op Agile ontwikkelingsprojecten kan dit referentiekader weer uitgebreid worden. In een eventueel vervolgonderzoek naar de verandermanagement aspecten van organisaties die willen overstappen naar de Agile werkwijze zou een nieuw kader kunnen worden geschetst. Aangezien Agile zelf nog evolueert en er vragen bestaan ten aanzien van het gebruik van Agile bij grote ontwikkelprojecten, alsmede het gebruik bij outsourcing, zal verdere verkenning nodig zijn met als doel dat uiteindelijk een groter percentage systeemontwikkelingsprojecten kan slagen.

6.4

Discussie We hebben geconstateerd dat veel beheersingsmaatregelen in het Agile proces geborgd zijn. Wij leggen dan ook de onderstaande stelling voor. Stelling: “Beheersing van het project is meer gewaarborgd bij een Agile ontwikkelingsproject dan bij een traditioneel ontwikkelingsproject” Projectmanagement van een traditioneel ontwikkelproject legt de nadruk vooral op het observeren en meten van project prestaties op basis van een vooraf opgesteld budget. Afwijking van een plan wordt in een traditionele ontwikkeling als exceptie gezien waarover verantwoording afgelegd dient te worden. Factoren als tijd, budget en, vaak in mindere mate, kwaliteit bepalen de speelruimte van het project. Wijzigingen dienen akkoord bevonden te zijn door het management. Het monitoren van een traditioneel ontwikkelproject wordt bepaald aan de hand van de hoeveelheid werk per taak. Binnen een Agile project wordt de voortgang bepaald aan de hand van de werkende software die per iteratie en per increment wordt opgeleverd. De voortgang is visueel zichtbaar. Het voordeel hiermee is dat een ‘Business / IT alignment’ vraagstuk wordt ingevuld, waarbij de klant direct het resultaat van het werk ziet en beoordeeld. Omdat er meerdere iteraties zijn, zijn er ook meerdere momenten voor het verkrijgen van feedback. De lessen van de vorige iteratie worden geëvalueerd en zorgen, indien nodig, voor verbeteringen in het proces. Dit komt de beheersbaarheid en volwassenheid van de processen ten goede. Het feit dat de ‘kwaliteitscirkel van Demin’, de PDCA-cyclus, inherent is aan het Agile ontwikkelproces geeft betere waarborgen voor de beheersbaarheid van een project dan het traditionele op budget gestuurde ontwikkelproces.

Status: Definitief

48/60

Versie: 1.1


Figuur: Cirkel van Deming (PDCA cyclus) voor systeemontwikkeling Een probleem voor een IT-auditor is dat er minder vastleggingen zijn bij Agile waardoor minder gegevensgericht gewerkt kan worden. Een procesgerichte en outputgerichte aanpak van de IT-auditor is nodig bij Agile. De IT-auditor moet opnieuw zijn positie bepalen ten aanzien van een audit op systeemontwikkeling en ‘principle based auditing’ toepassen in plaats van ‘rule based auditing’. Agile is in feite een uitdaging voor de IT-auditor omdat het minder houvast biedt aan de bestaande werkprogramma’s voor een auditor.

Status: Definitief

49/60

Versie: 1.1


REFERENTIES Allen, T.J., The influence of communication technologies on Organizational Structure: A conceptual Model for Future research, MIT, Sloan School of Management, 1987 Ambler, S.W., Lean Development Governance, Strategies for Scaling Agile Software Development IBM, 20 januari 2008, webLink: http://www.ibm.com/developerworks/blogs/page/ambler?entry=lean_development_governance (opgevraagd 15 januari 2009) Arendsen, M., Cannegieter, J.J., Grund., A., Heck, P., de Klerk, S., Zandhuis, J., Succes met de requirements, SDU uitgevers, ISBN 9789012125987, 2008 Beck K., Extreme Programming explained Reading Embrace change. MA: Addison-Wesley Longman, inc., 2000 Biene-Hershey van M.E., IT audit, an object oriented approach, Delwel publishers, 1998 Boehm, B., Philips, N., Understanding and Controlling Software Costs, IEEE Transactions on Software Engineering., oktober 1998 Boehm. B., Turner, T., Using Risk to Balance Agile and Plan- Driven Methods, IEEE computer society, juni 2003 Booch, G, The evolution of the Booch Method, ROAD, 1994 Cannegieter, J.J., Solingen van, R., De kleine CMMi voor ontwikkeling, SDU Uitgevers, Den Haag, 2007 Capers Jones, T., Assessment and Control of Software Risks, Prentice Hall PTR, ISBN: 9780137414062, 1994 Cockburn, A., Agile software development, second edition, Addison Wesley, 2006 Cockburn, A., Humans and Technology technical report, sept. 2005, weblink: http://alistair.cockburn.us/A+governance+model+for+Agile+projects (opgevraagd 12 december 2008) Computable, Agile rekent af met falend projectmanagement, 28-07-2008, Link: http://www.computable.nl/artikel/ict_topics/soa/2650514/2204519/Agile-rekent-af-met-falendprojectmanagement.html (opgevraagd 07-02-2009) Computable, Kabinet kiest voor agility bij ICT-projecten, 16-12-2008; link: http://www.computable.nl/artikel/ict_topics/development/2811676/1277180/kabinet-kiest-vooragility-bij-ictprojecten.html (opgevraagd 07-02-2009) Dekleva, S., Drehmer, D., Measuring software engineering evolution: A Rasch calibration. Inform. Systems Res. 8(1) 95-105., 1997 Easterbrook, S., Lutz, R., Covington, R., Kelly, J., Ampo, Y., Hamilton, D., Experiences Using Lightweight formal methods for requirements modeling, IEEE transactions on software engineering, vol 24, no 1, januari 1998 Fijneman, C., Roos Lindgren, E., Hang Ho, K., IT-auditing en de praktijk, SDU uitgevers, Den Haag, 2005 Firesmith, D., The business Case for requirements engineering, Software Engineering Institute Carnegie Mellon University, September 2003 Grood, de, D.J., TestGoal, resultaatgedreven testen, SDU Uitgevers, 2007 Harter, D. E., Slaughter, S.A., Quality Improvement and Infrastructure Activity Costs in Software Development: A Longitudinal Analysis. Management Science, Vol. 49, No. 6 pp 784-800, Juni, 2003 Harter D.E., Krishnan M. S., Slaughter S.A., Effects of Process Maturity on Quality, Cycle Time, and Effort in Software Product Development, Management Science, Vol. 46, No. 4, Information Technology Industry pp 451-466, April, 2000 Harvey, D., The Software Value Stream, Paper for Workshop, januari 2004 Herbsleb, J., D. Zubrow, D. Goldenson, W. Hayes, M. Paulk. Software quality and the capability maturity model. Comm. ACM 40(6) 30-40, 1997 Hettigei, N.T., The Auditor’s Role in IT Development Projects, Information Systems control Journal, volume 4, 2005

Status: Definitief

50/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding Hettigei, N.T., Audit Guidelines On How To Review SDLC Framework, ISACA roundtable, 12 december 2007 Hice, G.F., Turner, W.S., Cashwell L.F., System Development Methodology. Amsterdam, North-Holland Publishing Company, second edition 423 pp, 1978 Intosai Working Group on IT audit, “A Guideline for Auditing Systems Development”, INTOSAI Working Committee on IT Audit, mei 2008. ISACA, IS auditing Guideline System development life Cycle (SDLC) reviews, document G23, ISACA, 2003 ISO/IEC12207:2007, International standard, systems and software engineering – software livecycle processes, ISO/IEC FDIS 12207:2007(E) IEEE Std 12207, 2007 ISO/IEC15288:2007: Information Technology - Life Cycle Management - System Life Cycle Processes, ISO/IEC FDIS 15288:2002 ISO/IEC15504, Information technology, Standards for software process assessment, ISO/IEC JTC1/SC7/WG10, 2003-2006 ISO/IEC25000:2005, Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SQuaRE, ISO/IEC, 2005 ISO/IEC 9126-1:2001, Software Engineering — Product quality — Part 1: Quality model, ISO/IEC, 2001 Koch, A., Agile Software Development, evaluating the methods for your organization, Artech house, Norwood, MA, 2005 Konrad, M., Glazer, H. Shrum, s., Anderson, d., Dalton, J., CMMi or Agile, Why not embrace both?, Technical note, CMU/SEI-2008-TN-003, Software Engineering Institute, Carnegie Mellon University, 2008 Krishnan, M. S., Kellner M.I., Measuring process consistency: Implications for reducing software defects. IEEE Trans. Software Engrg. 25(6) pp 800-815, 1999 Larman, C., Agile and Iterative Development: A Manager's Guide (Agile Software Development Series), Pearson education Inc, Boston, 2005 Linders B., De factor mens, Bits & Chips, editie september 2007 Lindstrom, L., Jeffries, R. Extreme programming and Agile software Methodologies, Information Systems Management, 21(3), 41, 2004 Matthijse R., IT-auditor te vaak buiten beeld, Automatiseringsgids, editie 20 februari 2009 McConnell, S., Code complete, Microsoft press, 2004 OGC, Managing Successful Projects with PRINCE2, The Stationery Office, Office of Government Commerce, third edition, 2002 Pandata, SDM: een samenvatting van de system development methodology, Academic Service, 2de druk, 1984 Pikkarainen, M., Mapping Agile Software Development onto ISO 12207, ITEA, Agile Consortium ITEAAGILE-D2.9_v1.0.pdf, 2006 Praat, J., Suerink, J., Inleiding EDP-auditing, Ten Hagen & Stam uitgevers, 2004 Runge, L, New Method for a New Era, Information Center Quarterly, 1991 Sarup, D; “To Be or Not To Be,” Information Systems Control Journal, vol. 6, p. 18, 2003 Schwaber, K., The Truth about Agile Processes; Frank Answers To Frequently Asked Questions, Forrester Research, Augustus, 2007 Schwaber, K., Leganza, G., Daniels, M., The root of the problem: poor requirements, Forrester Research, September 2006 Schwaber, K, Agile Project Management with Scrum, Microsoft Press, 2004 Schwaber, K., M. Beedle, Agile Software Development with Scrum, Upper Saddle River, NJ: Prentice-Hall, 2002 Shine Technologies, Agile methodologies survey results. Agile Alliance, 2003, link : http://www.Agilealliance.com/articles/shinetechnologiesagil/file (opgevraagd 15-01-2009) Siau, K., en Tan, X., Evaluation Criteria for Information Systems Development Methodologies. In Communications of the AIS, 16 pp. 856-872, 2005 Singleton, T.W., “COBIT—A Key to Success as an IT-auditor,” Information Systems Control Journal, vol. 1, 2006

Status: Definitief

51/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding Singleton, T.W., Systems development Life Cycle and IT audits, Information Systems Control Journal, Vol. 1, 2007 Standish Group, The Chaos Report. Standish Group. Gepubliceerd op www.standishgroup.com, 1994, 1996, 1998, 2000, 2001, 2002, 2004, 2006 Subramaniam V, Hunt A., Practices of an Agile Developer, The Pragmatic Programmers, 2006 Suryn, W., Abran, A., ISO/IEC SQuaRE. The second generation of standards for software product quality, 2003 Sutherland, J., Jakobsen, C.R., Johnson K., Scrum and CMMi Level 5: The Magic Potion for Code Warriors, Agile 2007 conference, Washington D.C. USA, 2007 Van Onna, Koning, De Kleine Prince 2, Academic Service. Tweede oplage, februari 2008 Vinekar, V, 2006, Towards a theoretical framework of information systems development strategy: the contingent effects of organizational culture and project uncertainty, Proceedings of the 2006 Southern Association for Information Systems Conference, 2006 Woda, A., The Role of the Auditor in IT Governance, Information Systems Control Journal, Volume 2, 2002 Zahran, S., Software process Improvement, Addison Wesley, 1998

Status: Definitief

52/60

Versie: 1.1


BIJLAGEN A.1 SDM (Traditionele ontwikkelmethode) Een in Nederland veel gebruikte ontwikkelmethode is System Development Methodology (SDM versie 2). SDM is een waterval methode met SDLC fasen, ontwikkeld door het Nederlandse softwarehuis Pandata in opdracht van de voormalige Nederlandse PTT, Nationale Nederlanden en AKZO (Hice et al, 1978). Een gefaseerde aanpak is kenmerkend voor de methode SDM. De belangrijkste reden voor die gefaseerde aanpak is het bestuurbaar houden van het proces, met de mogelijkheid om tussentijds te kunnen bijsturen. Aan het eind van een fase kan men besluiten de volgende fase in te gaan of te stoppen met de systeemontwikkeling. Er is ook een tussenweg mogelijk waarbij een of meerdere fasen wordt teruggegaan om dezelfde fase nog eens over te doen. Teruggaan naar een vorige fase betekent meestal dat er ergens een fout is gemaakt en het is een kostbare zaak. Stappenoverzicht SDM De fasen van SDM worden hieronder kort uiteengezet. Iedere fase kent een viertal aspecten: systeemontwikkeling, validatie, besturing en organisatieverandering. Elke fase heeft mijlpaal producten die beschrijven wat die fase heeft voortgebracht. Elke fase heeft een feedbackloop met de voorgaande fase. De verschillende fasen van systeem development methodologie (Pandata, 1984) zijn: Fase 0 Informatie Planning (IP) Deze fase heeft als product het informatieplan. Het informatieplan beschrijft zowel het handmatige als het geautomatiseerde deel van het informatiesysteem. Het plan brengt in kaart de informatiebehoefte en hoe het te bouwen systeem in die behoefte zal voorzien. Er vindt een situatieanalyse plaats om allereerst het huidige systeem te bestuderen. Mijlpaal producten: - het rapport situatie analyse; - het rapport informatieplanning. Fase 1 Definitie Studie (DS) Dit is het werkelijke begin van de systeemontwikkeling waarbij wordt beoordeeld of het ontwikkelen van een informatiesysteem realiseerbaar is. Daarnaast bepaalt de opdrachtgever of er software ontwikkeld gaat worden of dat er een standaardpakket wordt aangeschaft. Er vindt een haalbaarheidsonderzoek plaats met daarin vijf centrale vraagstukken: 1. is ontwikkelen mogelijk en zinvol?; 2. is ontwikkelen technisch uitvoerbaar?; 3. is ontwikkelen economisch verantwoord?; 4. is het nieuwe informatiesysteem organisatorisch inpasbaar?; 5. is het nieuwe informatiesysteem politiek haalbaar?. Een IT audit richt zich op de volgende mijlpaal producten: • De beschrijving van de systeemeisen; • Het systeemconcept; • Het totaalplan en de kosten/baten analyse.

Status: Definitief

53/60

Versie: 1.1


Fase 2 Basis Ontwerp (BO) In deze fase stelt men het ontwerp van het gehele systeem vast. Dit houdt onder meer in het definiëren van de deelsystemen en de functies daarbinnen. Men beschrijft wat het systeem zal gaan doen. De mogelijke deelsystemen kunnen los van elkaar verder ontwikkeld worden. De definitie van de deelsystemen wordt grotendeels bepaald door: • de organisatie omgeving; • de gegevensstructuur; • de vereiste functies. Nadat het te bouwen informatiesysteem is gevalideerd worden er uitvoeringsplannen gemaakt. In deelprojecten vindt verdere detaillering plaats (zie opvolgende fasen). Om deze projecten ordelijk te laten verlopen is er een projectplan opgesteld tot aan de invoering. Ook de kosten en het tijdschema zijn hierin opgenomen. Mijlpaal producten: • bepaling basisgegevenstructuur; • bepaling basisfunctiestructuur; • technische systeemstructuur. Aan het einde van de fase wordt het basisontwerp gecontroleerd op mogelijke fouten of hiaten (valideren). In het rapport basisontwerp worden alle conclusies en verantwoordingen vastgelegd. Op basis van dit rapport is er een go of no go besluit. Fase 3 Detail Ontwerp (DO) Deze fase is te verdelen in twee stappen. De eerste stap is het in detail uitwerken van de onderdelen uit de vorige fase en het verwerken daarvan in een functioneel ontwerp rapport. De tweede stap is het opstellen van een acceptatie testplan. Het SDM functioneel ontwerp rapport beschrijft in detail wat het nieuwe informatiesysteem allemaal moet kunnen: • volledige beschrijving van alle functies; • een volledige beschrijving van de gegevensstructuur; • een volledige beschrijving van de user interface; • de gewenste/vereiste prestaties. In deze fase vindt veel overleg plaats met de toekomstige gebruikers. De tweede stap van de detailontwerp fase is het opstellen van een technisch ontwerp rapport. Het SDM technisch ontwerp rapport legt vast hoe de eerste stap gerealiseerd gaat worden. De technische aspecten hebben o.a. betrekking op: • handmatige procedures; • beeldschermindelingen; • lijstindelingen; • programmaspecificatie; • fysieke structuur van de database. Verder is in deze fase de wijze van testen uitgewerkt in een acceptatie testplan. De verschillende mijlpaal producten zijn hierbij als volgt: • Rapport functioneel ontwerp; • Rapport technisch ontwerp; • Plan voor systeemtest; • Plan voor acceptatietest; • Plan voor realisatie en invoering. Na deze fase is alles in theorie bekend en kan worden gestart met de bouw van het informatiesysteem. Opgemerkt moet worden dat bij kleinere projecten de Basisontwerp fase en de Detailontwerp fase wordt samengevoegd tot één fase, het Systeemontwerp. Fase 4

Realisatie (R)

Status: Definitief

54/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding In deze fase wordt het informatiesysteem gereed gemaakt voor invoering. De uitgangspunten, het functioneel ontwerp rapport en technisch ontwerp rapport worden omgezet in werkende programma´s. In deze fase wordt tevens de hardware aangeschaft, worden de programma´s geschreven, wordt het systeem getest, wordt de documentatie gemaakt en worden er acceptatie tests gehouden. Het testen is een belangrijke activiteit: • Programmatest Elke keer als de programmeur een programma klaar heeft zal hij dit testen. Als er meerdere programma's klaar zijn die een koppeling met elkaar hebben, zal de programmeur ook die koppeling testen. • Systeemtest De systeemtest is gericht op het ontdekken en herstellen van fouten. • Acceptatietest De acceptatietest maakt duidelijk of het ontwikkelde informatiesysteem daadwerkelijk de verwachtingen waarmaakt en aan de gestelde eisen voldoet. Mijlpaal producten: • Rapport systeemtest; • Rapport acceptatietest; • Systeem documentatie. Fase 5 Invoering (I) Tijdens deze fase wordt het informatiesysteem geïnstalleerd en overgedragen aan degenen voor wie het bedoeld is. De cursussen worden gegeven en de gebruikers raken vertrouwd met het nieuwe systeem. De gegevens worden in het nieuwe systeem geplaatst en eventueel wordt er een gegevensconversie uitgevoerd. Na deze fase is het systeem klaar voor gebruik. De volgende mijlpaal producten onderkennen we: • Conversie en invoeringsplan; • Afgesloten projectdocumentatie; • Overdrachtsrapport. Fase 6 Gebruik en Beheer Ondanks dat de organisatie het informatiesysteem in gebruik neemt zijn nog steeds beheerwerkzaamheden nodig. De SDM methode heeft hier richtlijnen voor zodat het systeem blijft voldoen aan de gestelde eisen. De activiteiten in deze fase hebben een doorlopend karakter en blijven bestaan zolang het systeem in gebruik is. Mijlpaal producten: • Organisatie van gebruik en onderhoud; • Verschillende gebruiken beheersplannen; • Volledige systeembeschrijving; • Periodiek beoordelingsrapport.

Status: Definitief

55/60

Versie: 1.1


A.2 eXtreme Programming (Ontwikkelingsvariant van Agile) Kent Beck is de grondlegger van Extreme Programming (XP) (Beck, 2000).

Figuur: Een voorbeeld van een typisch XP proces. (Lindstrum et al, 2004) XP heeft twaalf Best Practices (Beck, 2000) die indien in samenhang toegepast elkaar versterken: 1. Gebruik een zo simpel mogelijk ontwerp dat werkt; 2. Schrijf eerst de testcode (unittest) voordat je functionaliteit codeert; 3. Continue herstructurering (refactoring) van de programmacode; 4. Continue integratie van alle programmacode; 5. Iedere ontwikkelaar heeft gelijke rechten over alle programmacode; 6. Iedere ontwikkelaar gebruikt dezelfde codeerstandaard; 7. Programmeurs werken in paren (Pair Programming); 8. Opdrachtgever is onderdeel van ontwikkelteam en dus continue voor vragen beschikbaar; 9. Software wordt in een vaste regelmaat, in releases van beperkte omvang, aan de opdrachtgever opgeleverd voor beoordeling; 10. Ontwikkelaars plannen aan de hand van kleine brokjes functionaliteit (User Stories); 11. Alle teamleden (ontwikkelaars en de opdrachtgever) delen een gemeenschappelijk beeld van het systeem ('metafoor'); 12. Overwerken is een uitzondering.

Status: Definitief

56/60

Versie: 1.1


Figuur: XP kernpunten en levenscyclus van project (Lindstrum et al, 2004) XP definieert slechts twee rollen binnen het systeemontwikkelingsproject (Beck, 2000): dit zijn de opdrachtgever en de ontwikkelaar. De opdrachtgever bepaalt de requirements, de acceptatiecriteria en de toegevoegde waarde van het project voor de business. De ontwikkelaar implementeert vervolgens de requirements van de opdrachtgever. De ontwikkelaar is vervolgens verantwoordelijk voor de verificatie van de code. De opdrachtgever is vervolgens acceptant en heeft de verantwoordelijkheid om de code te valideren. XP: voor- en nadelen Voordelen: • Opdrachtgever is goed op de hoogte (klantgedreven ontwikkeling); • Gemotiveerde programmeurs; • Gedeelde kennis is toekomstvaste kennis; • Beheersing kosten (betaal zo lang het bevalt). Nadelen: • Niet eenvoudig in te voeren; • Er bestaat weinig ervaring met XP; • Einddoel kan ondersneeuwen; • Ontwikkelaar moet teamspeler zijn. Pair programming Pair programming is een techniek die zijn oorsprong vindt in eXtreme Programming (XP). Bij pair programming werk je met twee teamleden aan hetzelfde onderdeel. Eén teamlid zit achter het toetsenbord en muis en het andere teamlid zoekt informatie op en denkt mee. Zoals in de rallysport heb je dus een ‘driver’ en ‘navigator’. Je wisselt regelmatig van plaats. Deze wijze van werken blijkt vaak productiever dan wanneer beide teamleden achter hun eigen scherm zitten en levert betere kwaliteit op. en wordt ook in veel andere ontwikkelmethodes toegepast.

Status: Definitief

57/60

Versie: 1.1


A.3 Scrum (verschijningsvorm van Agile) Scrum is niet primair een ontwikkelmethode voor software. Het is vooral ook een methode om productontwikkeling te managen die toegepast kan worden op verschillende technologieën waaronder systeemontwikkeling. Daarnaast is Scrum een proces voor continue verbetering. De naam Scrum komt uit het rugby jargon waar de term scrum refereert aan de strategie om een bal terug in het spel te brengen. Scrum bestaat oorspronkelijk niet zozeer uit een proces maar eerder uit practices die de methode vorm geven waarbij het mogelijk is om deze practices gezamenlijk tot een proces te kneden (Schwaber, 2002 en Larman, 2005); Scrum Master De Scrum Master is verantwoordelijk voor het scrum proces en daarmee voor het correcte gebruik van scrum en het maximaliseren van de voordelen van scrum. De rol lijkt op de rol van projectmanager of teamleider maar heeft andere verantwoordelijkheden. Daarnaast is een Scrum Master in veel gevallen ook voor 50% een ontwikkelaar. De Scrum Master draagt zorg voor: • De beheerste uitvoering van de Scrum practices om te profiteren van de waarden van Scrum die zorgen dat het proces correct verloopt; • Het bijhouden van de voortgang van het team en het informeren van partijen over de voortgang; • Samenwerking met management en de opdrachtgever om te identificeren wie de rol van ´product owner´ vervult; • Het uitsluiten van externe invloeden op het Scrum team; • Het voorzitten van de ‘Daily Scrum meetings’ en het houden van de ‘Sprint Review’. Product Backlog De Product Backlog is de ´master´ lijst met alle functionaliteit vereist voor het product. Bij aanvang van project worden de primaire eisen opgesteld waarmee in de eerste iteratie wordt gestart. Elke ‘stakeholder’ kan requirements aan de Product Backlog toevoegen maar uiteindelijk heeft de productowner de eindverantwoordelijkheid. De Product Backlog zal gedurende het project groeien omdat requirements steeds beter zijn te specificeren. Sprint Een Scrum team werkt voor een gelimiteerde periode die een Sprint wordt genoemd. Normaliter is een Sprint vastgesteld op 30 kalender dagen. Mocht het doel van de Sprint gedurende de uitvoering niet meer relevant of niet meer te bereiken zijn dan wordt de Sprint tussentijds afgebroken. Scrum teams Een Scrum team bestaat meestal uit hoogstens 7 personen en committeert zich aan het doel van een Sprint. Binnen de Sprint heeft het team de volledige vrijheid om zelf beslissingen te nemen die zij nodig achten om het doel van de Sprint te bereiken. Dit betekent dat zij problemen, besluiten en projectplanning in eigen hand houden. Sprint Planning Meeting Elke Sprint begint met een Sprint Planning Meeting. Opdrachtgevers, eindgebruikers, management, producteigenaar, Scrum Master en het Scrum team bepalen gezamenlijk wat het doel wordt van de volgende Sprint met bijbehorende prioriteiten en functionaliteit. Dit wordt in de Sprint Backlog vastgesteld. De Sprint Backlog is een subset van de Product Backlog. Daily Scrum meeting

Status: Definitief

58/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding De Scrum werkwijze omvat Daily Scrum meetings waarbij de voortgang met elkaar wordt gedeeld. Elk lid van het team beantwoordt de volgende 3 vragen: 1. Wat heb je gedaan sinds de laatste meeting? 2. Wat ga je doen tussen nu en de volgende meeting? 3. Is er iets dat je weerhoudt om te doen wat je van plan bent? De eerste twee vragen gaan over voortgang. De derde vraag betreft problemen die de voortgang kunnen bedreigen. Alleen Scrum teamleden mogen in de meeting actief participeren. Geïnteresseerden kunnen meeluisteren maar hebben verder geen inbreng in de meeting. Doelstelling is dat mogelijke problemen worden aangekaart zodat daarop direct actie kan worden ondernomen opdat het doel van de Sprint niet in gevaar komt. Sprint Review Na elke Sprint is er een Sprint Review Meeting waar het increment van het tot dan toe ontwikkelde product in de vorm van een demo aan belanghebbenden wordt gepresenteerd. Deze meeting duurt ongeveer 4 uur en geeft een concreet beeld over de voortgang die bereikt is gedurende de Sprint en legt het fundament voor de volgende Sprint Planning Meeting. Zowel voor als na de Sprint zijn er dus meetings waardoor voortgangscontrole mogelijk is.

Figuur; weergave van het Scrum proces. Samenvatting kenmerken Scrum heeft de volgende kenmerken; SCRUM: technieken • Samenstellen van een Scrum team; • Creëren van Product Backlog; • Segmentatie van project; • Scrum meetings. SCRUM: Controls • Doordat het ontwikkelproces een ‘black box’ is, heeft de gebruikersorganisatie controls nodig; • Controls worden door Scrum Backlog vastgelegd; • Tussen de fasen en controls is interactie. SCRUM: voor- en nadelen Voordelen: • Hoge productiviteit; • Continue verbetering; • Gaat goed om met chaos; • Goed probleem oplossend vermogen en zelfsturing; • Goed team communicatie, lerend vermogen en sterke focus op het doel;

Status: Definitief

59/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling Referaat - Postgraduate IT (EDP) -audit opleiding • Goed te combineren met andere methoden. Nadelen: • Vereist goede afstemming tussen ontwikkelaars en gebruikers; • Vereist dat het management besluitvorming delegeert aan het team; • Definieert niet welke documenten het proces oplevert;

Figuur; weergave van het Scrum proces.

Scrum of scrums Scrum of scrums is een manier om schaalvergroting te bewerkstelligen met Scrum. Een scrum of scrums is een gremium bestaande uit één vertegenwoordiger van ieder scrum team. Wie het scrum team vertegenwoordigt is afhankelijk van de problematiek die besproken wordt. In de scrum of scrum meeting wordt overlegd over zaken die meerdere scrum teams aangaan. Elke vertegenwoordiger beantwoordt de volgende 4 vragen: 1. What has your team done since we last met?; 2. What will your team do before we meet again?; 3. Is anything slowing your team down or getting in their way?; 4. Are you about to put something in another team’s way?.

Status: Definitief

60/60

Versie: 1.1

Rol van de IT auditor bij agile systeemontwikkeling

Recommend Documents