1 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 die overgaan naar Netbeheerder X. Per 1 januari zal Netbeheerder Y organisatorisch en systeem technisch volledig geïntegreerd zijn in Netbeheerder X. Om dit te bewerkstelligen wordt de data uit de systemen van Netbeheerder Y ingehuisd in de systemen van Netbeheerder X. Hiervoor moet een data extractie uit de systemen van Netbeheerder Y plaatsvinden, die dan wordt ingeladen in de systemen van Netbeheerder X. Tellingen, een Gebruikers Acceptatie Test (afgekort tot GAT) per systeem en een keten- /regressietest moeten daarna aantonen, dat de systemen van Netbeheerder X met daarin toegevoegd de data van Netbeheerder Y blijven werken conform specificaties. 1.1.2 Scope 1.1.2.1 Domeinen en processen # Domein (Hoofd)proces *) [1] Asset Management Registratie ondergrondse bedrijfsmiddelen Registratie bovengrondse bedrijfsmiddelen Synchronisaties omliggende systemen Rapportages [2] Infra Services Realiseren aansluitingen Realiseren infrastructuur Oplossen storingen Onderhoud & inspecties Rapportages [3] Klant & Markt Beheren aansluitregister Alloceren en Reconciliëren Meetdata en Factureren (periodiek) Rapportages *) Gebaseerd op de Proces Atlas van Netbeheerder X 1.1.2.2 Systemen (meest relevante) De doelsystemen waar de data van Netbeheerder Y in belandt en overige systemen van Netbeheerder X, die door de inhuizing worden geraakt (zoals portals). De relevante koppelingen tussen de doelsystemen en aanpalende systemen. # Onderdeel (Doel)systeem Toelichting [1] Asset Management (AsM) GEN/GIS Geografisch informatiesysteem SAP Bedrijfsmiddelen Infra Services (INFRA) STAP Storingensysteem 1 Dit document is opgesteld vanuit perspectief van Netbeheerder X, die data overneemt van Netbeheerder Y Infocon versie 0.1 Pag. 1 van 9

# Onderdeel (Doel)systeem Toelichting WOM Workflow systeem Diverse portalen Zoals OVL portal [2] Klant & Markt (K&M) KV Aansluitregister Incl. C-AR GV Aansluitregister Allocatie en Reconciliatie Diverse portalen Zoals Slimme meter portaal 1.1.3 Aanpak migratie De migratie van data vindt per systeem plaats met max. drie proefmigraties (PM1, PM2 en PM3) en een dry run (afgekort tot DR; d.i. de generale repetitie) t.b.v. de productie belading. 1.1.4 Projectorganisatie Voor de integratie van Netbeheerder Y is de volgende projectorganisatie opgezet: Tellingen, de GAT testen per systeem en de keten-/regressietest vallen binnen het deelproject Transitie en Testen. Facility Management, HR, Finance en Fudura vallen buiten de scope van tellingen en testen. Het deelproject ICT is ondersteunend aan de overige deelprojecten. Infocon versie 0.1 Pag. 2 van 9

1.2 Product risico s (PRA) 1.2.1 PRA AsM Kenmerk: Functionaliteit *) Deelobjecten: Migratie Data Migratie Opwerken E GIS/GEN systeem SAP-PM systeem Keten/ regressie Faalkans **) H H L L L Testdoelen Schade Registratie H A A B B B ondergrondse bedrijfsmiddelen Registratie H A A B B B bovengrondse bedrijfsmiddelen Synchronisaties L B B C C C omliggende systemen Rapportages L B B C C C Risicoklasse => A A B B B *) Controle op volledigheid en juistheid van de data migratie en de functionaliteiten t.b.v. de registratie van ondergrondse (in het GIS/GEN systeem) en bovengrondse (SAP-PM systeem) bedrijfsmiddelen. **) Faalkans = Foutkans * Frequentie van gebruik. Voor de migratie wordt de Foutkans Hoog (H) ingeschat vanwege complexiteit, nieuwe (opwerk)functies, geografische spreiding ontwikkelaars, migratie glasvezel en riool nog niet duidelijk, e.d. Ook de Frequentie van gebruik van de gemigreerde data is Hoog (H). Hiermee komt de Faalkans op Hoog (H) uit. Voor de overige deelobjecten verandert er geen functionaliteit (er wordt slechts data toegevoegd). De Frequentie van gebruik wordt geschat op Normaal. Dit brengt de Faalkans op Laag (L). Kenmerk: Deelobjecten: Online Batch GEN, Tijdbeslag *) Faalkans **) L L Testdoelen Schade Registratie H B - ondergrondse bedrijfsmiddelen Registratie H B - bovengrondse bedrijfsmiddelen Synchronisaties L - B gekoppelde systemen Risicoklasse => B B *) Ook wel performance genoemd **) Er komt data bij in GEN Productie, die Beheer GBS met de beschikbare synchronisatie tools naar de gekoppelde systemen brengen. Functioneel verandert er niets. Dus als de synchronisaties langer gaan duren dan is dat zo, is inherent aan meer data. Beheer GBS verwacht overigens niet dat het wezenlijk langer gaat duren. Hun schatting is, dat er ten opzichte van de huidige grootte ongeveer 15% data er bij komt. Met de eerdere carve-out naar netbeheerder Z wordt naar schatting 5% verwijderd. Overigens de synchronisaties zijn afhankelijk van het aantal dagelijks aangeboden mutaties, die zullen met de data uit Netbeheerder Y niet significant anders zijn. Beheer GBS ziet hier dus geen problemen. Infocon versie 0.1 Pag. 3 van 9

1.2.2 PRA Infra Kenmerk: Inpasbaarheid *) Deelobjecten: STAP WOM Portals Keten/ regressie Faalkans **) L L L L Testdoelen ***) Schade Realiseren L C C C C aansluitingen Realiseren L C C C C infrastructuur Oplossen storingen L C C C C Onderhoud & L C C C C inspecties Rapportages L C C C C Risicoklasse => C C C C *) D.i. de integratie tussen de (primaire) processen en de doelsystemen. **) Er vinden geen proces-, systeem- en interface aanpassingen plaatst t.g.v. de inhuizing van Netbeheerder Y objecten. ***) Tabel is op hoofdprocesniveau. 1.2.3 PRA K&M Kenmerk: Inpasbaarheid *) Testdoelen***) Beheren aansluitregister Alloceren en Reconciliëren Meetdata en Factureren 2 (periodiek) Deelobjecten: Migratie Data GV KV Aansluitregister Aansluitregister A&R Portals Keten/ Faalkans **) H L L L L L Schade H A B B B B B H A - - B - B H A B B B B B Rapportages L B C C C C C Risicoklasse => A B B B B B regressie *) D.i. de integratie tussen de (primaire) processen en de doelsystemen. **) Er vinden geen proces-, systeem- en interface aanpassingen plaatst t.g.v. de inhuizing van Netbeheerder Y. ***) Tabel is op hoofdprocesniveau. Voor een verklaring van de gebruikte afkortingen voor risicoklassen in de bovenstaande tabellen: zie 2 Factureren n.v.t. voor KV Infocon versie 0.1 Pag. 4 van 9

Bijlage: Toelichting testtechnieken. 1.3 Testaanpak Tijd 1.3.1 Migratie AsM (GIS/GEN en SAP-PM) In het domein AsM worden Gas en Elektra gescheiden van elkaar gemigreerd in 3 tot 4 deelmigraties. Voor Elektra wordt eerst ondergronds (GIS/GEN) gemigreerd en daarna bovengronds (SAP-PM). Voor Gas worden ondergronds en bovengronds gelijktijdig gemigreerd. Uiteindelijk vindt de migratie voor zowel Elektra als Gas als de Dry Run plaats in de acceptatieomgeving van GIS/GEN. In de testaanpak worden zowel de deelmigraties en de Dry Run (DR) alsook de werkelijke migratie officieel goedgekeurd/geaccepteerd door de formeel acceptanten. De goedkeuring van de deelmigraties en de Dry Run (DR) is randvoorwaardelijk voor het starten van de werkelijke migratie. Tevens zijn de goedkeuring van de werkelijke migratie en de acceptatie van de data opwerking meerlijnigheid beheerkaart randvoorwaardelijk voor de ingebruikname van de gemigreerde data. Het uitgangspunt voor het accepteren van de Netbeheerder Y migratie is het migratieverslag 3 en de acceptatiecriteria. K&M Voor de GV en KV systemen zal de migratie van de Netbeheerder Y data bestaan uit onderstaande stappen: 1. Datamapping benodigde gegevens (Netbeheerder X Netbeheerder Y) 2. Extractie uit de bronsystemen van Netbeheerder Y (incl. tellingen) 3. Laden Netbeheerder Y data in een StagingDB 4. Validatie, transformatie en tellingen in de StagingDB 5. Export data van StagingDB 6. Upload data in doelsysteem GV en KV 7. Controles en tellingen in GV en KV 3 Een beschrijving van hoe de (proef- of dryrun-)migratie in zijn werk is gegaan Infocon versie 0.1 Pag. 5 van 9

Aan de hand van datamapping zal bepaald worden (op functionele/technische SAP velden) welke data benodigd is om de migratie in het GV systeem uit te kunnen voeren, zodat de aansluitingen volledig en gebruiksklaar in het GV systeem opgevoerd kunnen worden. Vanuit Netbeheerder Y zal deze data aangeleverd worden, in een door Netbeheerder X geprefereerd formaat. Tevens worden hier tellingen en volledigheidscontroles door Netbeheerder Y meegeleverd. Deze tellingen en controles zijn voor de borging dat alle data door de gehele keten uiteindelijk correct en volledig in het GV systeem landt. De data vanuit Netbeheerder Y wordt in een zogenaamde StagingDB geladen (Oracle database), waarin na het laden nogmaals controles en tellingen uitgevoerd worden. Tevens worden hier validaties en transformaties uitgevoerd, zodat de data inputklaar aan GV systeem opgeleverd kunnen worden. De aanpak voor zowel het tellingenmodel als het testen zal op de hierboven beschreven migratieaanpak worden afgestemd (n.t.b. in DTP, K&M). Voor wat betreft Slimme meters behoeft er geen brondata te worden overgehaald vanuit Netbeheerder Y systemen, omdat de data van de Slimme meters van Netbeheerder Y zich al op de EIServer van Netbeheerder X bevinden. Wel zal de data m.b.t. de netbeheerder, area s, e.d. aangepast gaan worden. Ook zit er een afhankelijk met het KV systeem. Op dit moment worden de FO s voor de wijzigingen opgesteld. Zodra deze definitief zijn zal de impact hiervan worden meegenomen in het DTP, K&M voor het onderdeel Slimme meters. 1.3.2 GAT De GAT wordt uitgevoerd door de operationeel acceptanten en officieel goedgekeurd/- geaccepteerd door de formeel acceptanten. Doel van de test is te bepalen of de doelsystemen van Netbeheerder X juist functioneren met zowel de Netbeheerder Y data als de Netbeheerder X data. De GAT zal worden uitgevoerd in de acceptatieomgevingen van de betreffende systemen nadat de Dry Run s zijn uitgevoerd. AsM Voor zover mogelijk (de eerste deelmigratie migreert slechts E ondergronds en liggingen van stations) wordt bij elke deelmigratie in de migratieomgeving een (gedeeltelijke) GAT uitgevoerd. 1.3.3 Keten-/regressietest De keten-/regressietest is een dynamische test, die moet aantonen, dat de aaneengesloten reeks van systemen een (bedrijfs)proces conform de specificaties ondersteunt. In de bovenstaande afbeelding vormen de systemen A t/m E een keten: van buiten het proces via C, A, B, D en E weer naar buiten. A en C, B, en D en E behoren tot verschillende organisatiedelen. Betrokken bij een ketentest zijn: processen, systemen en hun interfaces. De keten-/regressietesten worden uitgevoerd in de acceptatieomgevingen, na de GAT door (afvaardigingen van de) business en functioneel beheerders (tezamen de operationeel acceptanten). Ten behoeve van de Go/NoGo voor productie stelt de testcoördinator in samenspraak met de formeel acceptanten het vrijgave advies op. Infocon versie 0.1 Pag. 6 van 9

1.3.4 Relatie kwaliteitsattribuut, testvorm en testtechniek Kwaliteitsattribuut PRA-RK Relatief belang Migratie (juistheid, volledigheid) Functionaliteit (juistheid, volledigheid) Processen 5 (inpasbaarheid) Tijdbeslag (performance) (dynamisch) Testvorm A Technische tellingen Functionele tellingen Hash totals Visuele controles 4 B Pré-test GAT/Functionele test B Ketentest Variaties in procesverloop 6 B Opbouwen statistieken (online transacties tijdens GAT) (Doorloop)tijdmetingen tijdens migratie- en ketentesten 7 Testtechnieken Scripts/tellingen Steekproef, CKL ET SEM, SYN, DCT, ET DCT PCT, ET STAT RLT Toelichting Inrichtingszaken, m.n. voor de SAP systemen (Assets en Infra), worden dynamisch impliciet getest. Als tijdens het testen blijkt dat er inrichtingszaken ontbreken, dan wordt hier een Jira melding voor functioneel beheer van gemaakt met het verzoek om de ontbrekende inrichtingszaken) aan te vullen. Er is voor deze insteek gekozen, omdat inrichtingszaken in productie gebeuren met bestaande/bewezen SAP functionaliteit en het niet de bedoeling kan zijn om de standaard functionaliteit van SAP te gaan testen. Controles op de inrichting liggen bij functioneel beheer (FUB). Daarna komt de (aangepaste) inrichting (tijdig) beschikbaar in de A- omgevingen t.b.v. de GAT en Ketentesten. Het tijdbeslag wordt zowel dynamisch expliciet getest met behulp van een real-life test (voor migratie scripts, tellingen scripts, batch/synchronisatie processen, e.d.) als dynamisch impliciet door het opbouwen van statistieken tijdens het testen van functionaliteiten (m.n. online processen). Voor een verklaring van de gebruikte afkortingen in de bovenstaande tabel: zie Bijlage: Toelichting testtechnieken. 1.4 Werkwijze Voor de uit te voeren werkzaamheden wordt het testfaseringsmodel van TMap Next gehanteerd. Hierbij worden per testsoort (Migratie, GAT, Keten) de fasen Voorbereiding, Specificatie, Uitvoering en Afronding uitgevoerd. De fasen Planning, Beheer, en Inrichting en beheer infrastructuur worden voor de testsoorten uitgevoerd. Elke fase is/wordt onderverdeeld in activiteiten. Deze aanpak kan als volgt schematisch worden weergegeven: 4 Voor GIS/GEN zowel op gemigreerde data als data die is opgewerkt 5 Zoals Onderhanden werk (K&M, GA aspect) 6 Afhankelijk van beschikbaarheid van procesbeschrijvingen 7 Zoals tijdens de synchronisaties tussen GIS/GEN en omliggende systemen (zoals SAP-PM, SCADA, Meldpunt applicatie, EDWH, e.d.) Infocon versie 0.1 Pag. 7 van 9

In de fase Planning worden volgende werkzaamheden uitgevoerd: Het uitvoeren van een Product Risico Analyse (PRA). Het definiëren van acceptatiecriteria voor de data migratie. Het opstellen van een (master)testplan (MTP) voor het acceptatietesten van de data migratie. Tijdens de fase Beheer worden de activiteiten uit het MTP uitgevoerd, bewaakt en eventueel bijgestuurd. Formeel start deze fase na goedkeuring van het MTP. De fase Inrichting en beheer infrastructuur heeft als doel om zorg te dragen voor de benodigde testinfrastructuur die wordt gebruikt bij de verschillende TMap fasen en activiteiten. De fase Voorbereiding heeft als doel om te kunnen beschikken over een testbasis die voldoende van kwaliteit is voor het ontwerpen van de testgevallen. De testgevallen worden gespecificeerd in de fase Specificatie en uitgevoerd in de fase Uitvoering. De fase Specificatie bouwt voort op het MTP. Voor het specificeren van de testgevallen wordt als uitgangssituatie gebruikt: de requirements/acceptatiecriteria zoals die gelden voor het testtraject; de productrisico analyse zoals die voor het testtraject is opgesteld. Tijdens de fase Afronding wordt de testopdracht afgerond onder meer door het opstellen van een eindrapportage (inclusief tellingenrapportage en een vrijgave advies). Infocon versie 0.1 Pag. 8 van 9

1.5 Bijlage: Toelichting testtechnieken Term PRA-RK Uitleg Risico Klasse (RK) uit de test-/product risicoanalyse (PRA): risicotabel A/B/C De risicoklasse (RK) is bepalend voor de zwaarte van de test. Hierbij is risicoklasse A de hoogste risicoklasse en C de laagste. De teststrategie is er vervolgens op gericht om de risico s met de hoogste risicoklasse zo vroeg mogelijk in het testtraject af te dekken. Beperkte dynamische test Gemiddelde dynamische test Zware dynamische test *) S Statisch testen: controleren en onderzoeken van producten zonder dat de software wordt uitgevoerd I Impliciet testen: mee testen bij een andere testvorm zonder het maken van specifieke testgevallen SYN Syntactische Test SEM Semantische Test DCT Data Combinatie Test PCT Proces Cyclus Test ET Exploratory Testing RLT Real Life Test STAT (Beoordelen d.m.v. het) opbouwen van statistieken CKL (Beoordelen m.b.v.) checklist(en) Pré-test Voor aanvang van de acceptatietest wordt een intake uitgevoerd op de acceptatieomgeving. Deze test wordt uitgevoerd om vast te stellen of de onderdelen, die worden opgeleverd in de acceptatietestomgeving van voldoende kwaliteit zijn om de acceptatietest (GAT en Keten) te starten *) Alle testgevallen worden vooraf uitgewerkt EN uitgebreid gereviewd EN bij de testuitvoering gestuurd op controle van uitvoering van alle testgevallen. Infocon versie 0.1 Pag. 9 van 9