Controleplan Datamigratie

Transcriptie

1 Controleplan Datamigratie Auteur: Tine de Mik Status: Concept Versie: 0.8 Datum: 29 mei

2 SAMENVATTING In dit document wordt beschreven op welke wijze aangetoond zal worden hoe de datamigratie is verlopen. Er wordt gekeken naar: 1. de volledigheid van de data; naar de aantallen die verwacht worden gezien vanuit het oude Studielink, 2. de juistheid van de data; naar de data in HNS en deze te vergelijken met de data in het oude Studielink, 3. naar de bruikbaarheid van de data; naar het gebruik van de data na de migratie. Door deze controles iedere keer bij proefconversies (PC) uit te voeren en hierover te rapporteren, neemt de voorspelbaarheid van de datamigratie iedere keer toe. Tot we overgaan tot de echte conversie, welke dan met vertrouwen en voorspelbaarheid uitgevoerd kan worden. Deze echte conversie zal vervolgens ook leiden tot eenzelfde rapportage zoals gemaakt tijdens de proefconversies ten behoeve van een mogelijke audit. 2

3 Inhoud Inhoud Controle en acceptatie van de migratie Uitvoering van de migratie en controle Planning... 5 Instellingsdata... 5 Studentdata... 5 Broker berichten Controle Conversie Instellingsdata... 7 Instelling... 7 Opleidingen... 7 Alternatieve opleidingen Studentdata... 8 Persoonsgegevens... 8 Inschrijvingen en verzoeken s en mededelingen Brokerberichten

4 1. Controle en acceptatie van de migratie Er zijn verschillende rollen te onderscheiden bij het controleproces van de datamigratie: De eigenaar accepteert de datamigratie op de juistheid en volledigheid van de gegevens De gebruiker accepteert de datamigratie op bruikbaarheid van de gegevens De functioneel beheerders van het dashboard accepteren de datamigratie op beheersbaarheid, beschikbaarheid & exclusiviteit. Onderdelen datamigratie Stakeholders juistheid & volledigheid Stakeholders bruikbaarheid Stakeholders beheersbaarheid, beschikbaarheid exclusiviteit & Instellingsdata Dossierhouders bij instellingen zijn eigenaar van de gegevens, vertegenwoordigd door Studielink. Rapportage beoordelen en mededelen aan instellingen hoe de controles zijn gedaan en welke aanpassingen eventueel nodig waren. Medewerkers van instellingen zijn gebruikers van deze data, vertegenwoordigd door het Testteam Studielink? Studenten zijn ook gebruikers van deze data. Vertegenwoordigd door? En in de GAT/FAT testen? Betreft processen: Inrichten onderwijs? Inrichten periode? Productowner Studielink Studentdata Dossierhouders bij instellingen zijn eigenaar van de gegevens, vertegenwoordigd door Studielink. Rapportage beoordelen en mededelen aan instellingen hoe de controles zijn gedaan en welke aanpassingen eventueel nodig waren. Studenten Betreft processen: Aanmelden Herinschrijven Betalen Uitschrijven.. Productowner Studielink Brokerberichten Studielink is eigenaar van de gegevens. Betreft processen: Bericht zoeken Bericht opnieuw sturen Bericht downloaden Productowner Studielink 4

5 2. Uitvoering van de migratie en controle Zowel CACI als QDelft zullen voor het uitvoeren van de controles bestanden moeten opleveren. Deze bestanden zullen gebruikt worden om de controles op uit te voeren. Door SL wordt een consultant aangesteld om de controle-programmatuur op deze bestanden te maken en vervolgens de uitkomsten op te leveren om in de rapportages te gebruiken. 2.1 Planning Per categorie gegevens is een planning uitgewerkt om de proefconversies, controles en uiteindelijke conversie uit te voeren. Middels deze werkwijze komen we tot een voorspelbare conversie van de data. Instellingsdata De instellingsdata zijn reeds geconverteerd. Rapportage zal alsnog gedaan worden om achteraf aan te tonen hoe deze is gedaan en of alles goed is gegaan. Hiervoor worden de controles uit dit plan gebruikt. QDelft stelt een rapport op dat op de komende stuurgroep op maandag 4 juni geagendeerd zal worden. Studentdata In het overzicht hieronder is de planning schematisch weergegeven, hierin zijn de volgende termen opgenomen: D-omgeving: een speciaal ingerichte omgeving bij QDelft waar de datamigratie op getest wordt. Deze omgeving is extra beveiligd vanwege het testen met persoonsgegevens. P-gegevens: persoonsgegevens. P-omgeving: de productieomgeving die voor het dashboard nu al live is. Broker berichten Mogelijke scenario s zijn voorzien bij het migreren van deze gegevens: Geen conversie, CACI DB in beheer bij QDelft. Verzoeken om berichten opnieuw door te sturen ad hoc verzorgen door servicedesk. Geen conversie, CACI DB kopie bij QDelft. Verzoeken om berichten opnieuw door te sturen ad hoc verzorgen door servicedesk. Wel conversie laatste jaar en conversie voor uitvoeren Wel conversie laatste jaar en conversie na uitvoeren 5

6 OKP gebruiken voor her-verzenden van berichten van het oude SL -> SIS Om te kunnen bepalen welk scenario de voorkeur heeft, beleggen we een sessie met instellingen waarin we de volgende vragen zullen bespreken: Wat willen instellingen met deze oude berichten? Waarvoor wordt dit gebruikt? Door wie wordt dit gebruikt? Hoe vaak wordt dit gebruikt? -> Dit zullen we ook navragen bij CACI zodat we niet op gevoel afgaan maar echte getallen hebben, zeker over de periode van oktober/november. 6

7 3. Controle Conversie Het doel van de controle is om aan te kunnen tonen dat er na de conversie: geen onterechte/onbedoelde consequenties zijn voor de studenten geen onterechte/onbedoelde consequenties zijn voor inschrijvingen geen onterechte/onbedoelde consequenties zijn voor verblijfsaanvragen geen onterechte/onbedoelde consequenties zijn voor machtigingen 100% zekerheid is dat de instelling en Studielink met elkaar kunnen communiceren over dezelfde persoon en inschrijving. 100% zekerheid is dat DUO en Studielink met elkaar kunnen communiceren over dezelfde persoon en inschrijving. Per gegevensset wordt aangegeven welke controles nodig zijn om de conversie te kunnen controleren en vervolgens te kunnen accepteren. Bij het controleren van de volledigheid wordt gekeken vanuit de oude situatie naar de nieuwe situatie. Het aantal in het oude systeem geeft aan wat het aantal in het nieuwe systeem moet zijn. Dit wordt hieronder aangeduid als (SL_oud - HNS) Bij het controleren van de juistheid wordt gekeken vanuit de nieuwe situatie naar de oude situatie. In het nieuwe systeem zien we wat de waarde is en die toetsen we aan de waarde in het oude systeem. Dit wordt hieronder aangeduid als (HNS - SL_oud) In het geval van de stamtabellen geldt de aanduiding (DUO - HNS) of (HNS - DUO) 3.1 Instellingsdata Instelling Het aantal unieke en actieve BRIN-codes in HNS is gelijk aan het aantal unieke actieve BRIN-codes in DUO. Er zijn 57 BRIN-codes. Een actieve BRIN-code heeft geen einddatum (en tot drie jaar terug geen einddatum. TODO: uitzoeken wat het precieze filter is geweest.). Er is gekozen om tot drie jaar terug zonder einddatum te selecteren, vanwege de conversie van de historie. De tolerantiegrens is 0. Deze query kan op de nieuwe database omdat de BRIN-code een sleutelwaarde is. 1. Volledigheid controleren door het aantal instellingen aan de hand van BRIN-codes te tellen. (DUO met filter - HNS). Filter DUO-tabel: BRIN-code actief tot drie jaar terug van bekostigde instellingen. 1. aantal BRIN-codes na filtering in DUO-tabel = actieve BRIN-codes in HNS Transnationale universiteit Limburg is apart toegevoegd % juistheid controleren van (HNS - DUO): 1. BRIN-code 2. vestiging code (brin volgnummer) (Ook vestigingen tot drie jaar terug zijn meegenomen, gelijk aan de BRIN-codes. Vestigingen zijn door DUO niet eerder afgesloten, waardoor oude waarden zijn meegenomen. Opleidingen 3. Volledigheid controleren door het aantal ISAT-codes te tellen. Een vergelijking doen tussen DUO ISAT codes en HNS. (DUO - HNS). Onbekostigde instellingen en onderwijs en opleidingen zijn niet meegenomen uit de DUO-tabellen. Post-initiële masters vallen onder deze categorie die uitgefilterd wordt, maar worden apart wél overgenomen. 7

8 1. Query: aantal bekostigd onderwijs + post-initiële masters + TNUL in DUO-tabel = aantal onderwijs in HNS Vervolgens gaat het wekelijks proces draaien om de nieuwe DUO-bestanden in te lezen % juistheid controleren per ISAT van (HNS - DUO): 1. de periode NB dit zijn er meerdere per ISAT: naam, datum ingang en datum einde moeten gelijk zijn. 2. de licentie: per ISAT 3. de geldigheid hogere jaars: per ISAT TODO: uitzoeken of er een filtering is toegepast bij het inlezen van de ISAT? En zo ja, welke? Deze vervolgens verwerken in de controles zoals hierboven beschreven. Alternatieve opleidingen 5. Volledigheid controleren van het aantal alternatieve opleidingen waaraan in SL_oud een student gekoppeld is. In HNS moet dit aantal gelijk zijn. (SL_oud - HNS). Inmiddels zijn er al instellingen live met het dashboard dus de telling moet rekening houden met nieuw aangemaakte opleidingen vanaf 22 mei TODO: uitzoeken of elk nieuw record van een timestamp voorzien? % juistheid controleren (HNS - SL_oud). Belangrijk is om de sleutel te vinden waarmee de matching van de gegevens gedaan kan worden. Als de instellingen vanaf dashboard livegang nieuwe alternatieve opleidingen inrichten moeten ze precies dezelfde alternatieve-opleiding-code aanmaken. Sleutel is BRIN-ISAT-AltOplCode In communicatie moet worden aangegeven dat de alternatieveopleiding-code precies dezelfde zijn. SL vraagt aan CACI of het mogelijk is te monitoren op de aanmaak van alternatieve opleidingen in het oude SL. Rapportage naar SL en de betreffende instellingen waarschuwen over het aanmaken in HNS. 1. identificerende gegevens van de alternatieve opleidingen (nodig voor het koppelen van inschrijvingen aan deze opleidingen) BRIN-ISAT-AltOplCode 2. de naam TODO: uitzoeken of er een filter wordt gebruikt om alleen de opleidingen met studenten in de migratie over te nemen. In de controle nr.6 gaan we ervan uit dat we dit filter wel gebruiken. Ditzelfde filter moet dan gebruikt worden om het controlebestand uit SL_oud te halen. 3.2 Studentdata Persoonsgegevens 7. Volledigheid controleren van het aantal studenten op basis van Studielinknummers (SL_oud - HNS). Vergelijking doen van de aantallen in SL_oud en HNS. 8. Volledigheid controleren door: 1. het aantal BSN's en ON's te vergelijken tussen SL_oud en HNS. 2. studenten zonder PGN, dus er moet ook geteld worden hoeveel studenten er zijn ZONDER BSN en ON's % juistheid controleren per student van de volgende gegevens (HNS - SL_oud) 1. BSN ten behoeve van de link met DUO/BRP 2. Onderwijsnummer ten behoeve van de link met DUO/BRP 3. ten behoeve van communicatie met de student 4. Niet BRP-studenten (risico = hoog want SL_oud is de enige bron van deze gegevens, we kunnen hiervoor niet terugvallen op de gegevens uit de BRP. Ze zijn wel van groot belang voor de identificatie en inschrijving) 5. geboortedatum 8

9 6. nationaliteit 7. naam 8. adres (risico = laag want er wordt geen post verstuurd en wordt niet gebruikt voor bekostiging) Inschrijvingen en verzoeken 10. Volledigheid controleren van het aantal inschrijvingen door (SL_oud met filter - HNS): filter: alle inschrijvingen in SL_oud waarvoor geldt: collegejaar = xx of yy 1. Aantal uit het filter is gelijk aan alle inschrijvingen in HNS. Hier moet in de query op SL_oud hetzelfde filter worden gebruikt als wordt toegepast op de gekozen jaren uit SL_oud voor de migratie. 2. Van alle betreffende inschrijvingen moet nog een uitsplitsing gemaakt worden in aantal per: a. status b. instelling c. instelling per status 11. Volledigheid controleren van lopende verzoeken door (SL_oud met filter - HNS): filter: alle verzoeken in SL_oud waarvoor geldt: collegejaar = xx of yy 1. Aantal uit het filter is gelijk aan alle verzoeken in HNS % juistheid controleren van inschrijvingen door (HNS - SL_oud) 1. student (Studielinknummer) 2. inschrijfvolgnummer 3. collegejaar 4. status 5. BRIN 6. ISAT 7. alternatieve opleiding 8. vorm % juistheid controleren van verzoeken door (HNS - SL_oud) 1. student (Studielinknummer) 2. inschrijfvolgnummer 3. collegejaar 4. status 5. BRIN 6. ISAT 7. alternatieve opleiding 8. vorm Betaalgegevens 14: Volledigheid controleren van het aantal betalingen door (SL_oud met filter - HNS): filter: (student met inschrijving is geconverteerd EN periode studentbetaling > ) OF (student met VtI is geconverteerd EN periode studentbetaling > aantal student-betalingen per BRIN SL_oud = aantal studentbetalingen in HNS % juistheid controleren van iedere betaling door (HNS - SL_oud): 1. DIM status (datum, tijd, code) 2. Betaalwijze (betaalvorm, betaald door derde) 9

10 3. Betaalstatus Bovenstaande zijn gekozen omdat deze bij hergebruik nodig zijn. 16. Juistheid controleren door deelwaarnemingen van betalingen door per instelling te kijken naar (HNS - SL_oud): 1. Te betalen 2. Betaaltermijnen 3. Bevestiging betaling s en mededelingen 17. Volledigheid controleren van het aantal notificaties van studenten door (SL_oud met filter - HNS): filter: Studenten die gemigreerd zijn EN datum >= aantal door filter uit SL_oud = aantal notificaties in HNS Digitale Verblijfsvergunning Studie 18. Volledigheid DVS controleren door (SL_oud - HNS): 1. aantal DVS SL_oud = aantal DVS HNS 2. Tellingen per instelling en per werksoort % juistheid controleren van DVS op lopende aanvragen (HNS - SL_oud): 1. vreemdeling (+ adres, + contact) 2. indiening 3. opleiding 4. zaak 5. aanvullende identificatie (BedrijfsdocumentID) 6. verklaring 7. status 8. resultaat 20. Juistheid controleren door deelwaarnemingen van afgehandelde DVS aanvragen (HNS - SL_oud) 1. Alles controleren van 1 % van de aanvragen per instelling % juistheid controleren van afgehandelde DVS aanvragen (HNS - SL_oud): 1. aan juiste vreemdeling 2. aan juiste BRIN 3. resultaat 4. sleutel naar IND TODO: de volgende categorieën worden op verder uitgewerkt: Gebruikersnaam & Wachtwoord Vooropleiding Historische deelnames NF 10

11 3.3 Brokerberichten 11