Risicobeheersing bij nieuwe functionaliteit
|
|
- Frans Brander
- 8 jaren geleden
- Aantal bezoeken:
Transcriptie
1 topic change management Acceptatieprocedure bij agentschap BPR bewijst zich in de praktijk Risicobeheersing bij nieuwe functionaliteit Het in productie nemen van nieuwe of gewijzigde informatiesyste men door beheerorganisaties vereist een goede risicoanalyse en risicobeheersing. Als daarvan geen sprake is, kan het gevolg zijn dat informatiesys te men niet aan de functionele eisen, kwaliteitseisen en beheereisen voldoen. Het agentschap BPR (Basisadministratie Persoonsgegevens en Reisdocumenten) heeft een acceptatieprocedure opgesteld die invulling geeft aan het analyseren en beheersen van deze risico s. BPR heeft deze procedure inmiddels met succes toegepast. Bart de Best Veel beheerorganisaties hanteren nauwelijks of geen acceptatiecriteria om nieuwe of gewijzigde informatiesys temen te accepteren. Als er al acceptatiecriteria zijn, dan zijn die zo generiek dat er geen risicobeheersing van uitgaat. Aan de andere kant zijn er ook organisaties die wel acceptatiecriteria gebruiken in het Change Managementproces. Dit zijn er echter meer dan eens zoveel dat er geen tijd in projecten vrijgemaakt kan worden om ze toe te passen. De crux is dan ook om alleen die acceptatiecriteria te hanteren die gebaseerd zijn op een risicoanalyse, waarbij de faalfactoren van functionaliteit, kwaliteit en beheerbaarheid duidelijk worden. De acceptatiecriteria moeten worden gehanteerd als meetinstrument om vast te stellen of de risico s beheerst zijn. Op basis daarvan kan Change Management wel of niet het groene licht geven voor het in productie nemen van de nieuwe of gewijzigde functionaliteit. Het agentschap Basisadministratie Persoonsgegevens en Reisdocumenten (BPR) heeft invulling gegeven aan zo n risicoanalyse in de vorm van een acceptatieprocedure. Achtergrond BPR hecht veel waarde aan het beheersen van de risico s van nieuwe of gewijzigde informatiesys te men. Het agentschap is er namelijk verantwoordelijk voor te schouwen en toetsen of de in beheer zijnde informatiesys te men voldoen aan de gerelateerde wetgeving. Daarnaast zijn de informatiesys te men van groot maatschappelijk belang, omdat veel overheidsinstanties afhankelijk zijn van de beschikbaarheid en betrouwbaarheid van de informatievoorziening door BPR. Verstoringen aan applicaties, zoals de BV BSN en GBA-V (zie kader BPR-organisatie ), of erger nog, corruptie van de gegevensbanken waarvan het berichtenverkeer gebruikmaakt, heeft dan ook een directe impact op vele overheidsprocessen. Als acceptant van de nieuwe of aangepaste informatiesys te men hanteert BPR dan ook een stringente acceptatieprocedure, waarbij invulling wordt gegeven aan het beheersen van de risico s qua functionaliteit, kwaliteit en beheerbaarheid. Acceptatieprocedure De acceptatie van nieuwe of gewijzigde informatiesys te men geschiedt volgens het zogenaamde GSA-stappenplan, zoals afgebeeld in figuur 1. GSA staat voor Generieke en Specifieke. Het GSA-stappenplan is erop gericht om acceptatiecriteria 30 1 februari 2007 ITB07-01_v3.indd :36:23
2 BPR-organisatie te bepalen voor nieuw te ontwikkelen informatiesys te men of wijziging van bestaande informatiesys te men. Er worden zeven stappen doorlopen. Stap 1: beeld. De eerste stap is het bepalen van het beeld van de bedrijfsprocessen waarvoor het informatiesys teem wordt gebouwd of veranderd. Hierbij wordt naast de functionaliteit vooral gekeken naar de SMART-doelen van deze processen, om de kwaliteitseisen zoals de beschikbaarheid, beveiliging, capaciteit, performance en continuïteit te bepalen. Tevens wordt bepaald welke impact dit informatiesys teem heeft op het beheer (specifiek het functioneel beheer). Vervolgens wordt een plaat gemaakt van de applicatie en de omgeving waarmee de applicatie communiceert. Als derde onderdeel van de beeldvorming wordt een plaat gemaakt van de infrastructurele services waarvan het informatiesysteem gebruikmaakt. Deze platen zijn niet bedoeld als ontwerpdocumenten, maar alleen ter beeldvorming voor de beheerorganisatie van wat er nu eigenlijk geaccepteerd moet gaan worden. Stap 2: scope. In deze stap wordt een decompositie gemaakt van de applicatieplaat en de infrastructuurplaat in de vorm van bouwstenen (system building blocks). Hierdoor wordt het complexe geheel opgedeeld in eenduidig beheerbare eenheden. Van deze bouwstenen wordt bepaald welke wijzigingen ze vereisen ten opzichte van de bestaande infrastructuur en beheerprocessen. Voor bestaande informatiesys te men dienen de platen om vast te stellen welke onderdelen van de applicatie en de infrastructuur door de wijziging worden getroffen. Deze system building blocks (SBB s) worden uniek genummerd. De verkregen BPR (Basisadministratie Persoonsgegevens en Reisdocumenten) is een agentschap van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK). Het agentschap is eindverantwoordelijk voor de jaarlijkse uitwisseling van ongeveer zestig miljoen berichten met algemene persoonsgegevens en de productie en distributie van jaarlijks 1,2 miljoen paspoorten en Europese identiteitskaarten. De eerste opdracht van BPR is ervoor te zorgen dat de infrastructurele functie van de gemeentelijke basisadministratie en de reisdocumenten naar behoren functioneert. Daarnaast beheert BPR verschillende registers en informatiesyste men, waaronder het Basisregister Reisdocumenten, het register van burgerservicenummers (BV BSN) en de centrale component(en) van de moderne GBA (GBA-V). BPR verricht zelf het functioneel beheer (waaronder gegevensbeheer) en voert de regie over de leveranciers die het applicatiebeheer en technisch beheer uitvoeren voor deze informatiesys te men. Het functioneel beheer is dus het primaire bedrijfsproces van BPR; de core business. SBB-nummers worden gebruikt in de volgende stappen van het GSA-stappenplan, zoals het identificeren van risico s, acceptatiecriteria en testcases. Naast de decompositie van de infrastructuur en de applicatie worden ook de bedrijfsprocessen uiteengerafeld in de betrokken use cases (functionaliteit) en de supplementary specs (kwaliteit). De eisen die in stap 1 aan het informatiesys teem zijn gesteld, worden in deze stap per use case uitgewerkt. Ten slotte worden de use cases afgebeeld op de SBB s van de infrastructuur en de applicatie. Stap 3: risico. De risico s worden bepaald door per SBB-plaat met materiedeskundigen de mogelijke faalfactoren te onderzoeken. Daarna worden de risico s geclassificeerd. Zo worden per risico de kans en de impact bepaald, die samen het belang vormen van beheersing van het risico. De risicobeheersing bestaat uit het definiëren van tegenmaatregelen. Hoe groter het risico, des te belangrijker het is om de tegenmaatregelen toe te passen en te toetsen of ze effectief zijn. Hiertoe worden acceptatiecriteria opgesteld die de basis vormen voor de acceptatietestplannen. Tevens worden de risico s geclassificeerd per SBB, use case en ISO 9126-kwaliteitsattribuut 1. Deze classificatie van risico s is de basis voor stap 4. Stap 4: focus. BPR hanteert voor elk project een master testplan, waarin het testdomein, de testbasis, de testfocus en de teststrategie worden bepaald. Het testdomein wordt bepaald door de SBB s en de use cases die in stap 2 zijn vastgesteld als scope. De testbasis bestaat uit het benoemen van de testobjecten en de bijbehorende documentatie. Deze informatie komt uit stap 2 en uit het Project Initiation Document van het project. De testfocus geeft aan welke risico s in ieder geval beheerst moeten worden. Deze focus wordt bepaald door de classificatie van de risico s zoals in stap 3 is verricht. Zo kan de nadruk liggen op een bepaalde set van SBB s en use cases, en binnen deze set op het ISO 9126-kwaliteitattribuut beveiliging of beschikbaarheid. De richtlijn is dat de meerderheid van de testcases (bijvoorbeeld tachtig procent) binnen de testfocus moet vallen. Dit zijn immers de risico s die vooral beheerst moeten worden. De overige twintig procent van de risico s worden dus niet beheerst door middel van testcases. Stap 5: GSA. Deze stap is bedoeld om vast te stellen wanneer de geïdentificeerde risico s worden beheerst. Dit gebeurt door functionaliteiteisen, kwaliteitseisen en beheereisen te formuleren in de vorm van zowel generieke als specifieke acceptatiecriteria. De generieke acceptatiecriteria vormen een basisset van acceptatiecriteria waaruit per project een selectie wordt gemaakt. De specifieke acceptatiecriteria zijn uniek per project en moeten specifiek voor dat project onderkende risico s borgen. Beeld (1) Scope (2) Figuur 1 GSA-stappenplan Risico (3) Focus (4) GSA (5) Plan (6) Test (7) Stap 6: plan. De acceptatietestplannen beschrijven de testscenario s/testcases om vast te stellen of aan de acceptatiecriteria wordt voldaan. Het Operationele Acceptatie Testplan (OAT) omvat ener- 1 februari ITB07-01_v3.indd :36:24
3 topic change management zijds de testcases voor de individuele applicatie-sbb s en de infrastructuur-sbb s, en anderzijds de testcases om de juiste samenwerking van deze SBB s te toetsen. Het OAT wordt alleen in de acceptatieomgeving uitgevoerd. Het Productie Acceptatie Testplan (PAT) is een selectie van de OAT-testcases die in de productieomgeving wordt uitgevoerd nadat het informatiesys teem daar is geïnstalleerd en geconfigureerd. Het Functionele Acceptatie Testplan (FAT) wordt gebruikt om vast te stellen of het informatiesysteem de gespecificeerde functionaliteit biedt. Het Gebruiker Acceptatie Testplan (GAT) is bedoeld om vast te stellen of de beheerfunctionaliteit van het informatiesys teem voldoet aan de eisen van de functioneel beheerder en gegevensbeheerder. Het Performance Stress Testplan (PST) ten slotte is bedoeld om het gedrag van het informatiesys teem te testen op aspecten als beschikbaarheid, capaciteit en performance. Stap 7: test. Dit is de laatste stap in het GSA-stappenplan, waarin de acceptatietestplannen worden uitgevoerd. Ondersteund door de testresultaten wordt aan de CAB een advies over de inproductiename voorgelegd. Service Level Management SM1.1 Concept SLA Concept DAP PM2.1 Opzet Draaiboek GSA1.1. Proces Beeldvorming Stap 1. Beeldvorming GSA2.1 sbb s versus Use Cases Stap 2. Scope GSA3.1 Risicoanalyse Processen organisatie GSA1.2. Beeldvorming GSA2.2. sbb GSA3.2. Risicoanalyse GSA1.3. Beeldvorming GSA2.3. sbb GSA3.3. Risicoanalyse Project / RFC PM1.1 Projectbrief PM2.1 PID / RFC Bij elke stap wordt de verkregen informatie vastgelegd in specifiek hiertoe ontworpen documenten. Deze documenten vormen een belangrijke basis voor het beheer van de applicatie en de betrokken infrastructuur. Ze zijn dan ook niet voor eenmalig gebruik, maar dienen als uitgangspunt voor de risico- en impactanalyse ingeval van wijzigingen en onderhoudsprojecten. De documenten en de onderlinge samenhang zijn afgebeeld in figuur 2. Stap 3. Risicoanalyse Stap 4. Teststrategie GSA5.1. Generieke Processen GSA5.2. Specifieke Processen Stap 5. GSA4.1. Mastertestplan GSA5.3. Generieke GSA5.4. Specifieke GSA5.5. Generieke GSA5.6. Specifieke PM3.1 Faseplan / RFC planning Toelichting Stap 1: beeld. Een voorbeeld van een applicatieplaat (GSA-stap 1.2) is weergegeven in figuur 3. Dit is een eerste oriëntatie op wat gerealiseerd wordt. Deze plaat wordt of opgesteld in een definitiestudie, projectstartarchitectuur, functioneel ontwerp of wordt in samenwerking met het ontwikkelteam opgesteld. Belangrijk is dat deze stap zo vroeg mogelijk in het acceptatietraject wordt verricht. PM3.1 Releaseline PM7.1 SLA / DAP PM7.2 APH / IPH GSA6.1. Functionele Acceptatietestplan GSA6.2. Gebruiker Acceptatietestplan Stap 6. Testplannen GSA7.2. FAT GSA7.3. GAT Stap 7. Figuur 2 GSA-stappenplan-documentenflow GSA6.3. Performance Stresstestplan GSA7.4. PST GSA6.4. Operationele Acceptatietestplan GSA6.5. Productie Acceptatie Testplan GSA7.1. OAT GSA7.5. PAT PM7.1 PIR Project / PIR Change Voor de infrastructuur wordt een technisch schema (GSA-stap 1.3) gebruikt en voor het procesmodel bijvoorbeeld een data flow diagram (GSA-stap 1.1). De drie platen geven een goed beeld van wat opgeleverd gaat worden. Elke plaat wordt door de betrokken stakeholder in een beeldvormingssessie gepresenteerd aan de beheerorganisatie in de volgorde bedrijfsprocesmodel/beheerprocesmodel - applicatieplaat - infrastructuurplaat. Na afstemming van de beeldvorming tussen de ontwikkelorganisatie en de beheerorganisatie worden deze documenten vastgesteld februari 2007 ITB07-01_v3.indd :36:24
4 TMV TMV Webapplicatie Webservice LRDEM LRDPI Account View AM Mailbox TMV MI Tellers AM Reader AM Brug VOSpG Mailbox Client 3.7 Monitoring 3.8 LRD LRDPlus 3.3 AM BSN-Afslag Module De risico s inclusief tegenmaatregelen zijn de basis voor de acceptatiecriteria. Stap 4: focus. Behalve voor het bepalen van het testdomein en de testbasis is het master testplan ook bedoeld om een testfocus te bepalen voor de onderkende risico s en vervolgens de teststrategie (zie tabel 1). Hierbij worden de producten uit stap 2 en stap 3 gecombineerd. Tevens wordt de dekkingsgraad van de testcases vastgelegd in het master testplan door per SBB de testcases te tellen en te vergelijken met de risicokleuring. GBA Mailbox Server 5 typen GBAapplicaties gemeenten 2.9 Figuur 3 GSA-stap 1.2, applicatiebeeldvorming Stap 5: acceptatiecriteria. De acceptatiecriteria zijn bedoeld om vast te stellen of de risico s effectief worden beheerst (zie een voorbeeld in tabel 2). Stap 2: scope. De tweede stap is het afbeelden van de infrastructuurplaat op een system building block-plaat (GSAstap 2.3, zie figuur 4). BPR hanteert voor alle projecten dezelfde SBB-plaat en bepaalt vervolgens welke bouwstenen zijn geraakt. De infrastructuur-sbb-plaat is opgebouwd uit infrastructurele servicelagen. Elke laag is weer opgebouwd uit een aantal SBB s. De onderste laag is een verzamellaag van infrastructuurbeheerservices. De toegevoegde waarde van de SBB s is velerlei. BPR hanteert de platen voor de volgende zaken: overzicht van betrokken beheerpartijen door kleuring van de SBB-i s; overzicht van binnen of buiten scope zijn van SBB-i s; kleuren van risico s: rood (groot) geel (middel) groen (klein); stuurgroeppresentaties voor de go/nogobeslissingen; identificatie van risico s, acceptatiecriteria en testgevallen; configuratie-items voor ITIL-beheerprocessen. Analoog aan de infrastructuur-sbbplaat wordt ook voor de applicatie een SBB-plaat gemaakt (GSA-stap 2.2, zie figuur 5). Ook die is ingedeeld in lagen met daarbinnen de bouwstenen, en ook hier is de onderste laag gericht op het beheer. De laag daarboven bevat de applicatie-interfaces met andere informatiesys te men, de derde laag de applicatieprocesverwerkende modulen, en ten slotte komen de rapportage en de gebruikersinterfaces. Stap 3: risico. BPR hanteert voor zowel het proces, de applicatie als de infrastructuur een risicoanalyse. Hierbij worden drie groepen gevormd. De applicatie- en de infrastructuurgroep duiden de risico s die alleen aan één SBB toe te kennen zijn. Hierbij wordt bijvoorbeeld de A&Kanalyse (afhankelijkheden & kwetsbaarheden) gehanteerd. De derde groep bepaalt de procesgerelateerde risico s. Hiertoe worden de risico s per use case bepaald op basis van de afbeelding van de use case op de betrokken infrastructuur en applicatie-sbb s (zie figuur 6). Op basis van de initiële risico s wordt bepaald of een risico groot, middel of klein is door te bepalen wat de kans en de impact ervan is. Alle onderkende risico s worden voorzien van tegenmaatregelen. Praktijkervaring De belangrijkste best practices voor het toepassen van het GSA-stappenplan zijn: Begin in een project van meet af aan met het volgen van het stappenplan. De acceptatiecriteria moeten vaststaan voordat aan de bouw wordt begonnen. en servicenormen (in een sla) gaan hand in hand. Stel beide gelijktijdig op en relateer ze aan elkaar. Het beheersen van risico s vereist beeldvorming (stap 1) en afbakening (stap 2) op zowel proces-, applicatieals infrastructuurniveau. Een risicosessie levert meer relevante risico s op door: de drie aspectgebieden infrastructuur, applicatie en processen te scheiden. Wel moet minimaal één persoon alle drie de sessies bijwonen; een grondiger voorbereiding door bijvoorbeeld een beeldvormingssessie, waarin de platen uit de documenten van stap 1 en stap 2 worden doorgenomen en gecontroleerd. Ook moeten de betrokkenen tijdig de relevante projectdocumentatie krijgen en hebben gelezen; 1 februari ITB07-01_v3.indd :36:25
5 SBB-I 7. Presentatie SBB-I 7.1 Web Content Hosting SBB-I 7.2 Portal Service SBB-I 7.3 Framework SBB-I 6. SBB-I 6.1 Zoek Faciliteit SBB-I 6.2 Index Faciliteit SBB-I 6.3 Web Content Management SBB-I 6.4 Document SBB-I 6.5 Individuele Personalisatie SBB-I 6.6 Groepspersonalisatie SBB-I 6.7 Platform SBB-I 6.8 SBB-I 5. Dataopslag SBB-I 5.1 Document Opslag SBB-I 5.2 Data SBB-I 5.3 Repository SBB-I 5.4 Backup & Recovery SBB-I 5.5 Account Data SBB-I 5.6 Web Content Data SBB-I 5.7 In-Memory Data (cache) SBB-I 5.8 Sleutelopslag SBB-I 4. Platform SBB-I 4.1 Besturingssysteem SBB-I 4.2 Scaling & Load Balancing SBB-I 4.3 Fysiek Platform SBB-I 4.4 Authenticatie SBB-I 4.5 Autorisatie SBB-I 4.6 Input Devices SBB-I 4.7 Output Devices SBB-I 4.8 Integrity Checker SBB-I 3. Communicatie SBB-I 3.1 Webserver Communicatie SBB-I 3.2 Reverse Proxy SBB-I 3.3 Firewall SBB-I 3.4 Routers SBB-I 3.5 Communicatie SBB-I 3.6 Communicatie SBB-I 3.7 Integration Broker SBB-I 3.8 SSL-Offloader SBB-I 2. Netwerk SBB-I 2.1 Internet Connectie SBB-I 2.2 Intrusion Detection System SBB-I 2.3 Name/IP resolution SBB-I 2.4 Netwerk SBB-I 2.5 DMZ SBB-I 2.6 Koppeling SBB-I 2.7 Gemnet SBB-I 1. en Exploitatie SBB-I 1.1 Computerruimte Faciliteit SBB-I 1.2 Fysieke Locatie SBB-I 1.3 3rd Party Support SBB-I 1.4 Log & Alerting SBB-I 1.5 Statistiek SBB-I 1.6 Licentie & Certificaten SBB-I 1.7 Disaster Recovery Plan SBB-I 1.8 Werkplekbeheer SBB-I 1.9 OTAP Rekencentrum BPR Buiten Scope Figuur 4, GSA-stap 2.3, infrastructuur system building blocks SBB-A 5. Gebruikersinterface SBB-A 5.1 Java-enabled Browser SBB-A 5.2 Java-SSH Shell SBB-A 5.3 LRD Browser SBB-A 5.4 LDAP SBB-A 5.5 JMX-console SBB-A 4. SBB-A 4.1 Activiteiten SBB-A 4.2 Service Level Management SBB-A 4.3 Logging & Tracing SBB-A 4.4 SBB-A 3. Processing (subsystemen) SBB-A 3.1 Module SBB-A 3.2 LRD SBB-A 3.3 LRDplus SBB-A 3.4 AM Reader AM Brug SBB-A 3.5 SBB-A 3.6 AM SBB-A 3.7 VOSpG MailboxClient SBB-A 3.8 SBB-A 3.9 LO4 Berichten SBB-A 3.10 Berichten SBB-A 3.11 SBB-A 3.12 GBA-V Online SBB-A 3.13 BSN-afslag SBB-A 3.14 TMV SBB-A 3.15 MI Tellers SBB-A 3.16 Monitoring SBB-A 3.17 LO4 SBB-A 2. Interfaces SBB-A 2.1 AM / GXS AM SBB-A 2.2 GBA Mailbox Server SBB-A 2.3 LO4 Afnemer Bus Adapter SBB-A 2.4 Inter Gem.diensten bus Adapter SBB-A 2.5 LRDEM SBB-A 2.6 LRDPI SBB-A 2.7 Moderne Interfaces SBB-A 2.8 Inter gemeentelijke Dienstenbus SBB-A typen GBAapplicaties gemeenten SBB-A 2.10 Account View SBB-A 2.11 Afnemer Dienstenbus SBB-A 2.12 Afnemer Bus Adapter SBB-A1. beheer SBB-A 1.1 Installatie Deïnstallatie SBB-A 1.2 Operatie SBB-A 1.3 Code SBB-A 1.4 Documentatie SBB-A 1.5 SBB-A 1.6 Service Level Requirements Release 2, verandert niet in R3 Release 3, verandert niet in R4 Binnen scope Release 4 Buiten scope Release 4 Figuur 5 GSA-stap 2.2, applicatie system building blocks 34 1 februari 2007 ITB07-01_v3.indd :36:26
6 topic change management SBB-A typen GBA- s Gemeenten 6 Gemeenten SBB-A 2.2 Mailbox GBA Netwerk ID: UC-13 Datum UC: Release: GBAV R2.2 Datum verwerking: 16 juni 2006 Naam: UC Stellen synchronisatievraag 5 SBB-A 3.7 VOSpG MailboxClient SBB-A 3.8 meer domeinkennis aanwezig te laten zijn. Het verdient de voorkeur om in ieder geval de betrokken beheerders (waaronder leveranciers) uit te nodigen; zij hebben het grootste belang bij het onderkennen en beheersen van de risico s. Het verdient aanbeveling om de betrokken beheerders zelf de risicolijsten in te laten vullen (inclusief kans en impact). Deze risicolijsten moeten van tevoren aan de risicosessiedeelnemers worden gestuurd. Zij kunnen dan vooraf hun eigen risico s noteren. Eenduidige id s van SBB s maken de risicobeheersing makkelijker te traceren SBB-A 3.5 Figuur 6 GSA-stap 2.1, use cases versus system building blocks SBB-A 3.1 Module SBB-A 5.2 Java-SSH Shell 1 BPR GBA-V over acceptatiecriteria, testcases en testresultaten. Voorkom dubbelingen van risico s door eerst de SBB-gerelateerde risico s te bepalen en pas daarna de use case-gerelateerde risico s (die door de samenwerking van SBB s worden bepaald). moeten voorafgaand aan de bouw met de betrokken bouwers worden doorgenomen. Per acceptatiecriterium moet vastgesteld worden op welke wijze invulling gegeven gaat worden aan de gestelde eis. Het vertalen van acceptatiecriteria naar standaards en richtlijnen voor het bouwteam is een prima borging voor de kwaliteit, mits die standaards en richtlijnen worden bewaakt. De A&K-analyse en het stappenplan blijken goed samen te gaan, maar hiertoe moet wel een afstemming plaatsvinden tussen SBB s en de in de A&K-analyse onderkende objecten. RUP (Rational Unified Process) en het GSA-stappenplan zijn goed integreerbaar. Belangrijk is wel om onderscheid te maken tussen drie stromen: processen, applicatie en infrastructuur. De snelheden van het doorlopen van het stappenplan zijn namelijk niet evenredig aan elkaar. De infrastructurele GSA-stappen lopen in de fasen van RUP achter op de processen en de applicatieve GSA-stappen. Het uiteenlopen van de stappen moet echter beperkt blijven. Voor de bouwfase moeten de acceptatiecriteria vastgesteld zijn en omgezet zijn in standaards en richtlijnen. De generieke acceptatiecriteria kunnen prima hergebruikt worden. Het is wel belangrijk om per project een selectie te maken. Ook moeten die acceptatiecriteria techniekonafhankelijk geschreven worden. TESTSOORT SBB Gerelateerde service OAT FAT GAT PST PAT SBB-I 3.1 Webserver Communicatie SBB-I 3.2 Reverse Proxy SBB-I 3.3 Firewall SBB-I 3.4 Routers SBB-I 3.5 Communicatie SBB-I 3.6 Communicatie Tabel 1 Onderdeel van master testplan ID TCR ISO9126 Acceptatiecriterium Meetvoorschrift A T Analyseerbaarheid HERLEIDBAARHEID Elke foutboodschap moet refereren naar het onderdeel van de applicatie waar de fout is opgetreden. Tabel 2 Voorbeeld acceptatiecriterium Controleer de foutenlijst, verifieer dit bij het steekproefsgewijs veroorzaken van fouten. Hierbij dank ik de vele reviewers van dit artikel en het agentschap BPR voor hun medewerking aan dit artikel, met name drs. ing. P. (Peter) de Jong, coördinator service management. Verder dank aan ing. P.P.M. (Pascal) Huijbers voor zijn toestemming om de SBB- infrastructuurplaat bij BPR te gebruiken. Drs. ing. B. de Best RI, bartb@qforce.nl Noten/literatuur 1 ISO 9126 is een kwaliteitsmodel van ISO waarbinnen kwaliteit van informatiesys te men is gedefinieerd aan de hand van een aantal kwaliteitsattributen, zoals beschikbaarheid, onderhoudbaarheid, et cetera. De Best, B., Gebrek aan kwaliteitsbeheersing pragmatisch aanpakken, in: IT Magazine 7/2005 De Best, B., in de praktijk, in: IT Magazine 1/2006 B. de Best,, Sdu Uitgevers, ISBN februari ITB07-01_v3.indd :36:27
Beheerarchitectuur in projecten
architectuur Beheerarchitectuur in projecten Agentschap BPR leidt vele veranderingen in goede banen Het agentschap Basisadministratie Persoonsgegevens en Reisdocumenten (BPR) past beheerarchitectuurprincipes
Nadere informatieVerzekeraar beheerst de risico s van SOA
dossier SOA- en applicatiebeheer Verzekeraar beheerst de risico s van SOA De acceptatie van Service Oriented Architectuur informatiesystemen bij Interpolis Het gestructureerd accepteren van informatiesystemen
Nadere informatieDrievoudig demand en supply
special integratie domeinen Agentschap maakte keuzes bij integratie, en Drievoudig demand en supply Na de brede acceptatie van en de komst van modellen als voor applicatie en voor functioneel is het drievoudig
Nadere informatieOverheidsorganisatie verkleint risico s binnen het Software Lifecycle Management-proces.
TITEL Overheidsorganisatie verkleint risico s binnen het Software Lifecycle Management-proces. Door Marco Vos INTRODUCTIE Voor de serviceverlening van de overheid wordt al vele decennia software ontwikkeld.
Nadere informatieDigikoppeling adapter
Digikoppeling adapter Versie 1.0 Datum 02/06/2014 Status Definitief Van toepassing op Digikoppeling versies: 1.0, 1.1, 2.0, 3.0 Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900 555
Nadere informatieVan 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 informatieProcesvisie 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 informatieWij testen..maar....wat test jij?
Wij testen..maar....wat test jij? Wij testen maar wat test jij? Harm Pul, Busineslinemanager Functioneel Beheer TMAP dag 2015, 29 september 2015 Bussum 2 Herkent u dit? De gebruikers testen dit straks
Nadere informatieTechnische 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 informatieChange Management RFC Checklist
Change Management Versie 1.0 27 juli 2011 Definitief Auteur : Bart de Best Akkoord : Bart de Best Datum : 27 mei 2011 Versie : 1.0 Referentie : Pagina : I Colofon Titel Change Management Ondertitel Versie
Nadere informatieChange Management RFC Template
Change Management RFC Template Versie 1.0 27 juli 2011 Definitief Auteur : Bart de Best Akkoord : Bart de Best Datum : 27 mei 2011 Versie : 1.0 Referentie : RFC template Pagina : I Colofon Titel Change
Nadere informatiePrincipes en modellen. Product Breakdown Structure. Projectmanagement
architectuur als Architecten, ontwikkelaars, testers en beheerders blijken vaak eilandbewoners. Ieder afzonderlijk bepalen ze de functionaliteits- en kwaliteitsrisico s van informatiesystemen en ieder
Nadere informatieVrijgaveadvies. Project <naam project>
Vrijgaveadvies Project SYSQA B.V. Almere Datum : 08-02-2013 Status : Versie : Opgesteld door : Organisatie Project Pagina 2 van 16 Inhoudsopgave 1 Management samenvatting...
Nadere informatiebedrijfsprocessen 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 informatieGeautomatiseerd toetsen van acceptatiecriteria
Geautomatiseerd toetsen van De acceptatie van maatwerkprogrammatuur is vaak gebaseerd op functionele requirements. Kwaliteitsaspecten zoals de onderhoudbaarheid van de programmatuur verdienen echter ook
Nadere informatieGoed functioneel beheer noodzaak voor effectievere SPI
getronicspinkroccade.nl Goed functioneel beheer noodzaak voor effectievere SPI Machteld Meijer Zeist, 3 oktober 2006 Inhoud Domeinen en modellen Functioneel beheer en BiSL Rol van BiSL in SPI 1 Goed functioneel
Nadere informatieAcceptatiecriteria in de praktijk
topic acceptatiecriteria Toepassing, architectuurprincipes en tips Acceptatiecriteria in de praktijk Omdat aan ICT-dienstverlening steeds hogere eisen worden gesteld, wordt kwaliteitsbeheersing ook steeds
Nadere informatieMinisterie 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 informatieDraaiboek Invoering Basisregistratie Personen l Afnemers
Draaiboek Invoering Basisregistratie Personen l Afnemers Hoofdstap 4 Aansluiten Publicatiedatum: oktober 2014 Inleiding In de hoofdstap Aansluiten voert u de laatste voorbereidende werkzaamheden uit (technisch,
Nadere informatiePresentatie 06-03-2008 Gestructureerd en geautomatiseerd testen Ad Driessens en Gerben Mondeel
Presentatie 06-03-2008 Gestructureerd en geautomatiseerd testen Ad Driessens en Gerben Mondeel Doelstelling Introductie Practis en Producten Project bij Achmea Testaanpak Concrete toepassing van Rational
Nadere informatieKwaliteitsbewaking 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 informatieOlde Bijvank Advies Organisatieontwikkeling & Managementcontrol
SAMENVATTING ITIL ITIL is nog steeds dé standaard voor het inrichten van beheerspocessen binnen een IT-organisatie. En dekt zowel applicatie- als infrastructuur beheer af. Indien gewenst kan ITIL worden
Nadere informatieSubwerkgroep 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 informatieOperatie BRP Resultaten en stand van zaken
Operatie BRP Resultaten en stand van zaken Cor Franke Gedelegeerd opdrachtgever Operatie BRP Agenda plenaire sessie afnemers 1. Welkom 2. Waar staan we nu? 3. Wat hebben we nog te doen? 4. Aansluitstrategie
Nadere informatieTesten en QA bij pakketimplementaties
Testen en QA bij pakketimplementaties Eric Begeer Sogeti Nederland B.V. Testnet 5 november 2003 Agenda Waarom maken organisaties gebruik van pakketten? Welke risico s lopen ze hierbij? Welke maatregelen
Nadere informatieGeef handen en voeten aan performance management
Geef handen en voeten aan performance management De laatste jaren is het maken van concrete afspraken over de ICT-serviceverlening steeds belangrijker geworden. Belangrijke oorzaken hiervoor zijn onder
Nadere informatieHandleiding voor aansluiten op Digilevering
Handleiding voor aansluiten op Digilevering Versie 1.0 Datum 1 augustus 2013 Status definitief Colofon Projectnaam Digilevering Versienummer 1.0 Contactpersoon Servicecentrum Logius Organisatie Logius
Nadere informatieDATAMODELLERING ARCHIMATE DATA- & APPLICATIEMODELLERING
DATAMODELLERING ARCHIMATE DATA- & APPLICATIEMODELLERING Inleiding In dit whitepaper wordt de datamodelleervorm ArchiMate data- & applicatiemodellering beschreven. Deze modelleervorm staat in verhouding
Nadere informatieProgramma Borging veilige gegevensuitwisseling via Suwinet Normenkader Suwinet. Webinar, 28 juni 2017
Programma Borging veilige gegevensuitwisseling via Suwinet Normenkader Suwinet Webinar, 28 juni 2017 Agenda Algemeen: verschillen oude en nieuwe normenkader Relatie met ENSIA Highlights Norm voor norm
Nadere informatieDraaiboek Invoering Basisregistratie Personen l Afnemers
Draaiboek Invoering Basisregistratie Personen l Afnemers Van Oriëntatie naar Gebruik van de BRP Inleiding & toelichting op de vijf hoofdstappen Publicatiedatum: oktober 2014 Ten geleide Voor u ligt de
Nadere informatieVoorwoord. Bekijk de mogelijkheden voor dienstverlening die wij voor u kunnen ver - zorgen. 4PS Business Software 03
DIENSTEN CATALOGUS Voorwoord Met deze dienstencatalogus heeft u een overzicht van alle mogelijk heden die 4PS u biedt om u te onder steunen bij uw IT werkzaamheden. Bijvoorbeeld op het gebied van technisch
Nadere informatieemaxx Systeem eisen ManagementPortaal voor de ZakenMagazijn database
emaxx Systeem eisen ManagementPortaal voor de ZakenMagazijn database Datum: 25-09-2007 Auteur: ing. E.L. Floothuis Versie: 0.1 Status: Concept Kopersteden 22-4 Postbus 157 7500 AD Enschede Tel: 053 48
Nadere informatieOnline Back-up installatie handleiding. Sikkelstraat 2 4904 VB Oosterhout www.winexpertise.nl. E: info@winexpertise.nl
Online Back-up installatie Sikkelstraat 2 4904 VB Oosterhout www.winexpertise.nl E: info@winexpertise.nl Datum: 1-10-2012 Document versie: V1.0 Versie en distributie geschiedenis Versie Datum Auteur Status
Nadere informatieOperatie BRP Resultaten en stand van zaken
Operatie BRP Resultaten en stand van zaken Cor Franke Gedelegeerd opdrachtgever Operatie BRP Agenda plenaire sessie gemeenten 1. Welkom 2. Waar staan we nu? 3. Kijkje in de keuken van de PoC Bijhouden
Nadere informatieDraaiboek Invoering Basisregistratie Personen l Afnemers
Draaiboek Invoering Basisregistratie Personen l Afnemers Hoofdstap 3 Voorbereiden Publicatiedatum: oktober 2014 Inleiding U heeft een vastgesteld plan van aanpak, u weet welke voorbereidende werkzaamheden
Nadere informatieSoftware 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 informatieVAN 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 informatieDigitaal Archief Vlaanderen Stappenplan & Projectfiches
www.pwc.be Digitaal Archief Vlaanderen Stappenplan & Projectfiches september 2013 1. Inleiding In dit deel van de studie rond het Digitaal Archief Vlaanderen bekijken we het technische stappenplan dat
Nadere informatieRapportage Pizzasessie Functioneel-beheer.com Specialisten Managers Adviseurs Algemeen functioneel beheer applicatiebeheer informatiemanagement
Rapportage Pizzasessie Functioneel-beheer.com Alle deelnemers hebben hun functienaam opgegeven. De volgende functienamen zijn gemeld: Specialisten o Functioneel beheerder (9x) o Functioneel applicatiebeheerder
Nadere informatieVERSIE 1.0 WOLFMEISTER VOF SERVICE LEVEL AGREEMENT UITGEREIKT DOOR: WOLFMEISTER IT. Graafseweg AL - s-hertogenbosch KVK
VERSIE 1.0 WOLFMEISTER VOF SERVICE LEVEL AGREEMENT UITGEREIKT DOOR: WOLFMEISTER IT Graafseweg 10 5213 AL - s-hertogenbosch KVK 71055657 SERVICE LEVEL AGREEMENT 1. PARTIJEN Deze Service Level Agreement
Nadere informatieARE 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 informatieFunctioneel Applicatie Beheer
Functioneel Applicatie Beheer Functioneel Applicatie Beheer Goed functioneel beheer werkt als smeerolie voor uw organisatie en zorgt voor een optimale aansluiting van de informatievoorziening op de primaire
Nadere informatieDé cloud bestaat niet. maakt cloud concreet
Dé cloud bestaat niet. maakt cloud concreet 1 Wilbert Teunissen wilbert.teunissen@sogeti.nl Cloud Cases Strategie De rol van Functioneel Beheer 2 Onderwerpen 1. Context? Hug 3. the Impact cloud! FB 2.
Nadere informatieDraaiboek Invoering Basisregistratie Personen l Afnemers
Draaiboek Invoering Basisregistratie Personen l Afnemers Hoofdstap 1 Oriëntatie Publicatiedatum: oktober 2014 Inleiding De oriëntatie is erop gericht om informatie te verzamelen over de Basisregistratie
Nadere informatie1 Dienstbeschrijving all-in beheer
1 Dienstbeschrijving all-in beheer De all-in beheer overeenkomst van Lancom is modulair opgebouwd. U kunt bij Lancom terecht voor deelgebieden zoals helpdesk ondersteuning of backup, maar ook voor totale
Nadere informatieExploitatie testen voor het testen van Service Level Agreements. Geïnspireerd door
Exploitatie testen voor het testen van Service Level Agreements Geïnspireerd door 1 december 2009 Agenda Het begrip Exploitatie testen APG als inspiratiebron Service Level Testen binnen Service Level :
Nadere informatieProactief en voorspellend beheer Beheer kan effi ciënter en met hogere kwaliteit
Proactief en voorspellend beheer Beheer kan effi ciënter en met hogere kwaliteit Beheer kan efficiënter en met hogere kwaliteit Leveranciers van beheertools en organisaties die IT-beheer uitvoeren prijzen
Nadere informatieDit werkboek hoort bij Bart de Best, Acceptatiecriteria, Sdu Uitgevers, Den Haag 2009, ISBN 978 90 12 58133 2
Werkboek Meer informatie over deze en andere uitgaven kunt u verkrijgen bij: Sdu Klantenservice Postbus 20014 2500 EA Den Haag tel.: (070) 378 98 80 www.sdu.nl/service Dit werkboek hoort bij Bart de Best,
Nadere informatieTMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN
TMAP NEXT DOCUMENT OVERZICHT TOEGEPASTE TESTVORMEN Copyright Sogeti Nederland B.V. te Vianen Niets uit deze uitgave mag verveelvoudigd en/of openbaar worden gemaakt (voor willekeurig welke doeleinden)
Nadere informatieTESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE. 1. Inleiding. 2. TMap methode. Kwaliteit zonder gestructureerd testen is toeval.
TESTEN VOLGENS TMAP, EEN KORTE INTRODUCTIE Kwaliteit zonder gestructureerd testen is toeval Inhoudsopgave 1. Inleiding 2. De TMap methode 3. De fase Planning & Beheer 4. De fase testspecificatie 5. De
Nadere informatieCloud Computing, een inleiding. ICT Accountancy & Financials congres 2013: Cloud computing en efactureren. Jan Pasmooij RA RE RO: jan@pasmooijce.
Cloud Computing, een inleiding ICT Accountancy & Financials congres 2013: Cloud computing en efactureren 10 december 2013 Jan Pasmooij RA RE RO: jan@pasmooijce.com 10 december 2013 1 Kenmerken van Cloud
Nadere informatieConclusie: voor elke organisatie die dit nastreeft is het goed besturen en beheersen van de bedrijfsprocessen
1 Waarom? : Succesvol zijn is een keuze! Organisaties worden door haar omgeving meer en meer gedwongen om beter te presteren. Voornamelijk wordt dit ingegeven door de klant die haar eisen en wensen m.b.t.
Nadere informatieBusiness Impact Anlayses worden in de meeste organisaties eens per jaar of eens per halfjaar geactualiseerd en bevatten meestal beschrijvingen van:
(BIA s) Veel organisaties beschikken over BIA s ofwel Business Impact Analyses per Business Unit of per Afdeling. Hierna gaan we verder uit van Business Impact Analyses op Business Unit niveau. Dit artikel
Nadere informatie[functie] De functie die verantwoordelijk is voor het beheren van applicaties. [zaak] Een methode of maatregel om een risico te managen.
Applicatiebeheer het beheren van applicaties. [functie] De functie die verantwoordelijk is voor het beheren van applicaties. Beheer (beheren) Control Onder de activiteit applicatiebeheer valt de ontwikkeling,
Nadere informatieBijlage 11 Programma van Eisen
Bijlage 11 Programma van Eisen Het betreft hier minimale eisen, waarbij geldt dat: Het niet voldoen aan een eis leidt onherroepelijk tot leidt tot het ongeldig verklaren en terzijde leggen van de Inschrijving
Nadere informatieKernwaarden versus principes. Johan Hobelman Nieuwegein, november 2011
Kernwaarden versus principes Johan Hobelman Nieuwegein, november 2011 Enkele definities van architectuurprincipes: Fundamentele organisatiespecifieke keuzes Richtinggevende afspraken Regels en richtlijnen
Nadere informatieBeheermetamorfose bij BPR
Beheermetamorfose bij BPR Agentschap rondt inrichting raamwerk succesvol af Eerder verscheen in dit blad een artikel over het toepassen van het drievoudig demandsupplymodel bij BPR 1, een gestructureerd
Nadere informatieAansluit handleiding Omgevingsloket online. Webservices INREGELOMGEVING (INR) Directie Concern Informatievoorziening
Aansluit handleiding Omgevingsloket online Webservices INREGELOMGEVING (INR) Koningskade 4 Postbus 20901 2500 EX Den Haag Contactpersoon Postbus.functioneelbeheerolo @minienm.nl Betreft Aansluithandleiding
Nadere informatieNieuwe ontwikkelingen in de LSP-keten
Nieuwe ontwikkelingen in de LSP-keten leveranciers en gebruikersvertegenwoordiging Datum: 6 december 2018 Status: Definitief Versie: 2 Classificatie: Openbaar Eigenaar: VZVZ Dit document bevat de proces-
Nadere informatieNORA werkdocument. Katern Beveiliging. In 3 klikken naar bouwstenen voor invulling van de eisen. Sessie 6. Bijgewerkt op 23 aug.
NORA werkdocument Sessie 6 In 3 klikken naar bouwstenen voor invulling van de eisen Katern Beveiliging Bijgewerkt op 23 aug. 2013 katern Beveiliging Jaap van der Veen Essentie Sessie 6 1. Opzet digitaal
Nadere informatieWhitepaper. Veilig de cloud in. Whitepaper over het gebruik van Cloud-diensten deel 1. www.traxion.com
Veilig de cloud in Whitepaper over het gebruik van Cloud-diensten deel 1 www.traxion.com Introductie Deze whitepaper beschrijft de integratie aspecten van clouddiensten. Wat wij merken is dat veel organisaties
Nadere informatiePrivacy Bijsluiter Digitale Leermiddelen Basisonderwijs (Dr. Digi), Noordhoff Uitgevers
Bijlage 1 bij de Bewerkersovereenkomst Noordhoff Uitgevers Privacy Bijsluiter Digitale Leermiddelen Basisonderwijs (Dr. Digi), Noordhoff Uitgevers Noordhoff Uitgevers is een educatieve uitgeverij die verschillende
Nadere informatieProefexamen ITIL Foundation
Proefexamen ITIL Foundation 1. Van welk proces is risicoanalyse een essentieel onderdeel? a. IT Service Continuity Management b. Service Level Management c. Capacity Management d. Financial Management
Nadere informatieVAN DUIZEND BLOEMEN NAAR EEN HORTUS BOTANICUS Het Portaal 21 januari 2010 sambo~ict Coen Free Faraday van der Linden Maarten van den Dungen
VAN DUIZEND BLOEMEN NAAR EEN HORTUS BOTANICUS Het Portaal 21 januari 2010 sambo~ict Coen Free Faraday van der Linden Maarten van den Dungen Missie-Visie Het succes van de leerling is de reden van ons bestaan.
Nadere informatieBlackboard. Jan Willem van der Zalm Director EMEA, Blackboard Managed Hosting DATE
Blackboard Managed Hosting SURF Cloud Vendordag Jan Willem van der Zalm Director EMEA, Blackboard Managed Hosting DATE 2 Agenda SURF Cloud strategie Blackboard Managed Hosting & Private Cloud Blackboard
Nadere informatieINTEGRATIE PLATFORM IN DE PRAKTIJK. G100 Marco Bakker Project Manager 27 September 2016 De Efteling - Kaatsheuvel
INTEGRATIE PLATFORM IN DE PRAKTIJK G100 Marco Bakker Project Manager 27 September 2016 De Efteling - Kaatsheuvel 1 AGENDA Aanleiding Doelstelling Betrokkenen Voorwaarden Projectfasen Ervaringen 2 DE 10
Nadere informatieGAMP 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 informatieICT 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 informatieSoftware 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 informatieBeveiligingsbeleid Perflectie. Architectuur & Procedures
Beveiligingsbeleid Perflectie Architectuur & Procedures 30 november 2015 Versiebeheer Naam Functie Datum Versie Dimitri Tholen Software Architect 12 december 2014 0.1 Dimitri Tholen Software Architect
Nadere informatiePlan van Aanpak Pilot
Plan van Aanpak Pilot DBK-applicaties Beproeven compatibiliteit DBK-applicaties op innovatieplatform voor de Veiligheidsregio s Status : concept Versienummer : V0.2 Datum : Augustus 2012 Blad : 2 / 6 Inhoudsopgave
Nadere informatieBPR voert regie onder architectuur
BPR voert regie onder architectuur Basisadministratie Persoonsgegevens en Reisdocumenten (BPR) heeft vorig jaar de Burger Service Nummer in productie genomen. Het technisch beheer hiervan is uitbesteed
Nadere informatieProfessioneel beheer. Altijd kunnen vertrouwen op uw (bedrijfskritische) informatiesystemen
Professioneel beheer Altijd kunnen vertrouwen op uw (bedrijfskritische) informatiesystemen Onze visie op professioneel beheer Als een applicatie eenmaal ontwikkeld en in productie genomen is, dan draait
Nadere informatieProces to model en model to execute
Proces to model en model to execute Een end-to-end (bedrijfs)proces (figuur 1) is het geheel van activiteiten die zich, op een bepaalde plaats door een bepaalde rol, in bepaalde volgorde opvolgen en waarvan
Nadere informatieExamen BiSLF Business Information Management Foundation
Examen BiSLF Business Information Management Foundation Publicatiedatum Startdatum 1 januari 2006 1 oktober 2005 Doelgroep De doelgroep voor deze module heeft in zijn of haar functie een rol bij het aansturen,
Nadere informatieTMap Next zoals het hoort!
TMap Next zoals het hoort! Bart Broekman info@bartbroekman.nl Partner van Het verhaal en de moraal Aanleiding: Slimme mensen die domme dingen doen De kern van hoe het hoort Omdraaien van de volgorde Van
Nadere informatieW02 Vergroten voorraad A-nummers
W02 Vergroten voorraad A-nummers Versie 1.0 Datum 12 juli 2012 Status Definitief 1 Probleem 1.1 Omschrijving In 2007 is vastgesteld dat de voorraad A-nummers nog voldoende is tot eind 2013. Daarbij was
Nadere informatieDoel is, dat dit document uiteindelijk een visie formuleert, waar de volgende partijen achter kunnen staan:
User Profile Repository Art Recommender Visie document Versie 2.0 1 juli 2011 Auteurs Hennie Brugman, technisch coordator CATCHPlus hennie.brugman@meertens.knaw.nl Doel is, dat dit document uiteindelijk
Nadere informatieKIM. Slimme acties ondernemen
KIM Slimme acties ondernemen CONTROLE KWIJT? Herkent u dit soort ervaringen ook? Uw organisatie heeft allerlei systemen in huis, maar Niemand weet echt meer hoe het systeem exact werkt Voor kleine wijzigingen
Nadere informatie8-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 informatieRegister- en sleutelbeleid Bert Dingemans
Register- en sleutelbeleid Register- en sleutelbeleid Bert Dingemans Abstract Bij een toenemende volwassenheid van data-architectuur neemt het gebruik van generieke gegevensverzamelingen toe. Deze gegevens
Nadere informatieVan Haren Publishing: platform voor kennis en content
Van Haren Publishing: platform voor kennis en content World Leading Publis Best Practices and M V a n H a r e n P u b l i s h i n g B. V. projectie01.indb 12 Adv 420x297_management boeken.indd 1 Hogeweg
Nadere informatieBeheerrequirements voor regievoering
beheer Beheerrequirements voor regievoering Bij de derde generatie outsourcing besteedt een klant de dienstverlening uit aan verschillende leveranciers. De regievoering over die leveranciers wordt tegenwoordig
Nadere informatieSoftware 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 informatieMet dit whitepaper bieden we u een overzicht we een aantal soorten (product-) toetsing. Dit overzicht is niet volledig!
Toetsingen Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht we een aantal soorten (product-) toetsing. Dit overzicht is niet volledig! 1. Product-, proces- of organisatie-audit
Nadere informatieHet College van burgemeester en wethouders van de gemeente Winsum, gelet op artikel 14 van de Wet gemeentelijke basisadministratie persoonsgegevens;
Het College van burgemeester en wethouders van de gemeente Winsum, gelet op artikel 14 van de Wet gemeentelijke basisadministratie persoonsgegevens; besluit vast te stellen de navolgende Beheerregeling
Nadere informatieGebruikershandleiding Digikoppeling Compliance Voorziening (Portaal)
Gebruikershandleiding Digikoppeling Compliance Voorziening (Portaal) Versie 1.0 Datum 18-10-2016 Status Concept Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900 555 4555 (10 ct p/m)
Nadere informatiekwaliteitsmeterplus 4
kwaliteitsmeterplus 4 Testen voor de toekomst Eenvoudig en intuïtief Werkproces georiënteerd Scheiding bevindingen en issues Hertest methode Schermafdruk en -opnames SaaS Open platform kwaliteitsmeterplus
Nadere informatieTHIRD PARTY MEDEDELING 2017 LEVERANCIER: LIAAN CONSULT B.V. APPLICATIE: Third Party Mededeling 2017 E-DIENSTVERLENING VERSIE 7.2
THIRD PARTY MEDEDELING 2017 LEVERANCIER: LIAAN CONSULT B.V. APPLICATIE: E-DIENSTVERLENING VERSIE 7.2 KENMERK: 1709R.AH117 DATUM: 29 SEPTEMBER 2017 Third Party Mededeling 2017 Applicatie: CityPermit Release:
Nadere informatieCMS Ronde Tafel. Cloud Continuity. Ir. Jurian Hermeler Principal Consultant
CMS Ronde Tafel Cloud Continuity Ir. Jurian Hermeler Principal Consultant Introductie Quint Wellington Redwood Onafhankelijk Management Adviesbureau Opgericht in 1992 in Nederland Ruim 20 jaar ervaring
Nadere informatieHandleiding voor de checklist Overdracht project/change naar beheer. Handleiding : Frédéric van der Vaeren
Auteur(s) Datum Versie Frédéric van der Vaeren 11/03/2013 2.0 Eigenaar Doelpubliek Bert van Hemelen Gebruikers checklist overdracht project/change naar beheer Handleiding : Handleiding voor de checklist
Nadere informatieRegiodagen King & Logius
Regiodagen King & Logius Workshop Digikoppeling Johan ten Dolle Implementatie coördinator Logius Martin van der Plas Technisch adviseur Digikoppeling Logius Sept 2013 Agenda Inleiding Digikoppeling stelselvoorzieningen
Nadere informatieDigiNotar certificaten
DigiNotar certificaten Onlangs is duidelijk geworden dat er digitaal is ingebroken bij het bedrijf Diginotar. Daarmee worden alle DigiNotar certificaten niet meer als veilig geaccepteerd. Certificaten
Nadere informatieCustomer Case: WoningNet
Customer Case: WoningNet WoningNet en Webservices Woonruimtebemiddeling Shared service center Business uitdaging Architectuur visie Woonruimtebemiddeling Woningzoekende Corporatiemedewerker Corporatiemedewerker
Nadere informatieSURFconext Cookbook. Het koppelen van Alfresco aan SURFconext. Versie: 1.0. Datum: 8 december 2013. 030-2 305 305 admin@surfnet.nl www.surfnet.
SURFconext Cookbook Het koppelen van Alfresco aan SURFconext Auteur(s): Frank Niesten Versie: 1.0 Datum: 8 december 2013 Radboudkwartier 273 3511 CK Utrecht Postbus 19035 3501 DA Utrecht 030-2 305 305
Nadere informatieOntsluiten iprova via Internet Voorbeeld methoden
Ontsluiten iprova via Internet Voorbeeld methoden 12-12-2016 Inhoudsopgave 1 Inleiding... 3 2 Algemene aandachtspunten... 4 3 Voorbeeld methoden... 6 3.1 Ontsluiten via een (bestaande) telewerken oplossing
Nadere informatieEIGENSCHAPPEN CONVERGED HARDWARE
EIGENSCHAPPEN CONVERGED HARDWARE Eigenschappen Converged Hardware 1 van 8 Document Informatie Versie Datum Omschrijving Auteur(s) 0.1 29-09-2015 Draft Remco Nijkamp 0.2 29-09-2015 Volgende Versie opgesteld
Nadere informatie1 Data migratie project 1
1 Data migratie project 1 1.1 Inleiding 1.1.1 Achtergrond Het netwerkgebied van Netbeheerder Y is per 1 januari eigendom van Netbeheerder X. Het gaat om circa 100.000 elektriciteits- en 400.000 gasaansluitingen
Nadere informatie