Requirements Management

Maat: px
Weergave met pagina beginnen:

Download "Requirements Management"

Transcriptie

1 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 HV Amsterdam Begeleider Vrije Universiteit: E. Koning (DNB) KPMG IT Advisory Burgemeester Rijnderslaan MC Amstelveen Bedrijfsbegeleider: M. Vrins (KPMG) Auteur: D. Bremmer (KPMG)

2

3

4

5 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 i

6 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

7 Inhoudsopgave Voorwoord Samenvatting Inhoudsopgave i ii iii 1 Onderzoeksopzet Aanleiding en probleemstelling Doelstelling Onderzoeksvraag Methode Opbouw scriptie 4 2 Requirements management Wat is een requirement? Verschillende typen requirement documenten Technieken voor requirements verzameling Wat is requirements management? Traceerbaarheid tussen requirements Samenvatting 11 3 Requirements management binnen IT projecten Projectmanagementmethode PRINCE Requirements management binnen PRINCE Systeem ontwikkeling methodieken Meest toegepaste systeem ontwikkelingsmethodieken Rational Unified Proces (RUP) System Development Methodology II (SDM-II) Samenvatting 18 4 Concept control framework requirements management Inleiding CobiT Framework Inventarisatie van te selecteren CobiT-processen Analyse van de relevante control objectives Afronding 22 5 Validatie concept control framework Inleiding Casestudie Gebruikers requirement 23 iii

8 5.2.2 Requirements ontwikkeling Requirements management Succesfactoren Concept control framework Conclusie 26 6 Conclusie Inleiding Analyse Conclusie 28 7 Reflectie 30 Literatuurlijst 31 Geïnterviewden en begeleiders 32 Geïnterviewden 32 Begeleiders 32 A Kwaliteitsaspecten NEN-ISO B PRINCE2 35 B.1 Faseringen binnen het PRINCE2-procesmodel 35 B.2 Componenten van projectmanagement binnen PRINCE2 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 Plan and Organize 42 G.2 Acquire and implement 48 H Casestudy 52 H.1 Background 52 H.2 Requirement and Solution 52 H.3 What went well? 54 H.4 Lessons learned? 54 iv

9 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 Group 1 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

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

11 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

12 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

13 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 Standard 2 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 volgende 3 : Requirements zijn specificaties van datgene dat moet worden geïmplementeerd. Dit zijn beschrijvingen van hoe het systeem zich moet gedragen. De volgende definitie 4 is een combinatie van de twee bovengenoemde en daarom gebruikt voor deze scriptie. 2 IEEE Standard Glossary of Software Engineering Terminology (1990) 3 Requirements Engineering A good practice guide (Sommerville en Sawyer, 1997) 4 Software requirements: practical techniques for gathering and managing (Wiegers, 2005) 5

14 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

15 Functional requirements Non-Functional requirements Business requirements Visie en Scoping User requirements Business rules Quality attributes Use Case Interfaces Technical requirement Functional requirement Constrains 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

16 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 zijn 5 : 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

17 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 luidt 7 : 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

18 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

19 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 S2 Formuleer de acceptatiecriteria voor de requirements zo vroeg mogelijk in het project. 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

20 S3 S4 S5 S6 S7 S8 S9 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. 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). 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. De requirements dienen SMART (specifiek, meetbaar, acceptabel, realistisch en tijdgebonden) te zijn gedefinieerd. De opgeleverde requirements dienen te worden gebaselined en door de opdrachtgever te worden ondertekend en goedgekeurd. 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). 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

Auteurs: Jan van Bon, Wim Hoving Datum: 9 maart 2009. Cross reference ISM - COBIT

Auteurs: Jan van Bon, Wim Hoving Datum: 9 maart 2009. Cross reference ISM - COBIT Auteurs: Jan van Bon, Wim Hoving Datum: 9 maart 2009 Cross reference ISM - COBIT ME: Monitor & Evaluate Cross reference ISM - COBIT Management summary Organisaties gebruiken doorgaans twee soorten instrumenten

Nadere informatie

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe

Subwerkgroep Methoden. Toelichting inhoud en voortgang tot nu toe SPIDER werkgroep Requirements Management Subwerkgroep Methoden Toelichting inhoud en voortgang tot nu toe donderdag 17 januari 2008 Frans van Veen Bert Dubbelman Robert van Lieshout Erwin Bolwidt Jan-Willem

Nadere informatie

Lagant Management Consultants B.V. Presentatie NGI 26 augustus 2003

Lagant Management Consultants B.V. Presentatie NGI 26 augustus 2003 Lagant Management Consultants B.V. Presentatie NGI 26 augustus 2003 1 2 Inleiding Wat is PRINCE2? Organisation Discussie Wat is een project? Improvisatie Uniek Flexibel Vernieuwend Enerverend Chaotisch

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User

RUM. requirements Management. SPIder session Project. driven by requirements 25th april. Risk assessed User RUM Risk assessed User requirements Management - SPIder session Project driven by requirements 25th april Copyright 2006 ps_testware - Gijs Kuiper Risk assessed User requirement Management Personalia Gijs

Nadere informatie

RISICO MANAGEMENT, BASIS PRINCIPES

RISICO MANAGEMENT, BASIS PRINCIPES RISICO MANAGEMENT, BASIS PRINCIPES AGENDA Leerdoelen van vandaag Wat en waarom Risico Management? Validatie bij Automatisering GMP-Z, GAMP 5, ASTM 2500 en Risico Management Overzicht Risk Management Proces

Nadere informatie

ISO 20000 @ CTG Europe

ISO 20000 @ CTG Europe ISO 20000 @ CTG Europe 31/10/2007 mieke.roelens@ctg.com +32 496266725 1 Agenda 31 oktober 2007 Voorstelling Project Business Case: Doel & Scope Projectorganisatie Resultaten assessments en conclusies De

Nadere informatie

2 e webinar herziening ISO 14001

2 e webinar herziening ISO 14001 2 e webinar herziening ISO 14001 Webinar SCCM 25 september 2014 Frans Stuyt Doel 2 e webinar herziening ISO 14001 Planning vervolg herziening Overgangsperiode certificaten Korte samenvatting 1 e webinar

Nadere informatie

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman

Requirements Traceability. Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman Requirements Traceability Marcel de Baas, Jan Bank, Edwin Buisman, Frits Jacobs, Kitty Spaas, Erik Venema, Arno Zandman 22 Mei 2008 Werkgroep Traceability Doel van de werkgroep: Aanbieden van hulpmiddelen

Nadere informatie

Risk & Requirements Based Testing

Risk & Requirements Based Testing Risk & Requirements Based Testing Tycho Schmidt PreSales Consultant, HP 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Agenda Introductie

Nadere informatie

HET GAAT OM INFORMATIE

HET GAAT OM INFORMATIE Aan leiding C OB IT HET GAAT OM INFORMATIE Informatie is belangrijk voor het functioneren van een organisatie Informatie wordt gegenereerd, gebruikt, bewaard, ontsloten, verwijderd Informatietechnologie

Nadere informatie

CobiT. Drs. Rob M.J. Christiaanse RA PI themabijeenkomst Utrecht 29 juni 2005 9/2/2005 1

CobiT. Drs. Rob M.J. Christiaanse RA PI themabijeenkomst Utrecht 29 juni 2005 9/2/2005 1 CobiT Drs. Rob M.J. Christiaanse RA PI themabijeenkomst Utrecht 29 juni 2005 9/2/2005 1 Control objectives for information and related Technology Lezenswaardig: 1. CobiT, Opkomst, ondergang en opleving

Nadere informatie

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International Succes = x Visie x Draagvlak 2 Case: Implementatie Requirements Lifecycle management bij Rabobank International dinsdag 3 oktober 2006 Spider Congres Agenda Inventarisatie SPI-knelpunten Implementatie

Nadere informatie

PRINCE2 2009 is overzichtelijker

PRINCE2 2009 is overzichtelijker PRINCE2 2009 is overzichtelijker 29 mei 2009 door: Lia de Zoete en Reinier de Koning Half juni presenteert het Office of Government Commerce in Londen PRINCE2 2009. Het grote voordeel van de nieuwe versie

Nadere informatie

BiZZdesign. Bouwen van sterke en wendbare organisaties met behulp van standaarden, methode, technieken en tools. Research & Development

BiZZdesign. Bouwen van sterke en wendbare organisaties met behulp van standaarden, methode, technieken en tools. Research & Development BiZZdesign Bouwen van sterke en wendbare organisaties met behulp van standaarden, methode, technieken en tools Research & Development 1 Profile CV Joost Niehof Name Grade Nationality Residence Role Joost

Nadere informatie

Contractmanagement voor Software-ontwikkeling

Contractmanagement voor Software-ontwikkeling Contractmanagement voor Software-ontwikkeling Presentatie PIANO / NEVI Regionale bijeenkomst Den Haag nieuwe inzichten in contracteren en besturen November 2009 Marcel Blommestijn 2 Doel van deze presentatie

Nadere informatie

Roadmaps Ben Linders Jan Jaap Cannegieter. 4 maart 2009 1

Roadmaps Ben Linders Jan Jaap Cannegieter. 4 maart 2009 1 Roadmaps Ben Linders Jan Jaap Cannegieter 4 maart 2009 1 Geschiedenis van de roadmaps 2001 2006: ervaring opgedaan met continue representatie 15 september 2005: moeilijke discussie bij een opdrachtgever

Nadere informatie

De beheerrisico s van architectuur

De beheerrisico s van architectuur De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich

Nadere informatie

ISACA round-table 7 december 2009 Rik Marselis

ISACA round-table 7 december 2009 Rik Marselis ISACA round-table 7 december 2009 Rik Marselis Senior Testconsultant bij Sogeti Penningmeester van BNTQB, de member board voor België en Nederland van de International Software Testing Qualifications Board

Nadere informatie

Offshore Outsourcing van Infrastructure Management

Offshore Outsourcing van Infrastructure Management Offshore Outsourcing van Infrastructure Management an emerging opportunity dr. Erik Beulen Atos Origin/Tilburg University 1 Agenda Introductie Ontwikkelingen Risicovergelijking Best practices Conclusies

Nadere informatie

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept.

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept. 1. 1.1. Inleiding Doel De Requirementdiscipline richt zich op het vaststellen en vastleggen van de eisen en wensen die aan een oplossing worden gesteld: de requirements. Rollen De keyrol binnen deze discipline

Nadere informatie

Whitepaper implementatie workflow in een organisatie

Whitepaper implementatie workflow in een organisatie Whitepaper implementatie workflow in een organisatie Auteur: Remy Stibbe Website: http://www.stibbe.org Datum: 01 mei 2010 Versie: 1.0 Whitepaper implementatie workflow in een organisatie 1 Inhoudsopgave

Nadere informatie

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter 2 Opdrachtgever : Opdrachtnemers : Ing. P. van den Berg Michel van Reenen Thijs Mommen GAMP Toegepast op de DeskTopXorter Besturing DeskTopXorter

Nadere informatie

Snel naar ISO20000 met de ISM-methode

Snel naar ISO20000 met de ISM-methode Snel naar ISO20000 met de ISM-methode Cross-reference Datum: 16 oktober 2012 Versie: 1.0 Auteur: J. van Bon Integrated Service Management Snel naar ISO20000 met de ISM-methode! Organisaties moeten, door

Nadere informatie

LSSN seminar Amsterdam 01-11-2012 Edwin Kippers Master Black Belt. Project Management

LSSN seminar Amsterdam 01-11-2012 Edwin Kippers Master Black Belt. Project Management Lean Six Sigma Scrum Niet alleen voor software projecten LSSN seminar Amsterdam 01-11-2012 Edwin Kippers Master Black Belt Project Management Project succes survey The Standish Group's report: "CHAOS Summary

Nadere informatie

Enterprisearchitectuur

Enterprisearchitectuur Les 2 Enterprisearchitectuur Enterprisearchitectuur ITarchitectuur Servicegeoriënteerde architectuur Conceptuele basis Organisatiebrede scope Gericht op strategie en communicatie Individuele systeemscope

Nadere informatie

It s CMMI Jim, but not as we know it! CMMI toegepast op een Compliance organisatie Door Jasper Doornbos Improvement Focus

It s CMMI Jim, but not as we know it! CMMI toegepast op een Compliance organisatie Door Jasper Doornbos Improvement Focus It s CMMI Jim, but not as we know it! CMMI toegepast op een Compliance organisatie Door Jasper Doornbos Improvement Focus Inhoud Compliance vakgebied en organisatie CMMI software en systems engineering

Nadere informatie

Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling. Agile Methodiek en Technologie. Zest Application Professionals

Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling. Agile Methodiek en Technologie. Zest Application Professionals Verzamelde vragen en antwoorden Agile Applicatie ontwikkeling Agile Methodiek en Technologie Zest Application Professionals Hoe is de aansluiting op ontwikkelmethoden voor Legacy-systemen? Out of the Box

Nadere informatie

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

Nadere informatie

ORGANISATORISCHE IMPLENTATIE BEST VALUE

ORGANISATORISCHE IMPLENTATIE BEST VALUE ORGANISATORISCHE IMPLENTATIE BEST VALUE EEN ONDERZOEK NAAR DE IMPLEMENTATIE VAN BEST VALUE BINNEN EEN SYSTEMS ENGINEERING OMGEVING STEPHANIE SAMSON BEST VALUE KENNIS SESSIE WESTRAVEN 17 JUNI 09.00 12.00

Nadere informatie

8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten

8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Les 1 Docent: Marcel Gelsing Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Hoe test je een pen? 1 Bekijk eerst het filmpje over

Nadere informatie

Business Rules: het scheiden van kennis en processen 17 september 2014

Business Rules: het scheiden van kennis en processen 17 september 2014 Business Rules: het scheiden van kennis en processen 17 september 2014 Business rules scheiden kennis van processen 1 Agenda 18:30-18:40 Opening 18:40-19:15 Het scheiden van kennis en processen Peter Nobels,

Nadere informatie

Trefdag ZORG. Meer resultaten. door strategische inzet. van middelen

Trefdag ZORG. Meer resultaten. door strategische inzet. van middelen Trefdag ZORG Meer resultaten door strategische inzet van middelen September 2013 Francis Manas fm@amelior.be Herkenbaar? Aantal projecten neemt toe Projecten zonder link met doelen organisatie: geen fit

Nadere informatie

1Modelexamen 1. Modelexamen 1

1Modelexamen 1. Modelexamen 1 1Modelexamen 1 Het examen PRINCE2 Foundation wordt in Nederland afgenomen door Stichting EXIN. Om u voor te bereiden op het examen is er een representatief modelexamen bijgevoegd. Het examen bestaat uit

Nadere informatie

Aanpak projectaudits

Aanpak projectaudits Aanpak projectaudits 1. Inleiding Veel lokale overheden werken op basis van een standaardmethodiek Projectmatig Werken. Op die manier wordt aan de voorkant de projectfasering, besluitvorming en control

Nadere informatie

Managing Quality and Business Risks in Programmes. Mario van Os

Managing Quality and Business Risks in Programmes. Mario van Os Managing Quality and Business Risks in Programmes Mario van Os Mario van Os Mario van Os Programma Kwaliteitsmanager Email: mario@mvanos.nl Afgestudeerd TUE Wiskunde & Informatica 1986 gestart bij Interprogram

Nadere informatie

PROJECT INITIATION DOCUMENT

PROJECT INITIATION DOCUMENT PROJECT INITIATION DOCUMENT Versie: Datum: x.x dd-mm-jj DOCUMENTATIE Versie Naam opdrachtgever Naam opsteller Datum: dd-mm-jj Voor akkoord: Datum:. INHOUDSOPGAVE 1. Managementsamenvatting

Nadere informatie

Verandermanagement: Business as Usual

Verandermanagement: Business as Usual Verandermanagement: Samenvatting Voor organisaties is het inmiddels een vast gegeven dat hun processen en producten continue zullen moeten veranderen om zich te kunnen handhaven in een omgeving waar we

Nadere informatie

1. Thema: Plannen. Definities en Kernbegrippen. Inhoud

1. Thema: Plannen. Definities en Kernbegrippen. Inhoud Inhoud 1. Thema: Plannen 1. Thema: Plannen 1 1.1 Niveaus van Plannen 2 1.1.1 Project Plan (Projectplan) 2 1.1.2 Stage Plan (Faseplan) 2 1.1.3 Exception Plan (Afwijkingsplan) 2 1.2 Product Based Planning

Nadere informatie

Process Mining and audit support within financial services. KPMG IT Advisory 18 June 2014

Process Mining and audit support within financial services. KPMG IT Advisory 18 June 2014 Process Mining and audit support within financial services KPMG IT Advisory 18 June 2014 Agenda INTRODUCTION APPROACH 3 CASE STUDIES LEASONS LEARNED 1 APPROACH Process Mining Approach Five step program

Nadere informatie

VU BWI Bedrijfscase. Cursus Project management deel 1. Introductie. Henk Magré. BWI Bedrijfscase Projectmanagement deel 1

VU BWI Bedrijfscase. Cursus Project management deel 1. Introductie. Henk Magré. BWI Bedrijfscase Projectmanagement deel 1 1 VU BWI Bedrijfscase Cursus Project management deel 1 april 2011 Henk Magré Introductie Henk Magré Sinds 1986 werkzaam bij Logica / CMG 25 jaar ervaring in IT ontwikkeling en processen recente jaren Kwaliteitszorg

Nadere informatie

Balanced Scorecard. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V.

Balanced Scorecard. Een introductie. Algemene informatie voor medewerkers van: SYSQA B.V. Balanced Scorecard Een introductie Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 DE

Nadere informatie

IT Vernieuwing wie waarborgt resultaat?

IT Vernieuwing wie waarborgt resultaat? IT Vernieuwing wie waarborgt resultaat? ir. Richard Heijne den Bak Lezing ICT Zorg 004 en mei in Ede GOUDA 08-573 HENGELO (O) 074-674067 M I T O P I C S BV WWW.MITOPICS.NL INFO@MITOPICS.NL Even voorstellen

Nadere informatie

Procesvisie op Maat. Op basis van het Master Test Plan wordt een gedetailleerd testplan voor elke fase opgesteld.

Procesvisie op Maat. Op basis van het Master Test Plan wordt een gedetailleerd testplan voor elke fase opgesteld. 1. 1.1. Inleiding Doel In de discipline vindt de validatie van datgene wat binnen het project is gerealiseerd plaats. Dit bestrijkt het gebied van unittest tot en met acceptatie door gebruikers en beheerorganisatie.

Nadere informatie

BENT U ER KLAAR VOOR?

BENT U ER KLAAR VOOR? ISO 9001:2015 EN ISO 14001:2015 HERZIENINGEN ZIJN IN AANTOCHT BENT U ER KLAAR VOOR? Move Forward with Confidence WAT IS NIEUW IN ISO 9001:2015 & ISO 14001:2015 MEER BUSINESS GEORIENTEERD KERNASPECTEN "LEIDERSCHAP

Nadere informatie

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Titel, samenvatting en biografie Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Samenvatting: Eibert Dijkgraaf (testconsultant Test

Nadere informatie

Use-Case 2.0. Requirements Kenniscentrum 15 November 2012. Eric Lopes Cardozo elcardozo@ivarjacobson.com

Use-Case 2.0. Requirements Kenniscentrum 15 November 2012. Eric Lopes Cardozo elcardozo@ivarjacobson.com Use-Case 2.0 Requirements Kenniscentrum 15 November 2012 Eric Lopes Cardozo elcardozo@ivarjacobson.com Agenda Use cases: Een korte geschiedenis Waarom nog steeds use cases gebruiken? Waarom Use-Case 2.0?

Nadere informatie

Global Project Performance

Global Project Performance Return on investment in project management PCI DIAGNOSTIEK IMPLEMENTATIE PRINCE2 and The Swirl logo are trade marks of AXELOS Limited. PCI-DIAGNOSTIEK (PEOPLE CENTERED IMPLEMENTATION) Niet zelden zien

Nadere informatie

voorbeeldexamen I-Tracks Project Participation Foundation (PPF) voorbeeldexamen PPF uitgave oktober 2007

voorbeeldexamen I-Tracks Project Participation Foundation (PPF) voorbeeldexamen PPF uitgave oktober 2007 voorbeeldexamen Project Participation Foundation (PPF) I-Tracks Project Participation Foundation (PPF) voorbeeldexamen PPF uitgave oktober 2007 Inhoud inleiding 2 voorbeeldexamen 3 antwoordindicatie 12

Nadere informatie

Enterprise Portfolio Management

Enterprise Portfolio Management Enterprise Portfolio Management Strategische besluitvorming vanuit integraal overzicht op alle portfolio s 22 Mei 2014 Jan-Willem Boere Vind goud in uw organisatie met Enterprise Portfolio Management 2

Nadere informatie

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. BISL Business Information Services Library Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

Nadere informatie

Satisfy the real (and changing) customer expectation

Satisfy the real (and changing) customer expectation Han Duisterwinkel Test & Quality competence RUP competence LogicaCMG Nederland B.V. Eemsgolaan 1 P.O. Box 70237 9704 AE Groningen The Netherlands www.logicacmg.com @logicacmg.com

Nadere informatie

Medical device software

Medical device software Medical device software Medical device software Software ontwikkeling voor de medische wereld Nspyre Herculesplein 24 3584 AA Utrecht T 088-827 50 00 F 088-827 50 99 www.nspyre.nl Medical devices zijn

Nadere informatie

Combineren PRINCE2 met PMW en Projectmatig Creëren

Combineren PRINCE2 met PMW en Projectmatig Creëren TM PRINCE2 Symposium: Combineren PRINCE2 met PMW en Projectmatig Creëren Bert Hedeman b.hedeman@insights-int.nl PRINCE2TM is a Trade Mark of the Office of Government Commerce Bert Hedeman Partner Insights

Nadere informatie

Architecture Governance

Architecture Governance Architecture Governance Plan van aanpak Auteur: Docent: Stijn Hoppenbrouwers Plaats, datum: Nijmegen, 14 november 2003 Versie: 1.0 Inhoudsopgave 1. INLEIDING... 3 2. PROBLEEMSTELLING EN DOELSTELLING...

Nadere informatie

PRINCE2 Symposium: Zin en Onzin van een Methode. PRINCE 2 versus CMMI; raakvlakken, overlap en aanvullingen SYSQA B.V.

PRINCE2 Symposium: Zin en Onzin van een Methode. PRINCE 2 versus CMMI; raakvlakken, overlap en aanvullingen SYSQA B.V. PRINCE2 Symposium: PRINCE 2 versus CMMI; raakvlakken, overlap en aanvullingen Jan Jaap Cannegieter SYSQA B.V. SYSQA B.V. Operationeel Tactisch Strategisch Testen Requirements Quality assurance Auditing

Nadere informatie

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA.

Handout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven Johan Zandhuis SYSQA Start: 1999 Onafhankelijk Quality Assurance in IT 150 medewerkers (en groeiend) 2 SYSQA Operationeel

Nadere informatie

Prince2 audit. Kwaliteitsmaatregel met rendement

Prince2 audit. Kwaliteitsmaatregel met rendement Prince2 audit Kwaliteitsmaatregel met rendement Niek Pluijmert Dga INQA (samen met Hans) Project- en kwaliteitmanagement Sedert 1979 in ICT Bestuurslid Spider Bestuurslid KvK Midden Nederland TU Delft

Nadere informatie

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Evo Evolutionary Project Management. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Evo Evolutionary Project Management Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. INLEIDING... 3 2. EVO... 4 3. FASERING...

Nadere informatie

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk.

Op de computer kan naar eigen inzicht software op worden geïnstalleerd, een andere besturingssysteem is mogelijk. Planningsfase 1. Afspraken maken over doelstelling en randvoorwaarden De doelstelling van het project: De doelstelling van het project: het maken van het gewenste product. De doelstelling van de student:

Nadere informatie

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2

Testen. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Testen Presentatie Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Algemeen Tegenwoordig behoeft het belang van testen nauwelijks nog te worden uitgelegd. Binnen organisaties speelt

Nadere informatie

Whitepaper Kennis delen voor jouw persoonlijke groei. Prince2 en RUP. één plus één is drie

Whitepaper Kennis delen voor jouw persoonlijke groei. Prince2 en RUP. één plus één is drie Whitepaper Kennis delen voor jouw persoonlijke groei Prince2 en RUP één plus één is drie Trefwoorden Projectmanagement, Methodes, Prince2, Softwareontwikkeling, RUP, Kwaliteit Prince2 PRojects In Controlled

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Global Project Performance

Global Project Performance Return on investment in project management P3M3 DIAGNOSTIEK IMPLEMENTATIE PRINCE2 and The Swirl logo are trade marks of AXELOS Limited. P3M3 -DIAGNOSTIEK (PROJECT PROGRAMMA PORTFOLIO MANAGEMENT MATURITY

Nadere informatie

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1

Socio-technisch systemen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Socio-technisch systemen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 1 Systeem categoriën Technische op computer gesteunde systemen Systemen die HW en SW bevatten, maar waar

Nadere informatie

Programme Power. De weg van Portfoliomanagement naar Programmaregie

Programme Power. De weg van Portfoliomanagement naar Programmaregie Programme Power De weg van Portfoliomanagement naar Programmaregie Agenda Introductie Stedin Historie van Project- en Portfoliomanagement Van Portfoliomanagement naar Programmaregie Waar staan we nu Oog

Nadere informatie

Readiness Assessment ISMS

Readiness Assessment ISMS Readiness Assessment van ISMS ISO/IEC27001:2005 1 Senior Internal/IT auditor Luyke Tjebbes EMIA RO CISA Lead Auditor ISO/IEC27001:2005 Projectleider ISO assessment 2 Wat is ISO 27001 eigenlijk? ISO/IEC

Nadere informatie

ArchiMate voor kennismodellen van NORA en haar dochters. Marc Lankhorst 16 oktober 2013

ArchiMate voor kennismodellen van NORA en haar dochters. Marc Lankhorst 16 oktober 2013 ArchiMate voor kennismodellen van NORA en haar dochters Marc Lankhorst 16 oktober 2013 Agenda 13:00 introductie ArchiMate-status en -ontwikkelingen en NORA-kennismodel 14:00 parallelle workshops rond de

Nadere informatie

TFS als perfecte tool voor Scrum

TFS als perfecte tool voor Scrum TFS als perfecte tool voor Scrum René van Osnabrugge renevo@delta-n.nl About me René van Osnabrugge Communicate @renevo renevo@delta-n.nl http://osnabrugge.wordpress.com Agenda Wat is Scrum? Wat is ALM

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

From business transactions to process insights. BPM Round Table, TU/e 26 mei 2014

From business transactions to process insights. BPM Round Table, TU/e 26 mei 2014 From business transactions to process insights BPM Round Table, TU/e 26 mei 2014 Agenda 1 2 3 4 Korte introductie Process mining in de audit Enkele voorbeelden Uitdagingen & de toekomst 1 Korte introductie

Nadere informatie

Hans Jurgen Kroon Industrial HVAC Control Solutions hjkroon@ihcs033.nl

Hans Jurgen Kroon Industrial HVAC Control Solutions hjkroon@ihcs033.nl Hans Jurgen Kroon Industrial HVAC Control Solutions hjkroon@ihcs033.nl Introductie IHCS Introductie Industrial HVAC Control Solutions Commissioning in Farmacie Uitgangspunten van de Farmacie Commissioning

Nadere informatie

Enterprise Architectuur. een duur begrip, maar wat kan het betekenen voor mijn gemeente?

Enterprise Architectuur. een duur begrip, maar wat kan het betekenen voor mijn gemeente? Enterprise Architectuur een duur begrip, maar wat kan het betekenen voor mijn gemeente? Wie zijn we? > Frederik Baert Director Professional Services ICT @frederikbaert feb@ferranti.be Werkt aan een Master

Nadere informatie

Projeffect Issuemanagement proces [Setup]

Projeffect Issuemanagement proces [Setup] Projeffect Issuemanagement proces [Setup] Versie Documentnaam Datum 20-10-2014 Auteur M.S.Smilde Versie 1.0 concept Projeffect_Issuemanagement_processetup_v1_0.doc copyleft Projeffect BV: alles uit deze

Nadere informatie

Projectmanagement De rol van een stuurgroep

Projectmanagement De rol van een stuurgroep Projectmanagement De rol van een stuurgroep Inleiding Projecten worden veelal gekenmerkt door een relatief standaard projectstructuur van een stuurgroep, projectgroep en enkele werkgroepen. De stuurgroep

Nadere informatie

Business Process Management

Business Process Management Business Process Management Prof. dr. Manu De Backer Universiteit Antwerpen Katholieke Universiteit Leuven Hogeschool Gent Wat is een bedrijfsproces? Een verzameling van (logisch) gerelateerde taken die

Nadere informatie

Wat maakt een project en/of programma succesvol?

Wat maakt een project en/of programma succesvol? Wat maakt een project en/of programma succesvol? Bijeenkomst 4 april 2011 Drs. Sylvie Rath Voor informatie verwijs ik graag naar de website van WagenaarHoes, mijn laatste werkgever (www.wagenaarhoes.nl)

Nadere informatie

Martin van Leeuwen Happy Testing

Martin van Leeuwen Happy Testing Titel, samenvatting en biografie Samenvatting: Deze presentatie beschrijft een aantal test maatregelen die in een RUP nieuwbouw project zijn genomen, om ervoor te zorgen dat het testen aan het eind van

Nadere informatie

notitie Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen Definitief; vastgesteld Stuurgroep 4P

notitie Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen Definitief; vastgesteld Stuurgroep 4P notitie Van project onderwerp opgemaakt door Systems Engineering Lesplan Requirements Engineering (RE) Werkgroep opleidingen status datum opmaak 20-7-2012 bijlagen Definitief; vastgesteld Stuurgroep 4P

Nadere informatie

Programma 14 november middag. Risicomanagement Modellen. Strategisch risicomanagement

Programma 14 november middag. Risicomanagement Modellen. Strategisch risicomanagement Programma 14 november middag Risicomanagement Modellen Strategisch risicomanagement Kaplan 1www.risicomanagementacademie.nl 2www.risicomanagementacademie.nl Risicomanagement modellen Verscheidenheid normen

Nadere informatie

IV SDM - FASE 2 BASISONTWERP

IV SDM - FASE 2 BASISONTWERP IV SDM - FASE 2 BASISONTWERP IV.1 Inleiding Zoals reeds besproken onderkent het in Nederland veel gebruikte SDM II (System Development Methodology, versie II), bij de bouw van informatiesystemen de volgende

Nadere informatie

DEEL I 5.5 PRINCE2. 5.5.1 Definitie project. 5.5.2 Kern van PRINCE2. 5.5.3 Historie. 5.5.4 Scope. 5.5.5 Uitgangspunten

DEEL I 5.5 PRINCE2. 5.5.1 Definitie project. 5.5.2 Kern van PRINCE2. 5.5.3 Historie. 5.5.4 Scope. 5.5.5 Uitgangspunten 5 Projectmanagementmethoden 83 5.5 PRINCE2 Deel I van de beschrijving van PRINCE2 is geschreven door Ron Seegers en gereviseerd en geautoriseerd door Joost Nuijten, bestuurslid van de Prince User Group

Nadere informatie

Requirements Lifecycle Management

Requirements Lifecycle Management Lifecycle Management Wat is het? Waarom is het belangrijk? Presentatie: Marcel Overeem Groep: Berend van Huffelen, Renze Zijlstra, Martijn Ramaekers, Marcel Overeem Agenda Onderwerpen Aanleiding Lifecycle

Nadere informatie

Whitepaper. Exploratory Testing. Waarom doen we dat niet altijd? door Dennis Joele

Whitepaper. Exploratory Testing. Waarom doen we dat niet altijd? door Dennis Joele Whitepaper Exploratory Testing Waarom doen we dat niet altijd? door Dennis Joele Dennis Joele is werkzaam als test designer bij TriOpSys en heeft als zodanig voor de Dienst der Hydrografie van de Koninklijke

Nadere informatie

Zuivere Speeltijd 7 JUNI 2012. Achmea IT: Portfoliobeheersing door batenrealisatiemanagement 15E BPUG SEMINAR

Zuivere Speeltijd 7 JUNI 2012. Achmea IT: Portfoliobeheersing door batenrealisatiemanagement 15E BPUG SEMINAR Zuivere Speeltijd 15E BPUG SEMINAR 7 JUNI 2012 Achmea IT: Portfoliobeheersing door batenrealisatiemanagement Introductie: Drs. Guus van der Weijden RC 29 jaar uit Arnhem, samenwonend Motorrijden, zwemmen,

Nadere informatie

Kwaliteit in Agile: een gegeven?

Kwaliteit in Agile: een gegeven? QA in Agile: waste? Kwaliteit in Agile: een gegeven? Een praktijkvoorbeeld Arno Balemans senior Quality Assurance consultant Bussum, 29 september 2015 Kwaliteit in Agile 2015 2 Werkzaamheden In mijn opdrachten:

Nadere informatie

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV

Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Test Automatisering? Mislukken Slagen gegarandeerd! Ruud Teunissen - Polteq Test Services BV Mislukken Slagen gegarandeerd 2 Mislukken Slagen gegarandeerd Management verwacht onmiddellijk R.O.I. Doel:

Nadere informatie

Wat kleurt de invulling van het PMO

Wat kleurt de invulling van het PMO Wat kleurt de invulling van het PMO PMO Congres 13-3-2014 Michiel Dijkman PgMP Opbouw presentatie 1. Mijn achtergrondkleur 2. De eerste keer 3. Wat kleurt het succes 4. Wat kleurt de plaats 5. Wat kleurt

Nadere informatie

Conferentie Examinering in de bpv 31 mei 2013 Workshop : handboeken BPV en het buitenland

Conferentie Examinering in de bpv 31 mei 2013 Workshop : handboeken BPV en het buitenland Conferentie Examinering in de bpv 31 mei 2013 Workshop : handboeken BPV en het buitenland Andre van Voorst : sr adviseur Kenwerk / Examenwerk Mirjam Hensels : projectleider BPV Handboeken Programma Inleiding

Nadere informatie

Model driven Application Delivery

Model driven Application Delivery Model driven Application Delivery Fast. Flexible. Future-proof. How Agis streamlines health procurement using Mendix Model driven Application Platform Mendix in a nutshell Mendix delivers the tools and

Nadere informatie

Projectmanagement update

Projectmanagement update Projectmanagement update Alfred Krol Triple Plus BV Even voorstellen PRINCE2 is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries. The Swirl logo is

Nadere informatie

Projectmanagementenquête 2007

Projectmanagementenquête 2007 Projectmanagementenquête 2007 Handvatten voor succesvolle projecten 21 maart 2007 Bisnez Management in samenwerking met het IT Trends Institute en de Vrije Universiteit van Amsterdam copyright by Bisnez

Nadere informatie

EXIN WORKFORCE READINESS professional

EXIN WORKFORCE READINESS professional EXIN WORKFORCE READINESS professional DE ERVARING LEERT ICT is overal. Het is in het leven verweven geraakt. In een wereld waarin alles steeds sneller verandert, is het lastig te bepalen wat er nodig is

Nadere informatie

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Data Warehouse. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Data Warehouse Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 DOEL VAN

Nadere informatie

Beveiligingsaspecten van webapplicatie ontwikkeling met PHP

Beveiligingsaspecten van webapplicatie ontwikkeling met PHP RADBOUD UNIVERSITEIT NIJMEGEN Beveiligingsaspecten van webapplicatie ontwikkeling met PHP Versie 1.0 Wouter van Kuipers 7 7 2008 1 Inhoud 1 Inhoud... 2 2 Inleiding... 2 3 Probleemgebied... 3 3.1 Doelstelling...

Nadere informatie

Functieprofiel: Projectleider Functiecode: 0302

Functieprofiel: Projectleider Functiecode: 0302 Functieprofiel: Projectleider Functiecode: 0302 Doel Voorbereiden en opzetten van en bijbehorende projectorganisatie, alsmede leiding geven aan de uitvoering hiervan, binnen randvoorwaarden van kosten,

Nadere informatie

Tmap Dag 2015. Ik test, jij test, wij testen. Testen binnen een Wendbare Belastingdienst. 29 september 2015. Laurens Kremer

Tmap Dag 2015. Ik test, jij test, wij testen. Testen binnen een Wendbare Belastingdienst. 29 september 2015. Laurens Kremer Tmap Dag 2015 Ik test, jij test, wij testen Testen binnen een Wendbare Belastingdienst 29 september 2015 Laurens Kremer Introductie Naam: Laurens Kremer, SPC, CISA Rol: Agile coach Informatie Management

Nadere informatie

WHITE PAPER. Projectmanagement

WHITE PAPER. Projectmanagement WHITE PAPER Projectmanagement Volgens Prodapt Consulting vormt een uitgebalanceerde mix van specifieke kennis, vaardigheden en de projectmanager als persoon, naast vakkennis de sleutel tot succesvol projectmanagement.

Nadere informatie

Portal Planning Process

Portal Planning Process BROCHURE Portal Planning Process SAMENWERKEN AAN EEN WAARDEVOL PORTAAL BROCHURE PORTAL PLANNING PROCESS 2 Axians PORTAL PLANNING PROCESS BROCHURE Inhoud Introductie 4 3 Portal Planning Process 5 4 Uitdagingen

Nadere informatie

Agile bij grote administratieve systemen. Omgaan met requirements

Agile bij grote administratieve systemen. Omgaan met requirements Agile bij grote administratieve systemen Omgaan met requirements 1 Agenda Wat is een groot systeem? Aanpak van een groot systeem Agile alignment Agile en requirements (en architectuur) Agile en governance

Nadere informatie