TOETSING SCRUM IN HET KADER VAN DE JAARREKENINGCONTROLE

TOETSING SCRUM IN HET KADER VAN DE JAARREKENINGCONTROLE Toetsen van change management volgens de SCRUM methodiek in het kader van de jaarrekeningcontrole

Vrije Universiteit, Amsterdam IT Audit Opleiding Naam: Studentnr.: Scriptienr.:

Arriën van Deursen MSc 1729055 2027

Begeleider: Begeleider VU:

ir. E.F. Ernst Albers RE dhr. Paul Harmzen RA RE

Definitieve versie

2

1

VOORWOORD

Deze scriptie is geschreven als afsluiting van de postdoctorale opleiding IT Audit aan de Vrije Universiteit Amsterdam, die ik in de periode van 2012 tot en met begin 2015 heb gevolgd. Er zijn meerdere personen, die ik wil bedanken voor hun bijdrage aan de resultaten van deze scriptie en voor hun steun gedurende de totstandkoming van deze scriptie. Ten eerste wil ik de geïnterviewden bedanken voor hun inzichten en ervaring die zij met mij wilden delen. Ten tweede wil ik mijn begeleiders Paul Harmzen en Ernst Albers bedanken voor hun supervisie en praktische hulp. Ten slotte wil ik Anouk bedanken voor haar steun. Hoewel de onderwerpen mijlenver uiteen liggen, heb ik genoten van de uren waarin wij tegelijkertijd aan onze eigen scripties hebben gewerkt. Arnhem, maart 2015

Arriën van Deursen, 2015 - Toetsing SCRUM in het kader van de jaarrekeningcontrole

3

2

SAMENVATTING

In toenemende mate wordt door organisaties voor het change management (onderhoud en ontwikkeling) van applicaties SCRUM toegepast, een ontwikkelmethodiek die is gericht op snelle ontwikkeling van software en die zich kenmerkt door de aanpak waarbij in multidisciplinaire teams deelprojecten van systeemontwikkeling worden uitgevoerd. In het kader van de jaarrekening voert de IT auditor werkzaamheden uit om een uitspraak te kunnen doen over de effectiviteit van het change management proces. Hierbij hanteert de IT auditor een normenkader, dat is gebaseerd en gericht op de watervalmethodiek, en derhalve in beperkte mate toepasbaar is op de SCRUM ontwikkelmethodiek. Deze scriptie betreft de verslaglegging van het onderzoek, waarbij op een systematische wijze een normenkader is ontwikkeld dat door de IT auditor gehanteerd kan worden om change management volgens de SCRUM methodiek te toetsen. Hiermee wordt antwoord gegeven op de centrale onderzoeksvraag: ‘Hoe kan change management (softwareontwikkeling en -onderhoud) volgens de SCRUM methodiek getoetst worden in het kader van de jaarrekeningcontrole teneinde een uitspraak te kunnen doen over de betrouwbaarheid van de geautomatiseerde gegevensverwerking?’ Om een antwoord te kunnen geven op de centrale onderzoeksvraag is in drie verschillende stappen een normenkader ontwikkeld dat door de IT auditor kan worden gehanteerd om change management volgens de SCRUM methodiek te toetsen. Ten eerste, aan de hand van een literatuurstudie zijn de specifieke kenmerken en uitgangspunten van SCRUM onderzocht en zijn bestaande meetmodellen en normenkaders ten aanzien van SCRUM bestudeerd. Ten tweede, door middel van een theoretische uiteenzetting is het traditionele, op de watervalmethodiek gerichte normenkader geanalyseerd om te bepalen welke controle procedures niet toereikend zijn (‘gaps’) om te hanteren in een context waar SCRUM wordt toegepast. Voor deze ‘gaps’ zijn alternatieve controle procedures opgesteld aan de hand van de in de literatuurstudie behandelde meetmodellen en normenkaders. Ten slotte is het voorgestelde normenkader inclusief de alternatieve controle procedures gevalideerd door middel van interviews met subject-matter experts, waarbij specifieke aandacht is besteed aan de praktische toepasbaarheid van de controle procedures, rekening houdend met de vaktechnische vereisten. Er zijn duidelijke verschillen tussen het traditionele, op de waterval gerichte normenkader en het eindproduct van dit onderzoek, het gevalideerde normenkader dat door de IT auditor gehanteerd kan worden om change management volgens de SCRUM methodiek te toetsen in het kader van de jaarrekening controle. Het is ten eerste belangrijk dat de IT auditor een expliciet oordeel vormt over de


4

opzet van het change management proces: is SCRUM gezien de context van het type organisatie en type applicatie een geschikte ontwikkelmethodiek? Ten tweede, de selectie van de uit te voeren testwerkzaamheden moet, meer dan in het traditionele normenkader, vanuit een risico perspectief worden bepaald: welke SCRUM trajecten hebben een impact op de continue werking van de kernfunctionaliteiten van de bedrijfs-kritische applicaties? Het derde verschil betreft de nadruk op de aantoonbaarheid van deze kernfunctionaliteiten: welke maatregelen heeft een organisatie getroffen om ondanks de alternatieve ontwikkelmethode te waarborgen dat het systeem op een correcte wijze blijft functioneren? Ten slotte, de nadruk ligt bij SCRUM niet op uitvoerige documentatie. In verschillende controle procedures in het gevalideerde normenkader wordt aangegeven dat het noodzakelijk kan zijn om als IT auditor gedurende het SCRUM traject aan te haken in plaats van het oordeel te baseren op de inspectie van documentatie nadien.


5

3

INHOUDSOPGAVE

1

VOORWOORD

2

2

SAMENVATTING

3

3

INHOUDSOPGAVE

5

4 4.1 4.2 4.3 4.4 4.5

INLEIDING AANLEIDING VAN HET ONDERZOEK VRAAGSTELLING ONDERZOEKSVRAGEN SCOPE ONDERZOEKSMETHODE

7 7 7 8 8 9

5 5.1 5.2

SCRUM AGILE ONTWIKKELMETHODIEK SCRUM ONTWIKKELMETHODIEK

10 10 11

6 6.1 6.2

SCRUM: MEETBAAR EN TOETSBAAR SCRUM MEETMODELLEN SCRUM NORMENKADERS

14 14 15

7 7.1 7.2 7.3

TOETSINGSPUNTEN CHANGE MANAGEMENT BESCHRIJVING HUIDIG NORMENKADER ANALYSE HUIDIG NORMENKADER ‘GAPS’ HUIDIG NORMENKADER

18 19 19 22

8

CONCEPT NORMENKADER SCRUM VOOR IT AUDITOR

22

9 9.1 9.2 9.3 9.4

VALIDATIE NORMENKADER SCRUM VOOR IT AUDITOR TYPE ORGANISATIE EN APPLICATIE (MC-CONTEXT) POPULATIE EN SAMPLE (MC-START) AUTORISEREN VAN CHANGES (MC-1) TESTEN VAN CHANGES (MC-2) 9.4.1 FUNCTIONELE TESTEN (MC-2 FUNCTIONEEL) 9.4.2 REGRESSIETESTEN (MC-2 REGRESSIE) 9.5 GOEDKEUREN VAN CHANGES (MC-3) 9.6 MONITOREN VAN CHANGES (MC-4) 9.7 FUNCTIESCHEIDING CHANGE MANAGEMENT PROCES (MC-5)

25 27 29 32 34 34 36 38 39 41

10 10.1 10.2 10.3

43 43 46 47

CONCLUSIE BEANTWOORDING DEELVRAGEN BEANTWOORDING ONDERZOEKSVRAAG VERVOLGONDERZOEK


6

11

PERSOONLIJKE REFLECTIE

48

12

LITERATUURLIJST

50

BIJLAGE A: HUIDIG NORMENKADER CHANGE MANAGEMENT (WATERVALMETHODIEK)

54

BIJLAGE B: DEFINITIEF NORMENKADER CHANGE MANAGEMENT (SCRUM METHODIEK)

55

BIJLAGE C: VRAGENLIJST INTERVIEW IT AUDITOR (RE)

57

BIJLAGE D: VRAGENLIJST INTERVIEW IT AUDITOR (RA/RE)

58


7

4

INLEIDING

4.1

AANLEIDING VAN HET ONDERZOEK

Om in het kader van de jaarrekeningcontrole te kunnen steunen op geautomatiseerde systeemcontroles en gebruik te kunnen maken van systeem-gegenereerd lijstwerk (electronic audit evidence), moeten de IT General Controls (randvoorwaardelijke beheersingsmaatregelen) getoetst worden (Schellevis en Van Dijk, 2014), waarbij de IT auditor zich voornamelijk richt op change management, logische toegangsbeveiliging en continuïteitsbeheer van de relevante componenten van de IT omgeving. Het

normenkader

wat

de

IT

auditor

hanteert

ten

aanzien

van

change

management

(softwareontwikkeling en -onderhoud) in het kader van de jaarrekeningcontrole, is ontwikkeld op basis van en gericht op de traditionele watervalmethode. Binnen deze methode is er in het ontwikkelproces een duidelijke fasering aangebracht tussen ontwerp, ontwikkeling, testen, goedkeuring en onderhoud van applicaties (Strode, 2012; Collyer en Manzano, 2013;Trijsenaar en Zalm, 2013; Martens et al., 2014). In toenemende mate wordt binnen organisaties gebruik gemaakt van de SCRUM methodiek in de ontwikkeling en het onderhoud van (bedrijfs-kritische) applicaties (Kim et al., 2013; Trijsenaar en Zalm, 2013; Martens et al., 2014; Westerveld, 2014). Deze methode is gericht op een snelle ontwikkeling van software en kenmerkt zich door de aanpak waarbij in multidisciplinaire teams deelprojecten van de systeemontwikkeling worden aangepakt. Het huidige normenkader, dat door de IT auditor wordt gehanteerd in het kader van de jaarrekeningcontrole om change management (software onderhoud) te toetsen om een uitspraak te doen over de geautomatiseerde gegevensverwerking, lijkt niet toepasbaar in een omgeving waarin de SCRUM methodiek wordt gehanteerd (Barlow et al., 2011). Omdat de relevante kenmerken van de SCRUM methodiek afwijken van de watervalmethode, moet er een normenkader worden ontwikkeld om de IT auditor handvatten te bieden om in het kader van de jaarrekeningcontrole zijn werkzaamheden uit te voeren en om een uitspraak te kunnen doen over de betrouwbaarheid van de geautomatiseerde gegevensverwerking.

4.2

VRAAGSTELLING

Op basis van de in hoofdstuk 4.1 beschreven aanleiding van het onderzoek, is de volgende onderzoeksvraag geformuleerd:


8

Hoe kan change management (softwareontwikkeling en -onderhoud) volgens de SCRUM methodiek getoetst worden in het kader van de jaarrekeningcontrole teneinde een uitspraak te kunnen doen over de betrouwbaarheid van de geautomatiseerde gegevensverwerking?

4.3

ONDERZOEKSVRAGEN

Om de onderzoeksvraag zoals geformuleerd in hoofdstuk 4.2 te kunnen beantwoorden, zijn de volgende deelvragen geformuleerd:

—

Hoe kan de SCRUM methodiek worden gedefinieerd en wat zijn de relevante kenmerken, uitgangspunten en leading practices?

—

Welke methoden, variabelen en modellen zijn er ontwikkeld om de SCRUM methodiek meetbaar en toetsbaar te maken?

—

Welke toetsingspunten hanteert een IT auditor ten aanzien van change management in het kader van de jaarrekeningcontrole en in welke mate zijn deze toepasbaar op change management volgens de SCRUM methodiek?

—

Hoe ziet het normenkader er uit dat de IT auditor kan hanteren om change management volgens de SCRUM methodiek te toetsen in het kader van de jaarrekeningcontrole?

—

Is het normenkader dat de IT auditor kan hanteren om change management volgens de SCRUM methodiek te toetsen in het kader van de jaarrekeningcontrole toepasbaar in de praktijk?

4.4

SCOPE

Het beantwoorden van de onderzoeksvraag zal enkel betrekking hebben op het toetsen van change management volgens de SCRUM methodiek in het kader van de jaarrekeningcontrole door de IT auditor om uiteindelijk een uitspraak te kunnen doen over de betrouwbaarheid (voornamelijk juistheid en volledigheid) van de geautomatiseerde gegevensverwerking (geautomatiseerde systeemcontroles en systeem-gegenereerd lijstwerk). Met change management wordt in dit onderzoek verwezen naar het proces van ontwikkelen (en onderhouden naar aanleiding van gebruikerswensen) van software, maar niet naar het proces van installeren van standaard updates, patches en fixes. Het eindresultaat is een normenkader dat door de IT auditor tijdens de jaarrekeningcontrole kan worden gebruikt en zal derhalve niet volledig van toepassing zijn voor andersoortige controlewerkzaamheden die worden uitgevoerd door de IT auditor. De toepasbaarheid van het ontwikkelde normenkader zal worden gevalideerd aan de hand van verschillende interviews met subject-matter experts die werkzaam zijn binnen de financiële sector en


9

ervaring hebben met het toetsen van change management volgens de SCRUM methodiek binnen deze sector (banken, vermogensbeheerders, verzekeraars).

4.5

ONDERZOEKSMETHODE

De opbouw van deze scriptie is conform de hierboven geformuleerde deelvragen, zoals benoemd in paragraaf 4.3. In Figuur 1 is de opbouw van de scriptie schematisch weergegeven:

Wat is SCRUM?

Meten en toetsen van SCRUM

(hoofdstuk 5)

(hoofdstuk 6)

Normenkader SCRUM voor IT Auditor in jaarrekeningcontrole

Praktische toepasbaarheid normenkader SCRUM voor IT Auditor

(hoofdstuk 8)

(hoofdstuk 9)

Toetsingspunten IT Auditor in jaarrekeningcontrole ten aanzien van change management en identificatie ‘gaps’ (hoofdstuk 7)

Figuur 1: Schematische weergave scriptie: toetsing ‘SCRUM’ in het kader van de jaarrekeningcontrole

Teneinde een normenkader te ontwikkelen om change management volgens de SCRUM methodiek te toetsen in het kader van de jaarrekeningcontrole, dient SCRUM nader te worden gedefinieerd. Hoofdstuk 5 en 6 bevatten theoretische uiteenzettingen op basis van literatuuronderzoek. Hoofdstuk 5 richt zich voornamelijk op de gehanteerde definities, uitgangspunten en ‘leading practices’ van de SCRUM ontwikkelmethodiek en hoofdstuk 6 behandelt enerzijds de variabelen die zijn ontwikkeld om SCRUM meetbaar te maken en anderzijds normenkaders, die zijn voorgesteld om deze methodiek te beoordelen. Zoals hierboven beschreven, toetst de IT auditor in het kader van de controle van de jaarrekening de IT General Controls, bestaande uit de procedures voor change management, logische toegangsbeveiliging en continuïteitsbeheer. In hoofdstuk 7 wordt aan de hand van het huidige normenkader aangetoond welke toetsingspunten de IT auditor hanteert ten aanzien van change management in de jaarrekeningcontrole. De toetsingspunten ten aanzien van logische toegangsbeveiliging en continuïteit worden in dit onderzoek buiten beschouwing gelaten, omdat de SCRUM ontwikkelmethodiek enkel impact heeft op het change management proces. Door middel van een kritische beschouwing van dit normenkader en de theoretische uiteenzetting van SCRUM uit eerdere hoofdstukken wordt duidelijk dat het huidige normenkader niet voldoet en wordt inzichtelijk welke ‘gaps’ moeten worden aangevuld in het nieuwe normenkader.


10

Hoofdstuk 8 bevat een beschrijving van het normenkader voor het toetsen van change management volgens de SCRUM methodiek en de onderbouwing hiervan. Het ontwikkelde normenkader is gebaseerd op het bestaande normenkader en aanvullingen voor de in hoofdstuk 7 geïdentificeerde ‘gaps’. De praktische toepasbaarheid van het ontwikkelde normenkader wordt behandeld in hoofdstuk 9 in een discussie die wordt gevoed door vijf uitgevoerde interviews met subject-matter experts. Deze interviews zijn getranscribeerd met Express Scribe, een tool voor het vertraagd en gecontroleerd afspelen van de audiotapes. De transcripten van de interviews zijn vervolgens gecodeerd om de discussie van een zinvolle input te voorzien.

5

SCRUM

Om uiteindelijk een normenkader te ontwikkelen om change management volgens de SCRUM methodiek te toetsen in het kader van de jaarrekeningcontrole, dient SCRUM als software ontwikkelmethodiek nader te worden gedefinieerd. SCRUM wordt beschouwd als een van de meest voorkomende agile software ontwikkelmethodieken (Abrahamsson et al., 2002; Highsmit, 2002; Boehm en Turner, 2005; Suleiman et al., 2006; Mahnic en Vrana, 2007; Mahnic en Zabkar, 2007, 2008; Rodenburg en Vlaanderen, 2009; Lee en Xia, 2010; West en Grant, 2010; Strode, 2005, 2012; Trijsenaar en Zalm, 2013). Dit hoofdstuk bevat een uiteenzetting van gehanteerde definities en kernbegrippen van agile software ontwikkelmethodieken in het algemeen en van SCRUM in het bijzonder. Ten slotte worden het SCRUM proces en de stakeholders in dit proces nader uitgewerkt.

5.1

AGILE ONTWIKKELMETHODIEK

Volgens Strode (2005, 2012) zijn agile methodieken een groep van systeem ontwikkelmethodieken die in eerste instantie niet gericht zijn op een vooraf uitgevoerde analyse, een vooraf opgesteld ontwerp of een vooraf gedefinieerd object. Dit contrasteert met de uitgangspunten van de klassiekere watervalmethode, waarin deze zaken wel een prominente rol innemen in het ontwikkelproces (Trijsenaar en Zalm, 2013). De belangrijkste uitgangspunten van agile zijn door 17 ontwikkelaars vastgelegd in een manifest (Beck et al., 2001) en zijn als volgt verwoord door Trijsenaar en Zalm (2013): ‘personen zijn belangrijker dan processen en tools, werkende en bruikbare software is belangrijker

dan

lijvige

documentatie,

samenwerking

met

de

klant

levert

meer

op

dan

contractonderhandelingen en omgaan met verandering is belangrijker dan een vooraf bepaald strak plan volgen’.


11

Abrahamsson et al. (2002) hebben een definitie van agile ontwikkelmethodieken uiteengezet aan de hand waarvan verschillende methodieken worden ingedeeld. Zij stellen dat agile software ontwikkelmethodieken incrementeel (kleine releases met korte cycli), coöperatief (ontwikkelaars en gebruikers werken nauw samen), eenvoudig (de methodiek spreekt voor zich) en adaptief (wijzigingen kunnen tot het laatste moment worden toegepast) zijn. Op basis van literatuuronderzoek naar de verschillende definities van agile ontwikkelmethodieken, stelt Strode (2006) dat een agile software ontwikkelmethodiek ontworpen is voor het management en de ondersteuning van een iteratief en incrementeel ontwikkelproces van business systemen, in omgevingen waar verandering constant is, waarbij in kleine teams software wordt geproduceerd door communicatie, feedback, leerervaringen en frequente meetings en waarbij modelleren en documentatie niet een voornaam belang hebben. In deze scriptie zal de definitie van Strode (2006) worden gehanteerd, omdat hierin de principes van het agile manifest zijn verwerkt, de snel veranderende omgeving

in

ogenschouw

wordt

genomen

en

omdat

het

onderscheid

met

klassieke

ontwikkelmethodieken duidelijk wordt.

5.2

SCRUM ONTWIKKELMETHODIEK

In de wetenschappelijke literatuur wordt SCRUM voor het eerst benoemd door Takeuchi en Nonaka (1986). De term is afkomstig uit het rugby en beschrijft de spelsituatie waarin beide teams bij een spelhervatting in een groepsformatie tegen elkaar botsen om verder in het speelveld te geraken. De raakvlakken tussen de software ontwikkelmethodiek en de rugby-term zijn voornamelijk de focus op teaming, flexibiliteit en korte sprints. Volgens Strode (2005) is SCRUM als software ontwikkelmethodiek voornamelijk geïntroduceerd en uitgewerkt door Beedle et al. (1999) en Schwaber en Beedle (2002). Beedle et al. (1999) definiëren SCRUM als ontwikkelmethodiek door de technieken te beschrijven waarmee de ontwikkelaars de chaos en de complexiteit van de veranderende omgeving kunnen pareren. Abrahamsson et al. (2002) benadrukken op eenzelfde wijze dat de essentie van de SCRUM methodiek inhoudt dat er in het ontwikkelproces verschillende omgevings- en technische variabelen zijn (vereisten, tijdsbestek, hulpmiddelen en technologie) die tijdens het proces continu veranderen en die daarom flexibiliteit vereisen van de (gebruikte methodes van de) ontwikkelaars. Een belangrijke methode om de voortgang in het ontwikkelproces in een continu veranderende omgeving te waarborgen, is het betrekken van het management door middel van frequente besprekingen omtrent tekorten en belemmeringen (Abrahamsson et al., 2003).


12

De hierboven besproken definities maken nog niet voldoende mate duidelijk waarom SCRUM wordt beschouwd

als

een

aparte

verschijningsvorm

binnen

de

verzameling

van

agile

software

ontwikkelmethodieken. SCRUM wijkt voornamelijk af van de andere methodieken door de unieke procesgang. Deze procesgang zal hieronder verder worden toegelicht en geïllustreerd. Volgens Highsmit (2002) is SCRUM een project management raamwerk waarin ontwikkelactiviteiten (opstellen van vereisten, ontwerp, programmeren) plaatsvinden in iteraties van sprints (30 kalenderdagen), waarbinnen werkende software wordt opgeleverd.

Zie hieronder voor een

schematische weergave van het SCRUM ontwikkelproces, die is gebaseerd op verschillende (grafische) beschrijvingen van het proces (Abrahamsson et al., 2002; Highsmit, 2002; Strode, 2005; Mahnic en Vrana, 2007; Mahnic en Zabkar, 2007; Collyer en Manzano, 2013):

FEEDBACK

PREGAME PRODUCT BACKLOG

DEVELOPMENT SPRINT PLANNING MEETING

POSTGAME SPRINT REVIEW MEETING

RELEASE

30-DAY SPRINT SPRINT RETROSPECTIVE MEETING

SPRINT BACKLOG

SPRINT TASKS

DAILY SCRUM

Figuur 2: Schematische weergave SCRUM ontwikkelproces

Het product backlog is een lijst van wensen en vereisten die afkomstig zijn van verschillende stakeholders (Abrahamsson, 2002). Deze lijst bevat niet enkel technische vereisten, maar ook wensen vanuit de business (Highway, 2002). Tijdens de sprint planning meeting wordt door de product eigenaar (bijv. applicatie-eigenaar) een prioritering gemaakt van items die in de eerstvolgende sprint meegenomen moeten worden. Door het ontwikkelteam worden hiervoor de bijbehorende taken inclusief een inschatting van de benodigde tijd gemaakt. Op basis van het overleg binnen de sprint planning meeting wordt de sprint backlog opgesteld (Mahnic en Zabkar, 2007) als input voor de eerstvolgende sprint. Highway (2002) benadrukt het belang van een sprint goal (business doelstelling voor de sprint) om te voorkomen dat het SCRUM team zich verliest in de details van de afzonderlijke taken.


13

In een sprint worden de verschillende taken uitgevoerd die zijn opgenomen in de sprint backlog. Binnen de sprint is er geen sprake van een vooraf gedefinieerd proces (Beedle et al., 1999). De lengte van een sprint varieert tot maximaal 1 kalendermaand (30 dagen) (Beedle et al., 1999; Abrahamsson et al., 2002, Highway, 2002). Om de voortgang te bewaken, wordt er dagelijks een 15-minuten durende SCRUM meeting gehouden waarin ieder lid van het SCRUM team antwoord geeft op de vragen ‘wat heb je gedaan sinds de laatste dagelijkse SCRUM meeting’, ‘wat ga je doen voor de volgende SCRUM meeting’ en ‘zijn er belemmeringen in het ontwikkelproces’ (Mahnic en Vrana, 2007; Mahnic en Zabkar, 2007; Mahnic en Zabkar, 2008). Aan het eind van de sprint vindt er een sprint review meeting plaats waarin de voortgang wordt besproken en er een demonstratie van het eindresultaat wordt gegeven aan de klant (Highway, 2002). Het testen van een redelijk gedeelte van de ontwikkelde software is volgens Beedle et al. (1999) ook onderdeel van de sprint review meeting. Feedback vanuit de sprint review meeting wordt besproken in de sprint planning meeting voor de eerstvolgende sprint van de iteratiecyclus. In een aantal beschrijvingen van het SCRUM proces wordt ook een sprint retrospective meeting benoemd (Mahnic en Vrana, 2007, Mahnic en Zabkar, 2007, Mahnic en Zabkar, 2008) die plaatsvindt tussen de sprint review meeting en de eerstvolgende sprint planning meeting om het SCRUM team opties tot verbetering aan te laten dragen. Indien er als gevolg van een sprint of een iteratie van sprints een onderdeel van de software is die in productie kan worden genomen, wordt deze in productie genomen. Abrahamsson et al. (2002) onderscheiden een post-ontwikkelfase waarin ruimte is voor de voorbereiding van de in-productie name van de software door het uitvoeren van integratie- en systeemtesten. In de wetenschappelijke literatuur worden er verschillende stakeholders onderscheiden in het SCRUM proces. In de onderstaande tabel zijn de belangrijkste stakeholders weergegeven inclusief hun taken, verantwoordelijkheden en hun voornaamste belangen. Deze tabel is ontstaan uit een combinatie van de beschrijving van Abrahamsson et al. (2002) enerzijds en Mahnic en Vrana (2007) en Mahnic en Zabkar (2007, 2008, 2008) anderzijds:


14

STAKEHOLDER (IT) Management Product Customer

Owner

Scrum Master

Team Members

/

VERANTWOORDELIJKHEDEN Verantwoordelijk van het kiezen van de product owner; Opstellen van de product backlog; Bewaken eindresultaat van het SCRUM proces; Opstellen van de product backlog; Bewaken van SCRUM waardes en principes; Bewaken voortgang vs. planning; Oplossen belemmeringen tijdens SCRUM proces; Ontwikkelen software; Samenstellen sprint backlog;

BELANGEN Timely Information Performance; Quality Improvement; Customer Satisfaction;

on

-

Efficient Impediments Resolution;

-

Job Satisfaction;

Project

Tabel 1: Stakeholders in SCRUM ontwikkelproces: verantwoordelijkheden en belangen

6

SCRUM: MEETBAAR EN TOETSBAAR

In het vorige hoofdstuk zijn de definities van agile software methodieken in het algemeen en van SCRUM als verschijningsvorm hiervan nader uitgewerkt. Het doel om uiteindelijk een normenkader te ontwikkelen om de SCRUM methodiek te toetsen in het kader van de jaarrekeningcontrole, impliceert dat de procesgang van de SCRUM ontwikkelmethodiek toetsbaar en meetbaar is. Ten eerste bevat dit hoofdstuk een introductie van modellen die bedacht zijn om dit proces meetbaar (niet primair gericht op auditeerbaarheid) te maken zonder afbreuk te doen aan de principes van agile en SCRUM ontwikkelmethodieken. Ten tweede bevat dit hoofdstuk een uitwerking van de normenkaders die zijn voorgesteld door Collyer en Manzano (2013), Kim et al. (2013) en Trijsenaar en Zalm (2013). Deze modellen en normenkaders zijn door de auteurs niet specifiek opgesteld voor de jaarrekeningcontrole. In deze scriptie zullen deze modellen als input dienen voor het voorgestelde normenkader wat de IT auditor kan gebruiken in het kader van het toetsen van de geautomatiseerde gegevensverwerking door applicaties die volgens de SCRUM methodiek ontwikkeld en onderhouden worden.

6.1

SCRUM MEETMODELLEN

Volgens Mahnic en Vrana (2007) en Mahnic en Zabkar (2007, 2008) is de enige meeteenheid in het SCRUM proces de hoeveelheid werk die moet worden uitgevoerd voordat aan de vereisten in een product backlog is voldaan of voordat de taken in een sprint backlog zijn uitgevoerd. Schatz en Abdelshafi (2005) stellen echter dat het succes van een SCRUM ontwikkeltraject überhaupt niet gemeten kan worden omdat er een vooraf gedefinieerd plan ontbreekt en in die zelfde lijn stelt Yup (2006) dat er geen manier is om waarde ten opzichte van de kosten te meten. Het ontbreken van meeteenheden in het SCRUM proces is voor Mahnic en Vrana (2007) en Mahnic en Zabkar (2007, 2008, 2008) aanleiding geweest om een model op te stellen waarmee het software ontwikkelproces kan worden gemonitord en verbeterd met inachtneming van de belangen van de


15

verschillende stakeholders in het proces. In het AGIT (AGIle software developmenT) model, dat hieronder in tabelvorm is opgenomen, geven zij gehoor aan de oproep van Hartmann en Dymond (2006) om het gebruik van verschillende modellen en eenheden in het SCRUM proces ondergeschikt te maken aan de agile principes. In het model zijn de meeteenheden opgesteld aan de hand van de belangen van de door hen geïdentificeerde stakeholders: STAKEHOLDER IT Management

BELANGEN Timely Information on Project Performance Quality Improvement

Team members

Job Satisfaction

Scrum Master

Efficient Impediments Resolution

Customer

Customer Satisfaction

MEETEENHEDEN Work Effectiveness; Schedule Performance Index; Cost Performance Index of Labor Costs; Error Density; Cost of Rework; Fulfilment of Scope; Average Amount of Overtime at Sprint/Release/Project level; Average Number of Projects the Employee Work in Parallel; Qualitative Evaluation of Working Conditions; Average Number of Impediments per Task/Sprint/Team; Mean Time for Resolving an Impediment; -

Qualitative Evaluation of Customer Satisfaction using Criteria (error density / fulfilment of scope);

Tabel 2: Stakeholders SCRUM ontwikkelproces: belangen en meeteenheden

Mahnic en Zabkar (2007, 2008) hebben getracht om de meeteenheden in het AGIT model aan de hand van ITGI COBIT (2007) en ISACA (2008) te koppelen aan het COBIT model (versie 4.1). Aan de hand van deze mapping hebben Mahnic en Zabkar (2007, 2008) willen aantonen dat het AGIT model voldoende waarborgen biedt om te voldoen aan de algemene auditcriteria- en richtlijnen die gelden voor informatiesystemen en zoals deze zijn verwerkt in het COBIT model. Ondanks het feit dat de koppeling tussen het AGIT model en het COBIT model enkel berust op een vergelijking van de omschrijving van de meeteenheden (en in zeer geringe mate op de wijze van toetsing van de meeteenheden), biedt het AGIT model handvatten, die gebruikt kunnen worden voor het opstellen van een normenkader zoals deze gehanteerd kan worden tijdens de jaarrekeningcontrole.

6.2

SCRUM NORMENKADERS

In de vorige sectie is het AGIT model behandeld, dat zich voornamelijk richt op het meetbaar maken van het proces van software ontwikkeling volgens de SCRUM methodiek. Er bestaan ook normenkaders en auditmodellen, die zich richten op de auditeerbaarheid van het SCRUM ontwikkelproces. Hoewel er meer normenkaders bestaan, zijn in dit hoofdstuk drie normenkaders behandeld, die in verschillende mate zijn aangepast aan de specifieke kenmerken van SCRUM als ontwikkelmethodiek. Zie hieronder voor een schematische weergave van de positionering van deze modellen ten opzichte van elkaar. Ten eerste, het model van Collyer en Manzano (2013) beschrijft hoe aan de huidige normen kan worden


16

voldaan, die worden gehanteerd door een auditor. Ten tweede, het model van Kim et al. (2013) betreft een op SCRUM aangepast audit model. Ten slotte, het model van Trijsenaar en Zalm (2013) betreft een nieuw normenkader wat is ontwikkeld aan de hand van een analyse van de SCRUM ontwikkelmethodiek.

TRADITIONEEL NORMENKADER:

HYBRIDE NORMENKADER:

NIEUW NORMENKADER:

COLLYER EN MANZANO (2013)

KIM ET AL. (2013)

TRIJSENAAR EN ZALM (2013)

SCRUM ONTWIKKELMETHODIEK Figuur 3: Schematische weergave continuüm normenkader SCRUM

Collyer en Manzano (2013) beschrijven een casus waarin een organisatie, die in een strikt gereguleerde markt (medische apparatuur) gebruik maakt van agile ontwikkelmethodieken voor de software, voldoet aan de vereisten die de externe toezichthouder stelt aan o.a. software ontwikkeling. De auteurs beschrijven de gap tussen de uitgangspunten van de watervalmethode en van de agile software methodieken. Op basis van deze paradoxale uitgangspunten komen ze tot de conclusie dat er in feite twee conflicten ontstaan. Ten eerste, in de watervalmethodiek wordt er een vooraf gedefinieerd plan opgesteld aan de hand waarvan ook testplannen kunnen worden uitgewerkt, terwijl in de agile ontwikkelmethodiek tijdens de ontwikkeling nieuwe vereisten en wensen worden verwerkt in de software. Ten tweede, in tegenstelling tot de principes van de watervalmethodiek, wordt er in een omgeving waar agile ontwikkelmethodieken worden toegepast minimale aandacht besteed aan vastlegging van uitgevoerde testwerkzaamheden. Volgens het auditmodel van Collyer en Manzano (2013) kan het eerste conflict opgelost worden door voldoende diepgang te betrachten in de set van vereisten aan het begin van het ontwikkelproces. De auteurs merken op dat het niet zinvol is om het SCRUM team naar eigen inzicht functionaliteiten van de software te laten ontwikkelen. Op basis van de uitgebreide product backlog kan, parallel aan het ontwikkelproces, een hoogover testplan worden opgesteld. Tijdens en na het ontwikkelproces kunnen aanpassingen van het product backlog leiden tot extra testcases. Het tweede conflict wordt ondervangen door bij elke release een ‘verharde’ sprint uit te voeren waarbij ervoor wordt gekozen om voor deze sprint de vereisten, testverslagen en akkoorden wel uitvoerig vast te leggen. Waar Collyer en Manzano (2013) het huidige normenkader ongewijzigd laten en voorstellen om op onderdelen de SCRUM methodiek aan te passen, hebben Kim et al. (2013) een aanpassing gemaakt op het huidige normenkader door specifieke eigenschappen van SCRUM te betrekken in het normenkader. Kim et al. (2013) stellen een driedimensionaal audit model voor, waar ‘audit point’, ‘audit domain’ en


17

‘audit viewpoint’ centraal staan. Het resultaat van hun analyse is de in Tabel 3 opgenomen checklist, waarin enkel de dimensie ‘audit point’ wordt meegenomen. Het ‘audit domain’ heeft betrekking op het audit object, dat in deze context het change management proces is, en het ‘audit viewpoint’ beschrijft het niveau waarop de audit wordt uitgevoerd (proces, product of performance). AUDIT POINT Requirement Definition

Release Plan Architecture Construction

/

BASIC CHECK ITEMS 01. Analyzing current work and checking whether possible solutions to the problem are proposed or not 02. Sufficiency and adequacy of deducing and analyzing users’ requirements 03. Adequacy of use-case model specification level about system function 04. Checking whether conceptual analysis class was deduced sufficiently 05. Checking whether user interface prototyping plan was set fairly 06. Checking whether test plan was set appropriately 01. Checking whether release planning was set appropriately by analyzing requirements 02. Setting repetitive plan and appropriate selection of story for the release 01. Sufficiency and completeness of work and detailed analysis of user’s requirement / design / implementation of functions 02. Sufficient refinement of use-case model 03. Appropriate performance of user interface prototyping 04. Designing for convenience of user interface and its report 05. Sufficiency and appropriateness of refining analysis class and designing class in details 06. Sufficiency and appropriateness of interior / exterior interface analysis / design / implement 07. Appropriate analysis/design/implement of access privileges and control 08. Detailed design for introducing/implementing the component 09. Unit testing 10. Sprint review for each sprint

Tabel 3: Checklist Agile Audit Model Kim et al. (2013)

In tegenstelling tot de normenkaders van Collyer en Manzano (2013) en Kim et al. (2013), hebben Trijsenaar en Zalm (2013) geen gebruik gemaakt van een bestaand normenkader. Zij concluderen in hun uiteenzetting over de wijze waarop agile methodieken in het algemeen en SCRUM in het bijzonder ge-audit kunnen worden, met de stelling: ‘met een auditwerkwijze die aansluit op de controleerbare objecten die in Agile-methoden worden gerealiseerd, zoals Agile-ontwikkeldocumentatie (use cases en burndown charts), de werking van het Agile-proces en de bijbehorende randvoorwaarden en andere projectstuurparameters, kan Agile-softwareontwikkeling goed ge-audit worden’. Hieronder zijn deze vier elementen en de bijbehorende toetsbare items in een tabelvorm weergegeven om inzicht te verschaffen in het normenkader wat Trijsenaar en Zalm (2013) voorstellen: ELEMENT Agile-ontwikkeldocumentatie Werking Agile-proces

Randvoorwaarden Agile-proces

Projectstuurparameters

TOETSBAAR ITEM Use cases (aanwezigheid / accordering / format) Burndown chart Sprint planning meeting Sprint backlogs Sprint retrospective meeting SCRUM team (samenstelling / ervaring) Product owner (senioriteit business vertegenwoordiging) Communicatie SCRUM team en product owner Functionaliteit Kwaliteit

Tabel 4: Agile Audit Model Trijsenaar en Zalm (2013) (in tabelvorm)


18

In dit hoofdstuk zijn drie normenkades behandeld aan de hand waarvan de SCRUM ontwikkelmethodiek kan worden getoetst. De auteurs hebben echter in onvoldoende mate gespecificeerd in welke context en met welk doel deze modellen gehanteerd kunnen worden en daarom verschillen de modellen in de mate waarin deze zijn aangepast aan de specifieke kenmerken van SCRUM als ontwikkelmethodiek. Deze scriptie heeft als doel om een normenkader te ontwikkelen wat door de IT auditor gebruikt kan worden in het kader van de jaarrekeningcontrole om change management volgens de SCRUM methodiek te toetsen. In hoofdstuk 7 wordt aangetoond op welke onderdelen het huidige normenkader niet voldoet en in hoofdstuk 8 wordt een concept normenkader voorgesteld en wordt waar mogelijk gebruik gemaakt van bestaande auditmodellen om de geïdentificeerde ‘gaps’ te dichten.

7

TOETSINGSPUNTEN CHANGE MANAGEMENT

In voorgaande hoofdstukken is achtereenvolgens uiteengezet wat de definities en kernbegrippen van agile en SCRUM zijn en welke variabelen en modellen er zijn ontwikkeld om de SCRUM methodiek meetbaar en toetsbaar te maken. Dit hoofdstuk bevat een analyse aan de hand van de eerder uiteengezette definities van SCRUM om te bepalen in welke mate het huidige normenkader, dat is ontwikkeld op basis van en gericht op de traditionele watervalmethode, kan worden toegepast op een change management proces dat is ingericht volgens de SCRUM methodiek. De spanningsboog tussen de huidige normenkaders en de SCRUM methodiek worden door Boehm en Turner (2005) en Barlow et al. (2011) beschreven door te stellen dat IT governance raamwerken zoals ITIL, CMMI en COBIT structuur geven aan IT ontwikkeling en onderhoud en management processen, maar dat deze raamwerken in een agile omgeving de projectvoortgang hinderen. Waar deze auteurs voor de huidige normenkaders verwijzen naar achtereenvolgens ITIL, CMMI en COBIT, zal in deze scriptie als ‘huidig normenkader’ de beschrijving worden gehanteerd van de uit te voeren controlewerkzaamheden inzake change management, die door een van de BIG-4 kantoren wordt voorgeschreven in de audit methodologie en wordt gebruikt in de jaarrekeningcontrole. Dit normenkader is voor het doel van deze scriptie voldoende, omdat algemeen bekend is dat accountantskantoren deze normenkaders baseren op de hiervoor genoemde IT governance raamwerken en er daarom geen noemenswaardige verschillen zullen bestaan in de door de verschillende BIG-4 kantoren gehanteerde normenkaders. In Bijlage A is het ‘huidige normenkader’ opgenomen, waarbij voor het change management proces per IT General Control de bijbehorende controle procedures zijn uitgewerkt. De IT General Controls en de bijbehorende traditionele controle procedures uit Bijlage A zullen in de onderstaande analyse dienen als leidraad. Ten eerste worden de normen en de traditionele controle


19

procedures beschreven en ten tweede wordt, door middel van ontleding van de procedures, beoordeeld in hoeverre deze kunnen worden uitgevoerd om change management volgens SCRUM te toetsen. Aan de hand hiervan is inzichtelijk gemaakt wat de ‘gaps’ zijn in het huidige normenkader.

7.1

BESCHRIJVING HUIDIG NORMENKADER

In de traditionele software ontwikkelmethodiek wordt er voorafgaand aan de daadwerkelijke ontwikkeling een beschrijving opgesteld van de gewenste functionaliteiten en vereisten van de nieuwe programmatuur in de vorm van een functioneel en technisch ontwerp. Op basis van deze omschrijvingen wordt een inschatting gemaakt van de benodigde tijd en budget, waarna de ontwikkelaars door een verantwoordelijke partij worden geautoriseerd om te starten met de bouw van de gewenste software. Nadat de ontwikkeling is afgerond, worden er testwerkzaamheden uitgevoerd. Op basis van de resultaten van de testwerkzaamheden wordt een vrijgave-advies opgesteld, aan de hand waarvan de applicatie-eigenaar het akkoord geeft of een change wel of niet in productie mag worden genomen. Door de expliciete fasering binnen de traditionele ontwikkelmethodiek is er functiescheiding tussen het autoriseren, ontwikkelen en goedkeuren van changes. Met de normen MC-1, MC-2, MC-3 en MC-5 (zie Tabel 5 en Bijlage A) worden de risico’s afgedekt, dat wijzigingen ongeautoriseerd, zonder testwerkzaamheden en zonder goedkeuring in productie worden genomen door een en dezelfde persoon. Hiermee wordt voorkomen dat ongewenste, niet functionerende, productie verstorende functionaliteiten in gebruik worden genomen. In de traditionele software ontwikkelmethodiek wordt het change management proces gemonitord middels een periodiek overleg in de vorm van bijvoorbeeld een Change Advisory Board. Met de norm MC-4 (zie Tabel 5 en Bijlage A) wordt het risico afgedekt dat er beleidsmatige sturing ontbreekt aan het change management proces en het gebruik van de relevante componenten uit de IT omgeving.

7.2

ANALYSE HUIDIG NORMENKADER

In Tabel 5 is aan de hand van de theoretische uiteenzetting van de definities, het SCRUM proces en de bijbehorende stakeholders uit hoofdstuk 5 enerzijds en aan de hand van het traditionele normenkader uit Bijlage A anderzijds een analyse uitgevoerd om te beoordelen in welke mate de traditionele controle procedures toepasbaar zijn op een change management proces wat volgens de SCRUM methodiek is ingericht. In deze analyse is er voor gekozen om de controle procedures die betrekking hebben op het verzamelen van de populatie en het bepalen van een geschikt sample (ten behoeve van het testen van de werking)


20

te combineren in één aparte stap (omdat deze controle procedures in het traditionele normenkader steeds op een identieke wijze terugkeren in de normen MC-1, MC-2 en MC-3). Naar deze stap zal worden verwezen als ‘MC-START’. CONTROLE PROCEDURES (TRADITIONEEL)

ITGC MC-START: Bepaal de populatie van changes en selecteer een geschikt sample

A. Verzamel een complete lijst (populatie) van changes op relevante componenten uit de IT omgeving voor de periode van het begin van de audit periode tot en met de testdatum door het: Uitlezen van een systemgenerated change log; Opvragen registratie changes;

SCRUM

TOELICHTING In een omgeving waarin de traditionele software ontwikkelmethodiek wordt toegepast, verzamelt de IT auditor een lijst van alle changes, die betrekking hebben op relevante componenten uit de IT omgeving (applicaties in scope van de jaarrekening), en die in de testperiode in productie zijn genomen. Bij voorkeur gebruikt de IT auditor een system-generated change log, dat kan worden uitgelezen. Indien dit niet mogelijk is, wordt er gebruik gemaakt van de change registratie (tool). In beide gevallen moet de IT auditor werkzaamheden verrichten ten aanzien van de volledigheid van de populatie van changes.



In een omgeving waarin de SCRUM ontwikkelmethodiek wordt toegepast en waarin het mogelijk is om een system-generated change log te genereren, kan de IT auditor, om de populatie van changes te bepalen, dezelfde controle procedure uitvoeren als in een omgeving waarin de traditionele software ontwikkelmethodiek wordt toegepast. In een omgeving waarin de SCRUM ontwikkelmethodiek wordt toegepast, maar waarin een dergelijke lijst niet kan worden uitgelezen, moet er een aangepaste controle procedure worden uitgevoerd. Bij de SCRUM ontwikkelmethodiek wordt er gewerkt in iteratieve sprints, die uit meerdere changes opgebouwd kunnen zijn. Omdat de product backlog en de sprint backlog niet statisch zijn (gedurende het SCRUM proces kunnen nieuwe wensen en vereisten worden toegevoegd), kunnen deze niet gebruikt worden om de populatie van changes te bepalen. De traditionele controle procedure is niet volledig toepasbaar in het SCRUM proces: de IT auditor kan niet in alle gevallen de volledigheid van de lijst van in productie genomen changes vaststellen. Deze controle procedure wordt gebruikt als input voor de normen: ‘MC-1: Changes worden geautoriseerd’ (controle procedure 1A/1B); ‘MC-2: Changes worden getest’ (controle procedure 2A); ‘MC-3: Changes worden goedgekeurd’ (controle procedure 3A); In de traditionele software ontwikkelmethodiek wordt aan de hand van de lijst, die is verzameld in controle procedure ‘MC-START’ A, een geschikt sample bepaald. Hierbij wordt 10% van de populatie geselecteerd met een minimum van 5 changes en een maximum van 25 changes.

B. Selecteer een geschikt sample.



MC-1: Changes worden geautoriseerd

A. Stel voor de geselecteerde changes vast dat deze op een geschikte manier zijn geautoriseerd.



Indien er een lijst volledige lijst van changes beschikbaar is (hier wordt de problematiek zoals beschreven in controle procedure ‘MC-START’ A buiten beschouwing gelaten), is deze controle procedure ook toepasbaar in het SCRUM proces. Deze controle procedure wordt gebruikt als input voor de normen: ‘MC-1: Changes worden geautoriseerd’ (controle procedure 1A/1B); ‘MC-2: Changes worden getest’ (controle procedure 2A); ‘MC-3: Changes worden goedgekeurd’ (controle procedure 3A); In de traditionele software ontwikkelmethodiek worden changes door middel van toewijzing van tijd en budget, geautoriseerd door een verantwoordelijke partij. Deze controle procedure is deels toepasbaar in het SCRUM proces: een gedeelte van de changes is besproken en vastgelegd in de product backlog


21

CONTROLE PROCEDURES (TRADITIONEEL)

ITGC

B. Let op: afhankelijk van het beleid van de organisatie kunnen in bepaalde situaties autorisaties niet vereist zijn (bijv. minor change). MC-2: Changes worden getest

MC-3: Changes worden goedgekeurd

MC-4: Changes worden gemonitord

MC-5: Er is voldoende functiescheiding ingericht in het change management proces

A. Stel voor de geselecteerde changes vast dat deze op een geschikte manier zijn getest met als doel om te bevestigen dat de change werkt zoals oorspronkelijk bedoeld.

A. Stel voor de geselecteerde changes vast dat deze zijn goedgekeurd voordat deze in productie worden genomen. A. Verzamel documentatie waaruit blijkt dat het change management proces periodiek wordt gemonitord (periodiek change overleg / periodiek review van in productie genomen changes). A. Stel vast dat, zowel organisatorisch als logisch, verschillende personen de volgende taken binnen het change management proces uitvoeren: Aanvragen / autoriseren van een change;

SCRUM

TOELICHTING en de sprint backlog, die gezamenlijk door IT management, de product owner en het ontwikkelteam zijn vastgesteld en derhalve geautoriseerd. Gedurende het ontwikkelproces worden er nieuwe wensen en vereisten toegevoegd, die minder expliciet zijn geautoriseerd. In de traditionele software ontwikkelmethodiek kan beleidsmatig worden bepaald dat bepaalde changes geen autorisatie vereisen. Hierbij valt te denken aan changes die een beperkte investering behoeven.









Deze opmerking is ook toepasbaar voor het SCRUM proces: gedurende het proces worden aanvullende wensen verwerkt in functionaliteiten zonder dat hiervoor expliciete autorisatie is gegeven. Niet in alle gevallen zullen de aanvullende vereisten, separate autorisatie behoeven gezien de impact en omvang van de investering. De testwerkzaamheden die worden uitgevoerd in de traditionele softwaremethodiek zijn gericht op enerzijds het aantonen dat de nieuwe functionaliteit naar behoren werkt, zoals beschreven in het functioneel en technisch ontwerp (acceptatie testen) en anderzijds het aantonen dat de onaangepaste onderdelen van de software op eenzelfde manier functioneren (regressietesten). Deze controle procedure is om twee redenen niet toepasbaar in het SCRUM proces. Ten eerste, de nadruk bij de testwerkzaamheden in het SCRUM proces liggen voornamelijk op acceptatietesten en ten tweede, uitgevoerde testwerkzaamheden worden niet of nauwelijks vastgelegd. Een IT auditor kan voor geselecteerde changes daarom aan de hand van documentatie niet vaststellen dat deze met voldoende diepgang zijn getest. Zoals weergegeven in Figuur 2, vindt er aan het eind van elke iteratie een sprint review meeting plaats en wordt de ontwikkelde release in productie genomen in de ‘postgame’ fase. Deze fase is bedoeld om de in-productie name van software voor te bereiden. Deze controle procedure is toepasbaar in SCRUM op individuele sprints/releases die meerdere changes kunnen bevatten. Hierbij moet opgemerkt worden dat de ‘postgame’ fase niet in alle beschrijvingen van SCRUM in voldoende mate wordt beschreven, terwijl dit wel de randvoorwaarden schept om ontwikkelde software na goedkeuring in productie te nemen. In het SCRUM proces vinden meerdere typen overleg plaats, zoals weergegeven in Figuur 2: sprint planning meeting, sprint review meeting en eventueel een sprint retrospective meeting. Deze meetings bieden echter onvoldoende handvatten omdat enerzijds er minimale vastlegging plaatsvindt van deze meetings en anderzijds deze meetings zich focussen op de betreffende sprints en minder gericht zijn op de algemene beheersing van het overall change management proces.

Zoals verwoord bij norm ‘MC-1: Changes worden geautoriseerd’ (controle procedure 1A/1B) worden changes impliciet geautoriseerd in het opstellen van het product backlog en sprint backlog door middel van een overleg tussen IT management, de product owner en het ontwikkelteam.



Het ontwikkelteam is verantwoordelijk voor de bouw en de ontwikkeling van de gewenste change. Zoals verwoord bij norm ‘MC-3: Changes worden goedgekeurd’ (controle procedure 3A) is niet in alle SCRUM modellen een aparte fase opgenomen waarin de in-productiename wordt voorbereid. SCRUM schrijft niet voor wie er verantwoordelijk is voor de in-productie name. Zoals verwoord bij norm ‘MC-4: ‘Changes worden gemonitord’’ (controle


22

ITGC

CONTROLE PROCEDURES (TRADITIONEEL) -

-

-

SCRUM

Ontwikkelen van een change; In-productie nemen van ontwikkelde changes; Monitoren van changes;

TOELICHTING procedure 4A) vindt er geen expliciete monitoring plaats van het change management proces. Deze controle procedure is niet toepasbaar op change management volgens SCRUM methodiek. Hoewel er kan worden aangetoond dat er meerdere personen betrokken zijn in het change management proces, kan niet worden aangetoond dat er sprake is van een organisatorisch of logische functiescheiding.

Tabel 5: Analyse controle procedures van het traditionele normenkader ( = traditionele controle procedure wel toepasbaar op SCRUM /  = traditionele controle procedure niet (volledig) toepasbaar op SCRUM)

7.3

‘GAPS’ HUIDIG NORMENKADER

Uit de bovenstaande analyse van de verschillende IT General Controls en de bijbehorende controle procedures blijkt dat het huidige normenkader met controle procedures die gericht zijn traditionele ontwikkelmethodieken niet toereikend is om te worden toegepast op change management volgens de SCRUM methodiek. De analyse toont aan dat dit wordt veroorzaakt door de volgende ‘gaps’:

—

Indien er geen system-generated change log kan worden uitgelezen, kan de volledigheid van de lijst van changes, die in productie zijn genomen in een bepaalde periode, niet worden bepaald aan de hand van de change registratie (tool) (hoewel deze problematiek ook in de traditionele aanpak bestaat, is deze ‘gap’ hier expliciet opgenomen omdat bij de toepassing van de SCRUM ontwikkelmethodiek de volledigheid van de lijst van changes nog moeilijker is vast te stellen en omdat dit een directe impact heeft op de manier waarop selecties voor de testwerkzaamheden van de IT auditor dienen te worden bepaald);

—

De vastlegging van autorisaties van changes, de uitvoering van testwerkzaamheden en het monitoren van het change management proces ontbreken;

—

In de beschrijving van de SCRUM modellen wordt onvoldoende aandacht besteed aan het uitvoeren van regressietesten;

—

De scheiding van taken en verantwoordelijkheden binnen het change management proces kan niet worden aangetoond;

8

CONCEPT NORMENKADER SCRUM VOOR IT AUDITOR

Aan de hand van de definities van SCRUM en de uitwerking van het SCRUM proces, is in het voorgaande hoofdstuk aangetoond dat het huidige normenkader wat gehanteerd wordt om change management volgens de traditionele watervalmethodiek te toetsen, niet toereikend is om toe te passen op een change management proces dat is ingericht volgens de SCRUM principes. In dit hoofdstuk wordt een


23

concept normenkader voorgesteld, aan de hand waarvan de IT auditor in het kader van de jaarrekeningcontrole een uitspraak kan doen over de effectiviteit van het change management proces volgens de SCRUM methodiek. Het voorgestelde concept normenkader in Tabel 6 is opgesteld aan de hand van de ‘gaps’ die in voorgaand hoofdstuk zijn geïdentificeerd en aan de hand van de in de literatuur aangereikte meeteenheden en modellen uit hoofdstuk 6. Voor iedere controle procedure in het voorgestelde concept normenkader is een toelichting opgenomen. De discussie omtrent de praktische toepassing van dit voorgestelde concept normenkader, wordt behandeld in hoofdstuk 9 aan de hand van de vijf uitgevoerde interviews met subject-matter experts.

ITGC MC-START: Bepaal de populatie van changes en selecteer een geschikt sample


CONTROLE PROCEDURE (CONCEPT)

A. Verzamel een complete lijst (populatie) van changes op relevante componenten uit de IT omgeving voor de periode van het begin van de audit periode tot en met de testdatum door: Uitlezen van een system-generated change log; Opvragen registratie changes;

A. Verzamel een complete lijst (populatie) van sprints (en bijbehorende changes) op relevante componenten uit de IT omgeving voor de periode van het begin van de audit periode tot en met de testdatum door: Uitlezen van een system-generated change log en het maken van een indeling van changes per sprint; Opvragen lijst van alle releases, product backlogs, sprint backlogs en tussentijdse changes en na te gaan of alle changes via sprints in productie zijn genomen; B. Selecteer een geschikt sample uit de populatie van sprints.

B. Selecteer geschikt sample.


een

A. Stel voor de geselecteerde changes vast dat deze op een geschikte manier zijn geautoriseerd.

A. Stel voor de geselecteerde sprints vast dat deze tijdens de sprint planning meeting zijn geaccordeerd.

B. Let op: afhankelijk van het beleid van de organisatie kunnen in bepaalde situaties

B. Let op: afhankelijk van het beleid van de methodiek kunnen gedurende de sprints

SCRUM

TOELICHTING Waar in de traditionele software ontwikkelmethodiek per change een nieuw stuk software/nieuwe functionaliteit in productie wordt genomen, gebeurt dit bij de SCRUM ontwikkelmethodiek per sprint. Er zijn twee manieren om de definitieve lijst van sprints (en bijbehorende changes) te bepalen.



De eerste methode betreft het uitlezen van een system-generated change log. Op basis van deze lijst kan inzichtelijk worden gemaakt welke changes in welke sprint in productie zijn genomen. De tweede methode betreft het opvragen van alle releases (die beschreven zijn in de product backlogs), die in nader detail zijn uitgewerkt in de sprint backlogs. Indien de IT auditor kan vaststellen dat er geen changes buiten de sprints in productie zijn genomen, bevat de lijst van sprints alle onderliggende changes.







Aan de hand van de populatie sprints, die is verzameld in controle procedure ‘MCSTART’ A, kan een geschikt sample worden bepaald. Hierbij worden 10% van de populatie van sprints geselecteerd met een minimum van 5 sprints en een maximum van 25 sprints. Aan de hand van de notulen van de sprint planning meeting en de sprint backlogs moet worden vastgesteld dat de sprint is geautoriseerd. Deze controle procedure is o.a. gebaseerd op Trijsenaar en Zalm (2013), die verwijzen naar de toetsbare items om de werking van het Agile proces aan te tonen. Tijdens de sprint kunnen changes worden toegevoegd aan het sprint backlog. Deze changes worden in het overleg tussen de product owner en het SCRUM team


24

ITGC

MC-2: Changes worden getest



autorisaties niet vereist zijn (bijv. minor change).

specifieke changes, worden toegevoegd aan de sprint backlog zonder expliciete autorisatie.

A. Stel voor de geselecteerde changes vast dat deze op een geschikte manier zijn getest met als doel om te bevestigen dat de change werkt zoals oorspronkelijk bedoeld.

A. Stel voor de geselecteerde sprints vast dat een eindgebruiker (met voldoende senioriteit) deel uitmaakt van het SCRUM team.


A. Stel voor de geselecteerde changes vast dat deze zijn goedgekeurd voordat deze in productie worden genomen.

MC-4: Changes worden gemonitord

A. Verzamel documentatie waaruit blijkt dat het change management proces periodiek wordt gemonitord (periodiek change overleg / periodiek review van in productie genomen changes).

B. Stel voor de geselecteerde sprints vast dat bij in-productie name controlewerkzaamheden zijn uitgevoerd om de werking van de kernfunctionaliteiten aan te tonen. A. Stel voor de geselecteerde sprints vast dat deze tijdens de sprint review meeting zijn geaccordeerd. A. Stel vast dat IT management periodiek wordt geïnformeerd over: Kwaliteit van het SCRUM proces (error density / cost of rework / fulfilment of scope); Voortgang (work effectiveness / schedule performance index / cost performance index of labor) costs; B. Stel voor de geselecteerde sprints vast dat IT management aanwezig is bij de sprint planning meeting en de sprint review meeting.

SCRUM











TOELICHTING toegevoegd, waarbij de SCRUM master toezicht houdt op het SCRUM proces. Gezien het beleid van de SCRUM methodiek en de samenstelling van het SCRUM team (zie ook de controle procedures onder MC-5) hoeven dergelijke changes niet expliciet separaat te worden geautoriseerd. Aan de hand van de notulen van de sprint planning meeting en de sprint review meeting moet worden vastgesteld of een eindgebruiker (met voldoende senioriteit) deel uit heeft gemaakt van het SCRUM team. De belangrijkste taak en verantwoordelijkheid van de eindgebruiker is om tijdens de sprints de acceptatietesten uit te voeren. Indien de gebruiker zijn akkoord geeft tijdens de sprint review meeting, betekent dit dat de testen zijn uitgevoerd. De organisatie zal aan de hand van een risicoanalyse de kernfunctionaliteiten van de geautomatiseerde gegevensverwerking in kaart moeten brengen. Bij in-productie name van de software moet bijvoorbeeld een (geautomatiseerd) regressietestscript worden gedraaid. Aan de hand van de notulen van de sprint review meeting moet worden vastgesteld dat de sprint is geaccordeerd. Deze controle procedure is o.a. gebaseerd op Trijsenaar en Zalm (2013), die verwijzen naar de toetsbare items om de werking van het Agile proces aan te tonen. Aan de hand van de door Mahnic en Vrana (2007) en Mahnic en Zabkar (2007, 2008, 2008) geïdentificeerde variabelen omtrent de kwaliteit en de voortgang van het SCRUM proces, kan het IT management periodiek worden geïnformeerd en kan het IT management op basis van deze stuurinformatie het SCRUM proces monitoren.

Aan de hand van de notulen van de sprint planning en review meeting kan worden aangetoond dat IT management aanwezig is en betrokken is bij het ontwikkelproces. Omdat IT management de functie heeft om het change management proces van een hoger niveau te monitoren, kunnen zij in dergelijke meetings relevante informatie leveren.


25

ITGC MC-5: Er is voldoende functiescheiding ingericht in het change management proces



A. Stel vast dat, zowel organisatorisch als logisch, verschillende personen de volgende taken binnen het change management proces uitvoeren: Aanvragen / autoriseren van een change; Ontwikkelen van een change; In-productie nemen van ontwikkelde changes; Monitoren van changes;

A. Stel vast voor de geselecteerde sprints dat de verschillende rollen binnen het SCRUM proces (IT management / product owner / SCRUM master / SCRUM team) zijn ingevuld door de juiste personen: Stel vast dat de SCRUM master gecertificeerd is; Stel vast dat het SCRUM team op een juiste manier is samengesteld en over voldoende senioriteit beschikken; Stel vast dat het SCRUM proces volgens de juiste principes is uitgevoerd (dagelijkse meeting á 5 minuten); B. Stel vast dat personen uit het SCRUM team de ontwikkelde software niet in productie kunnen nemen.

SCRUM

TOELICHTING De norm ‘MC-5: Er is voldoende functiescheiding ingericht in het change management proces’ is opgesteld om het risico af te dekken dat een change door eenzelfde persoon wordt ontwikkeld en in productie kan worden genomen.





Aan de hand van de notulen van de sprint planning meeting en de sprint review meeting kan voor de geselecteerde sprints de samenstelling van het SCRUM team en de SCRUM master worden achterhaald. Op deze manier kan worden vastgesteld of de individuen in het SCRUM team over voldoende senioriteit beschikken. Deze controle procedure is o.a. gebaseerd op Trijsenaar en Zalm (2013), die verwijzen naar de toetsbare items om de werking van het Agile proces aan te tonen. Aan de hand van interviews met de SCRUM master en individuen uit het SCRUM team van de geselecteerde sprints kan worden vastgesteld in welke mate de principes van het SCRUM proces zijn gevolgd, omdat deze principes het toezicht en de communicatie tussen de verschillende teamleden waarborgt. Indien individuen uit het SCRUM team geen mogelijkheid hebben om software in productie te nemen, is er sprake van een duidelijke scheiding tussen de ontwikkelomgeving en de productieomgeving.

Tabel 6: Voorgestelde concept normenkader ( = concept controle procedure in theorie toepasbaar op SCRUM)

In bovenstaande tabel is aan de hand van het huidige normenkader met de ‘traditionele’ controle procedures enerzijds en de geïdentificeerde ‘gaps’ van dit normenkader in hoofdstuk 7 anderzijds, een concept normenkader voorgesteld met controle procedures die in theorie toegepast kunnen worden op een change management proces dat volgens de SCRUM methodiek is ingericht.

9

VALIDATIE NORMENKADER SCRUM VOOR IT AUDITOR

Het voorgestelde concept normenkader dat is gepresenteerd in hoofdstuk 8 is volledig gebaseerd op een theoretische analyse van het huidige normenkaders met de ‘traditionele’ controle procedures enerzijds en een uiteenzetting van de SCRUM principes en methodieken anderzijds. De doelstelling van het onderzoek, namelijk om een normenkader op te stellen dat de IT auditor kan hanteren om change management volgens de SCRUM methodiek te toetsen in het kader van de jaarrekeningcontrole, vereist dat het voorgestelde concept normenkader wordt geconfronteerd met de auditpraktijk. Voor dit


26

onderzoek zijn vijf subject-matter experts geïnterviewd over hun praktijkervaring met het toetsen van change

management volgens de SCRUM methodiek

(al dan niet) in het kader van de

jaarrekeningcontrole. In Tabel 7 zijn de profielen van de geïnterviewde subject-matter experts gepresenteerd: # 1 2 3 4 5

FUNCTIE Senior IT Auditor Senior IT Auditor Partner IT Audit Compliance Officer Manager IT Audit

TITEL RE CISA CIA EMITA RE RA CCS EMITA RA

BEDRIJF Nederlandse vermogensbeheerder BIG-4 kantoor BIG-4 kantoor Nederlandse verzekeringsmaatschappij BIG-4 kantoor

DATUM 02.07.2014 04.07.2014 04.07.2014 15.08.2014 19.08.2014

DUUR 1:05 0:40 1:10 0:45 0:40

TYPE 1 1 2 1 2

Tabel 7: Profielen geïnterviewde subject-matter experts

De subject-matter experts hebben allemaal minimaal 3 jaar IT audit ervaring en zijn allemaal werkzaam binnen de financiële sector (banken, vermogensbeheerders, verzekeraars). Binnen deze groep kan er een onderscheid worden gemaakt tussen IT auditors zonder accountancy-ervaring (type 1) en IT auditors met accountancy ervaring (type 2). Voor dit onderzoek zijn drie IT auditors geïnterviewd die geen relevante ervaring hebben binnen de financiële auditpraktijk (type 1). In deze interviews is ten eerste aandacht besteed aan de casus waarin de geïnterviewden controlewerkzaamheden hebben uitgevoerd om change management volgens de SCRUM methodiek te toetsen in het kader van de jaarrekeningcontrole, de door hen in deze casus toegepaste normenkaders en de voornaamste issues waar zij tegenaan liepen. Ten tweede is het concept normenkader uit hoofdstuk 8 besproken, waarbij voornamelijk aandacht is besteed aan de vaktechnische vereisten en de praktische toepasbaarheid van de voorgestelde concept controle procedures. Daarnaast zijn er twee IT auditors geïnterviewd die wel relevante ervaring hebben binnen de financiële audit praktijk (type 2). De opbouw van de interviews met deze IT auditors heeft zich voornamelijk gericht op de vaktechnische vereisten van de controle procedures die worden uitgevoerd door de IT auditor vanuit het perspectief van de financiële auditpraktijk. De eindverantwoordelijkheid van de uitgevoerde controle procedures ligt immers bij de accountant (RA), die zijn handtekening plaatst onder de controleverklaring waarmee een bepaalde mate van zekerheid wordt gegeven over de getrouwheid van de jaarrekening. Voor dit onderzoek zijn deze auditors geselecteerd vanwege hun relevante werkervaring binnen zowel de financiële auditpraktijk en de IT audit praktijk, omdat zij de impact van de controle procedures van de IT auditor op de jaarrekeningcontrole het beste kunnen inschatten.


27

Aan de hand van de confrontatie tussen het voorgestelde concept normenkader uit hoofdstuk 8, de discussies omtrent de verschillende praktijk casussen en de vaktechnische vereisten van de door de IT auditor uitgevoerde controle procedures is het eindproduct (zie Bijlage B) van dit onderzoek tot stand gekomen in de hier op volgende paragrafen. Om het proces van de totstandkoming van dit eindproduct inzichtelijk te maken, is er voor gekozen om de verschillende normen uit Tabel 6 te hanteren (hoofdstuk 9.2, 9.3, 9.4, 9.4.2, 9.6 en 9.7). Naar aanleiding van de interviews is hier een behandeling omtrent de context aan toegevoegd (hoofdstuk 9.1).

9.1

TYPE ORGANISATIE EN APPLICATIE (MC-CONTEXT)

Zowel het traditionele normenkader als het in hoofdstuk 8 voorgestelde concept normenkader is ontwikkeld op basis van de assumptie dat er sprake kan zijn van een generiek normenkader dat kan worden toegepast in verschillende type organisaties en type IT omgevingen. Echter, in theorie zou elk normenkader toegespitst moeten worden op de change management procedure die door een gebruikersorganisatie op basis van een gedegen risicoanalyse is opgesteld. Uit de interviews bleek bijvoorbeeld dat organisaties vaak een tussenvorm hanteren, waarbij SCRUM principes zijn geïntegreerd in de bestaande change management processen. De IT auditor moet daarom, voordat hij daadwerkelijk testwerkzaamheden uitvoert, een beoordeling uitvoeren van de opzet van het change management proces en hierbij de volgende drie elementen ten minste in acht te nemen: de context van het ‘type organisatie’, het ‘type applicatie’ en de ‘werkwijze en diepgang van documentatie’ die de organisatie hanteert. Hieronder worden deze elementen verder behandeld. Zoals eerder benoemd in dit onderzoek, wordt in toenemende mate binnen organisaties gebruik gemaakt van de SCRUM methodiek in het change management proces. Echter, een IT auditor dient in eerste instantie vast te stellen of de gehanteerde change management procedure in opzet de specifieke risico’s van de betreffende organisatie afdekken. De organisatie-specifieke risico’s worden onder andere bepaald door de aard van het ‘type organisatie’: ‘Als het een bank is waarbij de meest belangrijke applicatie volgens SCRUM wordt ontwikkeld en waarbij niet al te veel vastligt? Dan zou ik inderdaad vanuit het totaalplaatje van risico’s het toch iets zwaarder insteken op een alternatief of extra controlemaatregelen om zekerheid te krijgen, dan wanneer het een jongere onderneming in de software hoek is of dan wanneer het een handelsonderneming is…’ (int. 5) Dit citaat toont overigens ook aan dat niet de afzonderlijke elementen ‘type organisatie’, ‘type applicatie’ en ‘documentatie’ bepalen of SCRUM toepasbaar is in een bepaalde context, maar dat juist de


28

samenhang tussen deze elementen bepalend is voor de beoordeling van de IT auditor van de opzet van het change management proces. In het algemeen zijn de geïnterviewden het er over eens dat het ‘type applicatie’ mede bepaald of SCRUM wel of niet kan worden gehanteerd in de ontwikkeling en het onderhoud van deze applicaties: ‘Als iets bedrijfs-kritisch is, dan is het van belang dat dat ook als criterium wordt meegenomen.’ (int 1) ‘… vandaar dat wij ook voorlopig nog op de watervalmethode blijven hinken met name voor de grotere core applicaties en SCRUM gebruiken voor hele nieuwe ontwikkelingen.’ (int. 4) Ten slotte, in het voorgestelde concept normenkader in hoofdstuk 8 is het uitgangspunt dat er vastlegging plaatsvindt van de product backlogs, de sprint backlogs, de notulen van de sprint planning meetings en de sprint review meetings. Hoewel dit niet volledig volgens de agile principes van Beck et al. (2001) is, vergt het daarom inzet van organisaties die de SCRUM methodiek toepassen in het onderhoud van de kritische applicaties om deze items vast te leggen. De IT auditor zal moeten bepalen of er voldoende handvatten zijn om überhaupt een beoordeling te kunnen uitvoeren: ‘…er is altijd een spoor, ook bij agile of SCRUM. Het is niet excuus om bepaalde documentatie niet op orde te hebben. Het kan aan een andere standaard voldoen of veel beknopter zijn dan het in opzet was voordat agile of SCRUM gebruikt werd. Maar dat doet er niet aan af dat er vastlegging, al dan niet via email moet zijn.’ (int 2) In het traditionele normenkader en in het voorgestelde concept normenkader in hoofdstuk 8 zijn geen separate normen of controle procedures opgenomen, die er toe leiden om de opzet van het change management proces kritisch te beoordelen aan de hand van de context. Derhalve is in het eindproduct van dit onderzoek de norm ‘MC-CONTEXT’ expliciet opgenomen met de bijbehorende controle procedures: ITGC


MC-CONTEXT

CONTROLE PROCEDURE (DEFINITIEF) A. Voer een beoordeling uit van de opzet van het change management proces en besteed hierbij specifieke aandacht aan: Type organisatie; Type applicatie; Werkwijze en diepgang documentatie; Samenhang tussen hierboven genoemde elementen;

SCRUM



Tabel 8: Definitief normenkader ‘MC-CONTEXT’ ( = definitieve controle procedure toepasbaar op SCRUM)


29

9.2

POPULATIE EN SAMPLE (MC-START)

In dit onderzoek en deze analyse is gekozen om de controle procedures, die betrekking hebben op het verzamelen van de populatie en het bepalen van een geschikt sample, te combineren in de stap ‘MCSTART’, omdat deze stap de input betreft voor de ITGC normen MC-1, MC-2 en MC-3. In de controle procedures volgens het traditionele normenkader, vormt de IT auditor een oordeel over de effectieve werking van het change management proces op basis van een willekeurige selectie van changes uit de populatie van changes uit de betreffende audit periode. In het voorgestelde concept normenkader in hoofdstuk 8 zijn er twee manieren geopperd om de populatie te bepalen: de populatie kan worden bepaald aan de hand van een system-generated log of aan de hand van een lijst van alle sprints. In aanvulling hierop werd door de geïnterviewden met een financial audit achtergrond (type 2) geopperd om de populatie op te bouwen aan de hand van programmaplan / changeplan voor het betreffende jaar. Deze drie verschillende manieren van het bepalen van de populatie zijn terug te herleiden naar de manier waarop een change wordt gedefinieerd, namelijk respectievelijk als system change, sprint en projectchange. Hieronder wordt eerst elk van deze werkwijzen behandeld en wordt ten slotte een kritische beschouwing gegeven van de sample selectie voorschriften. Ten eerste, het bepalen van de populatie via een system-generated log is in een beperkt aantal situaties toepasbaar: deze werkwijze kan enkel worden gehanteerd indien het auditobject over een dergelijke functionaliteit beschikt en indien de IT auditor zich ervan heeft vergewist dat de logging betrouwbaar is: ‘… of op een soort log, dat je daarop kan aansluiten. Neemt niet weg dat een log vaak wel lastig leesbaar is. Vraag is: staat dat log ook altijd aan, is het een betrouwbare bron om daar je populatie op te baseren?’ (int. 5) Zelfs indien het praktisch wel mogelijk is om zo’n lijst te genereren en de betrouwbaarheid hiervan vast te stellen, zal er een extra slag moeten worden gemaakt om voor elk van de items in het log te herleiden in welke sprint deze is ontwikkeld, is getest en in productie is genomen. Een tweede manier om de populatie van changes te bepalen is aan de hand van een lijst van sprints die door de organisatie zijn uitgevoerd en die hebben geleid tot de in productie name van nieuwe of bijgewerkte software. Randvoorwaardelijk voor deze aanpak is dat de organisatie maatregelen treft om te waarborgen dat een dergelijke lijst volledig is.


30

‘Een complete lijst van changes is te vergelijken met de complete lijst van de uitgevoerde sprints, al dan niet gerelateerd aan een bepaald product of een bepaalde applicatie, waar je geïnteresseerd in bent. Want een sprint is in feite het verwerken van een aantal user stories.’ (int. 4) Waar het bij de eerste (system-generated log) en de tweede (lijst van sprints) methode voornamelijk van belang is dat er sprake is van een volledige populatie, zodat er aan de hand van een willekeurige selectie kan worden bepaald dat er sprake is van een uniforme werkwijze voor alle typen wijzigingen (groot, klein en spoed), is de derde methode (programmaplan / changeplan) gebaseerd op een risicoperspectief, waarbij er wellicht minder wordt gefocust op het aspect volledigheid: ‘Ja, ik denk dat dat lastig gaat worden. Omdat op zekere hoogte de volledigheid van de populatie als iets van changes, niet te doen is. Ook als wij een lijst zouden krijgen vanuit de organisatie waarop een lijst van alle projecten staat, kun je daarvan in principe nooit de volledigheid vaststellen. Dus ik zou het eerder risico gedreven aanpakken. Wat zijn de kritieke systemen in het kader van de jaarrekening, wat zijn de changes en projecten, waarvan wij op basis van gesprekken met personen van change management bepaald hebben: dit zijn grote projecten of wijzigingen die daarop invloed kunnen hebben. Dan zou ik het meer vanuit daar bepalen.’ (int. 2) ‘Je kunt meer van boven steken, vanuit het programmaplan, wat is het change plan voor dit jaar? Wat gaan we aanpakken? En daarmee pak je de echte grote geplande changes.’ (int. 3) Uiteindelijk zijn alle werkzaamheden die in het kader van de jaarrekeningcontrole uitgevoerd worden door financial auditors en IT auditors en de hierbij gehanteerde strategie en aanpak gericht op de vraag: bevat de jaarrekening een afwijking van materieel belang? Deze derde aanpak ligt in lijn met deze houding: de kans dat een regulier onderhoudsverzoek leidt tot foutieve programmatuur en daarmee tot een dergelijke afwijking is een stuk kleiner dan in het geval van een grote programmawijziging. Echter, om tegemoet te komen aan het volledigheidsaspect en het risico ten aanzien van relatief kleine wijzigingen af te dekken, kan er aanvullend een hygiëne check worden uitgevoerd: ‘Daarvan wil ik wel toetsen of dat op een nette manier gebeurt, dat is weer hygiëne, wordt er geen broddelwerk geleverd, waardoor er dingen insluipen, die niet bedoeld waren.’ (int. 3) De controle procedure voor het bepalen van de populatie van changes is sterk gelinkt aan de controle procedure voor het bepalen van de sample selectie. Zoals benoemd, de eerste twee werkwijzen zijn gericht op de volledigheid van en de uniformiteit binnen de populatie van changes. Om een oordeel te


31

geven over de effectieve werking van het change management proces, is het logisch om een willekeurig sample te selecteren met behulp van een random generator en voor de geselecteerde items te bepalen of deze volgens de voorschriften van de change management procedure in productie zijn genomen. Echter, men zou kunnen beweren dat het toetsen van het change management proces op die manier een doel op zich is geworden en ook in een context, anders dan de jaarrekeningcontrole, gehanteerd kan worden. Daarentegen, de laatste werkwijze is gebaseerd op een risicoanalyse en lijkt derhalve meer geschikt voor de jaarrekeningcontrole. Ten eerste, de selectie is gericht op de key-items en ten tweede, de selectie is erop gericht om te beoordelen of de kernfunctionaliteiten (application controls) van de geautomatiseerde gegevensverwerking ongewijzigd zijn gebleven: ‘Mijn aanpak is meer key-item testing, kijk nou eerst naar de grote programma’s, want daar weet je ook dat er conversiecontroles en functionaliteit controles zijn.’ (int. 3) ‘…dan gaat het om welke functionaliteit is cruciaal en hoe voorkom ik dat die onbedoeld gewijzigd wordt?’ (int. 5) In het voorgestelde concept normenkader in hoofdstuk 8 zijn slechts twee methodes opgenomen om de populatie van changes te bepalen en is de aanname dat de huidige sample selectie voorschriften nog steeds gebruikt kunnen worden. Naar aanleiding van de interviews is er een derde werkwijze voor de populatie bepaling opgenomen en is de koppeling met de controle procedure voor sample selectie aangescherpt: ITGC


CONTROLE PROCEDURE (DEFINITIEF)

MC-START: Bepaal de populatie van changes en selecteer een geschikt sample

A. Verzamel een complete lijst (populatie) van sprints (en bijbehorende changes) op relevante componenten uit de IT omgeving voor de periode van het begin van de audit periode tot en met de testdatum door het: Uitlezen van een system-generated change log en het maken van een indeling van changes per sprint; Opvragen lijst van alle releases, product backlogs, sprint backlogs en tussentijdse changes en nagaan of alle changes via sprints in productie zijn genomen;

A. Verzamel een complete lijst (populatie) van sprints (en bijbehorende changes) op relevante componenten uit de IT omgeving voor de periode van het begin van de audit periode tot en met de testdatum door het: Uitlezen van een system-generated change log en het maken van een indeling van changes per sprint; Opvragen lijst van alle releases, product backlogs, sprint backlogs en tussentijdse changes en nagaan of alle changes via sprints in productie zijn genomen; Opvragen programma changes e.d. en nagaan welke grote programma-changes in productie zijn genomen via SCRUM trajecten; B. Selecteer een geschikt sample uit de populatie van sprints: Indien de populatie tot stand komt door middel van system-generated log of lijst van sprints, bepaal een willekeurig sample volgens traditionele voorschriften; Indien de populatie tot stand komt door middel van een risicoanalyse, bepaal een

B. Selecteer een geschikt sample uit de populatie van sprints;


SCRUM





32

ITGC



SCRUM

sample op basis van key-item testing en selecteer daarnaast items t.b.v. hygiene testing;

Tabel 9: Definitief normenkader ‘MC-START’ ( = definitieve controle procedure toepasbaar op SCRUM)

9.3

AUTORISEREN VAN CHANGES (MC-1)

In de traditionele watervalmethodiek heeft het autoriseren van changes ten eerste betrekking op de expliciete goedkeuring door management om geld en resources toe te wijzen aan een bepaald ontwikkeltraject en ten tweede op het vertalen en vastleggen van de vereisten van de gebruikersorganisatie in een functioneel en technisch ontwerp. Hieronder worden deze twee aspecten in relatie tot het SCRUM proces behandeld en worden ten slotte de verschillende visies belicht (die tijdens de interviews naar voren kwamen) met betrekking tot de autorisatie van sprints in het SCRUM proces. Ten aanzien van de goedkeuring van management, het is niet de primaire taak van een IT auditor om in het kader van de jaarrekeningcontrole een uitspraak te doen over de (effectieve) urenbesteding van het SCRUM team van ontwikkelaars. Echter, aan de hand van de goedkeuring van budgetten kan worden vastgesteld dat er een bepaalde mate van support is vanuit management voor de ontwikkeltrajecten: ‘Het is vanuit de jaarrekening gedachte minder relevant om te weten dat er geen uren besteed zijn aan dingen die niet geaccordeerd zijn.’ (int. 1) ‘Er moet altijd iets aan ten grondslag liggen waarvan je zoiets hebt: dit is de support vanuit het management en we hebben ruimte, budget en resources beschikbaar.’ (int. 2) ‘Ook in de SCRUM methodiek zal iemand die de regie heeft … verantwoording moeten afleggen.’ (int. 5) Het niveau van goedkeuring door management zal veelal op een hoger niveau plaatsvinden en zal niet expliciet worden gegeven voor individuele ontwikkeltrajecten of sprints. In feite moet de IT auditor voor de in stap ‘MC-START’ geselecteerde sprints vaststellen of deze onderdeel uitmaken van een door management goedgekeurd programma, project of andersoortig traject. De vastlegging van de vereisten liggen in de SCRUM methodiek niet vast door middel van een formeel uitgewerkt functioneel of technisch ontwerp, maar is enkel zichtbaar in het wensenlijstje wat door van de gebruikersorganisatie kenbaar wordt gemaakt aan het SCRUM team door middel van de product


33

backlog en de hiervan afgeleide sprint backlog. Indien er formele vastlegging plaatsvindt van de sprint planning meetings kan hiermee de autorisatie van de geselecteerde sprint worden vastgesteld, omdat de sprint backlog tijdens deze meeting wordt bepaald. Het is hierbij voornamelijk van belang om vast te stellen dat de product owner aanwezig is geweest bij de sprint planning meeting: ‘… dat zit in het SCRUM team en in de product owner. Dat is zijn verantwoordelijkheid om te sturen. Om te zorgen dat zij doen wat hij wil.’ (int. 1) De visie van de verschillende geïnterviewden ten aanzien van de autorisatie van sprints, lopen sterk uiteen. Voor deze uiteenzetting worden twee uitersten van het spectrum beschreven. De ene geïnterviewde vindt de toetsing van de autorisatie van sprints door de IT auditor niet relevant en neemt MC-1 niet mee in een normenkader voor SCRUM. Deze zienswijze is gebaseerd op de assumptie dat de werkzaamheden die een IT auditor uitvoert voor ITGC’s MC-2 en MC-3 voldoende waarborgen bieden om een oordeel te kunnen geven over het change management proces: ‘In het kader van de jaarrekening, het enige wat van belang is, is de productie omgeving. Het systeem wat op de productie-omgeving staat, is dat goed?’ (int. 1) De andere geïnterviewde pleit ervoor dat de IT auditor niet enkel toetst of de originele sprint backlog is geautoriseerd, maar dat hij ook vaststelt dat de afwijkingen ten opzichte van de originele backlog (achteraf) zijn geautoriseerd (zie citaat hieronder). Deze zienswijze is juist gebaseerd op het feit dat MC1 wel noodzakelijk is om een oordeel te kunnen geven over het change management proces. Door te kiezen voor een tussenvorm (tussen SCRUM en waterval) wordt ook aan de vereisten van MC-1 voldaan. ‘De product owner moet voor het toevoegen en verwijderen van requirements toestemming geven. Dat is in feite het change management van de sprint backlog.’ (int. 4) De discussie met de geïnterviewden omtrent autorisatie van sprints heeft geleid tot een aantal aanpassingen in het definitieve normenkader voor het toetsen van SCRUM in het kader van de jaarrekening. Ten eerste, er is een splitsing aangebracht in de soorten autorisatie die een IT auditor kan beoordelen bij zijn werkzaamheden en ten tweede is er op basis van de tegenstrijdige zienswijzen een nuancering aangebracht ten aanzien van MC-1. Indien voor een geselecteerde sprint niet kan worden vastgesteld of deze vooraf is geautoriseerd, hoeft niet te betekenen dat de ontwikkelde programmatuur onbetrouwbaar is. Immers, tijdens MC-2 en MC-3 kan de IT auditor vaststellen dat werking van de nieuwe software is getest en is goedgekeurd om in productie te nemen:


34

‘… als je juist een flexibele manier hebt van ontwikkelen, dat je iets zwaarder op het testen gaat zitten, zowel technisch als functioneel.’ (int. 5) ITGC




A. Stel voor de geselecteerde sprints vast dat deze tijdens de sprint planning meeting zijn geaccordeerd.

A. Stel voor de geselecteerde sprints vast dat deze zijn geautoriseerd door: Vast te stellen dat de sprint onderdeel uitmaakt van een door management goedgekeurd programma, project of andersoortig traject; Vast te stellen dat in overleg met de product owner (vertegenwoordiger van de gebruikersorganisatie) en het SCRUM team een sprint backlog is gedefinieerd (op basis van het product backlog); B. Let op: afhankelijk van het beleid / change management procedure van een organisatie kan de expliciete autorisatie voor een sprint backlog ontbreken. Dit hoeft niet per definitie te betekenen dat er sprake is van een ineffectief change management proces. Afhankelijk van MC-2 en MC-3 kan worden vastgesteld dat enkel betrouwbare software in productie wordt genomen;

B. Let op: afhankelijk van het beleid van de methodiek kunnen gedurende de sprints specifieke changes, worden toegevoegd aan de sprint backlog zonder expliciete autorisatie.

SCRUM





Tabel 10: Definitief normenkader ‘MC-1’ ( = definitieve controle procedure toepasbaar op SCRUM)

9.4

TESTEN VAN CHANGES (MC-2)

Hoewel er in het huidige normenkader geen onderscheid wordt gemaakt in verschillende soorten testen, waarvan de IT auditor wil vaststellen of deze zijn uitgevoerd voor de hem geselecteerde changes, wordt in de rest van dit hoofdstuk een onderscheid gemaakt tussen enerzijds functionele testen en anderzijds regressietesten, omdat dit onderscheid in het concept normenkader in hoofdstuk 8 is geïntroduceerd. De twee typen testen worden in de volgende paragrafen behandeld en leiden ieder tot een aparte bijdrage tot het definitieve normenkader voor het toetsen van SCRUM in het kader van de jaarrekening.

9.4.1 FUNCTIONELE TESTEN (MC-2 FUNCTIONEEL) In de beschrijving van de SCRUM ontwikkelmethodiek in hoofdstuk 5.2 is reeds duidelijk geworden dat het testen van de ontwikkelde software geen aparte stap in het SCRUM proces is en dat in de theorie minimaal aandacht wordt besteed aan het testen van de ontwikkelde software. Uit de interviews bleek dat ook in de praktijk de testwerkzaamheden en -documentatie niet altijd op het gewenste niveau worden uitgevoerd en vastgelegd: ‘Testen in het team doen ze in dat team. Dus die mensen gaan testen en daar zitten gebruikers bij en dan wordt er getest. En aan het eind komt er uit: het is goed. Maar je moet nu niet verwachten dat er een


35

testplan ligt vooraf: dit en dit gaan wij testen en achteraf van: dit hebben wij allemaal getest en hier en hier is het script en dat is OK en dat is OK. Het gaat allemaal veel meer mondeling dan dat het gedocumenteerd is.’ (int. 1) ‘Ik denk met name dat dat (testproces) het dominante proces is waar je kunt zien dat er op een Agile manier gewerkt wordt.’ (int. 2) Om alsnog te kunnen vaststellen dat de testwerkzaamheden die worden uitgevoerd in een van de geselecteerde sprints voldoende diepgang hebben, was in het concept normenkader voorgesteld om vast te stellen dat een eindgebruiker met voldoende senioriteit deel uitmaakt van het SCRUM team. De interviews wezen uit er bezwaren zijn tegen een dergelijke controle aanpak van de IT auditor. Ten eerste, in veel gevallen maken eindgebruikers geen deel uit van het SCRUM team, waardoor het uitvoeren van deze controle procedure niet mogelijk is: ‘Het zou mij verbazen als ook de mensen vanuit de business die uiteindelijk akkoord moeten geven deel uitmaken van die SCRUM teams.’ (int.2) ‘Op het moment dat er iemand uit de gebruikersorganisatie bij getrokken wordt, zou je hem eigenlijk lid moeten maken van het SCRUM team, maar dat gebeurt niet.’ (int. 4) Ten tweede, indien de IT auditor wel kan vaststellen dat er een eindgebruiker onderdeel is van het SCRUM team, is dit nog geen garantie voor succes. ‘Testen is gewoon een vak, dus dat is moeilijk. Je hebt niet altijd een testexpert in je team zitten’ (int. 1) ‘Hij werd volledig platgewalst door de business die wel even zijn zin doordrukte. Ieder team is zo sterk als de interactie tussen de actoren.’ (int. 3) Om een bepaalde mate van zekerheid te verkrijgen over de vraag of een geselecteerde sprint is getest, is het dus onvoldoende om achteraf vast te stellen dat een eindgebruiker deel uitmaakte van het SCRUM team. Een oplossing zou kunnen zijn om als auditor deel te nemen aan bepaalde sprint meetings om vast te stellen wat de impact is van de aanwezigheid van een senior eindgebruiker.


36

In hoofdstuk 9.3 is gesproken over een organisatie waar gekozen is voor een tussenvorm van SCRUM en watervalmethodiek. Hierbij is er aan het eind van iedere sprint een formele gebruikersacceptatietest, waarin de ontwikkelde functionaliteiten worden getest. ‘Als je meerdere sprints hebt, dan vindt aan het eind van elke sprint een gebruikersacceptatietest plaats en op het moment dat de sprints samengevoegd worden, dan vindt nog een gebruikersacceptatietest plaats of het hele pakket functioneert zoals jij dat had bedoeld.’ (int. 4) Uit Figuur 2 blijkt dat ook in een change management proces waar SCRUM wordt gehanteerd als ontwikkelmethodiek, dat er sprake is van een ‘postgame’ fase. Hierin wordt de ontwikkelde software naar productie gebracht en wordt er een akkoord gegeven. Echter, het is nagenoeg onmogelijk om een onderbouwd akkoord te geven om software in productie te nemen, zonder dat is aangetoond dat de functionaliteit werkt. ITGC




A. Stel voor de geselecteerde sprints vast dat een eindgebruiker (met voldoende senioriteit) deel uitmaakt van het SCRUM team;

A. Stel voor de geselecteerde sprints vast dat de werking van de ontwikkelde functionaliteit is aangetoond door: Vast te stellen of een eindgebruiker (met voldoende senioriteit) deel heeft uitgemaakt van het SCRUM team (hierbij zal de IT auditor een inschatting moeten maken of de eindgebruiker voldoende inspraak heeft gehad: dit zou kunnen door als IT auditor actief deel te nemen aan het SCRUM proces); Te beoordelen op basis waarvan uiteindelijk is besloten om de ontwikkelde software naar productie te nemen (indien ontwikkelde software zonder onderbouwing naar productie wordt genomen, is er sprake van een ineffectief change management proces);

SCRUM



Tabel 11: Definitief normenkader ‘MC-2 (FUNCTIONEEL)’ ( = definitieve controle procedure toepasbaar op SCRUM)

9.4.2 REGRESSIETESTEN (MC-2 REGRESSIE) In de beschrijving van de controle procedures voor het bepalen van het sample ten behoeve van het definitieve normenkader in hoofdstuk 9.2 is reeds benoemd dat de werkzaamheden die een IT auditor in het kader van de jaarrekening uitvoert ten aanzien van het change management proces uiteindelijk erop gericht zijn om te kunnen vaststellen dat de kernfunctionaliteiten (application controls) van de geautomatiseerde gegevensverwerking ongewijzigd zijn gebleven. Waar in de vorige paragraaf de nadruk vooral lag op de testwerkzaamheden die door een organisatie worden uitgevoerd om vast te


37

stellen dat de nieuwe functionaliteiten in de ontwikkelde software op een juiste manier werken, is deze paragraaf gericht op de testwerkzaamheden die door een organisatie worden uitgevoerd om aan te tonen dat de bestaande kernfunctionaliteiten (application controls) niet worden aangetast door de ontwikkelde software. Tijdens de interviews zijn er verschillende methodes besproken, die door organisaties worden gehanteerd om dergelijke regressietesten uit te voeren: ‘Wij doen de regressietesten geautomatiseerd… je definieert wat er in gaat en wat er dan uitkomt. En dat valideer je als dat het goed is. En de volgende dag gooi je dezelfde input er weer in en dan vergelijk je de gevalideerde output file met de output file die je dan krijgt. En zolang die twee dan precies hetzelfde zijn, is alles goed.’ (int. 1) ‘… het liefst geautomatiseerd, gesimuleerd met tools testgevallen voor gemaakt, waardoor, als je de nieuwe software, een nieuwe set componenten, oplevert, dat je het hele zwikje er opnieuw doorheen kunt draaien en daardoor kan vaststellen (want je weet ook wat er uit moet komen, want je hebt de testgevallen gedefinieerd): dit stop ik er in en dit zou er uit moeten komen. Dan weet je precies dat het werkt.’ (int. 3) De scope van de IT auditor die werkzaamheden uitvoert ten aanzien van het change management proces, is in feite zeer beperkt. Indien de IT auditor kan vaststellen dat de regressietest de effectieve werking van de kernfunctionaliteit (application controls) aantoont en indien het mogelijk is om voor de software die is ontwikkeld in de geselecteerde sprints vast te stellen dat de regressietest is uitgevoerd, dan is het zelfs van ondergeschikt belang of de functionele test uit de vorige paragraaf wordt uitgevoerd. Echter, het uitvoeren van een integrale regressietest is een tijdrovende activiteit voor de organisatie en derhalve zal per sprint moeten worden beoordeeld of het nodig is om een dergelijke test uit te voeren: ‘… dat hoort op het moment dat je de nieuwe software integreert met wat je al hebt. Dat is voor mij gewoon een nieuwe versie en afhankelijk, van hoe diep dat wordt geraakt, hoe de architectuur is, moet je een complete regressietest uitvoeren.’ (int. 4) Naar aanleiding van de interviews zijn er een aantal aanpassing gemaakt aan de controle procedures in het definitieve normenkader. Ten eerste, het is cruciaal dat de IT auditor vaststelt dat voor alle kernfunctionaliteiten (application controls) die kritisch zijn vanuit de controle van de jaarrekening, er


38

testgevallen zijn gedefinieerd in de regressietest en dat de testgevallen de risico’s omtrent de kernfunctionaliteit in voldoende mate afdekken. Ten tweede, (voornamelijk als de regressietest handmatig wordt uitgevoerd) voor organisaties kan het een intensieve activiteit zijn om een integrale regressietest uit te voeren, waardoor dit niet voor alle geselecteerde sprints wordt uitgevoerd. In deze gevallen dient de IT auditor te beoordelen in hoeverre er een risico-inschatting is gemaakt door de organisatie. ITGC




B. Stel voor de geselecteerde sprints vast dat bij in-productiename controlewerkzaamheden zijn uitgevoerd om de werking van de kernfunctionaliteiten aan te tonen;

B1. Stel vast dat de door de organisatie gehanteerde regressietest en de uitgevoerde testgevallen de risico’s ten aanzien van de kernfunctionaliteit (application controls) in voldoende mate afdekken; B2. Stel vast voor de geselecteerde sprints dat bij in-productie name een regressietest is uitgevoerd. Indien een dergelijke test niet is uitgevoerd, stel vast in welke mate de ontwikkelde software een impact heeft op de bestaande kernfunctionaliteiten (bij voorkeur op basis van een door de organisatie opgestelde risico-inschatting);

SCRUM



Tabel 12: Definitief normenkader ‘MC-2 (REGRESSIE)’ ( = definitieve controle procedure toepasbaar op SCRUM)

9.5

GOEDKEUREN VAN CHANGES (MC-3)

Zoals eerder aangehaald, blijkt uit Figuur 2 dat er sprake is van een ‘postgame’ fase in de SCRUM ontwikkelmethodiek. In deze fase vindt de daadwerkelijke in productie name plaats. Alle geïnterviewden hebben benadrukt dat de goedkeuring van de in-productie name van nieuw ontwikkelde software ook met SCRUM vereist is: ‘… maar uiteindelijk moet iemand toch zeggen van: ‘OK, dit is wat wij bedacht hebben, dit is hoe de software nu werkt, ik heb een aantal zaken er door heen laten draaien en ik ben er van overtuigd dat het nu goed is en nu geef ik akkoord dat het in productie gaat.’’ (int. 3) De vorm en de frequentie van de accordering is afhankelijk van de manier waarop het SCRUM proces exact is gedefinieerd. Het akkoord voor in-productie name kan plaatsvinden aan het eind van een iteratie van sprints of per sprint en kan worden vastgelegd middels e-mail of middels een change registratietool: ‘… waarbij changes die naar productie gaan via een tool geregistreerd worden …’ (int. 1)


39

‘… nu gaat dat op een verhoogd tempo en zie je dat er minder formele akkoorden bij liggen … die zijn wel terug te vinden, maar heel veel is via e-mail of een akkoord ‘ik heb hem gezien’.’ (int. 2) ‘… ik denk wel dat het er in moet zitten en een goede bron daarvan vind ik de notities van de periodieke meetings.’ (int. 2) ‘… na elke sprint moet er een goedkeuring afgegeven zijn. Ook al maken ze deel uit van een groter geheel.’ (int. 4) In feite zijn de controle procedures die een IT auditor uitvoert voor MC-3 binnen een SCRUM proces niet wezenlijk

anders

dan

hij

uitvoert

binnen

een

change

management

proces

volgens

de

watervalmethodiek. Naar aanleiding van de interviews zijn de controle procedures verruimd: in de praktijk wordt het akkoord niet altijd gegeven binnen de sprint review meeting, maar ook wel in de ‘postgame’ fase. ITGC




A. Stel voor de geselecteerde sprints vast dat deze tijdens de sprint review meeting zijn geaccordeerd.

A. Stel voor de geselecteerde sprints vast dat de hierin ontwikkelde software is goedgekeurd, voordat deze in productie is genomen door: Akkoord in de notulen van de sprint review meeting terug te vinden; Akkoord in een e-mail terug te vinden; Akkoord in change registratie tool terug te vinden;

SCRUM




9.6

MONITOREN VAN CHANGES (MC-4)

In de praktijk komt het voor dat binnen een organisatie geen expliciete IT General Control is ingericht die betrekking heeft op het monitoren van het change management proces: ‘… vraag me af in welke mate je normaal gesproken al een monitoring mogelijkheid hebt als het echt om changes gaat.’ (int. 2) Desondanks kan in dergelijke gevallen toch worden geconcludeerd dat er ‘gesteund’ kan worden op het change management proces in het kader van de jaarrekeningcontrole. Niet alle IT General Controls in het huidige door de IT auditor gehanteerde normenkader lijken dus even zwaar mee te wegen in het eindoordeel over de effectieve werking van het change management proces. Het is voor de IT auditor niet essentieel of een dergelijke control is ingericht, zolang hij kan vaststellen dat er vanuit (IT)


40

management voldoende aandacht is voor (de context van) het change management proces. Deels heeft dit te maken met de in hoofdstuk 9.1 behandelde stap ‘MC-CONTEXT’. In de concept controle procedures die zijn voorgesteld in het normenkader in hoofdstuk 8 zijn een aantal meeteenheden voorgesteld die de IT auditor kan hanteren om vast te stellen dat er periodiek wordt gerapporteerd over de kwaliteit en de voortgang van het SCRUM proces. Hoewel uit de interviews niet naar voren is gekomen dat deze meeteenheden in de praktijk worden gebruikt, zijn ze wel in het definitieve normenkader opgenomen als handreiking voor de IT auditor. Om vast te stellen dat het (IT) management in voldoende mate is betrokken bij het SCRUM ontwikkelproces, was voorgesteld om voor de geselecteerde sprints vast te stellen dat IT management betrokken is bij de sprint review meeting. Echter, verschillende geïnterviewden wezen erop, dat meer nog dan formeel vast te stellen dat IT management aanwezig is, het belangrijk is om een beeld te vormen van de interactie met (IT) management: ‘… en anderzijds moet je ook bij bepaalde projecten echt een klein beetje meedraaien en zal je moeten kijken wat de interne beheersing is rondom zulke projecten …’ (int. 2) ‘ … ik denk het interessant kan zijn en van toegevoegde waarde kan zijn als een auditor anders dan anders, … , veel meer ook te kijken of de dynamiek van het proces deugt.’ (int. 3) Zoals beschreven, is het eerste gedeelte van het concept normenkader voor MC-4 ongewijzigd gebleven. Op basis van de interviews is het tweede gedeelte genuanceerd en is een overweging voor de IT auditor opgenomen om bij het SCRUM proces aanwezig te zijn om op die manier vast te stellen op welke manier (IT) management betrokken is bij het ontwikkelproces: ITGC



MC-4: Changes worden gemonitored

A. Stel vast dat IT management periodiek wordt geïnformeerd over: de kwaliteit van het SCRUM proces (error density / cost of rework / fulfilment of scope); de voortgang (work effectiveness / schedule performance index / cost performance index of labor costs);

A. Stel vast dat IT management periodiek wordt geïnformeerd over: Kwaliteit van het SCRUM proces (error density / cost of rework / fulfilment of scope); Voortgang (work effectiveness / schedule performance index / cost performance index of labor costs);


SCRUM



41

B. Stel voor de geselecteerde sprints vast dat IT management aanwezig is bij de sprint planning meeting en de sprint review meeting.

B. Stel voor de geselecteerde sprints vast dat (een vertegenwoordiger van (IT)) management aanwezig is bij de sprint planning meeting en de sprint review meeting. Voor deze controle procedure kan het noodzakelijk zijn om waarneming ter plaatse toe te passen, in plaats van inspectie van documentatie achteraf.




9.7

FUNCTIESCHEIDING CHANGE MANAGEMENT PROCES (MC-5)

Volgens het traditionele normenkader dient de IT auditor vast te stellen dat er voldoende functiescheiding is ingericht in het change proces. Hierbij wordt specifieke aandacht besteed aan enerzijds de functiescheiding tussen autoriseren en ontwikkeling van software en anderzijds de ontwikkeling en in-productie name. Zoals besproken in hoofdstuk 9.3 is het eerste type functiescheiding vervaagd. Hierdoor komt de nadruk verder te liggen op de functiescheiding tussen ontwikkeling en productie. Dit ligt in lijn met de discussie in hoofdstuk 9.5. In het concept normenkader waren een aantal controle procedures opgesteld, waarbij minder tastbare toetsingselementen met betrekking tot functiescheiding waren besproken, zoals de certificering van de SCRUM master, de samenstelling van het SCRUM team en de mate waarin de principes van SCRUM volgens de SCRUM procesbeschrijvingen werden gevolgd. Uit de interviews kwam naar voren dat deze handvatten niet toereikend zijn om een uitspraak te kunnen doen over de functiescheiding binnen het change management proces: ‘… de certificering vanuit audit perspectief zelf, daar zou ik geen waarde aan hechten … het zegt iets over de competenties van de persoon, maar niets over de beheersing van de systemen en de processen eromheen.’ (int. 2) Daarnaast is in het concept normenkader een controle procedure opgenomen om op technisch niveau vast te stellen dat ontwikkelaars geen toegang hebben tot de productie-omgeving. In lijn met de discussie uit hoofdstuk 9.5 zijn de geïnterviewden het er unaniem mee eens dat een dergelijke strikte scheiding noodzakelijk is: ‘… maar ik denk dat je normaliter wel een stap hebt tussen het sprint team en de productieomgeving, dat daar wel een formele scheiding is …’ (int. 1)


42

‘… ik zou kijken, naar inderdaad, de scheiding tussen OTAP …’ (int. 2) ‘Change en run, daar zit scheiding tussen en die overdracht vindt plaats op het moment dat ontwikkeling een standaard pakket met installatie instructies heeft opgeleverd. Dan wordt het met die instructies op de acceptatie omgeving aangebracht en daar heeft ontwikkeling geen rechten op. En als die instructies goed kloppen, dan gaat het naar productie.’ (int. 4) Uiteindelijk is in het definitieve normenkader voor SCRUM de eerste stap met de ‘softere’ controls niet verwijderd, maar is er bewust voor gekozen om de volgorde van de controle procedures om te draaien, om het kritische karakter van de eerste controle procedure te benadrukken. ITGC




A. Stel vast voor de geselecteerde sprints dat de verschillende rollen binnen het SCRUM proces (IT management / product owner / SCRUM master / SCRUM team) zijn ingevuld door de juiste personen: Stel vast dat de SCRUM master gecertificeerd is; Stel vast dat het SCRUM team op een juiste manier is samengesteld en over voldoende senioriteit beschikken; Stel vast dat het SCRUM proces volgens de juiste principes is uitgevoerd (dagelijkse meeting á 5 minuten); B. Stel vast dat personen uit het SCRUM team de ontwikkelde software niet in productie kunnen nemen.

A. Stel vast dat personen uit het SCRUM team de ontwikkelde software geen toegang hebben tot de productieomgeving en dus niet in staat zijn om de software in gebruik te nemen. Stel voor de geselecteerde sprints vast dat deze in productie zijn genomen door personen die niet in het SCRUM team zitten.

B. Indien mogelijk, stel vast voor de geselecteerde sprints dat de verschillende rollen binnen het SCRUM proces (IT management / product owner / SCRUM master / SCRUM team) zijn ingevuld door de juiste personen: Stel vast dat de SCRUM master gecertificeerd is; Stel vast dat het SCRUM team op een juiste manier is samengesteld en over voldoende senioriteit beschikken; Stel vast dat het SCRUM proces volgens de juiste principes is uitgevoerd (dagelijkse meeting á 5 minuten);

SCRUM





Voor deze controle procedure kan het noodzakelijk zijn om waarneming ter plaatse toe te passen, in plaats van inspectie van documentatie achteraf.


Aan de hand van de discussie omtrent het concept normenkader en de vijf interviews die zijn gevoerd met de subject-matter experts is er een nieuw normenkader ontwikkeld dat kan worden gebruikt door de IT auditor in het kader van de jaarrekeningcontrole om een change management proces te toetsen


43

dat volgens de SCRUM methodiek is ontwikkeld. Het eindresultaat is in feite opgenomen in de tabellen in de hoofdstukken 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, en 9.7, maar is als geheel ook opgenomen in Bijlage B.

10

CONCLUSIE

In hoofdstuk 4 is de problematiek omtrent het toetsen van change management volgens de SCRUM methodiek in het kader van de jaarrekening controle beschreven en zijn op basis hiervan een onderzoeksvraag en bijbehorende deelvragen opgesteld. Deze problematiek is op een systematische wijze geanalyseerd in de hoofdstukken 5 tot en met 9. In dit hoofdstuk is op basis van de uitkomsten van deze analyse een conclusie getrokken door de deelvragen en de onderzoeksvraag te beantwoorden. In aanvulling hierop zijn er aanbevelingen voor vervolgonderzoek geformuleerd.

10.1 BEANTWOORDING DEELVRAGEN Teneinde een antwoord te kunnen geven op de centrale onderzoeksvraag van dit onderzoek, zijn in hoofdstuk 4.3 vijf deelvragen geformuleerd. Hieronder is antwoord gegeven op de verschillende deelvragen. Hoe kan de SCRUM methodiek worden gedefinieerd en wat zijn de relevante kenmerken, uitgangspunten en leading practices? Uit het literatuuronderzoek blijkt dat SCRUM wordt beschouwd als een van de meest voorkomende agile ontwikkelmethodieken, van welke de uitgangspunten door Beck et al. (2001) zijn verwoord in het agile manifesto. Strode (2006) heeft agile gedefinieerd als een software ontwikkelmethodiek die is ontwikkeld voor management en de ondersteuning van een iteratief en incrementeel ontwikkelproces van business systemen, in omgevingen waar verandering constant is, waarbij in kleine teams software wordt geproduceerd door communicatie, feedback, leerervaringen en frequente meetings en waarbij modelleren en documentatie niet een voornaam belang hebben. Hoewel de definities van agile en SCRUM sterk overeenkomen, zijn de unieke kenmerken van SCRUM als verschijningsvorm van agile aangetoond aan de hand van de specifieke procesgang van SCRUM, zoals weergegeven in Figuur 2. Het SCRUM ontwikkelproces begint met het formuleren van wensen en vereisten (product backlog), op basis waarvan vervolgens in een iteratie van sprints software wordt ontwikkeld. Voorafgaand aan iedere sprint wordt in een sprint planning meeting door de product eigenaar bepaald welke items van de product backlog moeten worden ontwikkeld en in de sprint backlog moeten worden opgenomen. De lengte van de sprints varieert tot maximaal 1 kalendermaand, waarbij de SCRUM teamleden in een daily scrum meeting elkaar op de hoogte houden van de voortgang en


44

uitdagingen in de sprint. Een sprint wordt afgesloten met een sprint review meeting, waarin het resultaat van de betreffende sprint wordt gepresenteerd aan de eindgebruikers. Indien er als gevolg van een (iteratie van) sprint(s) software gereed is voor ingebruikname, wordt de software in productie genomen. Welke methoden, variabelen en modellen zijn er ontwikkeld om de SCRUM methodiek meetbaar en toetsbaar te maken? Het doel van dit onderzoek is om een normenkader te ontwikkelen dat door een IT auditor gebruikt kan worden bij de werkzaamheden die in het kader van de jaarrekening worden uitgevoerd om het change management volgens de SCRUM methodiek te toetsen. Uit het literatuuronderzoek blijkt dat er voor verschillende doeleinden zowel meetmodellen als normenkaders zijn ontwikkeld, gericht op het SCRUM proces, waarbij geen afbreuk wordt gedaan aan de principes van SCRUM en agile. Deze meetmodellen en normenkaders zijn uiteengezet om te analyseren in hoeverre deze kunnen worden gebruikt als input voor het eindresultaat van dit onderzoek. De bestaande, op het SCRUM proces gerichte meetmodellen zijn niet primair gericht op de auditeerbaarheid van het proces, maar op het monitoren van (de voortgang) van het ontwikkelproces. In hoofdstuk 6.1 en Tabel 2 is het AGIT model (Mahnic en Vrana, 2007; Mahnic en Zabkar, 2007, 2008, 2008) besproken, waarbij aan de hand van de geïdentificeerde stakeholders en hun belangen de belangrijkste meeteenheden zijn besproken. Er is geprobeerd om een koppeling te maken tussen het AGIT model en het COBIT model (Mahnic en Zabkar, 2007, 2008). Hoewel de koppeling slechts gebaseerd is op een omschrijving van de gehanteerde meeteenheden, biedt het AGIT model handvatten die gebruikt kunnen worden in het eindresultaat van dit onderzoek. In de literatuurstudie zijn drie bestaande, op het SCRUM proces gerichte normenkaders behandeld, die variëren in de mate waarin deze zijn aangepast aan de specifieke kenmerken van SCRUM als ontwikkelmethodiek, maar waarvoor niet expliciet is gespecificeerd in welke context deze kunnen worden gehanteerd. Waar het model van Collyer en Manzano (2013) voornamelijk beschrijft hoe het SCRUM proces kan worden aangepast zodat er aan het traditionele normenkader kan worden voldaan, hebben Kim et al. (2013) en Trijsenaar en Zalm (2013) in verschillende mate het normenkader aangepast aan de SCRUM ontwikkelmethodiek. De uiteenlopende wijzen waarop er wordt omgegaan met het spanningsveld tussen het normenkader en de ontwikkelmethodiek, dient als input voor het eindresultaat van dit onderzoek: de context van de jaarrekening controle bepaalt de mate waarin het


45

gehanteerde normenkader kan worden aangepast aan de ontwikkelmethodiek die door een organisatie wordt gehanteerd. Welke toetsingspunten hanteert een IT auditor ten aanzien van change management in het kader van de jaarrekeningcontrole en in welke mate zijn deze toepasbaar op change management volgens de SCRUM methodiek? In hoofdstuk 4 is op hoofdlijnen de problematiek geïntroduceerd aangaande het toetsen van change management volgens de SCRUM methodiek in het kader van de jaarrekening controle. Teneinde een normenkader te ontwikkelen dat door de IT auditor in deze context kan worden gehanteerd, zijn de toetsingspunten en controle procedures uit het traditionele, op de watervalmethodiek gerichte normenkader geanalyseerd. Door middel van een theoretische uiteenzetting van het traditionele normenkader enerzijds en de theoretische beschrijving en definities van het SCRUM proces uit hoofdstuk 5 anderzijds, is aangetoond dat het traditionele normenkader op vier belangrijke punten (‘gaps’) niet toereikend is voor het toetsen van change management volgens de SCRUM methodiek in het kader van de jaarrekening controle. Ten eerste, indien de mogelijkheid voor het uitlezen van een system-generated change log niet bestaat, kan de volledigheid van de lijst van changes, die in productie zijn genomen in een bepaalde periode, niet worden bepaald aan de hand van de change registratie (tool). Ten tweede, het SCRUM proces dwingt niet af dat er

vastlegging plaatsvindt

van autorisaties van changes, de uitvoering van

testwerkzaamheden en het monitoren van het change management proces. Ten derde, in het SCRUM proces is er onvoldoende aandacht voor de uitvoering van regressietesten (aantoonbaarheid continue werking van kernfunctionaliteiten). Ten slotte, de expliciete aantoonbaarheid van de scheiding van taken en verantwoordelijkheden binnen het change management proces ontbreekt. Hoe ziet het normenkader er uit dat de IT auditor kan hanteren om change management volgens de SCRUM methodiek te toetsen in het kader van de jaarrekeningcontrole? Op basis van de theoretische analyse in hoofdstuk 7 is aangetoond dat de toetsingspunten van het traditionele normenkader op vier belangrijke punten (‘gaps’) niet toereikend zijn om door de IT auditor gehanteerd te kunnen worden om change management volgens de SCRUM methodiek in het kader van de jaarrekening controle te toetsen. In hoofdstuk 8 is in Tabel 6 een concept normenkader gepresenteerd, dat gebaseerd is op de toetsingspunten uit het traditionele normenkader, maar waarbij


46

voor de geïdentificeerde ‘gaps’ aan de hand van de in hoofdstuk 6 besproken meetmodellen en normenkaders alternatieve controle procedures zijn opgesteld. Is het normenkader dat de IT auditor kan hanteren om change management volgens de SCRUM methodiek te toetsen in het kader van de jaarrekeningcontrole toepasbaar in de praktijk? Door middel van interviews, gehouden met verschillende subject-matter experts, die ervaring hebben met het toetsen van change management volgens de SCRUM methodiek, zijn de controle procedures uit het voorgestelde concept normenkader gevalideerd. Hierbij is specifieke aandacht besteed aan zowel de praktische toepasbaarheid van de procedures als de mate waarin wordt voldaan aan vaktechnische vereisten. Middels een systematisch beschouwing van de transcripten van de interviews zijn de controle procedures zodanig bewerkt dat er wordt voldaan aan de aspecten praktische toepasbaarheid en vaktechnische vereisten. Het eindresultaat van dit onderzoek is in onderdelen gepresenteerd in de verschillende paragrafen in hoofdstuk 9 en is als geheel gepresenteerd in Bijlage B.

10.2 BEANTWOORDING ONDERZOEKSVRAAG Op basis van de analyse uit de voorgaande hoofdstukken en de antwoorden op de vijf deelvragen, is hieronder antwoord gegeven op de centrale onderzoeksvraag van deze scriptie: Hoe kan change management (softwareontwikkeling en -onderhoud) volgens de SCRUM methodiek getoetst worden in het kader van de jaarrekeningcontrole teneinde een uitspraak te kunnen doen over de geautomatiseerde gegevensverwerking? Het eindresultaat van dit onderzoek, het gevalideerde normenkader zoals gepresenteerd in Bijlage B, dient als leidraad voor de IT auditor, zodat in het kader van de jaarrekening op een gestructureerde wijze werkzaamheden uitgevoerd kunnen worden ten aanzien van het change management proces volgens de SCRUM methodiek, teneinde een uitspraak te kunnen doen over de geautomatiseerde gegevensverwerking. Om de werkwijze (zoals verwerkt in het gevalideerde normenkader) verder toe te lichten zijn hieronder de vier voornaamste verschillen ten opzichte van het traditionele, op de watervalmethodiek gerichte normenkader beschreven. Ten eerste, in het gevalideerde normenkader in Bijlage B is er een additionele stap opgenomen, waarin de IT auditor zichzelf een oordeel dient te vormen over de opzet van het change management proces


47

volgens de SCRUM methodiek en daarbij vast te stellen, rekening houdend met het type organisatie, het type applicatie en de werkwijze en de diepgang van documentatie van het SCRUM proces, dat de gehanteerde werkwijze inzake het change management proces vanuit een risico perspectief een logische en geschikte werkwijze is. Ten tweede, de controle aanpak van de jaarrekening controle van zowel de financial auditor als de IT auditor is gebaseerd op het identificeren van risico’s (en bijbehorende beheersmaatregelen), die mogelijk kunnen leiden tot een materiële fout in de jaarrekening. In de traditionele controle aanpak van change management wordt door de IT auditor een oordeel gegeven over de effectieve werking van het proces door voor een willekeurig bepaald sample vast te stellen dat er sprake is van een uniforme behandeling van changes conform het change management proces. In het gevalideerde normenkader in Bijlage B is er een controle procedure opgenomen, waarbij de IT auditor op basis van een gedegen analyse de meest kritische changes en projecten identificeert en op basis hiervan het sample voor de testwerkzaamheden bepaald. Ten derde, waar in het traditionele normenkader geen specifieke controle procedure is opgenomen die betrekking heeft op de aantoonbaarheid van de werking van de kernfunctionaliteiten, is in het gevalideerde

normenkader

een

controle

procedure

opgenomen,

die

betrekking

heeft

op

regressietesten. In feite is het voor de IT auditor, wanneer hij werkzaamheden uitvoert in het kader van de jaarrekening controle niet relevant om vast te stellen of het SCRUM proces op een juiste manier is ingericht, zolang de organisatie bij de in productie name van nieuwe software aantoonbaar vaststelt dat de kritische kernfunctionaliteiten van de programmatuur ongewijzigd zijn. Ten slotte, in de traditionele controle aanpak van de IT auditor wordt voornamelijk gebruik gemaakt van inspectie van documentatie om op basis daarvan een oordeel te geven over de effectieve werking van het change management proces. Hoewel de essentie van SCRUM niet inhoudt dat er totaal geen aantoonbare vastlegging is, kan de werkwijze van de organisatie ertoe leiden dat de IT auditor proactief dient aan te haken bij belangrijke meetings in het SCRUM proces.

10.3 VERVOLGONDERZOEK In dit onderzoek is een normenkader ontwikkeld dat door de IT auditor kan worden gehanteerd in het kader van de jaarrekening voor het toetsen van change management volgens de SCRUM methodiek. In deze paragraaf zijn twee aanbevelingen voor verder onderzoek geformuleerd.


48

De opzet van dit onderzoek en de validatie van het voorgestelde concept normenkader is voornamelijk kwalitatief van aard en gebaseerd op de input van subject-matter experts, die praktijkervaring hebben met het toetsen van change management volgens de SCRUM methodiek. Door middel van vervolgonderzoek aan de hand van case studies en meer kwantitatieve methodes zal moeten worden aangetoond dat het gevalideerde normenkader voldoende handvatten biedt voor de uitvoering van de toetsingswerkzaamheden ten aanzien van change management volgens SCRUM in de context van de jaarrekening controle, in zowel de financiële sector als andere sectoren. De IT auditor wordt niet enkel ingezet om een oordeel te geven in het kader van de jaarrekening controle, maar ook voor andersoortige controlewerkzaamheden. Zowel uit de literatuurstudie als uit de interviews met de subject-matter experts blijkt dat organisaties de SCRUM ontwikkelmethodiek toepassen om de doorlooptijd van ontwikkeling en onderhoud van (bedrijfs-kritische) applicaties te verkorten. In dergelijke situaties zou een IT auditor in een adviserende rol waarde kunnen toevoegen door zich te richten op de elementen efficiëntie en effectiviteit. In vervolgonderzoek zouden de mogelijkheden hiervoor kunnen worden onderzocht.

11

PERSOONLIJKE REFLECTIE

Een significant deel van de werkzaamheden die ik als IT auditor in de afgelopen jaren heb uitgevoerd bij verschillende klanten binnen de financiële dienstverlening, hebben betrekking gehad op het toetsen van change management in het kader van de jaarrekening controles van de betreffende klanten. Op basis van praktijkervaring, adviezen van collega IT auditors, procesbeschrijvingen bij verschillende klanten en colleges inclusief discussies bij de IT audit opleiding aangaande het change management proces, heb ik mijzelf kundig gemaakt in het uitvoeren van dergelijke werkzaamheden. Veelal heb ik hierbij het normenkader, zoals opgenomen in Bijlage A en geanalyseerd in hoofdstuk 7.2 toegepast. Waar ik voorafgaand aan het schrijven van deze scriptie in de veronderstelling was dat ik de essentie van het normenkader begreep, ben ik mij achteraf bewust van het feit dat ik een tweetal belangrijke leerervaringen heb opgedaan tijdens het uitvoeren van dit onderzoek. Ten eerste, ongeacht van door de klantorganisatie gehanteerde ontwikkelmethodiek, dient de context waarbinnen de audit werkzaamheden worden uitgevoerd als belangrijke variabele te worden meegenomen. In de praktijk ben ik tegengekomen dat bij de werkzaamheden die een IT auditor uitvoert in het kader van de jaarrekening controle ten aanzien van het change management proces onvoldoende rekening wordt gehouden met het perspectief van de specifieke context (de jaarrekening controle). De systematiek van het willekeurig bepaalde sample kan ertoe leiden dat de aandacht komt te liggen op irrelevante changes die niet volledig conform het change management proces worden behandeld, terwijl


49

de IT auditor zich op basis van key-item testing had kunnen richten op grote, relevante wijzigingen binnen de bedrijfs-kritische systemen. Ten tweede, door de kritische analyse van de opzet van de SCRUM ontwikkelmethodiek in het kader van dit onderzoek en door de interviews met de verschillende subject-matter experts, heb ik niet alleen meer kennis opgedaan over deze relatief nieuwe methodiek, maar heb ik ook meer inzicht gekregen in het spanningsveld dat bestaat tussen een door de organisatie gehanteerde ontwikkelmethodiek en het door de IT auditor gehanteerde normenkader. Hoewel de belangen van een organisatie en de aandachtsgebieden van een IT auditor uiteen kunnen lopen, kan het noodzakelijk zijn om in sommige gevallen de werkwijzen op elkaar aan te passen. Het is een uitdaging voor de IT auditor om de organisatie ervan te overtuigen dat de belangrijkste risico’s te allen tijde moeten worden afgedekt, ongeacht de gehanteerde ontwikkelmethodiek.


50

12

LITERATUURLIJST

Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. (2002) Agile Software Development Methods: Review and Analysis, VIT Publications, 478, pp. 1-107 Abrahamsson, P. Warsta, J. Siponen, M.K., and Ronkainen, J. (2003) New Directions on Agile Methods: A Comparative Analysis, Proceedings of the 25th International Conference on Software Engineering, pp. 244-254 Barlow, J.B., Giboney, J.S., Keith, M.J., Wilson, D.W., Schuetzler, R.M., Lowry, P.B., Vance, A. (2011) Overview and Guidance on Agile Development in Large Organizations, Communications of the Association for Information Systems, 29(2), pp. 25-44 Beck, K., Beedle, M., Bennekum, A. van, Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmit, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.C., Mellor, S., Schwaber, K., Sutherland, J., Thomas, D. (2001)

Manifesto for Agile Software Development,

February,

http://agilemanifesto.org/ Beedle, M., Devos, M., Sharon, Y., Schwaber, K., Sutherland, J. (1999) Scrum: A pattern language for hyperproductive software development in: Harrison, N. Foote, B., Rohnert H. (eds.) Pattern Languages of Program Design, New York: Addison-Wesley, pp. 637-651 Boehm, B. and R. Turner (2005) Management Challenges to Implementing Agile Processes in Traditional Development Organizations, IEEE Software, Sept/Oct, pp. 30–39 Collyer, K., Manzano, J. (2013) Being Agile While Still Being Compliant: A Practical Approach For Medical Device Manufacturers, IBM Paper, March, pp. 1-14 Farley, D., Humble, J. (2011) Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation, Boston: Pearson Education Hartmann, D., Dymond, R. (2006) Appropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value, Proceedings of AGILE 2006 Conference, pp. 126-134


51

Highsmit, J. (2002) What is Agile Software Development?, The Journal of Defense Software Engineering, 15(10), pp. 4-9 Highsmith, J. (2002) Agile Software Development Ecosystems, Boston: Addison-Wesley ISACA (2008) IS Standards, Guidelines and Procedures for Auditing and Control Professionals, Information Systems Audit and Control Association, Rolling Meadows ITGI (2007) COBIT v4.1, Information Technology Governance Institute, Rolling Meadows Kim, D.H., Kim, D.S., Koh, C., Kim, H.W. (2013) An Information System Audit Model for Project Quality Improvement by the Agile Methodology, International Journal of Information and Education Technology, 3(3), pp. 295-299 Lee, G., Xia W. (2010) Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field Data on Software Development Agility, MIS Quarterly, 34(1), pp. 87-114 Mahnic, V., Vrana, I. (2007) Using Stakeholders-drive Process Performance Measurement for Monitoring the Performance of a Scrum-based Software Development process, Electrotechnical Review, 74(5), pp. 241-247 Mahnic, V., Zabkar, N. (2007) Introducing CMMI Measurement and Analysis Practices into Scrum-based Software Development Process, International Journal of Mathematics and Computers in Simulation, 1(1), pp. 65-72 Mahnic, V. Zabkar, N. (2008) Assessing Scrum-based Software Development Process Measurement from COBIT Perspective, 12th WSEAS International Conference on COMPUTERS, Heraklion, Greece, July 23-25, 1(1), pp. 589-594 Mahnic, V., Zabkar, N. (2008) Using COBIT Indicators for Measuring Scrum-based Software Development, Transactions on Computers, 7(10), pp. 1605-1617 Martens, M., Veldhuijs, G., Hulstijn, J. (2014) Agile Systeemontwikkeling: een Studie naar Projectsucces in de Financiële Sector, MCA, 2(1), pp. 30-38


52

Rodenburg, J., Vlaanderen, V. (2009) Rol van de IT auditor bij agile systeemontwikkeling, Referaat – Postgraduate IT-audit opleiding, VU Amsterdam, mei 2009, http://www.vurore.nl Schatz, B., Abdelshafi, I. (2005) Primavera Gets Agile: A Successful Transition to Agile Development, IEEE Software, May/June, pp. 36-42 Schellevis, W., Van Dijk, V. (2014) Jaarrekening Controle in het MKB: IT audit Geïntegreerd in de Controle-aanpak, http://www.nba.nl Schwaber, K., Beedle, M. (2002) Agile Software Development with Scrum, New Jersey: Prentice Hall Strode, D. (2005) The Agile Methods: An Analytical Comparison of Five Agile Methods and an Investigation of Their Target Environment, Department of Information Systems, Massey University, Palmerstone North, New Zealand Strode, D. E. (2006) Agile Methods: A Comparative Analysis in: Mann, S., Bridgeman, N. (eds.) Proceedings of the 19th Annual Conference of the National Advisory Committee on Computing Qualifications, pp. 257-264 Strode, D. (2012) A Theory of Coordination in Agile Software Development Projects, Victoria University of Wellington Sulaiman, T., Barton, B., Blackburn, T. (2006) Agile EVM - Earned Value Management in Scrum Projects, Proceedings of AGILE 2006 Conference, pp. 7-16. Takeuchi, H. en Nonaka, I. (1986) The New Product Development Game, Harvard Business Review, Jan/Feb, pp. 137-146 Trijssenaar, M., Zalm, M. van der (2013) Agile-ontwikkelmethoden Auditen, IT Auditor, nr. 3, pp. 10-14 West, D., Grant, T. (2010) Agile Development: Mainstream Adoption Has Changed Agility, Forrester Research, Jan, pp. 1-20 Westerveld, W. (2014) Great engineers attrack great engineers, Informatie, Sept, pp. 34-37


53

Yup, M. (2006) Value Based Extreme Programming, Proceedings of AGILE 2006 Conference, pp. 175184


54

BIJLAGE A: HUIDIG NORMENKADER CHANGE MANAGEMENT (WATERVALMETHODIEK) Zie hieronder voor het ‘huidige normenkader’, waarbij per IT General Control de bijbehorende controle procedures zijn uitgewerkt. Dit normenkader wordt door de IT auditor gebruikt om change management volgens de waterval methodiek te toetsen: IT GENERAL CONTROL (ITGC) MC-1: Changes worden geautoriseerd

CONTROLE PROCEDURES Verzamel een complete lijst van changes op relevante componenten uit de IT omgeving voor de periode van het begin van de audit periode tot en met de testdatum door: Uitlezen van een system-generated change log; Opvragen registratie changes; Selecteer een geschikt sample en stel voor de geselecteerde changes vast dat deze op een geschikte manier zijn geautoriseerd.


MC-3: Changes worden goedgekeurd MC-4: Changes worden gemonitored MC-5: Er is voldoende functiescheiding ingericht in het change management proces

Let op: afhankelijk van het beleid van de organisatie kunnen in bepaalde situaties autorisaties niet vereist zijn (bijv. minor change). Verzamel een complete lijst van changes op relevante componenten uit de IT omgeving voor de periode van het begin van de audit periode tot en met de testdatum. Selecteer een geschikt sample en stel voor de geselecteerde changes vast dat deze op een geschikte manier zijn getest met als doel om te bevestigen dat de change werkt zoals oorspronkelijk bedoeld. Verzamel een complete lijst van changes op relevante componenten uit de IT omgeving voor de periode van het begin van de audit periode tot en met de testdatum. Selecteer een geschikt sample en stel voor de geselecteerde changes vast dat deze zijn goedgekeurd voordat deze in productie worden genomen. Verzamel documentatie waaruit blijkt dat het change management proces periodiek wordt gemonitored (periodiek change overleg / periodiek review van in productie genomen changes). Stel vast dat, zowel organisatorisch als logisch, dat verschillende personen de volgende taken binnen het change management proces uitvoeren: Aanvragen / autoriseren van een change; Ontwikkelen van een change; In-productie nemen van ontwikkelde changes; Monitoren van changes;


55

BIJLAGE B: DEFINITIEF NORMENKADER CHANGE MANAGEMENT (SCRUM METHODIEK) Zie hieronder voor het ‘definitieve normenkader’ dat is ontwikkeld in deze scriptie, waarbij per IT General Control de bijbehorende controle procedures zijn uitgewerkt. Dit normenkader kan door de IT auditor gebruikt worden om change management volgens de SCRUM methodiek te toetsen: ITGC


MC-CONTEXT

A. Voer een beoordeling uit van de opzet van het change management proces en besteed hierbij specifieke aandacht aan: Type organisatie; Type applicatie; Werkwijze en diepgang documentatie; Samenhang tussen hierboven genoemde elementen; A. Verzamel een complete lijst (populatie) van sprints (en bijbehorende changes) op relevante componenten uit de IT omgeving voor de periode van het begin van de audit periode tot en met de testdatum door het: Uitlezen van een system-generated change log en het maken van een indeling van changes per sprint; Opvragen lijst van alle releases, product backlogs, sprint backlogs en tussentijdse changes en nagaan of alle changes via sprints in productie zijn genomen; Opvragen programma changes e.d. en nagaan welke grote programma-changes in productie zijn genomen via SCRUM trajecten; B. Selecteer een geschikt sample uit de populatie van sprints: Indien de populatie tot stand komt door middel van system-generated log of lijst van sprints, bepaal een willekeurig sample volgens traditionele voorschriften; Indien de populatie tot stand komt door middel van een risicoanalyse, bepaal een sample op basis van key-item testing en selecteer daarnaast items t.b.v. hygiene testing; A. Stel voor de geselecteerde sprints vast dat deze zijn geautoriseerd door: Vast te stellen dat de sprint onderdeel uitmaakt van een door management goedgekeurd programma, project of andersoortig traject; Vast te stellen dat in overleg met de product owner (vertegenwoordiger van de gebruikersorganisatie) en het SCRUM team een sprint backlog is gedefinieerd (op basis van het product backlog); B. Let op: afhankelijk van het beleid / change management procedure van een organisatie kan de expliciete autorisatie voor een sprint backlog ontbreken. Dit hoeft niet per definitie te betekenen dat er sprake is van een ineffectief change management proces. Afhankelijk van MC-2 en MC-3 kan worden vastgesteld dat enkel betrouwbare software in productie wordt genomen; A. Stel voor de geselecteerde sprints vast dat de werking van de ontwikkelde functionaliteit is aangetoond door: Vast te stellen of een eindgebruiker (met voldoende senioriteit) deel heeft uitgemaakt van het SCRUM team (hierbij zal de IT auditor een inschatting moeten maken of de eindgebruiker voldoende inspraak heeft gehad: dit zou kunnen door als IT auditor actief deel te nemen aan het SCRUM proces); Te beoordelen op basis waarvan uiteindelijk is besloten om de ontwikkelde software naar productie te nemen (indien ontwikkelde software zonder onderbouwing naar productie wordt genomen, is er sprake van een ineffectief change management proces); B1. Stel vast dat de door de organisatie gehanteerde regressietest en de uitgevoerde testgevallen de risico’s ten aanzien van de kernfunctionaliteit (application controls) in voldoende mate afdekken; B2. Stel vast voor de geselecteerde sprints dat bij in-productie name een regressietest is uitgevoerd. Indien een dergelijke test niet is uitgevoerd, stel vast in welke mate de ontwikkelde software een impact heeft op de bestaande kernfunctionaliteiten (bij voorkeur op basis van een door de organisatie opgestelde risico-inschatting); A. Stel voor de geselecteerde sprints vast dat de hierin ontwikkelde software is goedgekeurd, voordat deze in productie is genomen door: Akkoord in de notulen van de sprint review meeting terug te vinden; Akkoord in een e-mail terug te vinden; Akkoord in change registratie tool terug te vinden; A. Stel vast dat IT management periodiek wordt geïnformeerd over: Kwaliteit van het SCRUM proces (error density / cost of rework / fulfilment of scope); Voortgang (work effectiveness / schedule performance index / cost performance index of labor costs); B. Stel voor de geselecteerde sprints vast dat (een vertegenwoordiger van (IT)) management aanwezig is

MC-START: Bepaal de populatie van changes en selecteer een geschikt sample



MC-3: Changes worden goedgekeurd MC-4: Changes worden gemonitored


56

ITGC

CONTROLE PROCEDURE (DEFINITIEF) bij de sprint planning meeting en de sprint review meeting.


Voor deze controle procedure kan het noodzakelijk zijn om waarneming ter plaatse toe te passen, in plaats van inspectie van documentatie achteraf. A. Stel vast dat personen uit het SCRUM team de ontwikkelde software geen toegang hebben tot de productieomgeving en dus niet in staat zijn om de software in gebruik te nemen. Stel voor de geselecteerde sprints vast dat deze in productie zijn genomen door personen die niet in het SCRUM team zitten. B. Indien mogelijk, stel vast voor de geselecteerde sprints dat de verschillende rollen binnen het SCRUM proces (IT management / product owner / SCRUM master / SCRUM team) zijn ingevuld door de juiste personen: Stel vast dat de SCRUM master gecertificeerd is; Stel vast dat het SCRUM team op een juiste manier is samengesteld en over voldoende senioriteit beschikken; Stel vast dat het SCRUM proces volgens de juiste principes is uitgevoerd (dagelijkse meeting á 5 minuten); Voor deze controle procedure kan het noodzakelijk zijn om waarneming ter plaatse toe te passen, in plaats van inspectie van documentatie achteraf.


57

BIJLAGE C: VRAGENLIJST INTERVIEW IT AUDITOR (RE) Introductie interviewer: -

Introductie Arriën van Deursen;

-

Introductie scriptie ‘TOETSING SCRUM IN HET KADER VAN DE JAARREKENINGCONTROLE’;

-

Benadrukken dat scriptie op eigen naam wordt uitgevoerd;

-

Benadrukken vertrouwelijkheid interviews;

Introductie geïnterviewde: -

Functie / achtergrond / werkervaring;

Definitie SCRUM: -

Kenmerken van SCRUM;

-

Toepassing van SCRUM;

-

Verschillen SCRUM en watervalmethode;

-

Toepassing in JRR controle;

Praktijkcasus: -

Context casus;

-

Beschrijving casus;

-

Documentatie casus;

-

Gehanteerd normenkader in casus;

Concept normenkader (Tabel 6): -

Praktische toepasbaarheid;

-

Vaktechnische vereisten;

-

Volledigheid normenkader;

Overig: -

Aanvullende opmerkingen;


58

BIJLAGE D: VRAGENLIJST INTERVIEW IT AUDITOR (RA/RE) Introductie interviewer: -

Introductie Arriën van Deursen;

-

Introductie scriptie ‘TOETSING SCRUM IN HET KADER VAN DE JAARREKENINGCONTROLE’;

-

Benadrukken dat scriptie op eigen naam wordt uitgevoerd;

-

Benadrukken vertrouwelijkheid interviews;

Introductie geïnterviewde: -

Functie / achtergrond / werkervaring;

Definitie SCRUM -

Kenmerken van SCRUM;

-

Toepassing van SCRUM;

-

Verschillen SCRUM en watervalmethode;

-

Toepassing in JRR controle;

Praktijkcasus -

Context casus;

-

Beschrijving casus;

-

Documentatie casus;

-

Gehanteerd normenkader in casus;

Concept normenkader (Tabel 6) -

Praktische toepasbaarheid;

-


-

Volledigheid normenkader;

Perspectief accountant (RA): -


-

Verantwoordelijkheid (RA versus RE);

Overig: -

Aanvullende opmerkingen;


TOETSING SCRUM IN HET KADER VAN DE JAARREKENINGCONTROLE

Recommend Documents