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

Maat: px
Weergave met pagina beginnen:

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

Transcriptie

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 is de System Analist 1. De System Analist is verantwoordelijk voor het vaststellen van de eisen en wensen en het vertalen van deze eisen en wensen in specificaties voor de realiseren oplossing. Deze specificaties worden vastgelegd in een Software Set (SRS). De System Analist wordt hierbij ondersteund door de User Interface Designer die de specificaties ten aanzien van de User Interface uitwerkt. Belangrijke reviewers binnen het projectteam voor de System Analist zijn de Project Architect en de Test Analist. Aanpak De System Analist werkt de specificaties op hoofdlijnen uit in een Use Case Model, waarbij gebruik wordt gemaakt van het Proces Architectuur Model (PAM) 2, waarin de processen en activiteiten zijn weergegeven. De geïdentificeerde Use Cases worden vervolgens verder uitgewerkt in Use Case Specifications en Supplementary Specifications. In de Supplementary Specifications worden algemene specificaties vastgelegd die geldig zijn voor meerdere Use Cases en niet functionele specificaties. Parallel aan het optellen en uitwerken van het Use Case Model door de System Analist werkt de User Interface Designer de specificaties van de User Interface verder uit. Op niveau van het Use Case Model wordt dit vastgelegd in Storyboards en op het niveau van de Use Case Specifications in User Interface Specifications. Het Use Case Model, de Use Case Specifications en de Supplementary Specifications vormen tezamen met de User Inter Specifications de System Set (SRS). Storyboards vormen geen onderdeel van de SRS maar zijn een middel om tot de User Interface Specifications te komen en blijken in de praktijk zeer bruikbaar als basis voor discussie. Diepgang De betrokkenheid van de System Analist begint al in een vroegtijdig stadium (Conception fase) met het vaststellen van het probleem, stakeholders, scope en de belangrijkste eisen en wensen. Deze zaken worden de Conception fase in een concept Vision beschreven. Tijdens de planvorming (Inception fase) vindt de uitwerking van de concept Vision plaats. Dit betekent dat het probleem, de stakeholders, scope en eisen en wensen definitief worden vastgesteld. Tevens moet tijdens de planvorming benoemd zijn welke functionele risico s op welke wijze worden uitgewerkt in de Elaboration-fase. Tijdens de uitwerking en risico-eliminatie (Elaboration) worden de Use Cases zover uitgewerkt dat een risicovrije constructie mogelijk is. Dit betekent dat de Use Cases tot het niveau 'Functioneel Ontwerp zijn uitgewerkt. Tijdens de realisatie (Construction) en uitrolfase (Transition) beperkt de inzet van de System Analist zich uitsluitend tot scopebewaking (RfC procedure) en het actualiseren van de Use Cases. Belangrijk is dat met name in de eerste fasen voldoende tijd voor de System Analist wordt ingepland zodat de requirements volledig kunnen worden uitgewerkt. 1 Ook wel Business Proces Analist, Business Analist, e.d. genoemd 2 Het PAM wordt opgesteld door de Business Process Analist en wordt gebruikt als houvast voor de decompositie van bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept. Infocon Versie 0.1 Pagina 1 van 8

2 1.2. Rollen Wat doet de System Analist De System Analist is verantwoordelijk voor het vaststellen en vastleggen van requirements, maar ook voor het zorgdragen voor de juiste beeldvorming en het creëren van draagvlak. De System Analist heeft met name ook een communicatierol waarin beelden in de omgeving worden neergezet. Taken System Analist De activiteiten voor de System Analist zijn voor de Conception- en Inception-fase weergegeven in hoofdstuk 2 Activiteiten in Conception fase resp. hoofdstuk 3 Activiteiten in Inception fase 1.3. Samenhang begrippen Centraal in de discipline staat de focus op het probleem en niet op de oplossing. Op basis van het geconstateerde probleem worden de needs, features en requirements (doel-middelen hiërarchie) vastgesteld. Deze zaken worden vastgelegd in de deliverables Vision en SRS. Probleem versus oplossing De requirementsdiscipline richt zich nadrukkelijk op het op het lossen probleem en de eisen/wensen aan de oplossing en niet de oplossing zelf. Om gefundeerde requirements op te stellen is eerst een gedegen analyse van het probleem noodzakelijk ("Wat is het echte probleem waarvoor een oplossing moet worden gezocht?"). Infocon Versie 0.1 Pagina 2 van 8

3 Vervolgens is een gemeenschappelijke visie nodig voor alle belanghebbenden, waarin zowel het probleem als het systeem worden geschetst. Doel-middelen hiërarchie De requirement statements vormen een doel-middelen hiërarchie. Op het hoogste niveau onderkennen we de behoeften van de belanghebbenden (stakeholder needs). Deze business needs worden elk ingevuld door één of meer kenmerken die het systeem moet bieden (system features). De system features worden gerealiseerd in benoemde Use Cases en concreet gemaakt door een set aan detaileisen die aan betreffende Use Cases worden gesteld. Hiermee ontstaat een doel-middelen hiërarchie. Eisen en wensen die op detailniveau worden gesteld zijn herleidbaar tot features en needs. Indien dit niet het geval is, betekent dit dat er nog niet onderkende needs en features zijn die leiden tot een verschuiving in de scope (ofwel scope creep) of dat de detailrequirements die niet tot de scope behoren of niet bijdragen aan de doelen en dus kritisch moeten worden bekeken. Samenhang deliverables Binnen deze discipline spelen de volgende deliverables een belangrijke rol: Vision. Dit document is bedoeld voor beeldvorming en scope en vormt de onderbouwing van planvorming (PlD). De Vision bevat de volgende onderwerpen: probleem, needs, features, stakeholders, scope/omvang en oplossingsrichting (vanuit Anlysis&Design-discipline). Daarnaast wordt ook het visueel concept (de User lnterface op hoofdlijnen) vastgelegd. SRS (System Set), bestaande uit Use Case Model, Use Case Specifications en Supplementary Specifications. De SRS vormt in wezen het contract tussen gebruikers en project en vormt de baseline voor de bouwers. Binnen de SRS worden ook de specificalies van de User Interface vastgelegd. vastlegging Levensloop van de Use Case Use Case is geïdentificeerd en benoemd: de Use Cases zijn opgenomen in het Use Case Model en voorzien van korte omschrijving. Infocon Versie 0.1 Pagina 3 van 8

4 Use Case is globaal beschreven: outlined en alle alternate flows benoemd. Hiermee zijn de Use Case Scenario's geïdentificeerd. Use Case is in detail beschreven: alle flows zijn nader gedetailleerd, de pre-post conditions zijn beschreven, etc. De gedetailleerde beschrijving van de Use Cases is opgenomen in de Use Case Specifications. Use Case Model Dit is het context diagram van het systeem en nodig voor de afbakening van de scope. Het Use Case Model is een model van de functies van het systeem in de context van de omgeving die het systeem gebruikt. Als input wordt hiervoor het PAM model (Business Modeling) gebruikt, hierin zijn de onderkende activiteiten en te realiseren services weergegeven. Use Case Scenario s Use Case Scenario's worden geïdentificeerd door alle flows in samenhang te benoemen. De relevante paden worden in Use Case Scenario's benoemd en vormen tevens de basis voor test. De Use Case Scenario's worden gereviewd vanuit de Test-discipline. Parallel werkt de Test-discipline de scenario's uit in Test Scenario's. Deze Test Scenario's vormen een toets op de juistheid/correctheid van de Use Case-beschrijvingen. In de praktijk roept de review vanuit test vragen/opmerkingen op die helpen de Use Case Specifications consistent en compleet te maken. Use Case Specifications De Use Cases uit het Use Case Model worden in detail beschreven in Use Case Specifications, zodat deze door de Ontwikkelaar eenduidig kunnen worden geïnterpreteerd. In de specificotions wordt aandacht besteed aan de aanwezige velden, validaties, handelingen, etc. Algemene (niet-functionele) of Use Case overstijgende specificaties worden vastgelegd in de Supplementary Specifications. De Use Case Specifications worden gereviewd vanuit de Analysis&Design-discipline. Parallel werkt Analysis&Design de specificaties verder uit in Use Case Realizations. Deze vormen een toets op de juistheid/correctheid van de Use Case Specifications. In de praktijk roept de review vanuit Analysis&Design vragen/opmerkingen op die helpen de Use Case Specifications consistent en compleet te maken. Use Case Realizations Use Case Realizations zijn de vertaling van de interactie zoals beschreven in de flows van een Use Case (blackbox) naar welke interactie daarvoor binnen het systeem tussen de componenten moet plaatsvinden (whitebox). Deze worden opgesteld vanuit de Analysis&Design-discipline en vormen een toets van de specificaties aan de architectuur (SAD). De Use Case Realizations zijn opgenomen in het Analysis Model. Binnen de Analysis&Design-discipline wordt het Analysis Model verder gedetailleerd in het Design Model. User Interface Design De User Interface wordt op drie niveaus beschreven: op het niveau van de Vision wordt een visueel concept van de User Interface gemaakt ter ondersteuning van de beeldvorming; op het niveau van het Use Case Model worden Storyboards gemaakt; op het niveau van de Use Case Specifications worden User Interface Specifications gemaakt. Hierin zijn de visuele aspecten van de User Interface in detail beschreven. Visueel Concept en Storyboards zijn hulpmiddelen om te komen tot (User Interface) specificaties en maken formeel geen deel uit van de System Requirement Set (SRS). Toch bieden de visualisaties vaak ook na vaststelling van de specificaties toegevoegde waarde in discussies. Echter, planmatig zijn alleen afspraken vastgelegd in de SRS leidend voor het project. Situationeel zal een afweging worden gemaakt tussen deze toegevoegde waarde en dubbel onderhoud om visueel concept en/of Storyboards in lijn te houden met de (User Interface) specificaties. Aandachtspunt hierbij is ook hoe om te gaan met User Interface Specifications in het beheer. Als uitgangspunt is de actuele versie van het systeem leidend. Onderhoud op specificaties kan worden beperkt door een Infocon Versie 0.1 Pagina 4 van 8

5 scheiding te hanteren tussen User Interface Specifications en Use Case Specifications en uitsluitend de Use Case Specifications samen met het systeem over te dragen als systeemdocumentatie voor beheer. Immers de User Interface van het gerealiseerde systeem is altijd actueel Aanpak en diepgang De System Analist start in de Conception-fase met het analyseren van het probleem en het in kaart brengen van de needs die de stakeholders hebben. Op basis van deze needs worden de eisen en wensen (features) die aan de oplossing worden gesteld vastgesteld, waarmee tevens de scope van het te realiseren systeem helder wordt. Aanpak requirements Deze zaken worden tezamen met een beschrijving van de oplossingsrichting (Analysis&Design-discipline) in een concept Vision vastgelegd en vormen input voor de Project Brief. Naast het opstellen van de Vision wordt in de Conception-fase ook het Use Case Model opgesteld, waarin alle geïdentificeerde Use Cases benoemd en kort worden toegelicht. Parallel aan het opstellen van het Use Case Model wordt het (visuele) concept uitgewerkt. De concept Vision wordt in de Inception-fase verder uitgewerkt en vastgesteld (baseline). Tevens wordt het Use Case Model verder uitgewerkt waarbij aan het einde van de Inception-fase de volgende zaken zijn gerealiseerd: voor alle Use Cases uit het Use Case Model is een step-by-step outline opgesteld; alle Use Case Scenario's zijn benoemd. Deze scenario s vormen veelal de basis voor de planning en zijn derhalve een belangrijke input voor het PlD. Belangrijk is hierbij ook dat de scenario s worden gereviewd door de Test discipline, die op basis van hiervan tevens de Test Scenario's kon opstellen; de kritische/complexe Use Cases zijn verder uitgewerkt in Use Case Specifications ten behoeve van schatting en planning. Bij het vaststellen van de kritische Use Case speelt met name de complexiteit een rol. De complexiteit wordt bepaald door een aantal criteria. Een eerste criterium is technologisch van aard (nieuwe technologie waar nog geen ervaring mee is opgedaan, oplossingsrichting waarvan de Project Architect aangeeft dat dit complex is). Andere criteria zijn testbaarheid, gebruik van meerdere platforms, betrokkenheid van meerdere organisatie-onderdelen, betrokkenheid van externe partijen, aantal interfaces. Deze uitgewerkte Use Cases kunnen met name bij het realiseren van het Proof of Concept worden gebruikt. Naast het uitwerken van de Use Cases worden Storyboards gemaakt voor alle kritische Use Cases. In de Elaboration-fase worden alle Use Cases uitgewerkt in Use Case Specifications, waarbij geldt dat alle velden, validaties/controles en handelingen zijn beschreven. Het detailniveau van de Use Case Specifications is zodanig Infocon Versie 0.1 Pagina 5 van 8

6 dat deze niet voor meerdere uitleg vatbaar zijn. Hierbij geldt als richtlijn de 80/20-regel. Dit houdt in dat wel alle Use Cases (100%) uitgewerkt zijn, maar dat de diepgang geen 100% hoeft te zijn. Bepaalde formules kunnen bijvoorbeeld tijdens de Construction-fase nader worden uitgewerkt. Belangrijk is dat de ontbrekende specificaties geen risico's (bijvoorbeeld impact op planning) meer met zich meebrengen aangezien de focus van de elaboration risico eliminatie is en de construction 'risico-vrij' moet kunnen worden uitgevoerd. Tijdens de Construction-fase zal de focus van de System Analist met name gericht zijn op het managen van de scope en het strikt hanteren van de RFC-procedure, als er wijzigingen op de scope zijn. Daarnaast zal de System Analist de nog ontbrekende specificaties uitwerken. Verder zal de System Analist de bevindingen die uit test komen analyseren. Ook in de Transition-fase is de focus van de System Analist met name gericht op het managen van de scope. Daarnaast zal de System Analist ook betrokken zijn bij de overdracht aan de beheerorganisatie, waarbij de System Analist zich met name richt op het overdrogen van de documentatie (SRS). Voor zowel deze als de vorige (Construction-)fase geldt dat de betrokkenheid van de System Analist niet fulltime zal zijn. Een vuistregel is dat de betrokkenheid 10-20% bedraagt van de tijd die tijdens Elaboration is besteed. Infocon Versie 0.1 Pagina 6 van 8

7 2. Activiteiten in Conception fase Tijdens deze fase houdt de zich bezig met de beantwoording van de onderstaande vraagstellingen. De antwoorden worden vastgelegd in de weergegeven documenten, waarbij is aangegeven of het een baseline of een concept betreft. Een baseline product wordt formeel vastgesteld. Vraagstelling Toelichting Verantwoordelijke Betrokkenen Vorm/Document Status Welk probleem moet er worden opgelost? Door het probleem te concretiseren wordt enerzijds een gemeenschappelijke en gedragen probleemstelling vastgesteld, anderzijds wordt de focus voor het project geconcretiseerd Managers, Specialisten, Problem statement in Baseline Bedrijfsbrede architecten Vision document Wie hebben er belang bij de oplossing? Inventarisatie van stakeholders en hun belangen Managers, Bedrijfsbrede architecten Stakeholder tabel in Vision document Schets Wat willen de belanghebbenden (stakeholders) op hoofdlijnen Vanuit de businessdoelen (goals) zijn behoeften (needs) en kenmerken (features) waaraan het systeem moet voldoen vast te stellen Managers, Bedrijfsbrede Needs & Features tabel Schets architecten in Vision document Hoe ziet het visuele concept eruit? Eerst indruk van de interactie tussen gebruikers en systeem ondersteund door Project team, Visueel concept Schets User Interface Designer Specialisten Wanneer is de oplossing akkoord, ofwel wat zijn de acceptatiecriteria op hoofdlijnen? Vooraf te bepalen (toetsbare) criteria op basis waarvan het projectteam de oplossing gaat uitwerken en op basis waarvan aan het einde het projectresultaat kan worden getoetst Managers, Specialisten, Bedrijfs-brede Architecten Project Brief, detaillering in Vision (eventueel PAP 3 ), Baseline (Project Brief) Schets (Vision) 3 Product Acceptatie Plan Infocon Versie 0.1 Pagina 7 van 8

8 3. Activiteiten in Inception fase Tijdens deze fase houdt de zich bezig met de beantwoording van de onderstaande vraagstellingen. De antwoorden worden vastgelegd in de weergegeven documenten, waarbij is aangegeven of het een baseline of een concept betreft. Een baseline product wordt formeel vastgesteld. Vraagstelling Toelichting Verantwoordelijke Betrokkenen Vorm/Document Status Welk probleem moet er opgelost worden? Mogelijke wijzigingen in de probleemstelling worden formeel vastgelegd Managers, Specialisten, Problem statement in Baseline Bedrijfsbrede architecten Vision document Wie hebben welke belangen bij de oplossing? In deze fase is het van belang om naast de belanghebbenden ook hun rol en hun (verschillende) belangen gedetailleerd in beeld te brengen Managers, Bedrijfsbrede Stakeholder table in Baseline architecten Vision document Wat willen de belanghebbenden (stakeholders) in detail? Vanuit de business doelen (goals) zijn behoeften (needs) en kenmerken (features) waaraan het systeem moet voldoen vast te stellen Managers, Bedrijfsbrede Needs & Features tabel Baseline architecten in Vision document Wat zijn de specificaties voor de meest cruciale onderdelen van het systeem? Beschrijving van de belangrijkste functionaliteit. Deze dient ter uitwerking van de beeldvorming en scope en vormt een belangrijke basis voor het schatten van de omvang. Uitwerking vindt plaats door uitwerking van alle Use Cases op hoofdlijnen en significante Use Cases in meer detail. Uitwerking is gericht op het afdoende bepalen van complexiteit en omvang alsook het voorbereiden van uitwerkingen ten behoeve van risico eliminatie in de volgende fase Project team, Specificaties (System Baseline Specialisten Requirement Set) Hoe vindt de interactie met de gebruiker plaats? Visueel ontwerp van de interactie. Deze maakt onderdeel uit van de specificaties en dient in deze versie net als de significante Use Cases ter uitwerking van de scope en beeldvorming en vormt een belangrijke basis voor het schatten van de omvang ondersteund door Projectteam, Specialisten Storyboards Baseline User Interface Designer Wanneer is de oplossing akkoord, ofwel wat zijn de acceptatiecriteria? De acceptatiecriteria worden meetbaar gemaakt (SMART) Managers, Specialisten, Bedrijfs-brede Architecten PAP, desgewenst opgenomen in PID, hoofdlijnen vastgelegd in Vision Baseline Hoe ziet de acceptatiestrategie eruit? Vanuit de overall aanpak is een aantal specifieke onderdelen onderkend waarvoor expliciet gekeken wordt naar de te hanteren strategie als input voor de gehele projectaanpak. Op basis van de eerste beelden over aanpak/uitrol, projectresultaten en acceptatiecriteria wordt een teststrategie met bijbehorende planningsconsequenties vastgesteld Projectmanager i.s.m. Project team, Specialisten PID, desgewenst detaillering in PAP Baseline Infocon Versie 0.1 Pagina 8 van 8

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

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

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

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

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

De tester als bruggenbouwer

De tester als bruggenbouwer De tester als bruggenbouwer Tim Koomen Testnet voorjaarsevenement 9 juni 2004 Agenda Bruggen Enkele bruggen toegelicht De bruggenbouwer Trends Sogeti Nederland B.V. Pagina 1 Bruggen Systeem Beheer Stuur

Nadere informatie

Business Case. <>

Business Case. <<Naam project>> Business Case SYSQA B.V. Almere Versie : Datum : Status : Opgesteld door : Pagina 2 van 8 Inhoudsopgave 1 Inleiding... 1.1 Doel van dit document...

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

Requirements in een groot project

Requirements in een groot project Requirements in een groot project Gastcollege Technische Universiteit Eindhoven Harry Nieboer Insteek vandaag Requirements in de praktijk Eerst Requirements in een klein project (één software engineer

Nadere informatie

RUP Rational Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

RUP Rational Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. RUP Rational Unified Process Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 14 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER...

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

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

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V.

Regressietesten. De aanpak en aandachtspunten. Algemene informatie voor medewerkers van: SYSQA B.V. Regressietesten De aanpak en aandachtspunten Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING...3 1.1 ALGEMEEN...3 1.2 VERSIEBEHEER...3

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

Business Scenario. Voorbeeld Archimate Risico Extensie. versie 0.1. Bert Dingemans

Business Scenario. Voorbeeld Archimate Risico Extensie. versie 0.1. Bert Dingemans Business Scenario Voorbeeld Archimate Risico Extensie versie 0.1 Bert Dingemans Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging Review historie Naam Afdeling Functie Datum

Nadere informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

Kwaliteitsbewaking en testen in ICT beheerorganisaties DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt

Nadere informatie

Doen of laten? Een dag zonder risico s is een dag niet geleefd

Doen of laten? Een dag zonder risico s is een dag niet geleefd Doen of laten? Een dag zonder risico s is een dag niet geleefd Wie, wat en hoe Eric Lopes Cardozo & Rik Jan van Hulst sturen naar succes Doel Delen van inzichten voor praktisch operationeel risico management

Nadere informatie

Bijlage 3: Master testplan

Bijlage 3: Master testplan Bijlage 3: Master testplan KIS Testplan Inaxion Lelystad Adres: Jol -20 Postbus : 609 Postcode Plaats 8483 ED Lelystad I www.inaxion.nl Plaats Lelystad Datum 22 maart 200 Auteur Saidou Diallo Status Finaal.0

Nadere informatie

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. Unified Process Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding... 3 2. Unified Process... 4 3. Fasering... 5 3.1.

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

HERGEBRUIK VAN REQUIREMENTS

HERGEBRUIK VAN REQUIREMENTS HERGEBRUIK VAN REQUIREMENTS EEN PRAKTISCHE AANPAK BUSINESS ANALYSE CENTER OF EXCELLENCE - SYNERGIO Inhoudsopgave 1 HERGEBRUIK VAN REQUIREMENTS... 3 1.1 GEBRUIKEN VERSUS HERGEBRUIKEN... 4 2 STRATEGIE...

Nadere informatie

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER

VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER VAN USE CASE NAAR TEST CASE ORDINA SMART COMPETENCE CENTER Sander Hoogendoorn Versie 1.0 15 april 2002 Documentbeheer Versie Datum Auteur Omschrijving 0.1 15 April 2002 Sander Hoogendoorn 0.2 15 april

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

SMART requirements schrijven

SMART requirements schrijven SMART requirements schrijven Reverse Engineering als aanpak voor leren Requirements Kenniscentrum 27 maart 2012, 18:50 19:30 uur Hossein Chamani, docent en trainer bij Hogeschool Rotterdam 1 Introductie

Nadere informatie

het doel, de keuzen zijn gebaseerd op kennis en ervaring van de deelnemers van de bijeenkomsten.

het doel, de keuzen zijn gebaseerd op kennis en ervaring van de deelnemers van de bijeenkomsten. Rational Unified Process: aandachtspunten voor de auditor Systeemontwikkelingsorganisaties introduceren met regelmaat nieuwe of andere softwareontwikkelmethoden. Vaak ligt hier een ontevredenheid over

Nadere informatie

Stakeholder behoeften beschrijven binnen Togaf 9

Stakeholder behoeften beschrijven binnen Togaf 9 Stakeholder behoeften beschrijven binnen Togaf 9 Inventarisatie van concerns, requirements, principes en patronen Bert Dingemans Togaf 9 kent verschillende entiteiten om de behoeften van stakeholders te

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

Van Samenhang naar Verbinding

Van Samenhang naar Verbinding Van Samenhang naar Verbinding Sogeti Page 2 VAN SAMENHANG NAAR VERBINDING Keuzes, keuzes, keuzes. Wie wordt niet horendol van alle technologische ontwikkelingen. Degene die het hoofd koel houdt is de winnaar.

Nadere informatie

Oplossingsvrij specificeren

Oplossingsvrij specificeren Oplossingsvrij specificeren ir. J.P. Eelants, projectmanager Infrabouwproces CROW Samenvatting De methodiek van oplossingsvrij specificeren richt zich niet alleen op het formuleren van functionele eisen.

Nadere informatie

1. Business Proces Modeling

1. Business Proces Modeling 1. 1.1. Inleiding Doel Een eerste onderdeel in ERP en Kwaliteitsmaatregelen is. Deze discipline is vooral van belang om de context te beschrijven waarbinnen en waartoe (met welk doel) de verandering (de

Nadere informatie

Teststrategie met behulp van heuristieken

Teststrategie met behulp van heuristieken Workshop TestNet Teststrategie met behulp van heuristieken www.improveqs.nl (info@improveqs.nl) Versie 2.0 1 Acknowledgements Met dank aan: Ruud Cox voor de vele discussies over dit onderwerp Fiona Charles

Nadere informatie

Titel, samenvatting en biografie

Titel, samenvatting en biografie Titel, samenvatting en biografie \ Peter Wanders De Black Box Dialog methode Voorjaarsevent Testnet: 22 juni 2009 Samenvatting Nog nooit heb ik heb een klant horen zeggen: Enorm vervelend dat het IT project

Nadere informatie

Tips & Tricks: Tip van de maand januari 2009

Tips & Tricks: Tip van de maand januari 2009 Tips & Tricks: Tip van de maand januari 2009 Project Management met Teamcenter 2007 Door: Ramon van Raak Beheert u complexe projecten dan weet u als geen ander dat de projectvoorbereiding de basis legt

Nadere informatie

Het BiSL-model. Een whitepaper van The Lifecycle Company

Het BiSL-model. Een whitepaper van The Lifecycle Company Het BiSL-model Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht op hooflijnen van het BiSL-model. U vindt een overzicht van de processen en per proces een beknopte

Nadere informatie

Van requirements naar teststrategie

Van requirements naar teststrategie Van requirements naar teststrategie Testnet 7 januari 009 Ruud Harreman Appie Pries Waarom dit onderwerp? Leveranciersperspectief Bestaande testmethodes geven weinig aanknopingspunten hoe requirements

Nadere informatie

Requirements Management Werkgroep Traceability

Requirements Management Werkgroep Traceability Requirements Management Werkgroep Traceability Plan van Aanpak (1) Doel en definitie van Traceability Traceability heeft tot doel om tijdens het ontwikkelproces status informatie te verschaffen omtrent

Nadere informatie

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol. Datum: dd-mm-jj

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol. Datum: dd-mm-jj BUSINESS CASE: Versie Naam opdrachtgever Naam opsteller Datum: dd-mm-jj Voor akkoord: Datum: LET OP: De bedragen in deze business case zijn schattingen op grond van de nu beschikbare kennis en feiten.

Nadere informatie

Dragon1 EA Tool. Business case webbased EA tool. Een webbased EA tool geschikt voor elke architectuurmethode!

Dragon1 EA Tool. Business case webbased EA tool. Een webbased EA tool geschikt voor elke architectuurmethode! Dragon1 EA Tool Business case webbased EA tool Een webbased EA tool geschikt voor elke architectuurmethode! uw organisatie, datum, versie #.#, documentstatus eigenaar/budgetverantwoordelijke: Kies op deze

Nadere informatie

Product Risico Analyse

Product Risico Analyse Product Risico Analyse Jurian van de Laar TestNet Avond 9 oktober 2013 www.improveqs.nl (info@improveqs.nl) Versie 2.0 1 Herkenbaar? In ons testproces wordt product risico analyse toegepast Wij gebruiken

Nadere informatie

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Drechtsteden Technische Architectuur (DTA) ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Status : Definitief 1.0 Redactie : DTA Datum : 29-08-2007 1 Versiebeheer

Nadere informatie

Businesscase. Dit document is een sjabloon voor een businesscase rond sourcing en is gebaseerd op artikelen uit het blad Informatie Magazine.

Businesscase. Dit document is een sjabloon voor een businesscase rond sourcing en is gebaseerd op artikelen uit het blad Informatie Magazine. Businesscase Dit document is een sjabloon voor een businesscase rond sourcing en is gebaseerd op artikelen uit het blad Informatie Magazine. Colofon Datum 14 oktober 2010 Referentie Auteur BusinessCase

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

Taakcluster Operationeel support

Taakcluster Operationeel support Ideeën en plannen kunnen nog zo mooi zijn, uiteindelijk, aan het eind van de dag, telt alleen wat werkelijk is gedaan. Hoofdstuk 5 Taakcluster Operationeel support V1.1 / 01 september 2015 Hoofdstuk 5...

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

TestNet voorjaarsevenement 2014 Managen van een KetenTest bij NS met hun TOPAAS toolsuite. Managen van een Ketentest bij NS met hun TOPAAS tool-suite

TestNet voorjaarsevenement 2014 Managen van een KetenTest bij NS met hun TOPAAS toolsuite. Managen van een Ketentest bij NS met hun TOPAAS tool-suite Managen van een Ketentest bij NS met hun TOPAAS tool-suite Bart Broekman mei 2014 Onderwerpen De (prachtige) TOPAAS tooling De (niet zo prachtige) project-situatie De (oh zo mooie) dingen die we ermee

Nadere informatie

Hoe ver moet je gaan?

Hoe ver moet je gaan? Hoe ver moet je gaan? Requirements verzamelen in agile John Copier; Marcel Steur 8 oktober 2015 Introductie Marcel + Qquest Informatica TU Delft Bedrijfskunde HSA + VU IT combineren met bedrijfskunde Qquest

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

De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4. Rolbeschrijvingen

De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4. Rolbeschrijvingen De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4 V1.1 / 01 september 2015 MCTL v1.1 4. : taken, bevoegdheden en verantwoordelijkheden... 3 Rol Key-user...

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

Voorbeeld projectplan

Voorbeeld projectplan Voorbeeld projectplan Projectplan voor project < naam > Naam project Datum Naam projectleider Naam opdrachtgever Startdatum Einddatum Doorlooptijd in weken/ maanden Datum Versie Status Auteur(s) Maak een

Nadere informatie

Technische architectuur Beschrijving

Technische architectuur Beschrijving A gemeente Eindhoven Technische architectuur Beschrijving Specificatiecriteria Versie 1.1 A. van Loenen Technisch Beleidsadviseur B&E 21-Sep-2011 avl/fd11027578 Colofon Uitgave Gemeente Eindhoven Realisatie

Nadere informatie

VALUE ENGINEERING: THE H E G A G ME! E

VALUE ENGINEERING: THE H E G A G ME! E VALUE ENGINEERING: THE GAME! Involvement Process for Technical Projects Feedback/Learning/Knowledge Management Involvem ment Business Process Engineering Estimating Project Director Detailed Engineering

Nadere informatie

De juiste requirements juist

De juiste requirements juist De juiste requirements juist Een voorwaarde voor succesvolle applicatie ontwikkeling Arno van Herk Managing partner Synergio B.V. a.van.herk@synergio.nl 2011 Een brug naar onze presentatie Uniface is Compuware's

Nadere informatie

Testrisicoanalyse. Introductie

Testrisicoanalyse. Introductie 7 Testrisicoanalyse 7.1 Introductie Veel testtrajecten zijn tegenwoordig gebaseerd op risico s. Bij risicogebaseerd testen (RBT) bepaalt het risico dat de organisatie loopt als het systeem in gebruik wordt

Nadere informatie

Die inputs worden op een gecontroleerde manier aangeboden door (test) stubs. De test driver zorgt voor de uiteindelijke uitvoering ervan.

Die inputs worden op een gecontroleerde manier aangeboden door (test) stubs. De test driver zorgt voor de uiteindelijke uitvoering ervan. Nota: Schrijf je antwoorden kort en bondig in de daartoe voorziene velden. De puntenverdeling is 2 punten per theorie-vraag en 8 punten per oefening. Het totaal is 40. Vraag 1. Er bestaan verschillende

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

Big Data en Testen samen in een veranderend speelveld. Testnet 10 april 2014 Paul Rakké

Big Data en Testen samen in een veranderend speelveld. Testnet 10 april 2014 Paul Rakké Big Data en Testen samen in een veranderend speelveld Testnet 10 april 2014 Paul Rakké Kernvraag Is het testen van Big Data omgevingen, applicaties en de data anders dan het testen van meer traditionele

Nadere informatie

FloraHolland Ketenreleaseproces

FloraHolland Ketenreleaseproces Florecom Software Leveranciers Lunch FloraHolland Ketenreleaseproces Afgestemd met Florecom en Samenwerkingsverband Kwekersoftware 19 januari 2011 Ketenreleaseproces op hoofdlijnen 2 Processtappen 1. RFC

Nadere informatie

Vereenvoudigd sjabloon requirementsdocument. <>

Vereenvoudigd sjabloon requirementsdocument. <<Organisatie>> Vereenvoudigd sjabloon requirementsdocument SYSQA B.V. Almere Versie : Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van

Nadere informatie

HERGEBRUIK VAN REQUIREMENTS Een praktische implementatie

HERGEBRUIK VAN REQUIREMENTS Een praktische implementatie HERGEBRUIK VAN REQUIREMENTS Een praktische implementatie Zacharias van Diermen Legal & General www.landg.nl Edwin Schumacher Synergio www.synergio.nl Legal & General Bedrijf Bestaat al 175 jaar Opgericht

Nadere informatie

Procesvalidatie voor een veiliger ketentest

Procesvalidatie voor een veiliger ketentest Procesvalidatie voor een veiliger ketentest Johan Vink TestNet Voorjaarsevenement 2010 Agenda Inleiding Typering project & testaanpak Werkwijze business proces Probleem De opdracht voor het testteam Probleemanalyse

Nadere informatie

Toekomstbestending maken van selectie tool Rekening houdend met strikte privacy wetgeving

Toekomstbestending maken van selectie tool Rekening houdend met strikte privacy wetgeving Toekomstbestending maken van selectie tool Rekening houdend met strikte privacy wetgeving Kurt.Merchiers@colruytgroup.com Functioneel Analist Roel.Van.Assche@sas.com Consultant Agenda Vervanging van de

Nadere informatie

Voorstel ontwikkeling duurzaamheidsparagraaf Zoetermeer. 1. Inleiding

Voorstel ontwikkeling duurzaamheidsparagraaf Zoetermeer. 1. Inleiding Voorstel ontwikkeling duurzaamheidsparagraaf Zoetermeer 1. Inleiding Zoetermeer wil zich de komende jaren ontwikkelen tot een top tien gemeente qua duurzaam leefmilieu. In het programma duurzaam Zoetermeer

Nadere informatie

Applicatie outsourcing

Applicatie outsourcing Applicatie outsourcing Architectuur van en in de samenwerking dr. Jan Campschroer Management Consultant Ordina 13 oktober 2011 m.m.v.: Martin van den Berg Deze presentatie is gebaseerd op interviews met

Nadere informatie

Handreiking gebiedsgericht warmte-uitwisseling

Handreiking gebiedsgericht warmte-uitwisseling Handreiking gebiedsgericht warmte-uitwisseling De verdiepingsfase In de verdiepingsfase gaat u, samen met uw partners, de haalbaarheid en kansrijkheid van het door u voor ogen staande warmte-uitwisselingsproject

Nadere informatie

5 Programmastructuur

5 Programmastructuur 5 Programmastructuur Om het informatieplan en de daarin beschreven componenten is het aan te raden een programma- en projectenorganisatie in te richten. Volgend schema geeft de verschillende actoren en

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

Procesmanagement. Waarom processen beschrijven. Algra Consult

Procesmanagement. Waarom processen beschrijven. Algra Consult Procesmanagement Waarom processen beschrijven Algra Consult Datum: 22 oktober 2009 Inhoudsopgave 1. INLEIDING... 3 2. WAAROM PROCESMANAGEMENT?... 3 3. WAAROM PROCESSEN BESCHRIJVEN?... 3 4. PROCESASPECTEN...

Nadere informatie

Resultaat gerichter Testen

Resultaat gerichter Testen Resultaat gerichter Testen Verandering van test beleid bij Rabobank International De Rabobank 1 Rabobank International Information Systems &Development IS&D Global Services & IT Risk Management Strategy

Nadere informatie

Transparantie = Key!

Transparantie = Key! Transparantie = Key! Basis voor een inzichtelijk testproces Net Voorjaarsevenement 2012 Patrick Duisters Improve Quality Services BV info@improveqs.nl 1 Ervaringen Improve Quality Services B.V. 2 Observaties

Nadere informatie

Ontwikkelen & Beheren van testomgevingen is ook een vak!

Ontwikkelen & Beheren van testomgevingen is ook een vak! Patrick Scholte & Albert Dennis Janssen Anneveld Ontwikkelen & Beheren van testomgevingen is ook een vak! Agenda Even voorstellen De Rabobank Problemen met omgevingen Oorzaken Aanpak Verdere ontwikkelingen

Nadere informatie

De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4. Rolbeschrijvingen

De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4. Rolbeschrijvingen De wereld is een schouwtoneel, elk speelt zijn rol en krijgt zijn deel (Joost van den Vondel) Hoofdstuk 4 V1.2 / 01 februari 2016 MCTL 4. v1.2 Geen copyright! MCTL is in licentie gegeven volgens een Creative

Nadere informatie

Uitdagingen bij de ontwikkeling van draadloze producten D&E event FHI ( s Hertogenbosch) 9 oktober 2013

Uitdagingen bij de ontwikkeling van draadloze producten D&E event FHI ( s Hertogenbosch) 9 oktober 2013 Uitdagingen bij de ontwikkeling van draadloze producten D&E event FHI ( s Hertogenbosch) 9 oktober 2013 Uitdagingen bij de ontwikkeling van draadloze producten Welkom Productontwikkelproces volgen: Inhoud

Nadere informatie

Architectuurredeneermodel Afgewogen keuzes maken

Architectuurredeneermodel Afgewogen keuzes maken Architectuurredeneermodel Afgewogen keuzes maken Robert Deckers SASG okt 2012 v3 Architectuur: technologie in perspectief Klantbehoefte Toepassing Systeem T 2 Vele wegen die naar ergens leiden Bewuste

Nadere informatie

Ministerie van Infrastructuur en Milieu Beheerst naar beheer

Ministerie van Infrastructuur en Milieu Beheerst naar beheer Document D-2 Ministerie van Infrastructuur en Milieu Beheerst naar beheer Versie 1.0 Datum 15 juli 2014 Status Definitief Colofon Versie 1.0 Contactpersoon Paul Leunissen M 06-5250 6691 Paul.Leunissen@minienm.nl

Nadere informatie

Archimate risico extensies modelleren

Archimate risico extensies modelleren Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.

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

Intelligente Verkeers Regel Installatie (ivri) Fase 1. Overzicht deliverables. Datum: 28 januari 2016 Versie: final

Intelligente Verkeers Regel Installatie (ivri) Fase 1. Overzicht deliverables. Datum: 28 januari 2016 Versie: final Intelligente Verkeers Regel Installatie (ivri) Fase 1 Overzicht deliverables Datum: 28 januari 2016 Versie: final Inleiding In juni 2015 is opdracht verstrekt door het Ministerie van Infrastructuur en

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

Belastingdienst MCC Visie op mobiel en interactie met burgers en bedrijven

Belastingdienst MCC Visie op mobiel en interactie met burgers en bedrijven Belastingdienst MCC Visie op mobiel en interactie met burgers en bedrijven Bestede digitale tijd Aandeel telefoongebruik in digitale tijd ICT 2.500 FIOD 1.200 Toeslagen 1.200 CA 1.600 Belastingdienst BelTel

Nadere informatie

Checklist Slimme vragenlijst regievoering

Checklist Slimme vragenlijst regievoering Checklist Slimme vragenlijst regievoering versie 2.0 Slimme vragenlijst Leveranciersselectie Hoe stel ik vast dat dit beste leverancier is? Welke criteria hanteer ik daarbij? Wat als het selectieproces

Nadere informatie

Stuurgroep ICT innovatie in de ouderenzorg. 12 oktober 2010

Stuurgroep ICT innovatie in de ouderenzorg. 12 oktober 2010 Stuurgroep ICT innovatie in de ouderenzorg 12 oktober 2010 Agenda High Level Scope Projectorganisatie en werkingsprincipes Projectplanning en roll-out Projectopvolging Evaluatie diensten Agenda volgende

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

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009

MDA in de praktijk. Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 Functional Model Driven Development MDA in de praktijk Freek Bosch, Business Unit Manager Amsterdam, 4 juni 2009 FMDD agenda FMDD Waarom FMMD De praktijk Wat is FMDD Ervaringen en lessons learned Ervaringen

Nadere informatie

VORM GEVEN AAN VISIE

VORM GEVEN AAN VISIE VORM GEVEN AAN VISIE Hoe businessarchitectuur bijdraagt aan het bereiken van businessdoelen White paper Auteurs: Martin van den Berg, Aldert Boersma, Serge Bouwens, Erica Dane, Bonne van Dijk, Paul Dijkwel,Jan

Nadere informatie

Managementrapportage [datum]

Managementrapportage [datum] Managementrapportage [datum] [Projectnaam] Datum: Status: dd-mm-jj concept / definitief ALGEMENE PROJECTSTATUS Voortgang / bereikte resultaten Risico s / maatregelen BEVINDINGEN PROJECTCONTROL / ASSURANCE

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

Functionaliteitenbeheer

Functionaliteitenbeheer Organisatie Functionaliteit 1 Richtinggevend Sturend Uitvoerend Het gaat hier om het initiëren van en zorgdragen voor de uitwerking en verandering van de gewenste wijzigingen aan de informatievoorziening.

Nadere informatie

De goede requirements goed bij Philips Handheld Diagnostics Venture

De goede requirements goed bij Philips Handheld Diagnostics Venture De goede requirements goed bij Philips Handheld Diagnostics Venture Een groeipad voor het professionaliseren van werken met requirements Edwin Schumacher Managing partner Synergio B.V. e.schumacher@synergio.nl

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

Business Sprint in kader van project Leerling 2020. Door Madelief Keyser

Business Sprint in kader van project Leerling 2020. Door Madelief Keyser Business Sprint in kader van project Leerling 2020 Door Madelief Keyser Generieke vraag initiatieven gepersonaliseerd leren CONTENT: Ontwikkeling van adaptief digitaal leermateriaal opgedeeld in kleine

Nadere informatie

Software Test Documentation

Software Test Documentation FACULTEIT INGENIEURSWETENSCHAPPEN & WE- TENSCHAPPEN DEPARTMENT OF COMPUTER SCIENCE AND APPLIED COMPUTER SCIENCE Software Test Documentation Software Engineering Nicolas Carraggi, Youri Coppens, Christophe

Nadere informatie

Non Functional Requirements SMART maken

Non Functional Requirements SMART maken Non Functional Requirements SMART maken Robert van Lieshout SPIder plenaire bijeenkomst 2 juni 2010 Welke eisen? 2 1 Eigenschappen van een kussen Veilig Niet brandbaar Hypoallergeen Comfortabel Zacht Voldoende

Nadere informatie

MDA experiences in een uitvoeringsorganisatie. Eelco van Mens (Architect, Mn Services) 5 juni 2008

MDA experiences in een uitvoeringsorganisatie. Eelco van Mens (Architect, Mn Services) 5 juni 2008 MDA experiences in een uitvoeringsorganisatie MDA experiences in een uitvoeringsorganisatie Eelco van Mens (Architect, Mn Services) 5 juni 2008 2 Inhoud Korte introductie Mn Services Overwegingen om met

Nadere informatie

Managers moeten beslissingen nemen over IT, maar hebben weinig kennis. Eli de Vries

Managers moeten beslissingen nemen over IT, maar hebben weinig kennis. Eli de Vries Managers moeten beslissingen nemen over IT, maar hebben weinig kennis Eli de Vries Managers moeten beslissingen nemen over IT, maar hebben weinig kennis Managers moeten beslissingen nemen over IT, maar

Nadere informatie

3. Een norm voor valide examenproducten norm voor valide examenproducten cesuur exameninstrumentarium

3. Een norm voor valide examenproducten norm voor valide examenproducten cesuur exameninstrumentarium Dit document is een onderdeel uit het advies Drie routes naar een valide examenproduct van mei 2016. De uitwerking van het advies vindt plaats vanaf augustus 2016 door de hiervoor aangestelde kwartiermaker

Nadere informatie

Projectmanagement 2.0

Projectmanagement 2.0 Projectmanagement 2.0 Inleiding In ieder bedrijf waar in projecten wordt gewerkt liggen scopechanges op de loer. Zo ook bij het CrossOverteam Projectmanagement 2.0. De eerste dag van het project is gelijk

Nadere informatie

De Agile Analist. Ebook over requirements en agile. Deel II

De Agile Analist. Ebook over requirements en agile. Deel II De Agile Analist Ebook over requirements en agile Deel II 2 Inhoud Deel I... 3 1 Inleiding... 3 2 Just in time requirements... 3 3 Just enough requirements... 3 Deel II... 4 4 Samenwerken met de business...

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

Professionalisering van Levensduurverlenging

Professionalisering van Levensduurverlenging Professionalisering van Levensduurverlenging De toegevoegde waarde van VITALE Rob van Dongen 9 februari 2012 Agenda 1 2 3 4 Levensduurverlenging volgens VITALE Het referentiemodel Toepasbaarheid VITALE

Nadere informatie