Requirements Management

Requirements Management Onderzoek naar de kritieke succesfactoren bij het toepassen van requirements management binnen projecten

Vrije Universiteit Amsterdam Faculteit der Economische Wetenschappen en Bedrijfskunde (FEWEB) Afstudeerrichting: Postgraduate IT auditing opleiding De Boelelaan 1105 1081 HV Amsterdam

KPMG IT Advisory

Begeleider Vrije Universiteit: E. Koning (DNB)

Bedrijfsbegeleider: M. Vrins (KPMG)

Auteur: D. Bremmer (KPMG)

Burgemeester Rijnderslaan 10-20 1185 MC Amstelveen

Requirements Management Oktober 2009

Voorwoord Deze scriptie is geschreven in het kader van het afstudeertraject van de Postgraduate IT Audit Opleiding aan de Faculteit der Economische Wetenschappen en Bedrijfskunde (FEWEB) van de Vrije Universiteit Amsterdam. Ik heb ervoor gekozen deze scriptie te schrijven over het onderwerp requirements management binnen IT projecten. Requirements management is een boeiend onderwerp en mijns inziens één van de meest onderschatte kwesties in het bedrijfsleven en daar buiten. In de kern komt requirements management neer op het op een juiste manier vertalen van behoeften van A (vaak de business) naar B (vaak het orgaan dat de oplossing biedt op de behoefte). Deze communicatie blijkt in de praktijk weerbarstig te zijn gezien het grote aantal onderzoeken die telkens in deze richting wijzen wanneer het gaat om faalfactoren van projecten. Dit onderzoek richt zich op wat de succesfactoren zijn in deze vertaalslag. Ik heb dit onderzoek als een unieke manier gezien om het vakgebied requirements management vanuit verschillende perspectieven te bekijken. Ten eerste vanuit de literatuur en vervolgens vanuit de leverende en ontvangende partij in de praktijk. Ten slotte heb ik uitgebreid met deskundige collega’s binnen KPMG over dit onderwerp gepraat. Mijn dank gaat daarom uit naar de verschillende personen die bereid zijn geweest om mee te werken aan dit onderzoek in de vorm van interviews. De interviews hebben een grote bijdrage geleverd aan de uiteindelijke realisatie van de scriptie. Daarnaast wil ik KPMG IT Advisory bedanken, voor de gelegenheid die is geboden om een passende afstudeeropdracht binnen de organisatie uit te voeren. Speciale dank gaat uit naar Evert Koning en Martijn Vrins als scriptiebegeleiders. Evert bedankt voor je kritische en constructieve houding. Martijn, bedankt voor je waardevolle inhoudelijke aanvullingen. Utrecht, oktober 2009

948_Requirements_Management_Bremmer definitief

i


Samenvatting Uit onderzoeken blijken veel projecten te kampen met het niet behalen van hun oorspronkelijke doelstelling in termen van kosten, tijd en kwaliteit ondanks de toegenomen aandacht voor projectbeheersing. Eén van de meest belangrijke succes criteria van het doen slagen van een project is in een vroeg stadium van een project de juiste gebruikers behoeften (requirements) te doorgronden. Gedurende het ontwikkelproces wordt vaak veel tijd in beslag genomen door veranderende gebruikerseisen terwijl de ontwikkelaars al aan het werk zijn. Dit is niet het gevolg van onvoorziene ontwikkelingen in de technologie, maar veel vaker gaat het om ‘voortschrijdend inzicht’ en ‘technische complicaties’. Met andere woorden zaken die te voorzien waren geweest als er beter was nagedacht over de op te leveren functionaliteit. Op basis van literatuurstudie is onderzocht wat de kritieke succesfactoren zijn van een beheerst requirement management proces in een project. Dit is onderzocht voor de algemeen geldende factoren voor requirements management en voor de specifieke factoren vanuit de meest toegepaste projectmanagement methode (PRINCE2) en de twee meest toegepaste systeem ontwikkel methodieken (SDM II; waterval methode en RUP; iteratieve methode). Vanuit de in de literatuurstudie onderkende succesfactoren is een relatie gelegd met Governance model CobiT. Er is een analyse uitgevoerd op de vier CobiT domeinen. Als resultaat is een inventarisatie uitgevoerd binnen de CobiT-processen die relevant zijn voor requirements management binnen projecten. Vervolgens is een analyse en beoordeling uitgevoerd van de control objectives binnen de geselecteerde CobiT processen voor het toetsen van requirements management in projecten. Tenslotte zijn per control objective op een generiek niveau de test activiteiten uitgewerkt. Dit heeft geleidt tot een concept control framework. Vervolgens is met behulp van een case studie een analyse uitgevoerd op het concept control framework met als doel de tekortkomingen en onvolkomenheden te identificeren. Daarnaast is het concept control framework op bruikbaarheid getoetst. De case studie is uitgevoerd bij een project van een verzekeraar waarbij een polisadministratie wordt geïmplementeerd. Het concept control framework is voorgelegd aan betrokkenen van de leverende- en de vragende kant van het project. Het framework is tevens besproken met een senior IT auditor van KPMG. Uit de analyse blijkt dat op basis van de vertaling van de succesfactoren naar control objectives een framework is aangereikt dat als uitgangspunt kan dienen voor een IT auditor. Het framework dient nog wel specifiek gemaakt te worden voor de situatie waarin het framework zal worden gebruikt. Op basis hiervan is een oordeel te geven over de effectiviteit van requirements ontwikkeling en requirements management in IT projecten. Wanneer de aanbevelingen op basis van het specifiek gemaakte concept control framework door het project worden overgenomen vergroot dit de slagingskans om toekomstige projecten met het gewenste resultaat op te leveren. Hierbij dient te worden opgemerkt dat audits vaak achteraf worden uitgevoerd. Dit is te laat om resultaten in het lopende project te bewerkstelligen. Dit kan worden ondervangen door tussentijdse/periodieke project audits uit te voeren, om zo tijdig te kunnen bijsturen.


ii


Inhoudsopgave Voorwoord

i

Samenvatting

ii

Inhoudsopgave

iii

1

Onderzoeksopzet

1

1.1 1.2 1.3 1.4 1.5

Aanleiding en probleemstelling Doelstelling Onderzoeksvraag Methode Opbouw scriptie

1 2 3 3 4

2

Requirements management

5

2.1 2.2 2.3 2.4 2.5 2.6

Wat is een requirement? Verschillende typen requirement documenten Technieken voor requirements verzameling Wat is requirements management? Traceerbaarheid tussen requirements Samenvatting

5 6 8 9 11 11

3

Requirements management binnen IT projecten

13

3.1 3.1.1 3.1.2 3.2 3.2.1 3.2.2 3.2.3 3.3

Projectmanagementmethode PRINCE2 Requirements management binnen PRINCE2 Systeem ontwikkeling methodieken Meest toegepaste systeem ontwikkelingsmethodieken Rational Unified Proces (RUP) System Development Methodology II (SDM-II) Samenvatting

13 14 15 16 16 16 17 18

4

Concept control framework requirements management

19

4.1 4.2 4.3 4.4 4.5

Inleiding CobiT Framework Inventarisatie van te selecteren CobiT-processen Analyse van de relevante control objectives Afronding

19 19 20 20 22

5

Validatie concept control framework

23

5.1 5.2 5.2.1

Inleiding Casestudie Gebruikers requirement

23 23 23


iii


5.2.2 5.2.3 5.2.4 5.3 5.4

Requirements ontwikkeling Requirements management Succesfactoren Concept control framework Conclusie

23 24 25 26 26

6

Conclusie

28

6.1 6.2 6.3

Inleiding Analyse Conclusie

28 28 28

7

Reflectie

30

Literatuurlijst

31

Geïnterviewden en begeleiders

32

Geïnterviewden Begeleiders

32 32

A

Kwaliteitsaspecten NEN-ISO 9126

33

B

PRINCE2

35

B.1 B.2

Faseringen binnen het PRINCE2-procesmodel Componenten van projectmanagement binnen PRINCE2

35 35

C

Verdeling van meest gebruikte systeem ontwikkeling methodieken

37

D

Rational Unified Proces

38

E

SDM II

39

F

CobiT Model

40

G

CobiT concept control framework

42

G.1 G.2

Plan and Organize Acquire and implement

42 48

H

Casestudy

52

H.1 H.2 H.3 H.4

Background Requirement and Solution What went well? Lessons learned?

52 52 54 54


iv


1

Onderzoeksopzet In dit hoofdstuk wordt achtereenvolgens de aanleiding en probleemstelling, de doelstelling, de vraagstelling, de gehanteerde methode en de opbouw van de rapportage besproken.

1.1

Aanleiding en probleemstelling Bij organisaties in de financiële sector (banken en verzekeraars) worden continue nieuwe projecten in een hoog geautomatiseerde omgeving geïnitieerd. De aanleiding voor deze veranderingen zijn uiteenlopend, zoals het vanuit compliance oogpunt moeten voldoen aan nieuwe wet en regelgeving, nieuwe eisen en wensen vanuit de gebruikersorganisatie, introductie van nieuwe producten en het vervangen van complete legacy systemen en architecturen om kosten te reduceren. Veel projecten blijken in de praktijk te kampen met het niet behalen van hun oorspronkelijke doelstelling in termen van kosten, tijd en kwaliteit ondanks de toegenomen aandacht voor projectbeheersing. De belangrijkste oorzaak voor het mislukken van projecten blijkt vaak te liggen in het feit dat projectdoelstellingen ambitieus en complex zijn. Er is veel literatuur beschikbaar over hoe projecten moeten worden gemanaged en hoe de risico’s binnen projecten het beste kunnen worden beheerst. Desondanks weet volgens onderzoek van de Standish Group1 slechts 32% van de projecten het gewenste resultaat te leveren. 44% van de projecten worden opgeleverd met een overschrijding van het budget, de planning of met beperkte functionaliteit. Van 24% van de projecten is gezegd dat projecten voortijdig zijn gestopt en functionaliteit nooit is gebruikt. Eén van de in het rapport opgenomen succes criteria, is in een vroeg stadium van een project de juiste gebruikers behoeften (requirements) te doorgronden. Gedurende het ontwikkelproces wordt vaak veel tijd in beslag genomen door veranderende gebruikerseisen terwijl de ontwikkelaars al aan het werk zijn. Dit is niet het gevolg van onvoorziene ontwikkelingen in de technologie, maar veel vaker gaat het om ‘voortschrijdend inzicht’ en ‘technische complicaties’. Met andere woorden zaken die te voorzien waren geweest als er beter was nagedacht over de op te leveren functionaliteit. Deze scriptie richt zich op het spanningsveld van de vertaling van de gebruikers behoefte naar een technische oplossing. Deze vertaling kenmerkt zich door een hoge complexiteit en onderlinge afhankelijkheid tussen verschillende (nieuwe) functionaliteiten. Deze aspecten worden versterkt wanneer de behoeften gedurende een project veranderen. Daarnaast spelen er tevens verschillende belangen. Een IT organisatie is binnen een project gebaat bij een situatie waarin de vooraf gedefinieerde behoeften zo min mogelijk wijzigen. Daar staat tegenover dat de opdrachtgever van een project in een snel veranderende omgeving vaak flexibiliteit wenst te houden en geen gefixeerde requirements. De opdrachtgever van een IT project komt meestal uit de gebruikersorganisatie (de business) en het zwaartepunt van de uitvoering van een project ligt meestal bij de IT organisatie. Een mogelijk gevaar bestaat dat het project door de IT organisatie als een zuiver technische uitdaging wordt gezien. Het IT project zal dan voor het behalen van de doelstellingen de neiging 1

Standish Group report CHAOS 2009


1


hebben om te sturen op tijd en kosten en niet zozeer op de specifieke behoefte van de gebruikersorganisatie. Daar staat tegenover dat vanuit de gebruikersorganisatie vaak door de conceptuele status van de behoeften (kwaliteit), een vooraf bepaald budget (kosten) en tijdslijn een interessante uitdaging wordt meegegeven. De variabelen tijd en kosten van het project worden vastgezet, waardoor de enige vrijheid van het project kan worden gevonden in de op te leveren kwaliteit of functionaliteit van het product. Tijd en kosten zijn relatief eenvoudig meetbaar en stuurbaar te maken. Het probleem van het meetbaar en stuurbaar maken van kwaliteit ligt al in de definitie ervan besloten. Kwaliteit is in de praktijk een subjectief gegeven, dit wordt voornamelijk veroorzaakt doordat de requirements niet duidelijk gespecificeerd (kunnen) worden en kwaliteit langs veel aspecten gemeten kan worden. Hierbij valt bijvoorbeeld te denken aan de indeling van kwaliteitsaspecten volgens NEN-ISO 9126. De kwaliteitsaspecten zijn ter illustratie opgenomen in bijlage A. De kwaliteit van een product zegt iets over de mate waarop het product voldoet aan de vooraf gestelde acceptatie criteria. Deze acceptatie criteria zijn af te leiden uit de requirements. Hierdoor is ook kwaliteit meetbaar en stuurbaar te maken. De probleemstelling luidt: Succesvol afronden van IT projecten wordt vaak belemmerd doordat de randvoorwaarden voor een beheerst requirements management proces ontbreken, wat nadelig is voor de kwaliteit van de requirements definitie.

1.2

Doelstelling De doelstelling van deze scriptie is om te onderzoeken wat de kritieke succesfactoren zijn van een beheerst requirement management proces in een project. Verder zal worden onderzocht hoe de inrichting van het requirements management proces binnen projecten door de IT auditor kan worden getoetst met behulp van een door dit onderzoek samengesteld concept control framework. De scope van dit onderzoek is de requirements definitie waarmee de behoefte vanuit de gebruikersorganisatie wordt vertaald naar een technisch oplossing en het requirements managent proces dat deze vertaling ondersteunt. In figuur 1 is dit op een hoog niveau weergegeven.

Figuur 1: Requirements management proces binnen projecten


2


1.3

Onderzoeksvraag De onderzoeksvraag van de scriptie luidt: Welke succesfactoren binnen het requirements management proces in de literatuur en praktijk dragen bij aan de ontwikkeling van een control framework om tot een beheerst requirements management proces te komen, waarmee de slagingskans toeneemt om projecten met het gewenste resultaat op te leveren?

Om de onderzoeksvraag te kunnen beantwoorden, dienen de volgende deelvragen te worden beantwoord: a. Wat wordt in de literatuur verstaan onder requirements management en wat is het doel van het requirements management proces? b. Wat zijn de in de literatuur beschreven randvoorwaarden voor een beheerst requirements management proces? c. Welke methodieken worden in de praktijk het meest toegepast om een beheerst requirements management proces binnen projecten te ondersteunen? d. Hoe verhouden deze inzichten zich tot de in CobiT opgenomen algemene normen voor IT Governance en beheersmaatregelen voor IT organisaties om te komen tot een concept control framework? e. Is het in dit onderzoek ontwikkelde concept control framework bruikbaar in de praktijk en welke aanvullende succesfactoren worden vanuit de praktijk benoemd?

1.4

Methode Het onderzoek wordt uitgevoerd door middel van de volgende onderzoeksmethodieken: • •

literatuurstudie; case studie: interviews met projectleiders en betrokkenen van een project binnen een verzekeringsmaatschappij.

De literatuurstudie heeft als doel om inzicht te verschaffen in wat onder requirements management wordt verstaan en wat volgens de literatuur de succesfactoren binnen het requirements management proces zijn. Daarnaast is door middel van interviews en een case studie onderzocht hoe in de praktijk wordt omgegaan met het beheersen van requirements binnen een project. Op basis van de succesfactoren vanuit de literatuur en de casestudie is een concept control framework opgesteld. Dit concept control framework kan door een IT auditor als uitgangspunt worden gebruikt bij het toetsen van een requirements management proces gedurende een project audit.


3


1.5

Opbouw scriptie De opbouw van deze scriptie is als volgt. In hoofdstuk twee wordt ingegaan op requirements ontwikkeling en requirements management. In hoofdstuk drie zal van de meest gebruikte project management- en systeem ontwikkeling methodieken worden beschreven hoe zij het requirementsmanagement proces ondersteunen. De in hoofdstuk twee en drie beschreven succesfactoren van requirements management zijn het uitgangspunt voor een concept control framework dat in hoofdstuk vier wordt beschreven. Dit concept control framework zal doormiddel van een case studie in de praktijk worden gevalideerd. Dit is beschreven in hoofdstuk vijf. Deze scriptie is geschreven in het kader van de IT Audit opleiding aan de Vrije Universiteit van Amsterdam. Om deze reden zal ook stil worden gestaan bij het belang en de gevolgen van dit onderzoek voor het vakgebied IT auditing. Dit wordt in hoofdstuk zes beschreven. Ten slotte wordt in hoofdstuk zeven mijn persoonlijke reflectie beschreven.


4


2

Requirements management In dit hoofdstuk wordt beschreven wat requirements zijn en welke technieken voor handen zijn om requirements inzichtelijk te maken en te documenteren. Deze fase is kort te omschrijven als de requirements ontwikkel fase. Ten slotte wordt beschreven hoe het requirements management proces kan worden ingericht, zodat de ontwikkelde requirements op een gecontroleerde manier kunnen worden beheerd.

2.1

Wat is een requirement? Voordat we naar het requirements management proces kijken moet eerst worden bepaald wat een requirement daadwerkelijk is. In de Van Dale is het engelse woord requirement vertaald als eis/vereiste of behoefte/ benodigdheid. In projecten is het engelse woord requirement al een veel gebruikt begrip, daarom zal in deze scriptie de engelse variant wordt gebruikt. Daarnaast zijn in de literatuur verschillende definities terug te vinden waarin de verklaring van het begrip requirement wordt gegeven. Hieronder worden enkele definities beschreven. Volgens de IEEE Standard2 is een requirement het beste te definiëren als: 1. Een conditie of vermogen dat nodig is voor een gebruiker om een probleem op te lossen of om een doel te behalen. 2. Een conditie of vermogen dat een systeem (onderdeel) moet bereiken of bezitten om te voldoen aan een contract, standaard, specificatie of een ander formeel afgedwongen document. 3. Een gedocumenteerde representatie van een conditie of vermogen zoals in (1) en (2) Een andere definitie is de volgende3: Requirements zijn specificaties van datgene dat moet worden geïmplementeerd. Dit zijn beschrijvingen van hoe het systeem zich moet gedragen. De volgende definitie4 is een combinatie van de twee bovengenoemde en daarom gebruikt voor deze scriptie.

2

IEEE Standard Glossary of Software Engineering Terminology (1990) Requirements Engineering A good practice guide (Sommerville en Sawyer, 1997) 4 Software requirements: practical techniques for gathering and managing (Wiegers, 2005) 3


5


Een uiteenzetting van een behoefte of doelstelling of een conditie of vermogen over wat een product moet bevatten, zodat dit toereikend is om de behoefte of doelstelling van de opdrachtgever te beantwoorden. Vereenvoudigd wil dit zeggen dat het gaat om de vaststelling van de behoeften van een opdrachtgever ten aanzien van een systeem. Hierbij is het van belang de nadruk te houden op de behoeften van de opdrachtgever, zodat niet het risico wordt gelopen gedurende het verloop van het IT project het beschrijven van de technische oplossing van het probleem voorop te stellen. Requirements zijn belangrijk omdat ze de behoeften van de opdrachtgever en de gebruikers weergeven. Dit biedt de basis voor de verdere werkzaamheden binnen een IT project. Goed gedefinieerde requirements geven weer wat de tussen de opdrachtgever/gebruikers en de leverende partij overeengekomen functionaliteit moet bevatten. Dit is een basis voor de verdere werkzaamheden. Daarnaast definiëren requirements “wat” er moet worden opgeleverd en niet het “hoe”. Ten slotte vormen de requirements de basis voor het bepalen van tijd, kosten en de kwaliteit in een project, hierin schuilen tevens de acceptatiecriteria. Verder is naast de betekenis van het begrip requirements ook onderscheid te maken in het niveau van requirements. In de praktijk blijken verschillende belanghebbenden behoefte te hebben aan verschillende niveaus en detaillering van het begrip requirements. De verschillende niveaus die terug zijn te zien in projecten wordt verder beschreven in paragraaf 2.2. Maar een grove indeling is als volgt. Op het hoogste niveau geeft de opdrachtgever/sponsor een projectmanager een projectdoelstelling mee. Dit is voor beide partijen de requirement. Voor gebruikers, analisten en ontwikkelaars is dit niveau van requirements definitie echter te algemeen, zij verwachten een beschrijving waarin veel detail is aangebracht.

2.2

Verschillende typen requirement documenten Het onderstaande requirements model van Wiegers geeft de relaties weer tussen de diverse lagen van requirements (gebruikers en functionele requirements) en tussen de functionele en niet functionele requirements. Daarnaast is per laag aangegeven in welk type document een requirement wordt vastgelegd gedurende het requirements ontwikkel proces.


6


Functional requirements

Non-Functional requirements

Business requirements Visie en Scoping

User requirements

Business rules

Quality attributes Use Case Interfaces Technical requirement

Constrains Functional requirement

Software requirement specifications

Figuur 2: Het requirementmodel, (Wiegers, 2003)

Hieronder zijn enkele van de in bovenstaand model opgenomen type requirements documenten beschreven: •

In het visie en scope document worden de business requirements vastgelegd. De business requirements geven op een conceptueel niveau de behoefte van de organisatie of opdrachtgever weer en waarom die behoefte er is. De business requirements zijn vaak afkomstig van de sponsor van het project, de opdrachtgever, de manager van de toekomstige gebruikers of product ontwikkeling/marketing.

•

In use cases worden de gebruikers requirements vastgelegd. De gebruikers requirements behelzen de doelen of taken van wat de gebruikers wensen te doen met het nieuwe systeem. Per use case wordt vaak 1 proces weergegeven en een voorbeeld hiervan is het proces: “voer een nieuwe polis op” voor een verzekeringsproduct. Verder worden in de use case van een proces de precondities en de actoren vastgelegd. Voor het genoemde voorbeeld is een preconditie dat de gebruiker dient te zijn ingelogd in het systeem voordat een nieuwe verzekeringspolis kan worden ingevoerd. Actoren kunnen gebruikers maar ook ander systemen zijn.

•

Functionele requirements geven weer wat de software functionaliteit is die door de ontwikkelaars dient te worden gebouwd, zodat de gestelde business requirements worden


7


behaald. De functionele requirements zijn gedocumenteerd in de software requirements specificatie. In de software requirements specificatie is zo volledig als nodig de werking van het systeem beschreven. Naast de functionele requirements zijn in de software requirements specificatie ook de niet functionele requirements beschreven. Dit kunnen onder andere de gewenste perfomance van het systeem en de karakteristieken (gebruikersgemak, integriteit, efficiency en robuustheid) zijn. Andere niet functionele requirements zijn de interfaces met andere systemen (bijvoorbeeld communicatie via xml met de gemeentelijke basis administratie) en de design en implementatie beperkingen (de constraints). De constraints schrijven de beperkingen voor waar tot de ontwikkelaar zich aan moeten houden met betrekking tot het ontwerp (bijvoorbeeld de gebruikersinterface) en het bouwen (bijvoorbeeld alleen mogen programmeren in JAVA). Het ontwikkelen van requirements is een iteratief proces, waarbij telkens als een nieuwe functionaliteit wordt gevraagd, terug zal moeten worden gekeken in het scoping document om te bepalen of de functionaliteit tot de scope behoort of niet. Wanneer dit niet het geval is zal de opdrachtgever van het project aan moeten geven of de scope wordt uitgebreid of niet. Deze communicatie over en weer vergt een goede en heldere communicatie tussen de opdrachtgever en de opsteller(s) van de requirements. Het uitbreiden van de scope heeft directe gevolgen voor de planning en het budget. Dit geeft het sturende vermogen van goed gedefinieerde requirements documenten aan. Er kan namelijk niet worden gestuurd op requirements die op meerdere manieren zijn te interpreteren. Zij vormen dan een onvolledige en mogelijk onjuiste basis voor de acceptatiecriteria van het op te leveren systeem.

2.3

Technieken voor requirements verzameling Het opstellen en vaststellen van de requirements is een uitdagend proces, dat moet resulteren in requirements die SMART (specifiek, meetbaar, acceptabel, realistisch en tijdgebonden) en samenhangend zijn. Activiteiten die daarom moeten worden uitgevoerd om requirements vast te stellen zijn5: •

verzamelen van requirements (elicitation);

•

analyseren van requirements (analysis);

•

specificeren van requirements (specification);

•

valideren van requirements (validation).

Deze activiteiten worden per requirements niveau uitgevoerd en hebben invloed op elkaar. Dit heeft te maken met de relaties tussen de niveaus. Business requirements (doelstellingen) geven bijvoorbeeld richting aan de gebruikers requirements (processen). Daarnaast zijn bij de verschillende requirements niveaus verschillende belanghebbenden betrokken (zoals: de

5

Guide to the software engineering body of knowledge (Abran, 2005)


8


stuurgroep/opdrachtgever, de projectmanager, het projectteam) en zijn er meerdere mogelijkheden om de requirements te verzamelen, te weten: 6 •

Modeleren, door middel van een vereenvoudigde weergave van de gewenste behoefte;

•

Document analyse, veel projecten zijn een gevolg van een eerder uitgevoerd project, door document analyse is gebruik te maken van de eerder opgestelde requirements;

•

Checklists, worden gebruikt om te waarborgen dat geen van de belangrijke activiteiten of informatie wordt vergeten;

•

Brainstorming, gedurende brainstormsessie wordt in korte tijd een grote hoeveelheid out-ofthe-box ideeën gegenereerd. Vervolgens worden de ideeën op haalbaarheid beoordeeld;

•

Mind Maps, in een mind map worden grafisch de verbanden binnen een deelgebied weergegeven. Het hoofd onderdeel wordt in het midden weergegeven en alle ideeën en gedachten worden er omheen geordend;

•

Interviews, in een interview wordt direct de mening van verschillende betrokkenen gevraagd. Dit is een van de meest voor de handliggende manieren van informatie verzamelen, maar blijkt in de praktijk niet effectief te zijn.

•

Observatie, door middel van observatie van informatie vastleggen hoe processen lopen.

Het eindresultaat van requirements ontwikkeling is de baseline. Een baseline is een verzameling overeengekomen requirements die de ontwikkelingsfase ingaat. Zoals eerder beschreven heeft onafhankelijk van de manier waarop requirements worden verzameld requirements ontwikkeling een iteratief karakter. Er zijn vaak meerdere slagen nodig om tot de benodigde requirements definitie te komen. De geformuleerde requirements kunnen na de afstemming vervolgens worden beheerd in het requirements management proces. Dit proces wordt in de volgende paragraaf beschreven.

2.4

Wat is requirements management? De in deze scriptie gehanteerde definitie voor requirements management luidt7:

6

Requirements Management: The interface between Requirements Development and all other systems engineering processes (Hood, 2008) 7 The future of requirements management tools (A .Finkelstein and W. Emmerich, 2000)


9


Requirements management is een systeem ontwikkel activiteit die zich bezig houdt met het organiseren, documenteren en groeperen van requirements voor systemen waarbij de focus ligt op het onderhouden van traceerbaarheid van wijzigingen op requirements. Onder requirements management zijn de volgende activiteiten te verstaan: •

Het aftekenen van de requirements baseline. Dit document wordt door alle partijen ondertekend en goedgekeurd als uitgangspunt dat beantwoord aan de in de scoping benoemde behoefte.

•

Het reviewen van requirements wijzigingen en het bepalen van de impact van de wijziging op de overige functionaliteit, het budget en de planning.

•

Het op een gecontroleerde wijze toevoegen van de geaccepteerde wijziging in het bestaande project. Hiervoor is diverse tooling beschikbaar. In hoofdstuk 3 wordt de door ondersteunende tooling voor Rational Unified Proces (RUP) benoemd.

•

Het updaten van projectplannen (scoping documenten) op basis van de nieuw aangeleverde requirements.

•

Onderhandelen van nieuwe afspraken gebaseerd op de voorspelde impact van de gewijzigde requirements.

•

Het traceren van de individuele requirements naar corresponderende design, broncode en testgevallen.

•

Het traceren van de requirements statussen en wijziging activiteiten gedurende het project. Deze activiteit valt samen met de in hoofdstuk 3 verder uitgeschreven verantwoordelijkheid van configuratie management binnen een project/systeem ontwikkel methodiek.

In onderstaande figuur 3 is schematisch weergegeven wat het onderscheid is tussen requirements ontwikkeling en requirements management.


10


Figuur 3: Onderscheidt tussen requirement ontwikkeling en requirement management, (Wiegers, 2003)

2.5

Traceerbaarheid tussen requirements Een belangrijk element van requirements management is het administreren van traceability tussen de requirements. Dit wil zeggen het leggen van verbindingen tussen high level gebruikers requirements en ondergelegen requirements tot aan systeemspecificaties. Zodoende is de herkomst van iedere requirement te traceren. Echter het koppelen van requirements is arbeidsintensief proces en het leggen en onderhouden van traces vereist ervaring.

2.6

Samenvatting Op basis van de bestudeerde literatuur (zie literatuurlijst) wordt hieronder samenvattend weergegeven wat de succes factoren in een beheerst requirements ontwikkeling en requirementsmanagement proces zijn. Nummer Succesfactor S1

Formuleer de acceptatiecriteria voor de requirements zo vroeg mogelijk in het project.

S2

Kwaliteit is voldoen aan de verwachtingen van de opdrachtgever. Om te voorkomen dat het eindresultaat afwijkt van de behoeften van de opdrachtgever (b.v. door scope creep) dienen de ontwikkelde requirements continue te worden vergeleken met de verwachtingen van de opdrachtgever.


11


S3

Om scope creep binnen het project te voorkomen dient bij het ontwikkelen van requirements continue worden afgevraagd of nieuwe functionaliteit nog behoord tot de initiële scope. Requirements dienen bij de oplevering te voldoen aan de in het visie of scope document benoemde behoefte.

S4

Maak voor de verschillende detailniveaus van requirements definiëring verschillende typen documentatie. Aan scoping documentatie (in bijvoorbeeld het project plan) wordt een ander detailleringniveau gesteld dan aan het vastleggen van de gebruikers behoeften (in bijvoorbeeld een use case).

S5

Kwaliteit zit vooral verankerd in de mensen. Zorg ervoor dat medewerkers die verantwoordelijk zijn voor het schrijven van de requirements voldoende ervaring hebben met de processen en de kwaliteitsrichtlijnen.

S6

De requirements dienen SMART (specifiek, meetbaar, acceptabel, realistisch en tijdgebonden) te zijn gedefinieerd.

S7

De opgeleverde requirements dienen te worden gebaselined en door de opdrachtgever te worden ondertekend en goedgekeurd.

S8

De baseline dient het uitgangspunt voor het verdere ontwikkelproces te zijn. Zodoende zijn heldere randvoorwaarden aan de op te leveren functionaliteit gecreëerd in termen van kosten, tijd en de kwaliteit. In de baseline schuilen tevens de acceptatiecriteria (mits ongewijzigd).

S9

Verbindingen tussen high level gebruikers requirements, ondergelegen requirements tot aan systeemspecificaties dienen traceerbaar te zijn.

In het volgende hoofdstuk zal worden beschreven welke projectmanagement en systeem ontwikkel methodieken volgens onderzoek in de praktijk het meeste worden toegepast en hoe zij het requirementsmanagement proces ondersteunen. Hieruit zullen vervolgens specifiek geldende elementen als succesfactoren worden benoemd die in een beheerst requirements management proces te verwachten zijn.


12


3

Requirements management binnen IT projecten Dit hoofdstuk beschrijft de meest voorkomende project management methode en de meest toegepaste systeem ontwikkel methodieken. Verder wordt beschreven op welke manier requirementsmanagement een plek in neemt binnen de beschreven methodieken. In aanvulling op de algemeen geldende succesfactoren voor beheerst requirements management uit hoofdstuk 2 wordt beschreven wat de specifiek geldende succesfactoren voor beheerst requirements management zijn gebruikmakend van de onderzochte methodieken. In onderstaande figuur is een hiërarchische weergave geven van op portfolio-, programma- en projectniveau. Ten slotte is onderaan de figuur kort weergegeven hoe de fasen er op systeem ontwikkel niveau eruit zien.

Figuur 4: Samenhang programma-, project en systeem ontwikkel methode8

In deze scriptie wordt gekeken naar hoe requirements binnen projecten worden gedefinieerd en opgeleverd en hoe systeem ontwikkel methodieken het requirements managementproces ondersteunen. Om te bepalen wat het verschil en het nut van een projectmanagement methode en een systeem ontwikkeling methode is in de volgende paragrafen beschreven wat beiden inhouden.

3.1

Projectmanagementmethode Hieronder volgt allereerst een korte definitie van een project9:

8 9

Programmamanagement leidt tot betere projectresultaten, (KPMG, 2004) Managing successful projects with PRINCE2, (OGC, 2004)


13


Een project is een tijdelijke organisatievorm die nodig is om een uniek en vooraf gedefinieerd product te maken of resultaat te behalen op een vooraf afgesproken tijdstip, gebruikmakend van vooraf vastgestelde middelen. Om een project op een beheerste wijze uit te kunnen voeren, wordt veelal gebruik gemaakt van een projectmanagement methodiek. PRINCE2 is één van de meest bekende en gebruikte methodieken voor projectmanagement en kan bijdragen aan een goede sturing van een project. Volgens een onderzoek van Neering in 2005 onder 46 grote Nederlandse bedrijven wordt binnen 74% van de ondervragende bedrijven gebruik gemaakt van PRINCE210.

3.1.1

PRINCE2 De naam van de projectmanagementmethodiek PRINCE2 is een samenvoeging van PRojects IN Controlled Environments en is een gestructureerde projectmanagement methode ontwikkeld door het Britse Office of Government Commerce. Sinds de introductie in 1989 is PRINCE2 een veel gebruikte methode in zowel de publieke als private sector. De methodiek is gebaseerd op bestaande methoden voor projectmanagement en een groot aantal casestudies in GrootBrittannië. PRINCE2 is daardoor een integrale en universeel bruikbare bundeling van ‘Best Practices’ en hoewel het in eerste instantie is ontwikkeld voor het managen van IT-projecten, is de methode ook toepasbaar op niet IT-projecten. PRINCE211 is een proces georiënteerde benadering, waarbij elk proces is gedefinieerd op basis van input en output, gecombineerd met de specifiek te behalen doelen en activiteiten die moeten worden uitgevoerd om deze doelen te bereiken. De methode beschrijft hoe een project is verdeeld in beheersbare fasen, waardoor gebruik van middelen en regelmatige monitoring van de voortgang gedurende het project mogelijk is. De volgende acht faseringen worden binnen het PRINCE2-procesmodel onderkend: Opstarten van een project, Initiëren van een project, Dirigeren van een project, Managen van faseovergangen, Managen van product, Managen overgangsfasen, Plannen maken en Afsluiten van een project. Naast de acht faseringen worden binnen het PRINCE2-procesmodel de volgende acht componenten en processen als onderdelen van projectmanagement onderkend: Business Case, Organisatie, Plannen, Beheersing, Risicobeheer, Kwaliteitsbeheer, Configuratiebeheer en Wijzigingsbeheer. Ten slotte kent PRINCE 2 drie projectmanagementtechnieken die de handelingen beschrijven die dienen te worden uitgevoerd om de juiste eindproducten op te leveren. Dit zijn Kwaliteitsbeheer, Configuratiebeheer en Wijzigingsbeheer. 10 11

Het IT-methodenlandschap in Nederland anno 2005, (Neering, 2005) Managing successful projects with PRINCE2, (OGC, 2004)


14


De faseringen, componenten en technieken zijn in bijlage B nader uitgewerkt. In de volgende paragraaf wordt beschreven hoe binnen PRINCE2 het requirements management proces is vormgegeven.

3.1.2

Requirements management binnen PRINCE2 De methode PRINCE2 beschikt over drie hulpmiddelen om de veranderende projectomgeving te beheersen12.

3.1.2.1

•

Configuratiebeheer

•

Wijzigingsbeheer

•

Kwaliteitsbeheer

Configuratie beheer Effectief configuratie beheer wordt steeds belangrijker naarmate de omvang van het project toeneemt. Configuratie beheer is noodzakelijk om een groot team in een projectmatige en vaak hectische omgeving samen te laten werken. Door effectief configuratie beheer uit te voeren worden requirements beheerd, wijzigingen op requirements doorgegeven en statussen van de baselines bijgehouden.

3.1.2.2

Wijzigingsbeheer Wijzigingen op requirements worden centraal gemanaged volgens een wijziging beheer proces. Wanneer wijzigingen ter beoordeling aan een centraal orgaan (waarin de belanghebbenden van het project zitting hebben) wordt aangeboden wordt geborgd dat nieuwe of gewijzigde requirements worden geprioriteerd. Daarnaast wordt door effectief wijzigingsbeheer het risico verkleind dat ongeautoriseerde wijzigingen worden doorgevoerd en wijzigingen niet worden verwerkt in de requirements documentatie.

3.1.2.3

Kwaliteitsbeheer Vanuit het kwaliteitsbeheer proces worden standaarden opgesteld voor de binnen het project passende requirements management proces en worden richtlijnen gegeven hoe functionele en niet functionele requirements dienen te worden opgesteld. Verder wordt in het kwaliteitsbeheer proces ook richtlijnen opgegeven voor versie- en wijzigingenbeheer. Deze aspecten zijn van belang om de traceerbaarheid van requirements te waarborgen. Bij de uitvoering van kwaliteitsbeheer activiteiten vormen de richtlijnen de basis voor de beoordeling van producten en processen. De activiteiten zijn onder te verdelen naar de beoordeling op productniveau 12

Project Management Based on Prince2 (van Heemst, 2006)


15


(toetsen of producten: zoals het toetsen of een use case voldoet aan de vooraf opgestelde richtlijnen) of op procesniveau. Voor het meer specialistisch invullen van een project, bijvoorbeeld wanneer het om een IT oplossing gaat wordt PRINCE2 vaak aangevuld met een systeem ontwikkeling methode. In de volgende paragraaf wordt nader ingegaan op de meest toegepaste systeem ontwikkel methodieken en hoe zij zich verhouden tot requirements management.

3.2

Systeem ontwikkeling methodieken De definitie van een systeem ontwikkeling methode13 Een IT-methode die wordt toegepast bij het realiseren van nieuwe informatiesystemen, het (functioneel) aanpassen van reeds ontwikkelde informatiesystemen en/of het parametriseren van pakket- c.q. standaardsoftware. Wanneer een projectmanagementmethodiek (zoals PRINCE2) en een systeem ontwikkeling methode aanvullend worden gebruikt, leidt dit doorgaans tot een versterking van de voordelen van beide methoden.

3.2.1

Meest toegepaste systeem ontwikkelingsmethodieken Op basis van een in 2005 uitgevoerd onderzoek14 naar IT methodieken in Nederland is een selectie gemaakt van de twee meest voorkomende systeem ontwikkeling methodieken. Het onderzoek is gehouden onder 58 organisaties, waarvan 28% in de financiële sector. Uit het onderzoek blijkt dat van de belangrijkste methoden die organisaties gebruiken voor hun ontwikkelingsproces RUP het meest gebruikt wordt (25%) gevolgd door SDM/SDM-II (18%). Van deze methodieken zal nader worden onderzocht op welke manier zij het requirements management proces en changes op het requirements management proces ondersteunen. De volledige verdeling van meest toegepaste systeem ontwikkeling methodieken is verder gevisualiseerd in bijlage C.

3.2.2

Rational Unified Proces (RUP)15 Rational Unified Process of RUP is een iteratief softwareontwikkelingsproces. Dit proces is ontwikkeld in 1998 door een onderdeel van IBM: Rational Software Corporation. RUP is een gestructureerde en schaalbare methode voor softwareontwikkeling, gebaseerd op best practices. Deze best practices bestaan uit standaarden en richtlijnen voor: fasering, 13

Het IT-methodenlandschap in Nederland anno 2005 (Neering, 2005) Het IT-methodenlandschap in Nederland anno 2005 (Neering, 2005) 15 Rational Unified Process, Rational Software Development Company 1998 14


16


activiteiten, producten, disciplines en rollen, gedocumenteerd in een geïntegreerde, toegankelijke website. RUP voorziet in een verdeling van elk project in 4 hoofdfases: de Inceptiefase (Aanvang), Elaboratiefase (Detaillering), Constructiefase (Bouw) en de Transitiefase (Overgang). In bijlage D is een schematische weergave van het RUP procesmodel weergegeven evenals een korte beschrijving van de bovengenoemde fasen. In RUP start de requirements ontwikkeling in de inceptie fase en eindigt in de constructie fase. Binnen RUP is tooling beschikbaar wat het requirements managementproces ondersteund. RUP wordt ondersteund door de door IBM ontwikkelde Rational Tool Suit.

3.2.3

System Development Methodology II (SDM-II)16 SDM-II is een waterval model dat is ontwikkeld door Pandata. De eerste versie van SDM dateert uit de zeventiger jaren en de herziene versie SDM-II dateert uit 1985. Het model kent de volgende faseringen: 1 informatieplanning, 2 definitiestudie, 3 basisontwerp, 4 detailontwerp, 5 realisatie, 6 invoering, 7 gebruik en beheer. In bijlage E is een schematische weergave van het SDM II procesmodel weergegeven evenals een korte beschrijving van de bovengenoemde fasen. Afsluitend van iedere fase wordt in een mijlpaalproduct vastgelegd wat is gedaan en afgesproken. Requirements ontwikkeling is binnen SDM II terug te vinden in de volgende fasen: •

In de informatieplanning fase wordt op hoog niveau onderzocht wat de wensen van de opdrachtgever zijn. De mijlpaalproducten van deze fase zijn de situatieanalyse en het informatieplan.

•

Gedurende de definitiestudie worden de toekomstige systeemaanpassingen beschreven. Dit wordt vastgelegd in de mijlpaalproducten beschrijving systeemeisen en het systeemconcept.

•

In de fase basisontwerp wordt vastgelegd wat het systeem gaat doen in een basis functie/gegevens structuur. Er wordt vastgesteld wat het systeem moet doen en het ontwerp van het systeem wordt in algemene zin vastgesteld.

•

In de detailontwerp fase wordt het basisontwerp uit de voorgaande fasen nader uitgewerkt in een functioneel en een technisch ontwerp.

•

Het uitgangspunt bij het gebruik van een klassieke waterval methode zoals SDM II is dat de requirements op een zeker moment stabiel en gefixeerd zullen zijn.

16

Informatie en de besturing van organisaties (Prakken, 1997)


17


3.3

Samenvatting De PRINCE2 projectmanagement methodiek biedt geen expliciete ondersteuning voor systeem ontwikkeling. Voor een IT-project is dan ook naast PRINCE2 een methode voor systeem ontwikkeling nodig. Voor de eerste fasen heeft PRINCE2 een methode (de business case/feasibility study). Vervolgens kan de systeem ontwikkeling methode hierop worden aangesloten. Hieronder wordt samenvattend weergegeven welke succesfactoren binnen projectmanagement en systeem ontwikkeling methodieken kunnen worden onderkend en die het requirements ontwikkeling en requirements management proces ondersteunen. Nummer Succesfactor S10

Bij de start van een project dient een Business Case aanwezig te zijn die rechtvaardigt waarom het project kan worden gestart.

S11

Configuratie management dient te zijn ingericht, waardoor requirements worden beheerd, wijzigingen op requirements worden doorgegeven en statussen van de baselines bijgehouden.

S12

Wijzigingsbeheer dient te zijn ingericht, waardoor wijzigingen op requirements een standaard proces doorlopen en centraal worden bijgehouden.

S13

Kwaliteitsbeheer dient te zijn ingericht, waardoor standaarden worden opgesteld voor de binnen het project passende requirements structuur. Richtlijnen zijn opgesteld over hoe functionele en niet functionele requirements dienen te worden opgesteld.

S14

Voor iedere projectfase dienen op te leveren producten te zijn gedefinieerd, met duidelijke kwaliteitscriteria, normen en beoordelings- en acceptatierichtlijnen.

S15

(Tussen)Producten dienen zo spoedig mogelijk op de vereiste en afgesproken kwaliteit te worden getoetst, zodat tijdige bijsturing nog mogelijk is.

S16

Ondersteuning door de inzet van de tooling (zoals bijvoorbeeld de Rational Suite) leidt tot standaardisatie en efficiency van requirements management proces.

S17

Afsluitend aan iedere projectfase dient in een mijlpaalproduct te worden vastgelegd wat is gedaan en afgesproken.

Op basis van de in hoofdstuk twee en drie beschreven theorie volgt in het volgende hoofdstuk een beschrijving van een concept control framework, waarin control objectives zijn opgenomen die de succesfactoren in het requirements management proces borgen.


18


4

Concept control framework requirements management

4.1

Inleiding In dit hoofdstuk zal op basis van de uit de literatuurstudie onderkende succesfactoren voor requirementsmanagement in IT projecten en uit normen die vanuit CobiT zijn aangereikt een framework worden samengesteld. In de volgende paragraaf is beschreven hoe dit framework tot stand is gekomen.

4.2

CobiT Framework CobiT staat voor Control Objectives for IT and related Technology en wordt sinds 1994 ontwikkeld door de ISACA (Information Systems Audit and Control Association), de internationale organisatie van gecertificeerde IT-auditors17. Het is ontwikkeld als een generiek toepasbare en breed geaccepteerde standaard voor IT Governance en beheersmaatregelen voor IT organisaties. In CobiT is gekozen voor een procesgeoriënteerde aanpak van interne beheersing. Een proces kan worden gedefinieerd als een verzameling van regelmatig terugkerende, handmatige of geautomatiseerde activiteiten binnen de onderneming, inclusief de bij de activiteiten behorende informatieverwerking. In dit onderzoek is gekozen voor CobiT omdat dit een open standaard is die de IT activiteiten organiseert rond 34 IT processen. Binnen deze processen komen alle belangrijke wereldwijde informatietechnologienormen, waaronder ITIL, CMMI en ISO17799 samen. Voor elk proces heeft CobiT beheersdoelstellingen en corresponderende management richtlijnen. Het CobiT framework is weergegeven in Bijlage F. Hierin is aangegeven hoe de vier CobiT domeinen samenhangen met de 34 IT-processen. Voor elk van de geselecteerde processen heeft CobiT algemene beheersdoelstellingen (highlevel control objectives) opgesteld, die vervolgens uiteenvallen in een aantal specifieke beheerdoelstellingen (detailed control objectives). Wanneer alle high level control objectives worden gehaald, kan worden gesteld dat het proces waarvan de doelstelling onderdeel uitmaakt, wordt beheerst. Hieronder wordt kort toegelicht hoe dit framework tot stand is gekomen. Vanuit het CobiT-framework zijn de volgende activiteiten uitgevoerd die hebben geleid tot een concept control framework. •

Op basis van de in de literatuurstudie onderkende succesfactoren uit hoofdstuk 2 en 3 is een analyse uitgevoerd op de vier CobiT domeinen. Als resultaat is een inventarisatie uitgevoerd binnen de CobiT-processen die relevant zijn voor requirements management binnen projecten.

•

Vervolgens is een analyse en beoordeling uitgevoerd van de control objectives binnen de geselecteerde CobiT processen voor het toetsen van requirements management in projecten.

17

CobiT 4.1 (IT Governance Institute, 2007)


19


De relevantie is bepaald op basis van de in de literatuurstudie onderkende succesfactoren en de opgedane IT audit kennis. •

4.3

Tenslotte zijn per control objective op een hoog niveau de test activiteiten uitgewerkt.

Inventarisatie van te selecteren CobiT-processen In deze paragraaf zijn CobiT-processen gedefinieerd die relevant zijn voor het opzetten van een framework ter beoordeling van requirements management binnen IT projecten. Onderstaand is de opsomming van de vier belangrijkste CobiT-processen gegeven die verder worden uitgewerkt: Binnen het domein Plan and Organize zijn de volgende processen als relevant voor requirements management binnen IT projecten geselecteerd. •

PO8 Manage Quality

•

PO10 Manage Projects

Binnen het domein Acquire and Implement zijn de volgende processen als relevant voor requirements management binnen IT projecten geselecteerd.

4.4

•

AI1 Identify automated solutions

•

AI2 Acquire and maintain application software

Analyse van de relevante control objectives In de volgende stap is binnen deze geselecteerde processen, op basis van een risico analyse, de relevantie bepaalt van de onderliggende detailed objectives. In het control framework is dit voor PO10 Manage Projects als volgt weergegeven: High Level Control objectives A programme and project management framework for the management of all IT projects is established. The framework ensures the correct prioritisation and co-ordination of all projects. The framework includes a master plan, assignment of resources, definition of deliverables, approval by users, a phased approach to delivery, QA, a formal test plan, and testing and post-implementation review after installation to ensure project risk management and value delivery to the business. This approach reduces the risk of unexpected costs and project cancellations, improves communications to and involvement of business and end users, ensures the value and quality of project deliverables, and maximises their contribution to IT-enabled investment programmes.


20


Detailed control objective PO10.3 Project Management Approach Establish a project management approach commensurate with the size, complexity and regulatory requirements of each project. The project governance structure can include the roles, responsibilities and accountabilities of the programme sponsor, project sponsors, steering committee, project office and project manager, and the mechanisms through which they can meet those responsibilities (such as reporting and stage reviews). Make sure all IT projects have sponsors with sufficient authority to own the execution of the project within the overall strategic programme. Detailed control objective PO10.4 Stakeholder Commitment Obtain commitment and participation from the affected stakeholders in the definition and execution of the project within the context of the overall IT-enabled investment programme. It is accountable for the success of the project and has responsibility and authority for the project within the project mandate. Detailed control objective PO10.5 Project Scope Statement Define and document the nature and scope of the project to confirm and develop amongst stakeholders a common understanding of project scope and how it relates to other projects within the overall IT-enabled investment programme. The definition should be formally approved by the programme and project sponsors before project initiation. Detailed control objective PO10.6 Project Phase Initiation Approve the initiation of each major project phase and communicate it to all stakeholders. Base the approval of the initial phase on programme governance decisions. Approval of subsequent phases should be based on review and acceptance of the deliverables of the previous phase, and approval of an updated business case at the next major review of the programme. In the event of overlapping project phases, an approval point should be established by programme and project sponsors to authorise project progression. Detailed control objective PO10.7 Integrated Project Plan Establish a formal, approved integrated project plan (covering business and information systems resources) to guide project execution and control throughout the life of the project. The project plan should be maintained throughout the life of the project. The project plan, and changes to it, should be approved in line with the project governance framework. Detailed control objective PO10.8 Project Resources


21


Define the responsibilities, relationships, authorities and performance criteria of project team members, and specify the basis for acquiring and assigning competent staff members and/or contractors to the project.

4.5

Afronding Als laatste stap is het framework opgesteld met daarin de detailed control objectives die binnen de scope vallen, waarna op een hoog niveau testplannen zijn toegevoegd die de IT-auditor als richtlijn kan gebruiken bij het beoordelen van requirements management binnen IT projecten. In het control framework is voor dit voor PO10.8 Project Resources als volgt weergegeven: Detailed control objective

High level testplan

PO10.8 Project Resources

•


• •

Determine that the actual identification of tasks and resources required is undertaken during the initiation phase. Determine that the resources required are identified during the planning process. Determine how the project has secured that competent staff is assigned during the project.

Het hele model is in bijlage G bijgevoegd. Hierin is tevens de koppeling naar de uit de literatuurstudie onderkende succesfactoren voor requirementsmanagement in IT projecten gelegd.


22


5

Validatie concept control framework

5.1

Inleiding In deze paragraaf wordt de volledigheid en juistheid van het opgestelde concept control framework getoetst aan de hand van het toepassen van het framework in de praktijk. Het doel van de uitgevoerde analyse tussen het concept control framework en de case studie is om mogelijke tekortkomingen en onvolkomenheden te identificeren en het concept control framework op bruikbaarheid te toetsen.

5.2

Casestudie Deze casestudie beschrijft het requirements ontwikkel en requirements management proces binnen een project bij een verzekeraar. Een volledige beschrijving van de case studie kan terug worden gevonden in bijlage H.

5.2.1

Gebruikers requirement De organisatie is in 2003 een project gestart met als doelstelling het oude inflexibele mainframe systeem voor polis administratie en verwerking van schade verzekeringen te vervangen door een op Service Oriented Architecture (SOA) gebaseerde maatwerkapplicatie. De applicatie moest op een goedkopere en snellere manier nieuwe productadministratie en productwijzigingen kunnen realiseren. Daarnaast moest de nieuwe applicatie aan de volgende eisen voldoen: •

80% straight-through polis acceptatie en polis verwerking teneinde een kostenreductie van 80% in de backoffice kosten te realiseren.

•

Flexibele pricing mechanismen, zodat eenvoudig en snel stimuleringen ter vergroting van het marktaandeel kunnen worden doorgevoerd.

De nieuwe polisadministratie is het koppelpunt in een centraal verzekeringbedrijf waarop meerdere labels kunnen worden aangesloten. Met de project implementatie werd beoogd een efficiënt operating model op te zetten voor het verzekeringsbedrijf dat door de schaalgrootte in staat is kosten voordelen te behalen. In de volgende paragraaf volgt een korte beschrijving van de totstandkoming van de requirements.

5.2.2

Requirements ontwikkeling Gedurende de short list fase van het selectie traject van de leverancier is een demonstratie gegeven van het standaard pakket. Op basis hiervan is gedurende een serie workshops een gap analyse uitgevoerd tussen de bestaande functionaliteit van de IT oplossing en de gewenste functionaliteit van de opdrachtgever. De deelnemers van de workshops waren: een ontwikkelaar


23


van de leverancier, informatie analisten van zowel de opdrachtgever als de leverancier, een facilitator van de leverancier, IT experts van de opdrachtgever en de sponsor van het project om de beslissingen te kunnen maken. De high level requirements vormde de basis van de contractuele baseline. Deze baseline werd vastgelegd in een outline requirements document en het door de opdrachtgever opgezette requirements register. In deze documenten werd de scope van de functionaliteit bepaald. Bijvoorbeeld dat het systeem in staat moest zijn om online ingevoerde polissen te verwerken. De outline use cases werden gereviewed en afgetekend door de gebruikers analisten (business analisten; gedelegeerd door de project manager van de opdrachtgever) en vervolgens vertaald naar navigation maps (hierin werd de flow van de processen vastgelegd). De navigation maps zorgden ervoor dat de opdrachtgever het uiterlijk van het toekomstige systeem kon ervaren zonder dat hierin functionaliteit aan was verbonden. Gebaseerd op de navigation maps werden door de leverancier use cases opgeleverd, waarin de detail procesbeschrijvingen waren opgenomen. De verschillende verzekeringsproducten en product specificaties werden opgenomen in static data sheets. Voor de interfaces naar andere componenten in de architectuur werden integratie standaarden opgesteld. Op basis van de use cases werd een prototype ontworpen (Proof of Concept), zodat de toekomstige functionaliteit door de gebruikers van het systeem kon worden ervaren. Als systeem ontwikkel methode is gebruik gemaakt van Rational Unified Process (RUP). De door de opdrachtgever goedgekeurde use cases zijn vertaald naar het design in verschillende modellen gebruik makend van Unified Modeling Language (UML). Als risico is aangegeven dat wanneer de use cases niet SMART en eenduidig zijn beschreven, de situatie kan ontstaan dat de designer aannames maakt over hoe functionaliteit dient te worden vormgegeven. Op basis van de modellen hebben ontwikkelaars het systeem geprogrammeerd. In de volgende paragraaf volgt een korte beschrijving van het requirements management proces.

5.2.3

Requirements management Na de formele goedkeuring door de opdrachtgever werden de verschillende use cases en product specificaties gebaselined. Vanaf dit moment was de baseline leidend en werd elke wijziging op basis van een formeel wijzigingsbeheer proces goedgekeurd door het project management voor de financiële impact en door de informatie analist op functionele impact. Alle wijzingen werden door middel van een wijziging history vastgelegd in ieder document. Iedere wijziging had tevens een wijziging in versie nummer tot gevolg. Dit proces werd onderhouden door de configuratie manager en vastgelegd in Rational ClearCase. In deze tool is het mogelijk de traceerbaarheid van modellen terug te herleiden naar de use cases. Naast de systeem ontwikkel methode RUP werd binnen het project gebruik gemaakt van de project governance vanuit PRINCE2. Hierin waren ten behoeve van requirements management 2 stuurgroepen relevant.


24


1

Change Control Board (CCB). In deze meeting worden door de opdrachtgever (business) en het project de wijzigingsverzoeken geprioriteerd.

2

De uiteindelijke keuzes werden gemaakt in de Project Management meeting welke werd geadviseerd door de CCB. In de Project management meeting hadden verschillende leveranciers, het project management, inkoop en applicatie management zitting.

In de volgende paragraaf volgt een korte opsomming van de in case studie onderkende succesfactoren.

5.2.4

Succesfactoren Vanuit de hierboven beschreven casestudie werden de volgende succesfactoren ten aanzien van requirements management onderkend. Nummer Succesfactor S5

De sleutelrollen (informatie analisten, requirement manager, designer) binnen het requirements management proces worden vervuld door gekwalificeerde personen.

S4

De systeem documentatie (use cases, static data sheets en integration standards) beschrijft de volledige system functionaliteit en niet alleen het maatwerk deel van de functionaliteit.

S11

Configuratie management heeft een hoog volwassenheidsniveau, zodat alle specificaties gelijk zijn aan de opgeleverde functionaliteit (versie nummers en delivery notes). Daarnaast is een volledige audit trail beschikbaar voor alle wijzingen in requirements (volledig traceerbaar).

S12

Formeel wijzigingsbeheer is ingericht, zodat wijzigingen op een gestructureerde manier worden doorgevoerd.

S2, S3, Een beslissingsmatrix en een effectief beslissingsproces borgt dat alle belangrijke S7 belanghebbenden betrokken zijn in het requirements management proces. Nieuw

Het vervaardigen van testscripts is gekoppeld aan de requirements documentatie op basis waarvan gebouwd wordt. Dit vormt de vertaling van de requirements naar acceptatie criteria.

In de volgende paragraaf volgt de koppeling tussen deze succesfactoren en het opgestelde concept control framework.


25


5.3

Concept control framework Het concept control framework is getoetst op volledigheid, juistheid en bruikbaarheid bij zowel de leverende partij (supply) van de applicatie, de ontvangende partij (demand) en ten slotte ook met een senior Manager (IT Auditor) van KPMG. Dit is gedaan op basis van interviews. De conclusie is opgenomen in de volgende paragraaf.

5.4

Conclusie Uit de toetsing van het framework blijkt dat het generieke control framework op bijna alle onderdelen volledig is om de succesfactoren voor requirements management binnen projecten te toetsen. Uit de case studie kwam wel naar voren dat de detailed control objectives nog te generiek zijn om goed te kunnen worden toegepast binnen een specifieke situatie. Voor het specifiek maken dienen de op basis van de succesfactoren gedefinieerde detailed control objectives te worden vertaald naar controls met daarbij behorende testinstructies. Hieronder is een voorbeeld opgenomen, waarin is beschreven hoe dit zou kunnen worden uitgevoerd. Vanuit zowel de literatuur studie als de case studie is naar voren gekomen dat een belangrijke succesfactor de kennis van de betrokkenen is die de requirements verwoorden (de opdrachtgever), vastleggen en vervolgens vertalen naar een eenduidige design dat door ontwikkelaars niet op meerdere manieren kan worden geïnterpreteerd. In het concept control framework wordt de volgende control objective gegeven voor het aanstellen van gekwalificeerd personeel. Detailed control objective PO10.8 Project Resources Define the responsibilities, relationships, authorities and performance criteria of project team members, and specify the basis for acquiring and assigning competent staff members and/or contractors to the project.

Een control hiervoor zou kunnen zijn: Control

C10.8.1Project Resources The responsibilities, relationships, authorities and performance criteria of project team members are documented by the project manager in a roles and responsibilities matrix and is periodically reviewed on correctness.

Hieronder is een voorbeeld weergegeven van een testinstructie: Test instructions:

C10.8.1Project Resources •

Determine that the responsibilities, relationships, authorities and performance criteria of project team members


26


are documented in a roles and responsibilities matrix by the project manager.

•

Inspect that the roles and responsibilities matrix is reviewed periodically by the project manager.

Daarnaast is vastgesteld dat in CobiT een control objective ontbreekt waarvoor in de casestudy wel een succesfactor is onderkend. Dit is het koppelen van testscripts met de (gewijzigde) requirements. Dit element is de letterlijke vertaling van de requirements naar acceptatie criteria. Concluderend kan de IT-auditor met het framework (zie bijlage G) beschikken over een generiek framework dat als startpunt kan dienen om een requirements management proces binnen het betreffende project te beoordelen.


27


6

Conclusie

6.1

Inleiding In dit hoofdstuk worden de conclusies uit dit onderzoek beknopt weergeven en zijn aanbevelingen gegeven. In dit onderzoek stond de volgende onderzoeksvraag centraal. Welke succesfactoren binnen het requirements management proces in de literatuur en praktijk dragen bij aan de ontwikkeling van een control framework om tot een beheerst requirements management proces te komen, waarmee de slagingskans toeneemt om projecten met het gewenste resultaat op te leveren?

6.2

Analyse Om deze onderzoeksvraag goed te kunnen beantwoorden, zijn een aantal deelvragen opgesteld die in de verschillende hoofdstukken in meer detail zijn beantwoord. Hieronder volgt een beknopte opsomming van de belangrijkste deelconclusies uit het onderzoek, waarna de centrale onderzoeksvraag wordt beantwoord:

6.3

•

In de literatuur studie is vastgesteld dat requirements management een systeem ontwikkel activiteit is die zich bezig houdt met het organiseren, documenteren en groeperen van requirements voor systemen waarbij de focus ligt op het onderhouden van traceerbaarheid van wijzigingen op requirements.

•

Op basis van literatuurstudie zijn diverse succes factoren in het requirements ontwikkeling en requirements management proces onderkend (zie hoofdstuk 2.6 en 3.3).

•

Op basis van een case studie zijn de diverse succes factoren in het requirements ontwikkeling en requirements management proces onderschreven en aangevuld (zie hoofdstuk 5.2.4).

•

Op basis van de onderkende succesfactoren is vervolgens een concept framework gedefinieerd, gebruik makend van de control objectives van CobiT 4.1.

Conclusie Op basis van de vertaling van de succesfactoren naar control objectives is een framework aangereikt dat als uitgangspunt kan dienen voor een IT auditor. Dit framework dient nog wel specifiek gemaakt te worden voor de situatie waarin het framework zal worden gebruikt. Op basis hiervan is een oordeel te geven over de effectiviteit van requirements ontwikkeling en requirements management in IT projecten. Wanneer de aanbevelingen op basis van het specifiek gemaakte concept control framework door het project worden overgenomen, vergroot dit de slagingskans om toekomstige projecten met het gewenste resultaat op te leveren. Hierbij dient te worden opgemerkt dat audits vaak achteraf worden uitgevoerd. Dit is te laat om resultaten in het


28


lopende project te bewerkstelligen. Dit kan worden ondervangen door tussentijdse/periodieke project audits uit te voeren, om zo tijdig te kunnen bijsturen. Ten slotte dient te worden opgemerkt dat de control objectives zijn opgesteld voor de uitvoering van een proces audit. Wanneer de opdrachtgever behoefte heeft aan aanvullende zekerheid kan worden overwogen een aantal inhoudelijke producten te beoordelen. Hoewel het control framework ook onderdelen van producten raakt, is het niet volledig om dit te hanteren voor de uitvoering van product audits.


29


7

Reflectie Deze scriptie is geschreven ter afsluiting van de post-graduate IT Audit opleiding aan de VU in Amsterdam. Het onderzoek, wat geleid heeft tot het generieke control framework voor het toetsen van requirements management binnen projecten, is een leerzaam traject geweest. Het proces leek initieel eenvoudiger dan dat het uiteindelijk bleek te zijn. Uitgangspunt was om vanuit de literatuur de meest belangrijke succesfactoren voor requirements management te extraheren, zodat op basis daarvan een vertaling zou kunnen worden gemaakt naar een bestaand governance model met bijbehorende beheersmaatregelen. Doordat in de literatuur veel is geschreven over requirements management bleek het hierdoor niet eenvoudig een generieke en rode draad te vinden van de meest geaccepteerde manier van requirements management. Dit is de reden geweest om ook te kijken naar hoe bestaande methodieken requirements management ondersteunen. Daarnaast had ik verwacht dat de klassieke systeem ontwikkel methode, de waterval methode (SDM II) en de iteratieve systeem ontwikkel methode (RUP) tot meer karakteristieke succesfactoren zouden leiden met betrekking tot requirementsmanagement. Dit is echter niet het geval. Iteratieve ontwikkeling is in feite een mini waterval die als voordeel heeft dat tekortkomingen in het ontwikkel proces sneller aan het daglicht komen. Daarom is de case studie uiteindelijk gebaseerd op alleen iteratieve systeem ontwikkeling. Ten slotte was het de bedoeling een “kant-en-klaar” control framework samen te stellen. Gedurende het onderzoek is echter vast komen te staan dat ieder project te uniek is om een generieke en uitputtende set aan maatregelen voor te definiëren.


30


Literatuurlijst 1


2

Compact; De rol van het testen bij het accepteren van een systeem, (Vrins en Beucken, 2004)

3

Guide to the software engineering body of knowledge (Abran, 2005)

4

Het IT-methodenlandschap in Nederland anno 2005 (Neering, 2005)

5

IEEE Standard Glossary of Software Engineering Terminology (1990)

6

Informatie en de besturing van organisaties (Prakken, 1997)

7

Managing successful projects with PRINCE2, (OGC, 2004)

8

Project Management Based on PRINCE2 (van Heemst, 2006)

9

Rational Unified Process, Rational Software Development Company 1998

10 Requirements Engineering A good practice guide (Sommerville en Sawyer, 1997) 11 Requirements Management: The interface between Requirements Development and all other systems engineering processes (Hood, 2008) 12 Software requirements: practical techniques for gathering and managing (Wiegers, 2005) 13 Standish Group report CHAOS 2009 14 The future of requirements management tools (A .Finkelstein and W. Emmerich, 2000)


31


Geïnterviewden en begeleiders Geïnterviewden

Naam

Functie

Bedrijf

Chris Spiers

Software Architect

Unisys

Geert Jan van Gaans

Programma Manager

Nationale Nederlanden

Herman van Gils

Senior Manager

KPMG

Rob Voster

Senior Manager

KPMG

Ross Fleming

Project/Requirements Manager

Unisys

Naam

Functie

Bedrijf

Evert Koning

Hoofd Expertisecentrum DNB toezicht ICT

Martijn Vrins

Senior Manager

Begeleiders


KPMG

32


A

Kwaliteitsaspecten NEN-ISO 9126 De bekendste modellen voor het vastleggen van acceptatiecriteria zijn het ISO 9126-model en het Extended ISO-model. Deze modellen richten zich primair op productkwaliteit. In onderstaand overzicht zijn de kwaliteitsaspecten waarop deze modellen zich baseren, opgenomen. Dergelijke modellen ontlenen hun toegevoegde waarde voornamelijk aan het feit dat ze aan requirements en acceptatiecriteria een plaats geven. Daarmee kunnen dergelijke modellen een belangrijk hulpmiddel zijn om een volledige set van acceptatiecriteria op te bouwen.18 Functionality • Suitability • Accuracy • Interoperability • Compliance • Security • Traceability* Reliability • • • • •

Maturity Fault tolerance Recoverability Availability* Degradability*

Usability • • • • • • • • •

Understandability Learnability Operability Explicitness Customisability* Attractivity* Clarity* Helpfullness* User-friendlyness*

Efficiency • •

Time behaviour Resource behaviour

Maintainability • • • •

18

Analysability Changeability Stability Testability Compact; De rol van het testen bij het accepteren van een systeem, (Vrins en Beucken, 2004)


33


• •

Manageability Reusability

Portability • • • •

Adaptability Installability Conformance Replaceability

*) Extended ISO


34


B

PRINCE2

B.1

Faseringen binnen het PRINCE2-procesmodel De volgende acht faseringen worden binnen het PRINCE2-procesmodel onderkend:

B.2

1

Opstarten van een project beschrijft het werk dat moeten worden gedaan in de opstartfase van een project;

2

Initiëren van een project beschrijft de activiteiten die de projectmanager uitvoert nadat goedkeuring is gekregen het project verder uit te werken;

3

Dirigeren van een project beschrijft de rol van projectboard of stuurgroep;

4

Managen van faseovergangen beschrijft hoe de projectboard/stuurgroep wordt voorzien van informatie om beslissingen te kunnen nemen;

5

Managen van product oplevering beschrijft de aanname en oplevering van werkzaamheden van de teams;

6

Managen overgangs fasen beschrijft hoe de overgang naar een volgende Stage (projectfase) moeten worden gemanaged;

7

Plannen maken beschrijft het planningsproces;

8

Afsluiten van een project beschrijft het zorgen voor een gestructureerd projecteinde.

Componenten van projectmanagement binnen PRINCE2 Naast de acht faseringen worden binnen het PRINCE2-procesmodel de volgende acht componenten, als onderdelen van projectmanagement en bouwstenen voor de processen, onderkend: 1

In Business Case staat beschreven wat de redenen en rechtvaardiging van het project zijn;

2

Organisatie beschrijft de verantwoordelijkheden van de verschillende rollen binnen de projectorganisatie;

3

Plannen beschrijft de plannen die nodig zijn voor de productie van de juiste producten op het juiste tijdstip;

4

Beheersing beschrijft de mechanismen om te komen tot rapportage over voortgang en afwijkingen ten behoeve van tijdige bijsturing;


35


5

Risicobeheer beschrijft zowel handvatten om risicoanalyse en -beheersing uit te voeren als handvatten om beter te anticiperen op bedreigingen;

6

Kwaliteitsbeheer beschrijft hoe kan worden bijgedragen aan het bereiken van kwaliteitsverwachtingen en acceptatiecriteria;

7

Configuratiebeheer beschrijft hoe alle producten, ook de projectdocumentatie, moeten worden beheerd om efficiënt te kunnen werken;

8

Wijzigingsbeheer beschrijft het beoordelen van en het stellen van prioriteiten aan voorgestelde wijzigingen. Dit aan de hand van het effect op het project, gemeten in tijd, geld, kwaliteit, bereik en risico’s.


36


C

Verdeling van meest gebruikte systeem ontwikkeling methodieken V Model SDM (II) SP Scrum RUP RAD MSF LAD DSDM CDM CBD/e ASAP 0

5

10

15

20

25

30

Bron: Het IT-methodenlandschap in Nederland anno 2005, (Neering, 2005)


37


D

Rational Unified Proces

Schematische weergave van de Rational Unified Proces systeem ontwikkeling methode

RUP (Rational Unified Process) is een gestructureerde en schaalbare methode voor softwareontwikkeling, gebaseerd op best practices. Deze bestaan uit standaarden en richtlijnen voor: fasering, activiteiten, producten, disciplines en rollen, gedocumenteerd in een geïntegreerde, toegankelijke website. RUP onderkent de hieronder opgenomen fasen per iteratie. 1

In de Inceptie fase van RUP wordt een haalbaarheidsstudie uitgevoerd en wordt de scope van het project bepaald. Het einddoel is een go/no-go beslissing op basis van een uitgevoerde kosten en risico analyse.

2

Gedurende de Elaboratie fase worden de functionele requirements gespecificeerd (door middel van use cases). Verder wordt de systeem Architecture ontwikkeld.

3

In de Constructie fase ligt de nadruk op de bouw van het systeem. Elke iteratie bevat een aantal bij elkaar horende use cases. Eerst worden de use cases verder afgemaakt met een prototype. Dan worden zij gebouwd, waarna een integratietest en eventueel een gebruikersdeelacceptatietest wordt uitgevoerd.

4

De Transitie fase bestaat uit twee iteraties. De nadruk ligt vooral op de acceptatietest en oplevering, maar er wordt ook rework gedaan en de oplevering wordt voorbereid.


38


E

SDM II

1

Informatieplanning Hierbij moet opgemerkt worden dat de fasen informatieplanning in wezen geen deel uitmaakt van het ontwerpproces.

2

Definitiestudie Na de inventarisatie van de informatiebehoefte tijdens de fase definitiestudie

3

Basisontwerp stapsgewijs wordt gewerkt aan een nadere invulling en verfijning van de specificaties van het systeem. Dat gebeurt in de fase basisontwerp en detailontwerp.

4

Detailontwerp

5

Realisatie Vervolgens wordt door de ontwikkelaars gedurende de realisatiefase het systeem tot stand gebracht.

6

Invoering Aan het einde van de realisatiefase wordt door de gebruikersorganisatie een acceptatietest uitgevoerd. Nadat de acceptatietesten succesvol zijn afgerond wordt overgegaan tot de invoerings- (of implementatie fase). In deze fase zijn drie aandachtspunten van belang:

•

de invoering van het systeem

•

de overdracht van het systeem aan de organisatie

•

een eerste evaluatie van het systeem in de productie omgeving

7

Gebruik en beheer


39


F

CobiT Model

Figuur 5 CobiT 4 framework

Zoals bovenstaand figuur aangeeft, is het CobiT-model19 onderverdeeld in vier domeinen: • Plan and Organise (PO); • Acquire and Implement (AI); • Deliver and Support (DS); • Monitor and Evaluate (ME)

19



40


Vervolgens bevatten deze domeinen specifieke processen. Voor elk proces heeft CobiT beheerdoelen en corresponderende management guidelines. Het proces in ‘Plan and Organise’ gaat in op strategische en organisatorische invulling van IT in een organisatie. Het proces heeft raakvlakken met de IT Balanced Scorecard, MSP voor programmamanagement en PRINCE2 voor projectmanagement. Het domein ‘Acquire & Implement’ omvat de ontwikkeling, de acquisitie en de implementatie van IT-systemen en vertoont overeenkomsten met het CMM voor softwareontwikkeling. Het domein ‘Deliver & Support’ gaat over de IT-dienstverlening en vertoont duidelijke raakvlakken met modellen als ITIL. Ten slotte gaat het domein ‘Monitor and Evaluate’ in op het meten en het evalueren van de IT-processen.


41


G

CobiT concept control framework

G.1

Plan and Organize Domain Plan & Organize Process PO8 Manage Quality High Level Control objectives A Quality management system (QMS) is developed and maintained that includes proven development and acquisition processes and standards. This is enabled by planning, implementing and maintaining the QMS by providing clear quality requirements, procedures and policies. Quality requirements are stated and communicated in quantifiable and achievable indicators. Continuous improvement is achieved by ongoing monitoring, analysis and acting upon deviations, and communicating results to stakeholders. Quality management is essential to ensure that IT is delivering value to the business, continuous improvement and transparency for stakeholders. Detailed control objective (S1, S14, S17)

High level testplan

PO8.3 Development and Acquisition Standards

Determine that standards for all development projects are adopted and maintained that follow the life cycle of the deliverable. Considering:

Adopt and maintain standards for all development and acquisition that follow the life cycle of the ultimate deliverable, and include sign-off at key milestones based on agreed-upon sign-off criteria. Consider software coding standards; naming conventions; file formats; schema and data dictionary design standards; user interface standards; interoperability; system performance efficiency; scalability; standards for development and testing; validation against requirements; test plans; and unit, regression and integration testing.

Detailed control objective (S1, S2, S14, S17)


• •

Inclusion of sign-off at key milestones based on agreed-upon sign-off criteria; Software coding standards; naming conventions; file formats; schema and data dictionary design standards; user interface standards; interoperability; system performance efficiency; scalability; standards for development and testing; validation against requirements; test plans; and unit, regression and integration testing.

High level testplan

42


PO8.4 Customer Focus

•

Focus quality management on customers by determining their requirements and aligning them to the IT standards and practices. Define roles and responsibilities concerning conflict resolution between the user/customer and the IT organisation.

•


Determine that user department representatives are involved in system development projects are satisfied with the current use of the methodology. Determine that roles and responsibilities are defined concerning conflict resolution between the user/customer and the IT organisation.

43


Domain Plan & Organize Process PO10 Manage Projects High Level Control objectives A programme and project management framework for the management of all IT projects is established. The framework ensures the correct prioritisation and co-ordination of all projects. The framework includes a master plan, assignment of resources, definition of deliverables, approval by users, a phased approach to delivery, QA, a formal test plan, and testing and postimplementation review after installation to ensure project risk management and value delivery to the business. This approach reduces the risk of unexpected costs and project cancellations, improves communications to and involvement of business and end users, ensures the value and quality of project deliverables, and maximises their contribution to ITenabled investment programmes. Detailed control objective (S10, S17)

High level testplan

PO10.3 Project Management Approach

•

Establish a project management approach commensurate with the size, complexity and regulatory requirements of each project. The project governance structure can include the roles, responsibilities and accountabilities of the programme sponsor, project sponsors, steering committee, project office and project manager, and the mechanisms through which they can meet those responsibilities (such as reporting and stage reviews). Make sure all IT projects have sponsors with sufficient authority to own the execution of the project within the overall strategic programme.

• • • • •


Determine that a project management methodology and all requirements is adopted and consistently followed; Determine that the project management methodology was communicated to all appropriate personnel involved in the project. Determine that the nature and level of owner/sponsor involvement in the project definition and authorization is appropriate. Determine that the appropriate owner/sponsor and IT management approvals are obtained for each phase of the development project. Determine that each phase of the project is being completed and appropriate signoff is occurring. Determine that a project management methodology is applied with initiating,

44


executing and evaluating projects. Emphasize should be with the alignment between IT and Business. Detailed control objective (S2, S4, S7, S8)

High level testplan

PO10.4 Stakeholder Commitment

•

Determine that the project board represents, at a managerial level, the business, and supplier interests of the project.

Obtain commitment and participation from the affected stakeholders in the definition and execution of the project within the context of the overall IT-enabled investment programme. It is accountable for the success of the project and has responsibility and authority for the project within the project mandate. Detailed control objective (S1, S2)

High level testplan

PO10.5 Project Scope Statement

•

Determine that the project scope is defined during the initiation phase, documented and approved by the project board.

Define and document the nature and scope of the project to confirm and develop amongst stakeholders a common understanding of project scope and how it relates to other projects within the overall IT-enabled investment programme. The definition should be formally approved by the programme and project sponsors before project initiation. Detailed control objective (S1, S2, S7)

High level testplan

PO10.6 Project Phase Initiation

•

Approve the initiation of each major project phase and communicate it to all stakeholders. Base the approval of the initial phase on programme governance decisions. Approval of subsequent phases should be based on review and acceptance of the deliverables of the previous phase, and approval of an updated business case at the next major review of the programme. In the event of overlapping project phases, an approval point should be established by programme and project sponsors to authorise project progression.

•

Determine that the initiation of each major project phase is approved by the sponsors and communicated to all stakeholders; Determine that approval of subsequent phases are based on review and acceptance of the deliverables of the previous phase, and approval of an updated business case at the next major review of the project.

Detailed control objective (S5)

High level testplan

PO10.7 Integrated Project Plan

•

Establish a formal, approved integrated project plan (covering business and information systems


Determine that a formal, approved integrated project plan is established in line with the project governance framework (covering business and information systems resources) to guide project execution and control throughout the life of

45


resources) to guide project execution and control throughout the life of the project. The project plan should be maintained throughout the life of the project. The project plan, and changes to it, should be approved in line with the project governance framework.

the project.

•

Determine that the project plan, and changes to it, are maintained throughout the lifecycle of the project.


High level testplan

PO10.8 Project Resources

•


• •

Determine that the actual identification of tasks and resources required is undertaken during the initiation phase. Determine that the resources required are identified during the planning process. Determine how the project has secured that competent staff is assigned during the project.


High level testplan

PO10.9 Project Risk Management

•

Eliminate or minimise specific risks associated with individual projects through a systematic process of planning, identifying, analysing, responding to, monitoring and controlling the areas or events that have the potential to cause unwanted change. Risks faced by the project management process and the project deliverable should be established and centrally recorded.

• •

Determine that a systematic process of planning is in place for defining when risks should be reviewed. Determine that an approach to the analysis and management of risk is available (e.g. by using a risk log. Determine that project risks are reported to the project board as part of project reporting and considered by the project board when reviewing progress and authorizing plans.

Detailed control objective (S11, S12)

High level testplan

PO10.11 Project Change Control

•

Establish a change control system for each project, so all changes to the project baseline (e.g., cost, schedule, scope, quality) are appropriately reviewed, approved and incorporated into the integrated project plan in line with the programme and project governance framework.

•


Determine that a configuration management plan should be prepared and approved during project initiation as part of the project quality plan. Determine that the change control process should ensure that all project issues are captured, logged and categorised.

46


•


Determine that the processes and authority levels for approving requests should be defined during project initiation.

47


G.2

Acquire and implement Domain Acquire and implement Process AI1 Identify Automated Solutions High Level Control objectives The need for a new application or function requires analysis before acquisition or creation to ensure that business requirements are satisfied in an effective and efficient approach. This process covers the definition of the needs, consideration of alternative sources, review of technological and economic feasibility, execution of a risk analysis and cost-benefit analysis, and conclusion of a final decision to ‘make’ or ‘buy’. All these steps enable organisations to minimise the cost to acquire and implement solutions whilst ensuring that they enable the business to achieve its objectives. Detailed control objective (S2, S4, S10, S14)

High level testplan

AI1.1 Definition and Maintenance of Business Functional and Technical Requirements

•

Identify, prioritise, specify and agree on business functional and technical requirements covering the full scope of all initiatives required to achieve the expected outcomes of the IT-enabled investment programme.

Determine that a vision, functional and technical requirements scope document or high-level objectives of the organisation or customer (which would be part of the software requirements documents) is available.

Detailed control objective (S1, S2, S3, S10)

High level testplan

AI1.3 Feasibility Study and Formulation of Alternative Courses of Action

•

Develop a feasibility study that examines the possibility of implementing the requirements. Business management, supported by the IT function, should assess the feasibility and alternative courses of action and make a recommendation to the business sponsor.


Determine that a feasibility study that examines the possibility of implementing the requirements has been preformed. Determine that business management, supported by the IT function is involved by assessing the feasibility and alternative courses of action.

48


Detailed control objective (S4, S7, S8, S15, S17)

High level testplan

AI1.4 Requirements and Feasibility Decision and Approval

•

Verify that the process requires the business sponsor to approve and sign off on business functional and technical requirements. The business sponsor should make the final decision with respect to the choice of solution and acquisition approach.

•


Determine that the process requires the business to approve and sign off on business functional and technical requirements. Determine that the business made the final decision with respect to the choice of solution and acquisition approach.

49


Domain Acquire and implement Process AI2 Acquire and Maintain Application Software High Level Control objectives Applications are made available in line with business requirements. This process covers the design of the applications, the proper inclusion of application controls and security requirements, and the development and configuration in line with standards. This allows organisations to properly support business operations with the correct automated applications. Detailed control objective (S1, S2, S3, S10, S14, S15, S17)

High level testplan

AI2.1 High-level Design

•

Translate business requirements into a high-level design specification for software acquisition, taking into account the organisation’s technological direction and information architecture. Have the design specifications approved by management to ensure that the high-level design responds to the requirements. Reassess when significant technical or logical discrepancies occur during development or maintenance.

• •

Determine that business requirements are translated into a high-level design specification for software development, taking into account the organisation’s technological direction and information architecture. Determine that the design specifications are approved by management to ensure that the high-level design responds to the requirements. Determine that the design specifications are reassessed when significant technical or logical discrepancies occur during development or maintenance.

Detailed control objective (S1, S2, S3, S10, S14, S15, S17)

High level testplan

AI2.2 Detailed Design

•

Prepare detailed design and technical software application requirements. Define the criteria for acceptance of the requirements. Have the requirements approved to ensure that they correspond to the high-level design. Perform reassessment when significant technical or logical discrepancies occur during development or maintenance.

•

Determine that the criteria for acceptance of the requirements are defined.

•

Determine that the requirements are approved to ensure that they correspond to


Determine that detailed design and technical software application requirements are documented.

50


the high-level design.

•

Determine that the design specifications are reassessed when significant technical or logical discrepancies occur during development or maintenance.

Detailed control objective (S13, S14)

High level testplan

AI2.7 Development of Application Software

•

Ensure that automated functionality is developed in accordance with design specifications, development and documentation standards, QA requirements, and approval standards.

•

Determine that the quality criteria and processes for verification and validation at various interim products are addressed as part of planning. Determine that validations have been performed in accordance with design specifications, development and documentation standards, QA requirements, and approval standards.

Detailed control objective (S4, S8, S9, S11, S12, S16)

High level testplan

AI2.9 Applications Requirements Management

•

Track the status of individual requirements (including all rejected requirements) during the design, development and implementation, and approve changes to requirements through an established change management process.

•


Determine that a baseline is established for all key products and that they be subject to change control. Determine that application requirements management is implemented as part of configuration management and change control.

51


H

Casestudy

H.1

Background Client: Dutch bank/insurer Goal: Replacement contract engine for General Insurance processing and administration. Project duration: from 2003 Project management methodology: PRINCE2 System development methodology: Rational Unified Process The system is designed in the UK, built in India and implemented in The Netherlands. Tooling for supporting requirements management process: IBM Rational Suite requisite pro initially, Requisite Pro was never used ‘in anger’ after the initial tools assesment, it was considered overly complicated and didn’t add anything to the overall process. The basic idea of requisite Pro was that sentences in a word document could be linked directly to a requirement. In practice this didn’t happen, and the analysis model (derived from the use case) was more informative. ClearCase for configuration management, ClearQuest for supporting the defect management and change management process within the project.

H.2

Requirement and Solution

H.2.1

Business Requirements Turning an old, inflexible system which was deemed too expensive to make changes in, too slow in developing new products and features and reacting to market conditions and too expensive to upgrade to a higher level, into a completely redesigned contract engine in Service Oriented Architecture (SOA).

H.2.2

Solution The component-based platform was designed to deliver the following benefits: •

80% straight-through application acceptance and policy processing, this resulted an 80% reduction in the cost of issuing contracts.

•

Faster time to market for new product launches.

•

A flexible pricing mechanism to increase market share.


52


•

Improved underwriting experience.

•

Enhanced profitability.

It also provided a centralized insurance “factory” – a back end for processing policies for multiple products, companies, territories and brands. This gave the company a much more agile and efficient operating model for its general insurance business that would benefit from economies of scale as the business grew.

H.2.3

Requirements development •

During the vendor selection process (short list) the standard package solution was demonstrated and applied as a reference point for the new functionality. During a series of workshops the capabilities of the package where checked against the requirements register (high level requirements gathered by the business). Participants of the workshops were: a developer (vendor), information analysts (client/vendor), a facilitator (client), IT experts (client) and the sponsor of the project for making the end decisions.

•

High level requirements: Outline requirements and requirements register resulted in a contractual baseline. The scope of functionality was determined: e.g. the system must be able to contain the process “enter a policy” or must be able to process online entered policies.

•

Outline use cases were reviewed and signed off by client project manager and translated to navigation maps (this effectively demonstrated a storyboard of the back-office processes) to show the client what the system would look like.

•

Based on the navigation maps more detailed use cases were drafted. The use case contained process level descriptions. Products and product specifications were recorded in static data sheets and interface in integration standards. The basic functionality was captured in a prototype for the clients to experience the look and feel of the future system.

•

The use case to code transition is done various standard analysis techniques, together known as the Rational Unified Process, resulting in a system design expressed in various (UML) models. This process depends on correctly written and accurate use cases otherwise designer have to assume functionality which in the end will delay the process. The designer translates the Use Cases into objects and responsibilities (what the system should do) to create the design model. This model is the basis for code delivery.

•

The developer is adding “meat to the bones”. When the design is right the code delivery can’t go wrong.


53


H.2.4

Requirements management •

•

H.3

1

The Change Control Board (CCB). In this meeting the business and project prioritize change requests.

2

The CCB is advised by the PM2 meeting which contains participant of the different vendors, Project management, Procurement and Application management.

What went well? • •

• • •

H.4

After formal signoff from the client the use cases, static data sheets and interface in integration standards were base lined. Each change on the base line has to be approved by the Project management on financial impact and functionally approved by the client’s business information analyst. Project Governance; two formal project steering committees are setup:

Single point of contact from the client’s perspective. One person is appointed to handle all raised problems from the client. A formal change request process. This is a transparent (and somewhat bureaucratic) process, but effective. This reduces the amount of “nice to have” modifications to the requirements of the system and forces the client to raise well thought through changes only. To assure that all the appropriate stakeholders are involved the requirements change spreadsheet contains a decision making procedure. The systems documentation (use cases, static data sheets and integration standards) fully reflect the systems functionality. Configuration management: all specifications are in-line with deployed functionality (version numbers and delivery notes). Audit trail for all changes in requirements is maintained (fully traceable). System test exist report is included with delivery notes to the client.

Lessons learned? •

The robustness of the system as delivered is currently raising questions of the customer about the intensity of testing. The time to delivery might reduce when less testing is done offshore.

•

Automating regression testing.

•

The introduction of bucket changes (parcels of small changes) within well defined decision making boundaries. This streamlines the bureaucracy.


54

Requirements Management

Recommend Documents