Wijzigingsprotocol

1.1 Introductie

Geonovum ontwikkelt en beheert het Informatiemodel Geluid samen met het RIVM in opdracht van het minsiterie van Infrastructuur en Waterstaat. Mensen die in de praktijk gebruik maken van dit informatiemodel hebben vragen over de toepassing ervan, willen weten welke ontwikkelingen er spelen, en hebben mogelijk suggesties voor aanpassingen van het informatiemodel. Wijzigingen in het Informatiemodel Geluid worden niet zomaar doorgevoerd; voor de ene gebruiker van het model zal de wijziging gering zijn, voor de ander kan het grote gevolgen hebben. Daar houden wij rekening mee. De gebruikersgroepen van de standaarden en andere betrokkenen in het wijzigingsproces zijn vastgelegd, evenals de belangrijkste taken en verantwoordelijkheden en de momenten waarop zij betrokken zijn in dit proces.

1.2 Waarom een wijzigingsprotocol

In dit wijzigingsprotocol staan de sturende principes achter het wijzigingsproces voor deze standaard die Geonovum samen met het RIVM beheert: de manier waarop wijzigingen in het Informatiemodel Geluid plaatsvinden. Met het protocol wordt elke wijziging van het informatiemodel een voorspelbaar proces voor beheerders, ontwikkelaars en gebruikers van het informatiemodel. In het protocol zijn basisbegrippen en uitgangspunten uiteengezet voor het wijzigingsproces, bijvoorbeeld wat onder nieuwe en volgende versies verstaan wordt en wanneer deze nieuwe versie(s) verwacht mogen worden.

1.3 Begrippen

2.1 Releasebeleid

2.2 Proces varianten

In paragraaf releasebeleid zijn de X, Y en Z wijzigingen uitgelegd. Voor wijzigingen kent Geonovum dire proces varianten. Eén voor X wijzigingen, één voor Y wijzigingen en één voor Z wijzigingen.

De start van het proces is voor alle varianten hetzelfde. Op de Geonovum website wordt een wijzigingsverzoek ingediend. De impact van deze wijziging wordt door Geonovum beoordeeld in samenwerking met de functioneel beheerder in een impactanalyse. Deze impactanalyse beoordeelt tot welke SemVer categorie de wijziging hoort, welke betrokken partijen geraakt worden door de wijziging en wat de secundaire effecten van de wijziging zijn (e.g. er ontstaan extra validatieregels in het CVGG). De uitkomsten van de impactanalyse worden toegevoegd aan de geonovum website. Naast de impact analyse wordt er, indien mogelijk, een oplossing aangedragen voor het wijzigingsverzoek op de Geonovum website. Vervolgens wijkt het proces voor Z wijzigingen af van dat van X en Y wijzigingen.

Proces voor X en Y wijzigingen

X en Y wijzigingen vergen volledige afstemming en het doorlopen van alle in paragraaf 2.4 beschreven fasen: Inhoud, Toetsing, Besluitvorming en Implementatie. Voor de inhoudelijke fase wordt een werkgroep gestart met daarin vertegenwoordiging de stakeholders door de wijziging worden geraakt volgens de impactanalyse. Het resultaat van de werkgroep wordt tijdens het overleg van de Adviesgroep besproken. De Adviesgroep adviseert de functioneel beheerder van het IMG. X wijzigingen worden altijd voorgelegd aan de stuurgroep. De voorzitter van de CVGG stuurgroep stelt een nieuwe versie van het model vast. Y wijzigingen worden alleen voorgelegd aan de stuurgroep als de Adviesgroep hier aanleiding toe geeft. Y wijzigingen kunnen zonder betrokkenheid van de stuurgroep door de voorzitter van de CVGG stuurgroep worden vastgesteld. Indien nodig wordt met softwareleveranciers een convenant afgesloten of een bestaand convenant uitgebreid, waarin wordt afgesproken dat zij (onderdelen van) de standaard gaan ondersteunen.

Implementatie van X wijzigingen

De implementatiefase van X wijzigingen wijkt af van die van Y wijzigingen, de implementatie van X wijzigingen vraagt namelijk altijd om een heraanlevering van bronhouders.

Proces voor Z wijzigingen

In overleg met de functioneel beheerder worden deze kleine wijzigingen in de volgende release opgenomen. De inhoudelijke fase wordt door een medewerker van Geonovum gedaan. Besluitvorming vindt plaats in afstemming met het RIVM/ de functioneel beheerder van IMG. Implementatie vindt plaats door het publiceren van de wijziging op de Geonovum website.

2.3 Fasen en resultaten

Het volledige wijzigingsproces doorloopt de fasen Inhoud, Toetsing, Besluitvorming en Implementatie, zoals weergegeven in Figuur 1.

In de fase inhoud wordt voor ieder wijzigingsverzoek bepaald of deze wordt opgenomen in de nieuwe versie van de standaard of niet. Dit wordt door Geonovum intern vastgelegd in Jira en is raadpleegbaar via de Geonovum website. Voor ieder wijzigingsverzoek dat wordt meegenomen in de nieuwe versie van de standaard, wordt een impactanalyse uitgevoerd en oplossingen uitgewerkt. Deze impactanalyse beoordeelt tot welke SemVer categorie de wijziging hoort, welke betrokken partijen geraakt worden door de wijziging en wat de secundaire effecten van de wijziging zijn (e.g. er ontstaan extra validatieregels in het CVGG).

Dit werk voert Geonovum uit in samenwerking met de functioneel beheerder van het IMG. De impactanalyse betreft de impact van de wijziging van de standaard op de gebruikers en de door hen gebruikte software, waaronder ook de CVGG. De resultaten van de impactanalyse worden gecommuniceerd op de Geonovum website.

Wanneer tijdens de impactanalyse is vastgesteld dat het om een X of Y wijzigingverzoek gaat, wordt er een werkgroep ingepland. Afhankelijk van de omvang van de wijziging ten opzichte van de voorgaande versie en afhankelijk van welke gebruikersgroepen geraakt worden door de wijziging, verandert de samenstelling van deze werkgroep. De werkgroep wordt vooraf geïnformeerd over het wijzigingsvoorstel en indien Geonovum genoeg kennis in huis heeft wordt er een eerste probleemschets en oplossing aangedragen voorafgaand aan de werkgroep. De resultaten van de werkgroep worden in een notitie gedeeld met de leden van de adviesgroep.

Toetsing

De fase Toetsing vormt een brug tussen de inhoud, besluitvorming en de implementatie. In deze fase wordt eenieder (in het geval van een X of Y wijziging) of een beperkte groep belanghebbenden (in het geval van een Z wijziging) uitgenodigd om zijn visie te geven op het wijzigingsvoorstel voor de nieuwe versie van het IMG. Met deze consultaties vragen wij de gebruikers van de standaard actief hun reactie te geven op het wijzigingsvoorstel. Het wijzigingsvoorstel inclusief de terugkoppeling uit de consultatie wordt verwerkt als release candidate van het informatiemodel geluid.

Besluitvorming

Bij Besluitvorming wordt besloten om de gewijzigde specificatie van de standaard vast te stellen en te publiceren. Afhankelijk van het type wijziging (X, Y of Z, zie paragraaf proces varianten), besluit het ministerie dan wel de functioneel beheerder.

Implementatie

Het in gebruik nemen van het Informatiemodel in de praktijk staat centraal in deze fase. Hiervoor leveren we verschillende technische bestanden op, dit doen de beheerders van het IMG van Geonovum en RIVM gezamenlijk. De technische bestanden zijn bijvoorbeeld testbestanden. Deze bestanden ondersteunen bij de implementatie van de standaard in de software. Beheerders van de CVGG register nemen het Informatiemodel in gebruik. Wij ondersteunen de implementatie bovendien door de werking van het informatiemodel toe te lichten tijdens bijvoorbeeld bijeenkomsten of 'inloopspreekuren' voor de softwareleveranciers. Resultaat van deze fase is dat de gebruikers data kunnen maken en uitwisselen conform de nieuwe standaard. In Hoofdstuk 5 lichten we de implementatie verder toe.

2.4 Betrokkenen

De volgende organisaties en instanties (actoren) zijn betrokken bij het wijzigingsproces van het Informatiemodel Geluid:

• Ministerie van Infrastructuur en Waterstaat (IenW);
• RIVM;
• Geonovum;
• Bronhouders: omgevingsdiensten, provincies, gemeenten, Prorail, Rijkswaterstaat;
• Softwareleveranciers: DBvision, DGMR.

3.1 Wijzigingenbeheer

Belanghebbenden kunnen meldingen (wijzigingsverzoeken), variërend van wensen tot aanpassing van en fouten in het Informatiemodel, indienen via de helpdesk bij Geonovum. Wij geven inzicht in de ontvangen wijzigingsverzoeken en de status van de wijzigingsverzoeken via de Geonovum website. In het geval we een wijzigingsproces starten voor een nieuwe versie van de standaard, bundelen de verzoeken tot een wijzigingsvoorstel. Het wijzigingsprotocol beschrijft het wijzigingsproces en daarmee ook de procedure die het wijzigingsvoorstel doorloopt. In hoofdstuk 7 is een overzicht van de statussen van wijzigingsverzoeken.

Voor inzicht in de ontwikkeling, wijzigingsverzoeken en bijeenkomsten rondom van het Informatiemodel Geluid zetten we Geonovum website in.

Ontwikkelingen in de standaarden kunnen om verschillende redenen gewenst zijn, waaronder:

• Geconstateerde fout in de standaard;
• Wens tot wijziging, uitbreiding of vereenvoudiging uit de praktijk;
• Aanpassing van de standaard door internationale ontwikkelingen.

Met behulp van het wijzigingsprotocol wordt de geplande wijziging van het Informatiemodel Geluid uitgevoerd. In de aanloop naar een wijziging van de standaarden bundelt Geonovum de meldingen, verzoeken tot wijziging, in een wijzigingsvoorstel. Het wijzigingsvoorstel vormt de basis om een nieuwe versie van een standaard op te stellen. Het beheerteam IMG werkt daarvoor nauw samen met experts. Met behulp van onder andere een publieke consultatie via de Geonovum website leggen wij het voorstel voor de nieuwe versie van een standaard voor aan de gebruikers van de standaard en vragen hun feedback. Het definitieve voorstel leggen wij voor aan de adviesgroep voor besluitvorming.

3.2 Het wijzigingsproces in detail

De meldingen en wijzigingsverzoeken alsook (inter)nationale ontwikkelingen geven aanleiding tot de verdere ontwikkeling voor een standaard. Het wijzigingsproces dat dit wijzigingsvoorstel doorloopt bestaat uit tien stappen, die in onderstaande Figuur 2 in onderlinge samenhang zijn weergegeven. In figuur 2 zijn processen, besluiten en de relevante actoren en actorgroepen en hun interacties weergegeven. Iedere processtap is vervolgens kort beschreven.

Processtappen

De volgende processtappen worden doorlopen om te komen tot wijzigingen in de IMG standaard (zie ook figuur 2):

1. Met een ‘melding’ begint het wijzigingsproces. Doorgaans zal de gebruiker van het informatiemodel een eis of wens indienen, maar het kan ook de functioneel of technische beheerder zijn in sommige gevallen (bijv. wanneer een onderliggende standaard is bijgesteld). Er zijn meerdere ‘triggers’, die kunnen leiden tot het indienen van een wijzigingsverzoek. De kern van het wijzigingsproces is een gezamenlijk wijzigingenbeheer. Eisen en wensen, die kunnen leiden tot wijzigingen in het informatiemodel Geluid kunnen ontstaan ten gevolge van de volgende triggers:

• Aanpassing van business doelen van de opdrachtgever;
• Nieuwe of aangepaste wetgeving;
• Aanpassing van aspecten van (onderliggende) standaarden;
• Gewijzigde gebruikerswensen;
• Wijzigingen in technische voorzieningen;
• Wijzigingen in systemen waar mee gekoppeld wordt;
• Het herstellen van fouten/bugs;
• Het voor zijn van het optreden van fouten (preventief).

De bovengenoemde aanleidingen kunnen leiden tot meldingen in het informatiemodel Geluid, waarmee het wijzigingsproces in gang kan worden gezet. In het algemeen worden 4 typen meldingen onderscheiden:

• Een vraag;
• Een wijzigingsverzoek n.a.v. een verbetering of fout/bug;
• Een incident;
• Een klacht.

De melding wordt gestuurd naar de IMG helpdesk en ingediend via een mail aan helpdesk bij Geonovum.

2. De IMG helpdesk (Geonovum) registreert het wijzigingsverzoek in het meldingen systeem Jira. De IMG helpdesk medewerker (technisch beheerder) beoordeelt het wijzigingsverzoek. De IMG helpdesk medewerker (actiehouder van de melding) controleert of de melding volledig en helder is. Bij een fout onderzoekt de medewerker of dit inderdaad het geval is. Ook kan de medewerker verder informatie opvragen bij de indiener van de melding. Ook wordt gecontroleerd of de melding geen duplicaat van een reeds ingevoerde melding. Indien de melding helder is beschreven, en het betreft een wens voor het aanpassen van de standaard of een gevonden fout, dan kan melding worden "erkend" en wordt de melding formeel opgenomen in het meldingen systeem (jira). Indien de melding de niet erkend wordt, zal de helpdesk medewerker de indiener inlichten via de mail en de melding is afgehandeld.

3. De binnengekomen meldingen wordt besproken in het IMG beheeroverleg, het overleg tussen functioneel en technisch beheer van IMG. Zij stellen samen een lijst op met potentiële wijzigingsverzoeken. De lijst met wijzigingsverzoeken (het eerste wijzigingsvoorstel) wordt pas gemaakt als overeengekomen wordt, dat de binnen gekomen wijzigingsverzoeken naar een nieuwe release van de IMG standaard kan leiden. Tot dan is er alleen de registratie in het meldingen systeem (jira), op Github en in WELT. Tevens wordt in deze stap een eerste impactanalyse uitgevoerd voor de wijzigingsverzoeken. Indien een melding wordt afgewezen – dus niet in de lijst met wijzigingsverzoeken wordt opgenomen – wordt door de IMG helpdesk een bericht met de verklaring van de afwijzing van de melding aan de indiener gestuurd.

4. Indien het functioneel beheer het nodig acht om te komen tot een wijzigingsvoorstel voor de IMG standaard, wordt een IMG werkgroep in het leven geroepen bestaande uit m.n. experts en belangrijke stakeholders en de beheerders. Zij stellen evt. de impactanalyse van wijzigingsverzoeken bij en bepalen wat voor soort wijziging (X, Y of Z) aan de orde is. De werkgroep levert een wijzigingsvoorstel voor een nieuwe versie van de IMG standaard op voor de IMG adviesgroep (de change advisory board) in geval van een X of Y-wijziging.

5. Indien het wijzigingsvoorstel enkel Z-wijziging(en) betreft, neemt het IMG beheeroverleg een besluit en gaat (al dan niet) over tot implementatie van de Z-wijziging.

6. De IMG adviesgroep toetst het wijzigingsvoorstel. In de IMG adviesgroep hebben gebruikers, belangrijke stakeholders en de beheerders zitting. Indien de IMG adviesgroep over het wijzigingsvoorstel positief adviseert, wordt het wijzigingsvoorstel aan IMG technisch beheer gestuurd om een Release Candidate op te stellen. De IMG adviesgroep bepaalt ook of de Release Candidate wordt voorgelegd ter publieke consultatie van één maand. In geval de IMG adviesgroep het voorstel nog niet kan accorderen en eerst wijzigingen wil doorvoeren en het wijzigingsvoorstel wil laten bijstellen dan wel de impactanalyse wil bijstellen, dan gaat het voorstel terug naar de IMG Werkgroep. De IMG werkgroep stelt vervolgens het voorstel bij en brengt het voorstel opnieuw in bij de IMG adviesgroep.

7. Het IMG technisch beheer stelt een Release Candidate op. En indien nodig geacht door de IMG adviesgroep, wordt de opgestelde Release Candidate één maand ter publieke consultatie aangeboden op de website van Geonovum. Na de publieke consultatie zorgt het IMG technisch beheer, dat de resultaten van de consultatie worden verwerkt in een Release Candidate. De Release Candidate wordt daarna ingebracht bij de IMG Adviesgroep voor toetsing van de Release Candidate van d IMG standaard. Na toetsing wordt de Release Candidate van de IMG standaard met een advies gestuurd aan CVGG Stuurgroep voor een besluit.

8. De voorzitter van de CVGG stuurgroep neemt een besluit over de implementatie van Definitieve Release van de IMG standaard. Indien de voorzitter van de CVGG stuurgroep akkoord is, wordt de implementatie-ondersteuning in gang gezet. Indien het besluit tot implementatie negatief is, wordt terugmelding gemaakt aan de gebruikers en stakeholders.

9. De implementatie-ondersteuning wordt uitgevoerd door het IMG technisch beheer, waarbij de technische documentatie en (validatie)regels worden bijgesteld en gepubliceerd.

10. Na afronding van de implementatie-ondersteuning, vindt publicatie en communicatie plaats over de nieuwe IMG standaard.

5.1 Technische bestanden

Om softwareleveranciers en gebruikers te ondersteunen bij de implementatie van een nieuwe versie van de standaard, leveren wij verschillende bestanden en documentatie op:

• Implementatiebestanden;
• Voorbeeldbestanden;
• Voorbeeldberichten.

Schema’s zijn voorbeelden van implementatiebestanden die als onderdeel van standaarden door Geonovum worden opgeleverd. Het kan hier ook gaan om implementatiebestanden voor visualisatieregels en iconen.

Voorbeeldbestanden en voorbeeldberichten kunnen worden gebruikt voor het testen van applicaties.

5.2 Validatie

Na het opleveren van de nieuwe standaard inclusief de verschillende onderdelen, richten wij ons op de ondersteuning van de standaard van softwareleveranciers, beheerders van de voorziening. Bij deze groep gebruikers is de ondersteuning vooral technisch van aard. De validator van de CVGG is het hulpmiddel bij uitstek hierbij. Van het IMG is wel een schema beschikbaar voor validatie. Voor de implementatie van de regels is vooralsnog geen schematron beschikbaar van de validator. De regels beschreven in het IMG worden door de CVGG en softwareleveranciers nu zelf geïmplementeerd.

5.3 Opleiding

Per standaard, en nieuwe versie van de standaard, bekijken we in hoeverre opleiding en advies van toegevoegde waarde zijn voor ondersteuning van de gebruikers bij implementatie van de standaard. Middelen als documentatie, bijeenkomsten en workshops zetten wij in om kennis te delen en te ondersteunen bij de implementatie van de nieuwe versie van de standaard. Publicaties in vakbladen kunnen we ook inzetten.

5.4 Communicatie

Het hele wijzigingsproces staat of valt met een goede communicatie. Onder goede communicatie wordt verstaan het tijdig leveren van de juiste informatie aan de juiste belanghebbenden. Dit betreft de proceskant alsook de producten die er worden opgeleverd.

Website(s)

De actuele vigerende versie van het Informatiemodel is via het documentenregister van Geonovum beschikbaar.

Consultatie

Bij X en Y-wijzigingen legt Geonovum de aanpassingen in het model voor aan alle gebruikers van de standaard, belanghebbenden en geïnteresseerden door middel van een publieke consultatie via de Geonovum website en de nieuwsbrief van de CVGG.

Werkafspraken

De werkafspraken die bepalen hoe er in de tussentijd moet worden omgegaan met geconstateerde fouten en problemen (zie Hoofdstuk 4). De werkafspraken publiceren wij via de Geonovum website. Door middel van nieuwsberichten op de website en het versturen van de nieuwsbrief in samenwerking met RIVM en het ministerie van Infrastructuur en Waterstaat informeren wij het werkveld over de nieuwe dan wel aangepaste werkafspraak.

Nieuwe producten inclusief releasenotes

Wijzigingen in het model worden bekendgemaakt op de Geonovum website en in de nieuwsbrief van de CVGG.

6.1 Sturende principes bij escalatie

We doorlopen een escalatieprocedure als er een wijziging noodzakelijk is die niet in het reguliere wijzigingsproces doorgevoerd kan worden, omdat dit te lang duurt. Een uitputtende lijst met situaties en criteria wanneer dit van toepassing is, valt op voorhand niet te geven. Maar voor de beeldvorming: het gaat om situaties waarbij het niet doorvoeren van een bepaalde noodzakelijke wijziging leidt tot onaanvaardbare risico's voor de uitvoeringspraktijk of het onmogelijk uitvoeren (vanwege bijvoorbeeld tegenstrijdige wetten) van werkzaamheden.

De escalatieprocedure wordt niet gebruikt om reguliere wijzigingen sneller door te kunnen voeren. Er wordt geen vast proces gegeven om de escalatieprocedure te doorlopen, omdat verschillende situaties wellicht tot een verschillende wijze van handelen moeten leiden. In plaats daarvan zijn onderstaande sturende principes leidend om verantwoordelijkheden te duiden.

Signalering Uit het werkveld kunnen signalen ontstaan dat er met spoed iets gewijzigd zou moeten worden. Het is vooraf niet aan te geven uit welke kanalen deze geluiden zullen ontstaan. Het is wel van belang om de rol van Geonovum te onderkennen als antennefunctie voor het werkveld. In ieder geval zullen deze signalen op enig moment de opdrachtgever of Geonovum bereiken, en op dat moment zal er overleg gevoerd worden over deze signalen.

Overleg Bij de besluitvorming binnen de escalatieprocedure wordt er in principe overleg gevoerd tussen Geonovum, RIVM en desgewenst IenW. De partijen raadplegen de betrokkenen daar waar nodig.

Besluitvorming De beoordeling of de escalatieprocedure van toepassing is, wordt genomen door de voorzitter van het gremium dat de beheeropdracht monitort, dan wel de contactpersoon bij de opdrachtgever van IenW. Ook het besluit welke wijzigingen er precies doorgevoerd moeten worden en op welke manier, wordt genomen door dezelfde persoon.

Coördinatie De coördinatie tijdens de escalatieprocedure wordt uitgevoerd door de voorzitter van het gremium dat de beheeropdracht monitort, dan wel de contactpersoon bij de opdrachtgever.

Communicatie met het werkveld De communicatie met het werkveld wordt uitgevoerd door Geonovum. Als beheerder van de betreffende standaard wordt verwacht dat Geonovum de meest directe contacten heeft met het werkveld.

6.2 Klachtenafhandeling

Het garanderen van het serieus nemen van klachten kan alleen, door deze volgens een zorgvuldige procedure te behandelen. Klachten kunnen ook beschouwd worden als verbetersuggestie. We onderscheiden daarom twee verschillende type klachten met betrekking tot de standaarden:

• Klachten over de toepassingsmogelijkheid van de standaard;
• Klachten over het beheer van de standaard.

In het eerste geval is het feitelijk geen klacht maar een wens of eis tot het aanpassen van de standaard. De beheerders van de betreffende standaard nemen dit in behandeling en vastgelegd als wijzigingsverzoek en niet als klacht. In dit geval doet Geonovum haar werk goed.

In het tweede geval is er sprake van ontevredenheid over de uitvoering van het beheerproces van de standaard en betreft niet de inhoud, de standaard zelf. De indiener is van mening dat Geonovum, het beheerteam van de betreffende standaard, dan wel een persoon het werk niet naar behoren uitvoert. In dat geval wordt de klacht doorgezet naar opdrachtgever van het beheer van de standaard.

De route van indienen van klachten is bij Geonovum in principe via de helpdesk van de betreffende standaard. Dit is de manier om met Geonovum in contact te komen, vragen te stellen en wensen en eisen met betrekking tot de standaard kenbaar te maken. Door het via een helpdesk te laten verlopen, wordt ook het type van de issues geregistreerd. De helpdesk route voor zowel vragen, wijzigingsverzoeken, klachten en incidenten geeft een zo compleet mogelijk overzicht in het contact met de gebruikers van de standaarden, over de standaarden.