Operationeel beheer omvat volgens BOMOS het tekstuele beheer van de documentatie, het verzamelen van eisen en wensen en de vertaling daarvan naar wijzigingsvoorstellen. Verder omvat het operationele proces de besluitvorming en het versie- of release-beheer
Het operationele wijzigingsproces is ingericht op Github. De omgeving die we ook gebruiken voor het beheer en de publicatie van de documentatie. In dit hoofdstuk wordt het operationele wijzigingsproces op hoofdlijnen beschreven. Voor details van de implementatie verwijzen we naar de bijlage over gebruik Github in het beheerproces
Toevoegingen aan de standaard zoals het toevoegen van een nieuwe koppelvlakspecificatie worden behandeld als in introductie van een nieuwe standaard.
-
Uitbreidingen en aanpassingen in de standaarden in beheer bij Logius komen tot stand door participatie van de verschillende belanghebbenden.
-
Belanghebbenden kunnen op verschillende manieren participeren.
- op persoonlijke titel (het proces is volledig open)
- als lid van de community voor de standaard
- als lid van één van de overleggen: het Technisch Overleg, de Programmeringstafel Gegevensuitwisseling of het OBDO.
Wensen en eisen zijn aanpassingen op de bestaande standaarden en koppelvlakspecificaties.
Wijzigingsvoorstellen kunnen binnen komen via verschillende kanalen:
- Rechtstreeks bij de beheerorganisatie, tijdens overleggen, via de website of mail
- Bij de werkgroepoverleggen van de standaard en tijdens overleggen, via de website of mail
Afhankelijk van de impact van een wijziging kan deze aangemerkt worden als een patch. Een patch is een kleine (tekstuele) wijziging die geen impact heeft op implementaties.
Een wijziging is een aanpassing met impact op de werking of het proces van de standaard. Waarbij nog een onderscheid gemaakt wordt tussen wijzigingen met kleine en met grote impact.
Patches en wijzigingen worden verzameld in een release. Een release is een nieuwe versie van de standaard. Nieuwe releases worden regelmatig doorgevoerd en moeten worden goedgekeurd door het Technisch Overleg en, afhankelijk van de impact van een nieuwe release door een programmeringstafel. Een nieuwe release wordt bekrachtigd door het besluitvormend overleg. Afhankelijk van de impact van een wijziging kan deze aangemerkt worden als een patch. Een patch is een kleine (tekstuele) wijziging die geen impact heeft op implementaties.
Een wijziging is een aanpassing met impact op de werking of het proces van de standaard. Waarbij nog een onderscheid gemaakt wordt tussen wijzigingen met kleine en met grote impact.
Patches en wijzigingen worden verzameld in een release. Een release is een nieuwe versie van de standaard. Nieuwe releases worden regelmatig doorgevoerd en moeten worden goedgekeurd door het Technisch Overleg en, afhankelijk van de impact van een nieuwe release door een programmeringstafel. Een nieuwe release wordt bekrachtigd door het besluitvormend overleg.
- Acceptatie van een wijzigingsvoorstel.
- Labelen van een voorstel als groot/klein, aangeven van status.
- Behandeling van een wijzigingsvoorstel.
- Agendering voor een overleg.
- Advisering vanuit overleggen.
- Acceptatie van een wijzigingsvoorstel.
- Doorvoeren van een wijzigingsvoorstel.
- Publicatie van een wijziging in de komende release
Wanneer een wijziging is geaccepteerd kan deze deel uitmaken van een volgende release.
Een patch is een zeer kleine wijziging die geen impact heeft op de implementatie. Bijvoorbeeld tekstuele wijzigingen in de documentatie. De beheerorganisatie beoordeelt de impact van een wijziging en bepaalt daarmee of het een patch betreft (of een wijziging).
- Beoordeling van een voorgestelde patch door de beheerorganisatie
- Doorvoeren van de patch door de beheerorganisatie
- Publicatie van een patch in de komende release
De onderdelen van de xxx standaard en de voorzieningen zullen gezamenlijk en afzonderlijk onderhevig zijn aan beheer en onderhoud wat leidt tot nieuwe releases. Het vaststellen van nieuwe releases vindt plaats binnen het releaseplanningsproces. Het tactisch overleg is verantwoordelijk voor de juiste uitvoering. Hier komen alle belanghebbenden met verantwoordelijkheid voor de behoefte, effecten en impact op de bedrijfsvoering, informatievoorziening en ICT samen.
Het vaststellen van een nieuwe release van afzonderlijke onderdelen en een samenhangende architectuur wordt gedaan volgens het beleid in paragraaf 2.4. Het beheer zal binnen de releaseplanning niet alleen nieuwe releases voordragen aan het tactisch/strategisch overleg maar ook voorstellen hoe lang oude releases in bedrijf blijven en ondersteund zullen worden.
Voor nieuwe releases wordt uitgegaan van een aantal principes:
- De standaard dient in principe zo stabiel te zijn dat nieuwe releases van de standaard bestaande implementaties van een oudere release niet tot migratie verplichten.
- Nieuwe releases van de standaard dienen als nieuwe profielen binnen een Koppelvlakstandaard naast de bestaande profielen gerealiseerd te worden (uitbreiding). Indien dit niet mogelijk is wordt gestreefd naar het interoperabel (engels: backwards compatible) zijn van profielen met voorgaande releases (interoperabele verandering). Bij wijzigingen waarin ook dit niet mogelijk is, vindt een expliciete afweging plaats van de geboden verbetering ten opzichte van het belang van bestaande implementatie (beperking impact).
- Wijzigingsaanvragen kunnen door belanghebbenden worden ingediend bij de beheerder.
- Het Technisch Overleg is verantwoordelijk voor de beoordeling van ingediende wijzigingsaanvragen, uitwerken ervan en de inhoudelijke (door)ontwikkeling van de te beheren onderdelen van de standaard.
- De beheerder zorgt voor de voorbereiding van de releaseplanning.
- Het tactisch overleg beoordeelt de releasevoorstellen en stelt het beleid en de roadmap van nieuwe releases van de standaard vast in het releaseplanningsproces.
- Bij het vaststellen van de inhoud van een nieuwe release van een onderdeel van de standaard wordt gestreefd naar consensus. Als consensus uitblijft zal de beheerder, samen met het Ministerie van BZK de inhoud van een nieuwe release vaststellen.
- Bij het vaststellen van een nieuwe release zal het strategisch overleg uitspraken doen over het ondersteunen van oude releases.
- Maximaal kunnen twee (opéénvolgende) releases van een onderdeel gelijktijdig de status „In Gebruik‟ hebben.
- De releasetermijnen voor de verschillende onderdelen zijn afgestemd op de omgeving waarin deze worden gebruikt. Koppelvlak standaarden hebben bijvoorbeeld een kortere releasetermijn dan de bovenliggende architectuur.
- In bijzondere gevallen kan van de releasetermijn worden afgeweken.
- Op het moment dat het functionele toepassingsgebied van waarvoor het pas-toe-of-leg-uit-regime geldt wijzigt, wordt dit voorgelegd aan Forum Standaardisatie en het OBDO zodat het regime kan worden bekrachtigd voor dit nieuwe toepassingsgebied.
Afhankelijk van de impact van een wijziging of patch krijgt een release een nieuwsversienummer. Het versienummerbeheer volgt principes voor semantische versienummering en is beschreven in een bijlage
De impact van een wijziging kan verschillen per koppelvlakspecificatie. Voor de standaard hebben we de volgende impactmatrix opgesteld:
| Standaard | Toevoegen | Wijzigen | Verwijderen | Vervallen |
|---|---|---|---|---|
| major/minor | major/minor | major/minor | major/minor |
In de matrix zijn kolommmen opgenomen voor verwijderen en vervallen. Met verwijderen wordt het volledig verwijderen van een regel of concept bedoeld. Bij vervallen blijft deze behouden maar wordt door een geldigheidsdatum aangegeven dat de regel of eht concept niet meer van toepassing is.
| Afkorting | Status van de standaard | Beschrijving van de status |
|---|---|---|
| IO | In Ontwikkeling | Een nieuwe release van de standaard is "In Ontwikkeling" wanneer er met medeweten en medewerking van participanten aan gewerkt wordt en wanneer dit onderdeel of deze release nog niet voor de buitenwereld is gepubliceerd. |
| IG | In Gebruik | Als een nieuwe release van de standaard gereed is, en is bestendigd door Forum Standaardisatie, stelt het Technisch Overleg de status 'In Gebruik' vast. Door deze vaststelling worden gebruikers en ICT-leveranciers opgeroepen deze nieuwe release op te nemen in software en in gebruik te nemen. |
| EO | Einde Ondersteuning | De standaardversie met de status "Einde ondersteuning" wordt niet meer ondersteund door de beheerder. De kennis en informatie voor vragen en support is bij de beheerder niet langer beschikbaar. |
| TG | Teruggetrokken | De standaard krijgt de status "Teruggetrokken" indien een release van de standaard niet bruikbaar blijkt (bijv. vanwege implementatieproblemen). |
De vergaderstukken van het Technisch overleg en overige besluitvormende gremia.
De specificaties van de standaard
De voorlopige specificaties van de nieuwe versie van de standaard.
Versie xx van de xx is gepubliceerd op: