pa:VDraft Toetsingskader: verschil tussen versies
| Regel 15: | Regel 15: | ||
De criteria gelden voor alle informatiestandaarden die onder beheer staan van Nictiz. | De criteria gelden voor alle informatiestandaarden die onder beheer staan van Nictiz. | ||
| − | + | =Definitie= | |
| − | |||
| − | |||
Toetsingscriteria zijn ontwerpregels die de productarchitectuurprincipes vertalen naar toetsbare eisen. Ze bieden houvast bij het beoordelen van ontwerpen en bevorderen de eenduidigheid in de toepassing van architectuur. | Toetsingscriteria zijn ontwerpregels die de productarchitectuurprincipes vertalen naar toetsbare eisen. Ze bieden houvast bij het beoordelen van ontwerpen en bevorderen de eenduidigheid in de toepassing van architectuur. | ||
| Regel 24: | Regel 22: | ||
* welke regels gelden voor het gebruik van generieke standaarden binnen een informatiestandaard. | * welke regels gelden voor het gebruik van generieke standaarden binnen een informatiestandaard. | ||
| − | + | =Niveau van verplichting= | |
Elk toetsingscriterium kent een niveau van verplichting, afhankelijk van de status van de onderliggende documentatie: | Elk toetsingscriterium kent een niveau van verplichting, afhankelijk van de status van de onderliggende documentatie: | ||
* Verplicht: gebaseerd op documentatie met een definitieve status of waarover brede consensus bestaat. | * Verplicht: gebaseerd op documentatie met een definitieve status of waarover brede consensus bestaat. | ||
* Aanbevolen: afgeleid van documentatie met een alfa- of bètastatus die nog niet volledig is gevalideerd of beproefd. | * Aanbevolen: afgeleid van documentatie met een alfa- of bètastatus die nog niet volledig is gevalideerd of beproefd. | ||
| − | |||
| − | |||
De volgende niveaus worden gehanteerd: | De volgende niveaus worden gehanteerd: | ||
| − | {| class="wikitable" style="table-layout:fixed; width: | + | {| class="wikitable" style="table-layout:fixed; width:76%;" |
|- | |- | ||
! style="width:8%; vertical-align:top; text-align:left" | Niveau | ! style="width:8%; vertical-align:top; text-align:left" | Niveau | ||
| − | ! style="width: | + | ! style="width:34%; vertical-align:top; text-align:left" | Betekenis |
| + | ! style="width:34%; vertical-align:top; text-align:left" | Afwijking toegestaan? | ||
|- | |- | ||
| style="vertical-align:top; text-align:left" | MUST | | style="vertical-align:top; text-align:left" | MUST | ||
| − | | style="vertical-align:top; text-align:left" | Verplicht. | + | | style="vertical-align:top; text-align:left" | Verplicht. Dit criterium moet worden gevolgd. Er is brede consensus over de onderliggende documentatie. |
| − | + | | style="vertical-align:top; text-align:left" | Alleen bij onderbouwing met zeer zwaarwegende argumenten.<br>Er moet een plan zijn hoe op termijn wel kan worden voldaan aan dit criterium. | |
| − | |||
| − | | style="vertical-align:top; text-align:left" | | ||
|- | |- | ||
| style="vertical-align:top; text-align:left" | MUST NOT | | style="vertical-align:top; text-align:left" | MUST NOT | ||
| − | | style="vertical-align:top; text-align:left" | Niet toegestaan. | + | | style="vertical-align:top; text-align:left" | Niet toegestaan. |
| + | | style="vertical-align:top; text-align:left" | " " | ||
|- | |- | ||
| style="vertical-align:top; text-align:left" | SHOULD | | style="vertical-align:top; text-align:left" | SHOULD | ||
| − | | style="vertical-align:top; text-align:left" | | + | | style="vertical-align:top; text-align:left" | Aanbevolen. Sterke voorkeur om te volgen. De onderliggende documentatie heeft nog geen definitieve status. |
| + | | style="vertical-align:top; text-align:left" | Ja, mits de afwijking onderbouwd wordt. | ||
|- | |- | ||
| style="vertical-align:top; text-align:left" | SHOULD NOT | | style="vertical-align:top; text-align:left" | SHOULD NOT | ||
| − | | style="vertical-align:top; text-align:left" | | + | | style="vertical-align:top; text-align:left" | Afgeraden. |
| + | | style="vertical-align:top; text-align:left" | " " | ||
|- | |- | ||
| style="vertical-align:top; text-align:left" | MAY | | style="vertical-align:top; text-align:left" | MAY | ||
| style="vertical-align:top; text-align:left" | Optioneel. Toepassing is toegestaan, maar niet verplicht. | | style="vertical-align:top; text-align:left" | Optioneel. Toepassing is toegestaan, maar niet verplicht. | ||
| + | | style="vertical-align:top; text-align:left" | - | ||
|- | |- | ||
|} | |} | ||
| Regel 62: | Regel 61: | ||
* het opstellen van ontwerpdocumentatie door de beheerder van een informatiestandaard; | * het opstellen van ontwerpdocumentatie door de beheerder van een informatiestandaard; | ||
* de toetsing tijdens besluitvorming over acceptatie of wijziging van een informatiestandaard door het Productarchitectuurteam en de Productarchitectuurboard; | * de toetsing tijdens besluitvorming over acceptatie of wijziging van een informatiestandaard door het Productarchitectuurteam en de Productarchitectuurboard; | ||
| − | * de borging van interoperabiliteit binnen het stelsel van informatiestandaarden. | + | * de borging van interoperabiliteit binnen het stelsel van informatiestandaarden, met inbegrip van EHDS-compatibiliteit. |
=Proces= | =Proces= | ||
| + | De toetsing productarchitectuur is onderdeel van het [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen QA-proces] van Nictiz voor het ontwikkelen van informatiestandaarden. De beheerder van de informatiestandaard is verantwoordelijk voor het tijdig benaderen van het Productarchitectuurteam om de vereiste toetsingen uit te voeren op de momenten die in QA zijn vastgelegd. | ||
| + | |||
==Ingangstoets== | ==Ingangstoets== | ||
| − | + | Het toetsingsproces start met een ingangstoets. Deze toets vindt plaats in één of meerdere werksessies waarin het Productarchitectuurteam en de beheerder van de informatiestandaard gezamenlijk de ontwerpplannen beoordelen. Een tweede beheerteam van een andere informatiestandaard kan deelnemen in het kader van peer review. De ingangstoets resulteert in een toetsingsrapport op de interne [https://nictiz.atlassian.net/wiki/spaces/POB/pages/340099187/Product+Architectuur?atlOrigin=eyJpIjoiM2YyM2YzMTY4ODQ4NDIzZjk5NzE5NGM4N2FiMjBkOGUiLCJwIjoiYyJ9 Confluence-pagina Productarchitectuur]. Het toetsingsrapport bevat Jira-tickets voor de opvolging van afwijkingen en potentiële afwijkingen. | |
| − | Deze toets vindt plaats in één of meerdere werksessies waarin het Productarchitectuurteam en de beheerder van de informatiestandaard gezamenlijk de ontwerpplannen beoordelen. Een tweede beheerteam van een andere informatiestandaard kan deelnemen in het kader van peer review. | ||
| − | |||
| − | |||
==Monitoring== | ==Monitoring== | ||
| − | De opvolging van acties bij geconstateerde afwijkingen vindt plaats via de | + | De opvolging van acties bij geconstateerde afwijkingen vindt plaats via de Confluence-pagina Productarchitectuur, met verwijzingen naar de aangemaakte Jira-tickets. Elke informatiestandaard heeft een toegewezen productarchitect die fungeert als eerste aanspreekpunt voor vragen en advies over productarchitectuur. De productarchitect signaleert nieuwe afwijkingen die kunnen ontstaan tijdens de verdere uitwerking van de ontwerpplannen. |
| − | |||
| − | Elke informatiestandaard heeft een toegewezen productarchitect die fungeert als eerste aanspreekpunt voor vragen en advies over productarchitectuur. | ||
| − | De productarchitect signaleert nieuwe afwijkingen die kunnen ontstaan tijdens de verdere uitwerking van de ontwerpplannen. | ||
==Toets voorafgaand aan publicatie== | ==Toets voorafgaand aan publicatie== | ||
| − | Het voldoen aan de toetsingscriteria is een voorwaarde voor publicatie van een informatiestandaard. | + | Het voldoen aan de toetsingscriteria is een voorwaarde voor publicatie van een informatiestandaard. Bij onopgeloste afwijkingen geeft de beheerder van de informatiestandaard een onderbouwing volgens het comply or explain-principe. Ook geeft de beheerder aan hoe op termijn alsnog aan het criterium kan worden voldaan. De Productarchitectuurboard beoordeelt op basis van deze onderbouwing of publicatie kan doorgaan. |
| − | Bij | ||
| − | |||
| − | |||
=Beheer= | =Beheer= | ||
De toetsingscriteria worden beheerd door het Productarchitectuurteam en vastgesteld door de Productarchitectuurboard van de afdeling Productontwikkeling & Beheer van Nictiz. In het Productarchitectuurteam is tevens het Architectuurteam van de afdeling Strategie & Advies van Nictiz vertegenwoordigd. | De toetsingscriteria worden beheerd door het Productarchitectuurteam en vastgesteld door de Productarchitectuurboard van de afdeling Productontwikkeling & Beheer van Nictiz. In het Productarchitectuurteam is tevens het Architectuurteam van de afdeling Strategie & Advies van Nictiz vertegenwoordigd. | ||
| − | Wijzigingen of aanvullingen worden vastgesteld na consultatie van betrokken stakeholders en gepubliceerd in de meest recente versie van dit document. | + | Afwijkingen van verplichte of aanbevolen criteria worden vastgelegd en periodiek geëvalueerd om te bepalen of aanpassing van de toetsing nodig is. Wijzigingen of aanvullingen worden vastgesteld na consultatie van betrokken stakeholders en gepubliceerd in de meest recente versie van dit document. De toetsingscriteria kennen een hogere wijzigingsfrequentie dan de meer stabiele, overkoepelende productarchitectuurprincipes. |
| − | |||
| − | De toetsingscriteria kennen een hogere wijzigingsfrequentie dan de meer stabiele, overkoepelende productarchitectuurprincipes. | ||
=Documenthistorie= | =Documenthistorie= | ||
| Regel 100: | Regel 90: | ||
| style="vertical-align:top; text-align:left" | 0.1.0-alfa.1 | | style="vertical-align:top; text-align:left" | 0.1.0-alfa.1 | ||
| style="vertical-align:top; text-align:left" | draft | | style="vertical-align:top; text-align:left" | draft | ||
| − | | style="vertical-align:top; text-align:left" | | + | | style="vertical-align:top; text-align:left" | 07-11-2025 |
|- | |- | ||
|} | |} | ||
Voor het opstellen van deze pagina is ChatGPT gebruikt als hulp voor het verbeteren van de schrijfstijl en zinsstructuur en voor grammaticacontrole. | Voor het opstellen van deze pagina is ChatGPT gebruikt als hulp voor het verbeteren van de schrijfstijl en zinsstructuur en voor grammaticacontrole. | ||
Versie van 7 nov 2025 om 15:09
 |
This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. |
This page has been removed from search engines' indexes.
| Hoofdpagina Productarchitectuur | Productarchitectuurprincipes | Toetsingskader | Toetsingscriteria |
|---|
Inhoud
Doel
De toetsingscriteria dragen bij aan de consistentie en samenhang tussen informatiestandaarden en ondersteunen daarmee de zorgbrede interoperabiliteit. Ze vormen een concrete uitwerking van de overkoepelende productarchitectuurprincipes en bieden kaders voor het ontwerpen van informatiestandaarden.
Reikwijdte
De toetsingscriteria zijn van toepassing op:
- het ontwerp van nieuwe informatiestandaarden;
- het beheer en de doorontwikkeling van bestaande informatiestandaarden.
De criteria gelden voor alle informatiestandaarden die onder beheer staan van Nictiz.
Definitie
Toetsingscriteria zijn ontwerpregels die de productarchitectuurprincipes vertalen naar toetsbare eisen. Ze bieden houvast bij het beoordelen van ontwerpen en bevorderen de eenduidigheid in de toepassing van architectuur.
De toetsingscriteria specificeren:
- welke generieke standaarden (en welke versies daarvan) moeten worden toegepast;
- welke regels gelden voor het gebruik van generieke standaarden binnen een informatiestandaard.
Niveau van verplichting
Elk toetsingscriterium kent een niveau van verplichting, afhankelijk van de status van de onderliggende documentatie:
- Verplicht: gebaseerd op documentatie met een definitieve status of waarover brede consensus bestaat.
- Aanbevolen: afgeleid van documentatie met een alfa- of bètastatus die nog niet volledig is gevalideerd of beproefd.
De volgende niveaus worden gehanteerd:
| Niveau | Betekenis | Afwijking toegestaan? |
|---|---|---|
| MUST | Verplicht. Dit criterium moet worden gevolgd. Er is brede consensus over de onderliggende documentatie. | Alleen bij onderbouwing met zeer zwaarwegende argumenten. Er moet een plan zijn hoe op termijn wel kan worden voldaan aan dit criterium. |
| MUST NOT | Niet toegestaan. | " " |
| SHOULD | Aanbevolen. Sterke voorkeur om te volgen. De onderliggende documentatie heeft nog geen definitieve status. | Ja, mits de afwijking onderbouwd wordt. |
| SHOULD NOT | Afgeraden. | " " |
| MAY | Optioneel. Toepassing is toegestaan, maar niet verplicht. | - |
Toepassing
De toetsingscriteria vormen het kader voor:
- het opstellen van ontwerpdocumentatie door de beheerder van een informatiestandaard;
- de toetsing tijdens besluitvorming over acceptatie of wijziging van een informatiestandaard door het Productarchitectuurteam en de Productarchitectuurboard;
- de borging van interoperabiliteit binnen het stelsel van informatiestandaarden, met inbegrip van EHDS-compatibiliteit.
Proces
De toetsing productarchitectuur is onderdeel van het QA-proces van Nictiz voor het ontwikkelen van informatiestandaarden. De beheerder van de informatiestandaard is verantwoordelijk voor het tijdig benaderen van het Productarchitectuurteam om de vereiste toetsingen uit te voeren op de momenten die in QA zijn vastgelegd.
Ingangstoets
Het toetsingsproces start met een ingangstoets. Deze toets vindt plaats in één of meerdere werksessies waarin het Productarchitectuurteam en de beheerder van de informatiestandaard gezamenlijk de ontwerpplannen beoordelen. Een tweede beheerteam van een andere informatiestandaard kan deelnemen in het kader van peer review. De ingangstoets resulteert in een toetsingsrapport op de interne Confluence-pagina Productarchitectuur. Het toetsingsrapport bevat Jira-tickets voor de opvolging van afwijkingen en potentiële afwijkingen.
Monitoring
De opvolging van acties bij geconstateerde afwijkingen vindt plaats via de Confluence-pagina Productarchitectuur, met verwijzingen naar de aangemaakte Jira-tickets. Elke informatiestandaard heeft een toegewezen productarchitect die fungeert als eerste aanspreekpunt voor vragen en advies over productarchitectuur. De productarchitect signaleert nieuwe afwijkingen die kunnen ontstaan tijdens de verdere uitwerking van de ontwerpplannen.
Toets voorafgaand aan publicatie
Het voldoen aan de toetsingscriteria is een voorwaarde voor publicatie van een informatiestandaard. Bij onopgeloste afwijkingen geeft de beheerder van de informatiestandaard een onderbouwing volgens het comply or explain-principe. Ook geeft de beheerder aan hoe op termijn alsnog aan het criterium kan worden voldaan. De Productarchitectuurboard beoordeelt op basis van deze onderbouwing of publicatie kan doorgaan.
Beheer
De toetsingscriteria worden beheerd door het Productarchitectuurteam en vastgesteld door de Productarchitectuurboard van de afdeling Productontwikkeling & Beheer van Nictiz. In het Productarchitectuurteam is tevens het Architectuurteam van de afdeling Strategie & Advies van Nictiz vertegenwoordigd.
Afwijkingen van verplichte of aanbevolen criteria worden vastgelegd en periodiek geëvalueerd om te bepalen of aanpassing van de toetsing nodig is. Wijzigingen of aanvullingen worden vastgesteld na consultatie van betrokken stakeholders en gepubliceerd in de meest recente versie van dit document. De toetsingscriteria kennen een hogere wijzigingsfrequentie dan de meer stabiele, overkoepelende productarchitectuurprincipes.
Documenthistorie
| Versie | Status | Datum | Wijziging |
|---|---|---|---|
| 0.1.0-alfa.1 | draft | 07-11-2025 |
Voor het opstellen van deze pagina is ChatGPT gebruikt als hulp voor het verbeteren van de schrijfstijl en zinsstructuur en voor grammaticacontrole.
