Project Initiatie Document Basisregistratie Personen

Transcriptie

1 Project Initiatie Document Basisregistratie Personen Versie 1.0 Datum 7 juli 2011 Status Publicatieversie

2

3 Inhoud 1 INLEIDING DOEL EN BEREIK VAN DIT DOCUMENT DEFINITIES, ACRONIEMEN EN AFKORTINGEN REFERENTIES DOCUMENTSTRUCTUUR EN LEESWIJZER PROJECTACHTERGROND HISTORIE EN AANLEIDING VAN HET PROJECT PLAATS BINNEN HET PROGRAMMA MODERNISERING GBA BELANGHEBBENDEN EN GEBRUIKERS BELANGRIJKSTE BEHOEFTEN GEBRUIKERS EN BELANGHEBBENDEN Algemene behoeften Koplopergemeenten en -afnemers Toekomstige beheerder van de BRP OPLOSSINGSRICHTING PRODUCTEIGENSCHAPPEN BEGRENZING VAN DE OPLOSSING PROJECTDEFINITIE PROJECTDOELSTELLINGEN EN SCOPE PROJECTAANPAK Projectmanagement en fasering Methoden, technieken en hulpmiddelen Inhuur- en uitbestedingsstrategie OP TE LEVEREN PRODUCTEN EN DIENSTEN RANDVOORWAARDEN EN BEPERKINGEN AFHANKELIJKHEDEN ACCEPTATIE EN AFSLUITING EVOLUTIE VAN HET INITIATIEDOCUMENT BUSINESS CASE PROJECTORGANISATIE EN BEHEERSING STRUCTUUR VAN DE PROJECTORGANISATIE ROLLEN EN VERANTWOORDELIJKHEDEN BEHEERSINGSMECHANISMEN Toleranties Voortgangsrapportages Tijd- en kostenrapportages Kwaliteitsrapportages Uitzondering / Escalatie (INITIËLE) PROJECTPLANNING RANDVOORWAARDEN DECOMPOSITIE VAN WERKZAAMHEDEN Fase 1 Realisatie Bevraging Fase 2 Realisatie Bijhouding Fase 3 Realisatie Verstrekking Fase 4 Realisatie BRP Fase 5 Ketenintegratiefase...32 Pagina 3 van 51

4 6.2.6 Fase 6 Koplopersfase PLANNING BEMENSING EN BENODIGDE HULPBRONNEN PROJECTRISICO S PROJECTSPECIFIEKE RISICO S RISICOMANAGEMENT PROJECTBORGING EN ONDERSTEUNING PROJECTKWALITEITPLAN REQUIREMENTSMANAGEMENTPLAN CONFIGURATIEMANAGEMENTPLAN COMMUNICATIEPLAN...41 BIJLAGE: DETAILS REALISATIEFASEN BRP...43 FASE 1 BEVRAGING...45 FASE 2 BIJHOUDING...46 FASE 3 LEVERING...48 FASE 4 BRP...49 Pagina 4 van 51

5 1 Inleiding 1.1 Doel en bereik van dit document Dit PID betreft alle werkzaamheden die noodzakelijk zijn voor het ontwikkelen, in productie brengen en in beheer geven van de centrale voorzieningen in het kader van de Basisregistratie Personen. De twee belangrijkste redenen voor gebruik van dit document zijn: de basis van een project zeker te stellen, voordat de stuurgroep gevraagd wordt belangrijke verplichtingen aan te gaan ten aanzien van het project. te dienen als basisdocument op grond waarvan de stuurgroep en de projectleider de voortgang van het project kunnen meten, wijzigingen kunnen beoordelen en vragen ten aanzien van de levensvatbaarheid van het project kunnen beoordelen. 1.2 Definities, acroniemen en afkortingen Voor het programma mgba als geheel wordt een zogenaamde Glossary bijgehouden [PGL]. Hierin staan alle definities, acroniemen en afkortingen die nodig zijn om dit document afzonderlijk te kunnen begrijpen. 1.3 Referenties Code Document Versie Datum PPP Programmaplan PA_BRP Architectuur BRP 0.6, concept Augustus 2011 PBC Business Case (programma mgba) PPH Procedurehandboek mgba PGL Glossary mgba PCP Communicatieplan PCAT Producten Catalogus BRP 0.3, concept Februari 2011 PAA Algemene acceptatiecriteria mgba Versie PFM Financieel model SPECBZM Specificaties van burgerzaken modules Definitief September 2011 In het document zal omwille van de leesbaarheid naar deze referenties worden verwezen met de notatie [code]. In dit PID wordt de informatie die in de bovenstaande documenten staat niet onnodig herhaald. Pagina 5 van 51

6 1.4 Documentstructuur en leeswijzer Hoofdstuk 3 (het wat en waarom/de inhoud) beschrijft welke concrete doelstellingen met het project gehaald moeten worden en welke partijen en gebruikers daarbij belang hebben. Hoofdstuk 4 (het hoe/projectmatige) beschrijft de aanpak en projectmatige kant van het project: de oplevering van producten en de globale volgorde waarin de oplossingen gerealiseerd worden. Ook wordt ingegaan op de randvoorwaarden en beperkingen. Hoofdstuk 5 beschrijft de relatie met de Businesscase [PBC]. Hoofdstuk 6 beschrijft de interne organisatie van het project en de projectbeheersing. Hoofdstuk 7 beschrijft de initiële projectplanning en randvoorwaarden. Hoofdstuk 8 beschrijft de belangrijkste projectrisico s. Hoofdstuk 9 betreft tot slot de projectborging en -ondersteuning. Nota bene: Dit PID bevat op plaatsen waar het de leesbaarheid ten goede komt, verwijzingen naar de derde persoon enkelvoud door gebruikmaking van het woord hij. De lezer mag voor deze tevens het woord zij lezen, aangezien dit uitsluitend voor leesbaarheidsredenen is doorgevoerd (in plaats van een verwijzing hij/zij ). Pagina 6 van 51

7 2 Projectachtergrond 2.1 Historie en aanleiding van het project In het Programmaplan mgba [PPP] staat de achtergrond en aanleiding van het programma mgba beschreven. Hier wordt aanvullend ingegaan op de specifieke historie en aanleiding van het project BRP. De doelstellingen van de modernisering van de GBA zijn [PPP]: - GBA als spil in de identiteitsinfrastructuur; - Verhogen snelheid berichtenverkeer en toegankelijkheid van gegevens; - Flexibeler en goedkoper aanpassen van de GBA en van burgerzakensystemen; - Betere gegevenskwaliteit en minder complexe bijhouding; - Mogelijk maken van plaatsonafhankelijke dienstverlening door gemeenten; - Beter faciliteren van gemeentelijke samenwerking (shared services); - Expliciet toepassen van e-overheidsstandaarden. Deze doelstellingen zijn nog steeds volledig van kracht. Wel is de doelstelling uitgebreid met het opnemen van gegevens van niet-ingezetenen (RNI) in de BRP. Binnen het project BRP worden alle toekomstgerichte programmaproducten opgeleverd, te weten de centrale voorzieningen in het kader van de Basisregistratie Personen en het bijhorende Logisch Ontwerp BRP, die daarmee een bijdrage leveren aan de bovenstaande programmadoelstellingen. Het project Basisregistratie Personen is deels ontstaan uit twee voormalige resultaatpaden binnen het programma mgba: - Resultaatpad Burgerzakensysteem (BZS) In het resultaatpad BZS waren opgenomen de deelprojecten: o Burgerzakensysteem-Kern (BZS-K), de centrale bijhoudingsvoorzieningen van de basisregistratie personen; o Burgerzakenmodules, het opstellen van het specificaties van modules die gemeenten nodig hebben om hun burgerzaken taken te kunnen uitvoeren in combinatie met BZS-K; o Logisch Ontwerp BRP, de systeembeschrijving. Van het resultaatpad BZS worden de deelprojecten BZS-K en LO BRP voortgezet in het project BRP. Het deelproject BZM wordt in de zomer van 2011 afgerond en overgedragen aan de VNG. - Resultaatpad GBA-Verstrekkingen (GBA-V) Het resultaatpad GBA-V betrof: o Doorontwikkeling GBA-V gebaseerd op LO 3.x (release 1 t/m 6), de verstrekkingenvoorziening binnen het (huidige) GBA-stelsel; o Ontwikkeling GBA-V gebaseerd op LO BRP (release 7), de verstrekkingenvoorziening binnen het BRP-stelsel; o Ontwikkeling voorzieningen ten behoeve van migratie (release 7). Van het resultaatpad GBA-V wordt de ontwikkeling van GBA-V gebaseerd op LO BRP (release 7) voortgezet binnen het project BRP. De Stuurgroep mgba heeft ingestemd met het ontwikkelen van een geïntegreerde Basisregistratie Personen, waardoor de bovenstaande activiteiten in het kader van BZS-K (bijhouden) en GBA-V (verstrekken) als één project worden opgepakt. Daarnaast zal er één geïntegreerd Logisch Ontwerp worden opgesteld. Pagina 7 van 51

8 Voor een uitgebreid overzicht van de historie van en aanleiding voor het programma wordt verwezen naar het programmaplan [PPP]. 2.2 Plaats binnen het programma modernisering GBA Het programma modernisering GBA is ondergebracht bij het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties. De onderstaande projecten maken hiervan onderdeel uit: - project Basisregistratie Personen; - project Migratie, dat alle voorzieningen realiseert die noodzakelijk zijn om gemeenten, afnemers en de beheerorganisatie te migreren van het GBAnaar het BRP-stelsel, en zorg draagt voor communicatiesystemen tussen het GBA- en het BRP-stelsel; - project Implementatie, dat de regie voert over alle ondersteuning voor gemeenten en afnemers bij de invoering van het BRP-stelsel. Figuur 1 - Plaats van het project BRP binnen het programma mgba Het project BRP valt onder de directe aansturing van de programmamanager mgba, die hierover verantwoording aflegt aan de Stuurgroep mgba en de (gedelegeerd) opdrachtgever. 2.3 Belanghebbenden en gebruikers De BRP kent drie belangrijke gebruikersgroepen: - Bijhoudende instanties. Dit zijn bestuursorganen die wijzigingen in persoonsgegevens mogen doorvoeren. Voor ingezetenen zijn dit de College s van Burgemeester & Wethouders (gemeenten) en voor niet ingezetenen de minister van BZK (Rijk) 1. - Gebruikers van persoonsgegevens, ook wel afnemers genoemd. Dit zijn geautoriseerde bestuursorganen die binnen de kaders van de wet GBA en/of BRP gebruik moeten of mogen maken van persoonsgegevens. Hieronder vallen onder meer overheidsorganisaties en organisaties met een publiekrechterlijke taak. - Beheerder van de BRP. Dit is de organisatie, die namens de minister van BZK, zorg draagt voor de werking en instandhouding van de centrale BRPvoorziening. Het Agentschap BPR is aangewezen als beoogd beheerder van de centrale voorzieningen binnen het BRP-stelsel. 1 De BRP zal initieel worden ingericht met het oog op de bijhouding van gegevens van ingezeten. Wel worden bijhoudende instanties (specifiek: Aangewezen Bestuursorganen, onderdeel van de afnemersgroep) gevraagd ook vanuit de specifieke ABO-rol de functionaliteiten BRP te bezien. (zie ook paragraaf 3.1 Projectdoelstellingen en scope) Pagina 8 van 51

9 Figuur 2 - Belanghebbenden en gebruikers project BRP Binnen de groepen bijhoudende instanties en afnemers onderkennen we twee subgroepen die voor het project BRP een bijzondere positie innemen: Koplopergemeenten. Uit de totale populatie van gemeenten (als bijhouders) zal een tiental fungeren als representatieve groep koplopers bij de invoering van het BRP-stelsel. Deze gemeenten zullen als eerste gebruik maken van Burgerzakenmodules (BZM) en die koppelen aan de BRP. Daarnaast zullen ze als eerste afnemers van de BRP fungeren voor het binnengemeentelijk verkeer. Tijdens de ontwikkeling van de BRP zal het project nauw optrekken met deze gemeenten. Deze gemeenten vervullen een bijzondere rol vanaf de vroege testen van de BRP tot en met de ketenintegratietest, waarbij ze als acceptant van de BRP zullen optreden. Deze gemeenten verwachten van het BRP-project extra ondersteuning en uitgebreide informatie over de werking van de BRP, voorafgaand aan de officiële publicatie van bijvoorbeeld het Logisch Ontwerp. Dit is noodzakelijk om tijdig te kunnen aansluiten op de BRP. Koploperafnemers. Naast de gemeentelijke koplopers zullen tien afnemers fungeren als koplopers, die als eerste gebruik zullen maken van de BRP als gebruiker van persoonsgegevens. Koploperafnemers zullen een belangrijke rol vervullen bij het opleveringen van de bevindingen over de werking van de BRP. Deze informatie zal nadrukkelijk worden gebruikt door de opdrachtgever/projectstuurgroep bij de acceptatie van de BRP. Koploperafnemers krijgen voorafgaand aan de invoering extra ondersteuning en uitgebreide informatie over de werking van de BRP. Nota bene: beide groepen koplopers zullen primair door het project Implementatie worden begeleid en ondersteund. In samenwerking met de projecten BRP en Migratie werkt het project Implementatie een Koploperstrategie uit. Hierin staan onder andere de criteria van koplopers beschreven en tevens wat wordt verstaan onder representatieve groep. Pagina 9 van 51

10 De overige belanghebbenden van het project BRP vallen samen met de belanghebbenden van het programma, zoals opgenomen in het programmaplan [PPP]. 2.4 Belangrijkste behoeften gebruikers en belanghebbenden Algemene behoeften De behoeften van gebruikers en belanghebbenden van de BRP vallen samen met de doelstellingen van het programma mgba, waarbij tijdigheid en kwaliteit van de gegevens tegen de economisch meest voordelige voorwaarden de belangrijkste zijn. In de Architectuur van de BRP [PA_BRP] is een overzicht van de belangrijkste eisen en behoeften van gebruikers opgenomen Koplopergemeenten en -afnemers Koplopergemeenten en -afnemers vormen een belangrijke groep voor het project BRP. Ze geven ons inzicht in de werking van de BRP voor gemeenten (als bijhouder en afnemer) en afnemers in een zo vroeg mogelijk stadium van de ontwikkeling. Doordat het BRP-systeem in die periode op iteratieve wijze wordt ontwikkeld, zijn tussentijdse wijzigingen onvermijdelijk. Het project BRP zal in geval van wijzigingen de koplopers hierover expliciet informeren. Waar mogelijk gaat dit gepaard met vooraankondigingen en instructies hoe best om te gaan met de wijzigingen. Zo zijn de volgende zaken beschikbaar: - Koplopers krijgen als eerste toegang tot concept ontwerpen van de BRP; - Koplopers kunnen beschikken over een aparte omgeving binnen Modernodam (referentie-omgeving), waarmee ze zowel hun Burgerzakenmodules en het binnengemeentelijk gegevensgebruik (gemeenten) als afnemersfuncties (afnemers) in relatie tot de BRP kunnen beproeven. - Koplopers hebben de mogelijkheid tot directe inbreng bij het ontwerp en de ontwikkeling van de BRP (doordat ze meteen meetesten); - Het project BRP informeert koplopers expliciet over op handen zijnde wijzigingen die van invloed zijn op de werking van de BRP-koppelvlakken (overige wijzigingen zijn minder relevant voor koplopers); - Koplopers kunnen voor technische ondersteuningsvragen terecht bij het BRP-projectteam, de ontwikkelaars van de BRP; - Het project BRP kan koplopergemeenten zij het in beperkte mate adviseren over de nadere invulling van Burgerzakenmodules, met name daar waar de opgeleverde specificaties nog ruimte laten voor nadere invulling. - Koplopers vormen een bijzondere doelgroep in het acceptatieproces. Ze informeren de projectstuurgroep BRP zelfstandig over hun bevindingen en adviseren daarmee bij de finale acceptatie van de BRP na BRP (ontwikkel)fase 4, de ketenintegratietest (fase 5) en de koploperfase (fase 6) Toekomstige beheerder van de BRP De beoogd beheerder van de BRP, Agentschap BPR, heeft de taak om de BRPvoorziening ca jaar na inproductiename te beheren. De complexiteit van de BRP vereist dat de beheerder gedegen kennis van de voorziening opdoet alvorens het beheer uit te voeren. Bovendien heeft de beheerder een belangrijke rol in de acceptatie van de verschillende producten. Pagina 10 van 51

11 Daarom worden de volgende zaken geregeld voor (beoogde medewerkers van) de beheerorganisatie: - Beheerders draaien mee tijdens de BRP (ontwikkel)fase 1 t/m 4, indien mogelijk in een projectrol (anders als toehoorder); - Beheerders vervullen de rol van gebruiker van de beheerfunctionaliteit, waarvoor ze onder meer requirements zullen formuleren; - De beheerorganisatie accepteert de BRP na de ketenintegratietest (fase 5), alvorens de koplopersfase ingaat; - Vanaf de start van de koploperfase nemen de beheerders geleidelijk het (tijdelijk) beheer over van de projectorganisatie. Betrokkenheid van de toekomstige beheerder van de BRP is op bestuurlijk niveau als volgt geborgd: - De eigenaar van agentschap BRP, DG Bestuur en Koninkrijksrelaties van BZK, is de opdrachtgever van het programma mgba en tevens opdrachtgever voor de inbeheername BRP, waardoor hij ultiem kan waken over gezamenlijke opdrachten. - De directeur van agentschap BPR is lid van de Stuurgroep mgba en het Sturingsoverleg binnen BZK. - Agentschap BPR is lid van de Projectstuurgroep BRP. 2.5 Oplossingsrichting De BRP is een centraal georiënteerd systeem met één centrale bron voor het bijhouden en verstrekken van persoonsgegevens van ingezetenen en nietingezetenen. De functies van het centrale systeem BRP zijn gegroepeerd in de volgende categorieën, verder koppelvlakken genoemd: - BRP-Bijhouding: ten behoeve van het wijzigen van persoonsgegevens - BRP-Bevraging: ten behoeve van het eenmalig opvragen van persoonsgegeven (initiatief ligt bij de gebruiker) - BRP-Levering: ten behoeve van het spontaan verstrekken van persoonsgegevens naar aanleiding van een wijziging (initiatief ligt bij de BRP) - BRP-Terugmelding: ten behoeve van het melden van een foutvermoeden door een afnemer Ten behoeve van beheer, zowel door beheerorganisatie als gemeenten en afnemers, is een aantal speciale functies nodig. Deze verzameling functies heet BRP-Beheer. Ten behoeve van migratie is een aantal tijdelijke functies nodig die ervoor moeten zorgen dat migratie correct en efficiënt verloopt. Deze functies vallen onder het koppelvlak BRP-Migratie. De BRP is opgebouwd uit identificeerbare componenten, waarbij functionele verantwoordelijkheden zodanig worden verdeeld dat onderhoud zo eenvoudig mogelijk is en dat ze voldoen aan eisen van schaalbaarheid. Voor elk BRPkoppelvlak bestaat een component verantwoordelijk voor een uniforme uitvoering van de betreffende groep functies. Alle bijhoudingen volgen bijvoorbeeld vergelijkbare stappen. Daarnaast bestaan er componenten die ondersteunend zijn of die functionaliteit bieden die gedeeld wordt door andere componenten (ook die functionaliteit moet eenmalig en uniform worden gemaakt en gebruikt). Pagina 11 van 51

12 Tot slot zijn er componenten die een koppeling met externe voorzieningen bevatten, zoals naar de BV BSN. In totaal leidt dat tot de volgende lijst van (functionele) componenten: Bijhouding Bevraging Levering Terugmelding Beheer Migratie Gegevensopslag Toegangsbewaking Protocollering Abonnementenbeheer Kwaliteitscontrole Mutatieverwerking Documentarchief Bijhoudingsrechtenbeheer Managementinformatie Toegang BV BSN Toegang BAG Voor een gedetailleerde beschrijving van de functionele en technische componenten verwijzen we naar het architectuurdocument BRP [PA_BRP]. De werking van de centrale BRP-voorziening, met name gericht op de koppelvlakken, wordt beschreven in het Logisch Ontwerp (LO) BRP. Hierin zijn tevens de gegevenscatalogus en de aansluitvoorwaarden opgenomen. Het Logisch Ontwerp is gelijktijdig met de centrale BRP-voorziening gereed en groeit tussentijds mee met de BRP-voorziening, waarbij meerdere tussentijdse publicaties zullen plaatsvinden. Het Logisch Ontwerp is daarmee het resultaat van de ontwikkelingen binnen het project BRP. In het kader van het project Burgerzakensysteem is in de periode gewerkt aan de eerste invulling van het LO BRP. 2.6 Producteigenschappen De BRP is een administratief systeem, dat in staat is met andere systemen te communiceren via moderne koppelvlakken. Eindgebruikers hebben geen directe toegang tot het systeem, maar koppelen via bijvoorbeeld afnemersvoorzieningen of Burgerzakenmodules. Ten behoeve van beheer worden mens-machine-interfaces gerealiseerd. Aan de registratie van persoonsgegevens ligt een complex stelsel van wet- en regelgeving ten grondslag. Dit maakt dat rekening moet worden gehouden met een grote hoeveelheid uitzonderingssituaties en mogelijkheden, die in reguliere administratieve systemen eenvoudigweg geweerd zouden kunnen worden. Complexiteitsreductie is evenwel niet op alle plaatsen mogelijk en/of toegestaan. Niet-functionele eisen De BRP vormt bovendien een belangrijke hoeksteen van de elektronische overheid, waardoor hoge eisen aan het systeem worden gesteld, zoals hieronder weergegeven: - Zeer hoge beschikbaarheid van de BRP-voorzieningen, omdat gemeenten te allen tijde wijzigingen moeten kunnen doorvoeren en afnemers zowel tijdens Pagina 12 van 51

13 kantoortijden (piekbelasting) als daarbuiten (beperkt gebruik) moeten kunnen vertrouwen op de BRP als basisregistratie; - Snelle responsetijd (ca. 1-3 seconde verwerkingstijd van de meest voorkomende processen van de BRP); - Hoge transactievolumes (geschat op in totaal meer dan 1 miljard per jaar) voor zowel wijzigingen als gebruik van gegevens, waarbij bovendien sprake is van een stijgende trend door gebruik van realtime bevragingen in plaats van opslag in kopiebestanden. Schaalbaarheid is daarbij zeer belangrijk. - Kwalitatief hoogstaande informatie (bijv. door plausibiliteits- en consistentiecontroles); - Veilige opslag van gegevens en afhandeling van transacties (traceerbaarheid en beveiligbaarheid); - Snelle aanpasbaarheid (bijv. snel en goedkoop kunnen doorvoeren van wijzigingen). Een overzicht van de producteigenschappen van de BRP op hoofdlijnen, is opgenomen in de architectuur van de BRP [PA_BRP]. Deze zullen nader worden uitgewerkt in de RUP specificaties van de BRP (use cases en supplementary specifications) en het Software Architectuur Document (SAD). 2.7 Begrenzing van de oplossing De begrenzing zoals opgenomen in het programmaplan [PPP] en de algemene acceptatiecriteria [PAA] zijn van toepassing voor dit project. Specifiek geldt dat waar mogelijk gebruik dient te worden gemaakt van de e- overheidsstandaarden, zoals NORA en GEMMA en standaarden voor het stelsel van basisregistraties en gegevensstandaarden, zoals StUF en DigiKoppeling. Er dient te worden gewerkt met open koppelvlakken. Een open koppelvlak beschrijft de wijze waarop systemen op uniforme wijze met elkaar kunnen communiceren en de informatie erover is voor iedereen toegankelijk. Gelet op het feit dat de BRP persoonsgegevens bevat waarbij alleen geautoriseerde gebruikers toegelaten mogen worden, moeten de centrale voorzieningen voldoen aan de (wettelijke) informatiebeveiligingseisen, waaronder tenminste de wet GBA en/of BRP en het Voorschrift Informatiebeveiliging Rijksdienst Het nieuwe Logisch Ontwerp BRP sluit aan op afspraken binnen het stelsel van basisregistraties. Meer details over de begrenzing van de BRP zijn opgenomen in de architectuur van de BRP [PA_BRP]. Zie ook paragraaf 3.4 Randvoorwaarden en beperkingen. Pagina 13 van 51

14 3 Projectdefinitie 3.1 Projectdoelstellingen en scope De doelstelling voor het project BRP luidt: Het opleveren en overdragen naar beheer van de centrale voorzieningen van de BRP, uiterlijk juni 2013, zodanig dat gemeenten en afnemers hierop uiterlijk juni 2016 zijn aangesloten en de doelstellingen van het programma mgba gerealiseerd kunnen worden. In scope van het project BRP: - Het ontwerpen, ontwikkelen en testen van de centrale voorziening BRP. - De uitvoering van de ketenintegratietest van de BRP in combinatie met alle gekoppelde voorzieningen (in samenwerking met de projecten Migratie en Implementatie) alsmede het doorvoeren van eventuele noodzakelijke wijzigingen in de BRP. - Inhoudelijke ondersteuning en aansluiting van gebruikers tijdens de koplopersfase (in samenwerking met project Implementatie) alsmede het doorvoeren van eventuele noodzakelijke wijzigingen in de BRP. - De totstandkoming van het Logisch Ontwerp BRP en de afstemming met wet- en regelgeving. - Ondersteuning bij de werkzaamheden van de beheerder van de BRP en het Logisch Ontwerp BRP ter voorbereiding op de inbeheername. - De overdracht van de BRP en het Logisch Ontwerp naar de beheerorganisatie. - Werkzaamheden ten behoeve van de noodzakelijke (informatie)beveiliging van het BRP-stelsel, in nauwe samenwerking met de beheerder van de BRP 2. - [Onder voorbehoud] aansluiting op e-overheidsontwikkelingen, onder de aanname dat de BRP kan/mag communiceren met afnemers via een technisch koppelvlak voor DigiMelding en DigiLevering 3, waarbij de leverings- en meldingsfunctionaliteit bij de BRP zelf ligt. Niet in scope van het project BRP zijn: - Aanschaf productieomgeving (P) De beheerder van de BRP schaft de productieomgeving aan. De opdrachtgever van het programma mgba zal hierover (financiële) afspraken maken met de beheerder. Het project BRP levert de specificaties en ondersteuning op die noodzakelijk zijn voor het aanschaffen en initieel inrichten van de productieomgeving. - Inrichting en beheer Modernodam (OTAR) Binnen het programma was een apart project ingericht voor de inrichting en beheer van Modernodam. Project BRP is een gebruiker van Modernodam. De specificaties en ondersteuning die noodzakelijk is voor de inrichting en werking van Modernodam worden door het project BRP geleverd. - Implementatie van de BRP Binnen het programma is een afzonderlijk project gedefinieerd voor de implementatiewerkzaamheden. Het project BRP levert ondersteunende 2 Eventuele aanschaf van beveiligingsvoorzieningen vallen onder de aanschaf van de productieomgeving en zijn derhalve niet in scope. 3 Op het moment van schrijven van dit PID lopen nog diverse onderzoeken naar de mogelijkheden voor een technisch koppelvlak waarvan ook de BRP gebruik kan maken. Pagina 14 van 51

15 diensten aan dit project, bijvoorbeeld door inhoudelijke kennis te leveren en tweedelijns support te leveren bij aansluiting van gebruikers en koplopers (zie: in scope). Zodra de koplopersfase is afgesloten, neemt de beheerorganisatie deze rol over. - Lokaal BRP In het Bestuurlijk Akkoord van 17 december 2009 is afgesproken dat gemeenten op verzoek kunnen beschikken over een lokaal BZS-K (lees: lokaal BRP) ten behoeve van een geleidelijke overgang naar het BRP-stelsel. Nadere gesprekken met gemeentelijke vertegenwoordigers hebben uitgewezen dat de behoefte aan een lokaal BRP op dit moment niet bestaat. Dit onder twee strikte voorwaarden. Ten eerste dat de BRP voldoet aan de beschikbaarheidseisen. Ten tweede dat gemeenten middels de zogenaamde Burgerzakenmodule binnengemeentelijke levering [SPECBZM], kunnen voorzien in de behoefte aan beschikbaarheid van de gegevens binnen de gemeente 4. Mocht aan een van deze voorwaarden niet kunnen worden voldaan, dan kan de Projectstuurgroep BRP, of de Stuurgroep mgba de lokale BRP weer in scope verklaren. - Realiseren Burgerzakenmodules De verwerving van Burgerzakenmodules is een verantwoordelijkheid van de gemeenten. Het project BRP biedt gemeenten de mogelijkheid om in de Modernodamomgeving zoveel mogelijk gezamenlijk op te trekken met betrekking tot het realiseren van de centrale BRP-voorziening en de modules, in samenhang. - Realiseren van migratievoorzieningen Het realiseren van migratievoorzieningen valt buiten de scope van dit PID. Het scheppen van randvoorwaarden waaronder efficiënt kan worden gemigreerd, valt wel binnen de scope. Enerzijds wordt bij de ontwikkeling van BRP-voorzieningen zoveel mogelijk rekening gehouden met migratievraagstukken (minimaliseren van lasten voor gebruikers), anderzijds wordt de BRP uitgerust met een tijdelijk koppelvlak voor de migratievoorzieningen ten behoeve van een optimale communicatie tussen beide. - Tijdelijke voorziening RNI in het kader van GBA LO 3.8 Voor de tijdige invoering van de RNI is een tijdelijke RNI-voorziening nodig. Het realiseren van deze voorziening valt buiten de scope van dit PID. De BRP wordt wel ontwikkeld met het oog op de volledige BRP-populatie (voormalig GBA en RNI). Na de implementatie van de tijdelijke RNIvoorziening (buiten scope project BRP) kan de BRP RNI-gegevens verstrekken, mede via de migratievoorzieningen. Het BRP-koppelvlak Bijhouding wordt voorbereid op de definitieve RNI-functionaliteiten, die in het kader van het BRP-stelsel worden ontwikkeld (hierover moet nog besluitvorming plaatsvinden). - Ontwikkeling bijhoudingsfuncties voor RNI De bijhouding van de BRP zal initieel gebeuren voor ingezetenen door gemeenten met Burgerzakenmodules. Hoewel de BRP zoveel mogelijk wordt voorbereid op het bijhouden van gegevens van niet-ingezetenen, zal de daarmee corresponderende bijhoudingsvoorziening (naar het model van de burgerzaken modules) niet worden ontwikkeld door het project BRP. Na de implementatie van de BRP wordt voor de bijhoudingsfunctionaliteit RNI een nieuw project opgestart, waarbij wordt geadviseerd dit project na de koplopersfase BRP te starten. De tijdelijke RNI-voorziening en de BRP kunnen tot die tijd goed naast elkaar functioneren. Met deze planning wordt 4 De module Binnengemeentelijke Levering wordt nader beschreven in de specificaties voor de burgerzaken modules. Deze module zal uitsluitend voor raadplegen en leveren worden ingezet en niet voor bijhoudingsactiviteiten. Pagina 15 van 51

16 voorkomen dat gemeenten en andere afnemers overbelast worden door implementatie van zowel de BRP als de definitieve RNI-voorziening. Het programma mgba bereid voor het nieuwe project een projectplan voor (hierover moet nog besluitvorming plaatsvinden). - Eventueel noodzakelijke aanpassingen van de Handleiding Uitvoeringsprocedures (HUP) en Handleiding Operationele Procedures (HOP), zoals momenteel ingezet in het huidige GBA-stelsel. Beide documenten zijn in beheer bij Agentschap BPR. Het project BRP zal Agentschap BPR voorzien van basismateriaal ten behoeve van de eventuele aanpassingen, indien het LO BRP en/of haar bijlagen hierin niet reeds voorzien. - Het aanpassen of deels herontwikkelen van de Beheervoorziening BSN (presentievraag) De (functionele) component Toegang BV BSN (zie paragraaf 3.5) regelt de koppeling tussen de BRP en de BSN. De aanpassing van de beheervoorziening zelf maakt geen onderdeel uit van het project BRP. 3.2 Projectaanpak Projectmanagement en fasering De BRP moet in overzichtelijke stappen tot stand komen, waarbij - mogelijke risico s en onzekerheden zo vroeg mogelijk in het traject worden geadresseerd, - na elke fase een test kan plaatsvinden, waarbij onderdelen in samenhang kunnen worden beproefd, - stappen goed beheersbaar zijn. Om te komen tot een indeling en planning van realisatiewerkzaamheden is de volgende aanpak gevolgd: - De functionaliteit van de BRP is verdeeld over 17 functionele componenten (zie paragraaf 2.5). - Van de componenten zijn vervolgens versies onderkend, die elk een stadium in de ontwikkeling representeren. - De versies zijn in een logische volgorde in de tijd uitgezet. - De versies zijn verdeeld over vier realisatiefasen, zodanig dat: o een evenwichtige verdeling ontstaat, o elke fase een herkenbaar (hoofd)doel heeft, o het zwaartepunt in de middelste twee fasen zit. - Binnen een fase onderscheiden ontwikkelen we op basis van releases (samenhangende delen functionaliteit, zie bijlage 2a). - Releases zullen waar mogelijk parallel worden uitgevoerd. - Na afronding van elke release kunnen - in principe - de (interne) functionele testen ervan starten. NB: In bijlage 2a is een uitgebreide beschrijving van de inhoud van de verschillende releases opgenomen. Tijdens de realisatiefasen 1 tot en met 4 zullen alle testen worden uitgevoerd, die in de Modernodamomgevingen (ontwikkel, test, acceptatie en referentie) kunnen worden uitgevoerd. Op deze wijze borgen we dat alle functionele en zoveel mogelijk technische testen zijn uitgevoerd, voordat de ketenintegratietest (KIT, fase 5) start. Waar mogelijk en zinvol wordt gebruik gemaakt van geautomatiseerd testen, zodat deze herhaald en bij voorkeur na werktijd uitgevoerd kunnen worden. Resultaten zijn dan de volgende werkdag beschikbaar. Wanneer nieuwe functionaliteit wordt toegevoegd, tonen deze herhaalde (regressie)testen aan dat reeds bestaande Pagina 16 van 51

17 functionaliteit nog net zo werkt als voor de wijziging op het systeem. Daarmee wordt de goede werking van zowel de bestaande als de nieuwe functionaliteit getest. De BRP wordt pas vrijgegeven voor de KIT als de bovenstaande testen geslaagd zijn. Indien bepaalde testen, zoals stresstesten of testen waarbij koppelingen met externe (pre)productiesystemen betrokken zijn, niet uitvoerbaar zijn in Modernodam, zullen deze in de ketenintegratietest worden uitgevoerd. Samen met de oplevering van de BRP aan het eind van fase 4, wordt ook het LO BRP gepubliceerd. Aan het einde van de vier realisatiefasen wordt de BRP vrijgegeven voor (pre)productie. Zij is dan gereed voor de laatste beproevingen die plaatsvinden in twee opeenvolgende fasen, waarbij de BRP geleidelijk in productie wordt gebracht: - Ketenintegratiefase: In de ketenintegratiefase wordt de BRP in een productierijpe vorm in de toekomstige productieomgeving beproefd in combinatie met alle gekoppelde systemen (bij voorkeur in pre-productie stadium). In deze fase, waarbij de projecten BRP en Migratie gezamenlijk zullen optrekken, wordt de ketenintegratietest (KIT) uitgevoerd. - Koplopersfase: Tijdens de koplopersfase, gaat een beperkte groep (ca. 10) gemeenten en afnemers de BRP daadwerkelijk gebruiken in een productiesituatie. De groep koplopers wordt in deze fase bij de inrichting van de productieomgeving en aansluiting op de BRP begeleid. - Na afloop kan de BRP worden vrijgegeven voor productie en kunnen de overige gemeenten en afnemers aansluiten. Het beheer is aan het eind van deze fase volledig overgedragen aan BPR. Een aanvullende beschrijving is opgenomen in paragraaf 7.3 Planning Methoden, technieken en hulpmiddelen Het project BRP hanteert Prince2 voor de projectmatige sturing (proces) en RUP voor de systeemontwikkeling (inhoud). Meer informatie hierover is opgenomen in het procedurehandboek [PPH]. Het project BRP is opgedeeld in fasen. Ten behoeve van de projectsturing wordt per fase een faseplan opgesteld, waarin voor iedere fase, zoals beschreven in dit PID, in detail wordt ingegaan op de resultaten die gerealiseerd worden. Beoogde resultaten per fase zijn onder meer de verschillende releases (zie bijlage 2a) en andere projectproducten (testplan, acceptatieplan etc.). Elke fase wordt afgerond met een fase-eindrapport en vrijgaveadvies voor de bij de fase behorende producten (zie ook paragraaf 4.6 Acceptatie en Afsluiting). De faseplannen, fase-eindrapporten en vrijgaveadvies worden ter besluitvorming aan de Stuurgroep mgba voorgelegd. Ten behoeve van de sturing op het proces van systeemontwikkeling is elke fase in doorlooptijd opgedeeld in verschillende iteraties, met een vaste doorlooptijd van drie weken. Voor iedere iteratie wordt de doelstelling, die is genoemd in het faseplan, uitgediept. Dit gebeurt tijdens een zogenaamde planningsworkshop waarbij alle teamleden aanwezig zijn. Hierbij worden twee sturingsinstrumenten gebruikt: de backlog en de risicolijst. De backlog is het totaaloverzicht van producten en resultaten die gerealiseerd moeten worden. De backlog is geordend op logisch volgordelijkheid van de Pagina 17 van 51

18 ontwikkeling van de BRP. Hierdoor worden producten en resultaten just-in-time gerealiseerd, waardoor er geen werk blijft liggen of bijvoorbeeld ontwerpen herijkt moet worden omdat deze te vroeg zijn opgesteld. De risicolijst is een overzicht van risico s die bijzondere aandacht vergen of geen integraal onderdeel vormen van de backlog onderwerpen. Per risico wordt aangegeven welk resultaat aan het einde van de iteratie moet zijn behaald om het risico te minimaliseren. Figuur 3 - schematisch overzicht van iteratief werken per fase De risico s op deze lijst worden tijdens de iteratie planningsworkshop door het projectteam samen met de projectleider benoemd en voorzien van een risicofactor (kans x impact). De inschattingen zijn gebaseerd op inzichten van het team, waarbij de projectleider een finaal oordeel geeft. In geval van twijfel zal deze overleggen met de programmamanager. Het gaat hier om risico s die bijzondere aandacht vergen of geen integraal onderdeel vormen van de backlog onderwerpen. Met behulp van de risicofactor worden de risico s geprioriteerd. Per onderdeel van de backlog en risico wordt bepaald welke resultaat aan het einde van de iteratie is bereikt. Dit wordt vastgelegd in een iteratieplan. Dit plan wordt met de programmamanager, gedelegeerd opdrachtgever en de projectstuurgroep BRP gedeeld, zodat zij inzicht hebben in de gemaakte afwegingen en/of in kunnen grijpen in de uit te voeren werkzaamheden, bijvoorbeeld bij een andere afweging van de risico s. De in het iteratieplan benoemde resultaten worden vertaald naar concrete en meetbare taken per teamlid. Per taak wordt een schatting gemaakt van de benodigde uren, waardoor de werkvoorraad meetbaar is en in overeenstemming is met de beschikbare capaciteit. Dagelijks bepaalt ieder teamlid hoeveel tijd nog nodig is voor afronding van een taak. Hierdoor is het mogelijk om tijdens de iteratie steeds vast te stellen of de doelstellingen al dan niet gehaald gaan worden door de nog te besteden tijd af te zetten tegen de beschikbare tijd. Als blijkt dat taken toch langer gaan duren dan wordt door de teamleider en het teamlid de takenlijst geherprioriteerd, eventueel na afstemming met de projectleider. Pagina 18 van 51

19 Tijdens de iteratie kunnen ook nieuwe taken ontstaan. De teamleider evalueert of door herprioritering de doelstellingen van de fase moeten worden bijgesteld. Zo niet, dan bepaalt hij samen met het teamlid de nieuwe prioritering van de takenlijst en informeert de projectleider. Indien dat wel het geval is, overlegt hij met de projectleider die hierover met de programmamanager in overleg treedt. Aan het einde van de iteratie wordt een assessment uitgevoerd, waarin de resultaten van de afgelopen iteratie worden geëvalueerd. Allereerst wordt vastgesteld welke resultaten zijn behaald. Van de resultaten die niet of deels zijn gehaald, wordt de oorzaak door de teamleider achterhaald en wordt in de iteratie planningsworkshop bepaald naar welke iteratie deze resultaten doorgeschoven worden. De oorzaken worden geanalyseerd en waar mogelijk worden leerpunten geformuleerd die tijdens de volgende iteratie actief toegepast worden. De resultaten van het assessment worden vastgelegd in een assessmentdocument, dat, net als het iteratieplan, met de programmamanager, gedelegeerd opdrachtgever en de projectstuurgroep BRP wordt gedeeld. De assessments vormen tevens belangrijke input voor het fase-eindrapport. Het project maakt, met name gedurende de realisatiefasen (1 t/m 4), gebruik van de voorzieningen in Modernodam. Deze ontwikkel-, test-, acceptatie- en referentieomgeving stelt het project in staat om eigen deelproducten, ontwikkeld in de vorm van releases, te beproeven in samenhang met elkaar en/of met de omgeving. Waar mogelijkworden zoveel mogelijk koppelingen met extern afhankelijke systemen gelegd, zoals Burgerzakenmodules, afnemerssystemen, e- overheidsdiensten en de voorzieningen in het kader van Migratie en de RNI. Op deze wijze waarborgen we in een zo vroeg mogelijk stadium de goede werking van alle in het BRP-stelsel betrokken voorzieningen. Voor een gedetailleerde beschrijving van Modernodam, verwijzen we naar het procedurehandboek [PPH] Inhuur- en uitbestedingsstrategie Voor de werkzaamheden in het kader van systeemontwikkeling hebben Stichting ICTU en het programma mgba een raamovereenkomst afgesloten met acht dienstverleners (en/of samenwerkingsverbanden). Daarnaast kan het programma gebruik maken van de overige raamovereenkomsten van ICTU. Zie hiervoor tevens het procedurehandboek [PHB]. Het project BRP maakt een zorgvuldige afweging tussen inhuur van menskracht en het, al dan niet op basis van resultaatverplichting, uitbesteden van werkzaamheden. Indien sprake is van uitbesteding, zal dit voornamelijk een (combinatie van) technische component(en) bevatten, waarvoor een geselecteerd partij gedurende de releases waarbinnen die component(en) worden geraakt werkzaamheden zal uitvoeren, een zogenaamde ontwikkelstroom. Zodoende voorkomen we dat er voortdurende overdracht van werkzaamheden noodzakelijk is en er teveel wisselingen zullen optreden. 3.3 Op te leveren producten en diensten Het project BRP levert de volgende producten en diensten op 5 : - Werkende centrale BRP-voorzieningen, bestaande uit: o (maatwerk)software, inclusief bijhorende broncode; o database(s) met productiegegevens; 5 Het project levert uiteraard ook managementproducten op. Hiervoor wordt verwezen naar het Procedurehandboek Pagina 19 van 51

20 o installatie-instructies; o architectuurdocumenten; o ontwerpdocumentatie; o beheerhandleidingen; o informatiebeveiligingsplan BRP. - Het Logisch Ontwerp BRP, bestaande uit: o hoofddocument betreffende de systeembeschrijving o bijlagen met o.a. koppelvlakdefinities en gegevenscatalogus o basisinformatie ten behoeve van aanpassingen HUP en procesbeschrijvingen. - Integratietesten (tijdens de realisatiefasen) van de BRP, eventueel in combinatie met reeds beschikbare externe voorzieningen. - Uitvoering van testen ten behoeve van de BRP tijdens de Keten Integratietest. - Integratie van de BRP in het stelsel, inclusief de koppeling met externe voorzieningen en communicatie-infrastructuur (DigiNetwerk etc.). - Ondersteuning van gemeenten en afnemers tijdens de voorbereiding op aansluiting op de BRP, met name gericht op koplopers (tot en met het einde van de koplopersfase). - Ondersteuning van de beheerder bij het in beheer nemen van de BRP (tot en met het einde van de koplopersfase). Een uitgebreide beschrijving van de op te leveren producten en diensten is opgenomen in de Producten Catalogus BRP [PCAT], die aan het einde van fase 1 zal worden opgeleverd. Het project conformeert zich bovendien tenminste aan de algemene acceptatiecriteria mgba [AAC] en de daarbij horende (management)producten. 3.4 Randvoorwaarden en beperkingen Voor het BRP-project onderkennen we de bij de start onderstaande randvoorwaarden: - Het hart van de BRP-voorziening vormt een relationeel model van uitgenormaliseerde gegevens. Dit houdt in dat gegevens enkelvoudig worden opgeslagen en via (unieke) sleutels met elkaar in verband staan. Dit in tegenstelling tot de huidige GBA-voorzieningen, waarbij gebruik wordt gemaakt van persoonslijsten. - De BRP communiceert met haar gebruikers op moderne wijze; indien gebruikers hiertoe (nog) niet in staat zijn, worden deze daarbij geassisteerd door migratievoorzieningen 6, die namens dezen een moderne gebruiker simuleren. De centrale BRP-voorzieningen concentreren zich zodoende maximaal op hun moderne taak, zodat aanpassingen in de voorzieningen zelf na de migratieperiode niet noodzakelijk is. - De Registratie Niet-Ingezetenen is ingevoerd en initieel gevuld; indien dit niet het geval is, zal de BRP rekening moeten houden met bepaalde groepen opgeschorte persoonslijsten en de mogelijkheid tot het bijhouden van de gegevens daarvan. - De e-overheidsvoorzieningen DigiMelding en DigiLevering 7 bieden de BRPvoorziening de mogelijkheid aan te sluiten op een technische koppelvlak, waarlangs BRP berichten van en naar afnemers kunnen worden geleid conform de eisen van de BRP. 6 Zoals opgeleverd door het project Migratie binnen het programma mgba 7 Ten tijde van het schrijven van dit PID is het onbekend of het project DigiLevering dit technisch koppelvlak zal bieden voor de BRP. Onderzoek voor een dergelijk koppelvlak ten behoeve van DigiMelding is nog gaande. Pagina 20 van 51