qa:Ontwikkelen en Testen: verschil tussen versies
(→Procesactiviteiten) |
|||
Regel 63: | Regel 63: | ||
!Hulpmiddel | !Hulpmiddel | ||
|- | |- | ||
− | | 1 | + | | <ol start="1" style="list-style-type: decimal;"> |
− | + | <li><p>''' '''</p></li></ol> | |
− | ''' ''' | ||
| Projectleider /Productowner / Productmanager | | Projectleider /Productowner / Productmanager | ||
Regel 71: | Regel 70: | ||
Voltooien projectplan | Voltooien projectplan | ||
* Output van het proces Verkennen is een startversie van het projectplan. Hierin zijn de hoofdstukken ingevuld conform acceptatiecriteria van proces 'Verkennen'. | * Output van het proces Verkennen is een startversie van het projectplan. Hierin zijn de hoofdstukken ingevuld conform acceptatiecriteria van proces 'Verkennen'. | ||
− | * Ontwikkelen & Testen | + | * Ontwikkelen & Testen voltooit dit projectplan en dan met name: |
** Communicatieplan | ** Communicatieplan | ||
** Teststrategie | ** Teststrategie | ||
Regel 79: | Regel 78: | ||
** Aanzet tot implementatie | ** Aanzet tot implementatie | ||
* Projectplan reviewen door in- en externe experts | * Projectplan reviewen door in- en externe experts | ||
− | * Projectplan goedkeuren door | + | * Projectplan goedkeuren door Autorisator (namens de Houder) |
Regel 98: | Regel 97: | ||
* Autorisator beoordeelt projectplan | * Autorisator beoordeelt projectplan | ||
− | + | ** Bij goedkeuren: door naar volgende stap | |
− | * Bij goedkeuren | + | ** Bij afkeuren: terug naar de vorige stap |
− | |||
− | * Bij afkeuren | ||
| | | | ||
Regel 112: | Regel 109: | ||
* De Projectleider bouwt een projectorganisatie op, inclusief vertegenwoordigers uit het (zorg)veld (waaronder patiënten) en hulpmiddelen (waaronder licenties en applicaties). | * De Projectleider bouwt een projectorganisatie op, inclusief vertegenwoordigers uit het (zorg)veld (waaronder patiënten) en hulpmiddelen (waaronder licenties en applicaties). | ||
− | |||
* De Productowner maakt een resourceplanning, waarin de benodigde interne capaciteit (waar nodig) verder wordt gespecificeerd. | * De Productowner maakt een resourceplanning, waarin de benodigde interne capaciteit (waar nodig) verder wordt gespecificeerd. | ||
− | |||
* Het samenstellen van het projectteam en het betrekken van de stakeholders gebeurt in nauwe samenwerking met de Productmanager en Adviseur. | * Het samenstellen van het projectteam en het betrekken van de stakeholders gebeurt in nauwe samenwerking met de Productmanager en Adviseur. | ||
Regel 125: | Regel 120: | ||
| <u>Analyseren zorgproces/richtlijn:</u> | | <u>Analyseren zorgproces/richtlijn:</u> | ||
− | * De Informatieanalist voert op basis van het projectplan een inhoudelijke analyse uit op het zorgproces, inclusief bijbehorende richtlijnen, werkafspraken en terminologie. Dit gebeurt altijd samen met het veld en een | + | * De Informatieanalist voert op basis van het projectplan een inhoudelijke analyse uit op het zorgproces, inclusief bijbehorende richtlijnen, werkafspraken en terminologie. Dit gebeurt altijd samen met het veld en een Adviseur, en in eventuele afstemming met een Terminoloog. Het resultaat hiervan is een prototype van de usecases, benodigde dataset en scenario's. De uitwerking van de analyse mag 'free format' plaatsvinden. |
− | + | * De Informatieanalist legt, in afstemming met de Productmanager en Projectleider, het prototype voor aan de relevante stakeholders uit het veld en voert op basis van de feedback uit het veld eventuele wijzigingen door. | |
− | * De Informatieanalist legt, in afstemming met de Productmanager en Projectleider, het prototype voor aan de relevante stakeholders uit het veld en voert op basis van de feedback uit het veld eventuele wijzigingen | ||
| | | | ||
Regel 137: | Regel 131: | ||
| <u>Ontwikkelen a</u>lpha-release: | | <u>Ontwikkelen a</u>lpha-release: | ||
− | Informatieanalist is verantwoordelijk voor uitwerken functionele producten: | + | Informatieanalist is verantwoordelijk voor het uitwerken van functionele producten: |
* Functioneel ontwerp (FO) | * Functioneel ontwerp (FO) | ||
− | |||
* Usecase(s) | * Usecase(s) | ||
− | + | * Dataset, inclusief terminologie in afstemming met Terminoloog | |
− | * Dataset, inclusief terminologie in afstemming met | ||
− | |||
* Scenario's, transactiegroepen, transacties | * Scenario's, transactiegroepen, transacties | ||
− | Specialist gegevensuitwisseling is verantwoordelijk voor uitwerken technische producten: | + | Specialist gegevensuitwisseling is verantwoordelijk voor het uitwerken van technische producten: |
* Technisch ontwerp (TO) | * Technisch ontwerp (TO) | ||
+ | * FHIR-profielen en/of | ||
+ | * HL7v3-templates | ||
+ | * Technische voorbeelden | ||
− | + | Het functioneel ontwerp is leidend. | |
− | |||
− | |||
− | |||
− | Het functioneel ontwerp is | ||
Het uitwerken van de producten gebeurt iteratief, in afstemming met externe experts (vastgesteld in stap 3) en eventuele andere Nictiz-specialisten. De oplevering van de producten gebeurt in ART-DECOR, wiki en Simplifier. | Het uitwerken van de producten gebeurt iteratief, in afstemming met externe experts (vastgesteld in stap 3) en eventuele andere Nictiz-specialisten. De oplevering van de producten gebeurt in ART-DECOR, wiki en Simplifier. | ||
− | |||
Regel 175: | Regel 164: | ||
oXygen | oXygen | ||
− | |||
|- | |- | ||
Regel 182: | Regel 170: | ||
| Informatieanalist / Specialist gegevensuitwisseling / expert groep | | Informatieanalist / Specialist gegevensuitwisseling / expert groep | ||
− | | <u>Interne review alpha | + | | <u>Interne review alpha release</u> |
− | Informatieanalisten, | + | Informatieanalisten, Specialisten gegevensuitwisseling en de deelnemers aan de expertgroep reviewen de in de vorige stap ontwikkelde producten. |
| [https://nictiz.atlassian.net/jira/ Jira (BITS)] | | [https://nictiz.atlassian.net/jira/ Jira (BITS)] | ||
Regel 192: | Regel 180: | ||
| Projectleider / Productmanager | | Projectleider / Productmanager | ||
− | | <u> | + | | <u>Gereed voor publicatie?</u> |
− | |||
− | |||
− | + | Als er bij de interne review bevindingen zijn die leiden tot een aanpassing van de functionele en/of technische producten, herhalen de stappen 5 en 6. Als er na de laatste interne review geen bevindingen zijn die leiden tot herontwikkeling, kunnen de Projectleider en Productmanager het akkoord geven op de publicatie van de alpha release. | |
− | Omdat | + | Omdat externe stakeholders nu nog geen substantiële inspanning en investering hoeven te doen, is een akkoord van de Projectleider / Productmanager afdoende. |
| | | | ||
Regel 206: | Regel 192: | ||
| Projectleider / Productmanager | | Projectleider / Productmanager | ||
− | | <u>Publicatie alpha | + | | <u>Publicatie alpha release</u> |
− | De alpha release wordt gepubliceerd en gecommuniceerd naar alle externe stakeholders | + | De alpha release wordt gepubliceerd en gecommuniceerd naar alle in- en externe stakeholders |
| | | | ||
Regel 218: | Regel 204: | ||
| <u>Externe review</u> | | <u>Externe review</u> | ||
− | Externe stakeholders zoals leveranciers en koepelorganisaties reviewen | + | Externe stakeholders zoals leveranciers en koepelorganisaties reviewen de producten in de alpha-release zoals beschreven in het sjabloon testplan. Indien nodig registreren zij bevindingen. Het projectteam beoordeelt deze samen met de externe stakeholders. Bevindingen kunnen leiden tot wijzigingen aan / herontwikkeling van producten. Voor die wijzigingen gaan we terug naar stap 5. |
| [https://nictiz.atlassian.net/jira/ Jira (BITS)] | | [https://nictiz.atlassian.net/jira/ Jira (BITS)] | ||
Regel 226: | Regel 212: | ||
| Autorisator | | Autorisator | ||
− | | <u>Gereed voor | + | | <u>Gereed voor bèta release</u> |
− | Als er | + | Als er vanuit de externe review nog bevindingen zijn die leiden tot een aanpassing van de functionele en/of technische producten, moeten deze eerst stappen 5 t/m 9 doorlopen. |
− | Als er na de laatste externe review geen bevindingen | + | Als er na de laatste externe review geen bevindingen zijn die leiden tot herontwikkeling, kan de Autorisator akkoord geven op het ontwikkelen van de bèta release. |
| | | | ||
Regel 238: | Regel 224: | ||
| Informatieanalist / Specialist gegevensuitwisseling | | Informatieanalist / Specialist gegevensuitwisseling | ||
− | | <u>Ontwikkelen bèta | + | | <u>Ontwikkelen bèta release</u> |
Testmaterialen toevoegen aan de op te leveren producten uit stap 5. | Testmaterialen toevoegen aan de op te leveren producten uit stap 5. | ||
− | |||
Regel 258: | Regel 243: | ||
<li><p>''' '''</p></li></ol> | <li><p>''' '''</p></li></ol> | ||
− | | Informatieanalist / Specialist gegevensuitwisseling / | + | | Informatieanalist / Specialist gegevensuitwisseling / expertgroep |
− | | <u> | + | | <u>Interne test/review bèta release</u> |
− | Intern uitvoeren van | + | Intern uitvoeren van testen, waarmee we zowel de producten van de informatiestandaard als ook de testmaterialen zelf valideren. |
Bij benodigde wijzigingen aan overige op te leveren producten (zie stap 5) ook daarvoor interne review uitvoeren, zie stap 6. Met andere woorden: hiervoor wordt stap 5 en 6 ook uitgevoerd. | Bij benodigde wijzigingen aan overige op te leveren producten (zie stap 5) ook daarvoor interne review uitvoeren, zie stap 6. Met andere woorden: hiervoor wordt stap 5 en 6 ook uitgevoerd. | ||
Regel 278: | Regel 263: | ||
| Autorisator | | Autorisator | ||
− | | <u>Gereed voor publicatie</u> | + | | <u>Gereed voor publicatie?</u> |
− | Als er bij de interne review bevindingen | + | Als er bij de interne review bevindingen zijn die leiden tot een aanpassing van de functionele en/of technische producten, moeten deze eerst worden ontwikkeld en intern gereviewd – een herhaling van stappen 5 en 6 en/of 11 en 12. Als er na de laatste interne review geen bevindingenzijn die leiden tot herontwikkeling, kan het akkoord worden gegeven op de publicatie van de bèta release. |
− | |||
− | |||
− | |||
− | |||
+ | De Autorisator beslist of de ontwikkelde producten gereed zijn voor publicatie omdat aan de externe reviewers nu wel substantiële inspanning en investering wordt gevraagd. | ||
Regel 294: | Regel 276: | ||
| Projectleider / Productmanager | | Projectleider / Productmanager | ||
− | | <u>Publicatie | + | | <u>Publicatie bèta release</u> |
− | + | Publiceren van bèta release en communiceren naar alle in- en externe stakeholders | |
| | | | ||
Regel 304: | Regel 286: | ||
| Externe deelnemers aan testen bèta-release / Informatieanalist / Specialist gegevensuitwisseling | | Externe deelnemers aan testen bèta-release / Informatieanalist / Specialist gegevensuitwisseling | ||
− | | <u>Externe test/review | + | | <u>Externe test/review bèta release</u> |
De gepubliceerde producten extern reviewen en testen. Dit betekent dat leveranciers daadwerkelijk de specificaties gaan inbouwen en testen. Ook ketentesten horen hier bij. Het zijn nog wel testen in testomgeving(en). | De gepubliceerde producten extern reviewen en testen. Dit betekent dat leveranciers daadwerkelijk de specificaties gaan inbouwen en testen. Ook ketentesten horen hier bij. Het zijn nog wel testen in testomgeving(en). | ||
Regel 314: | Regel 296: | ||
| | | | ||
− | | <u>Gereed voor | + | | <u>Gereed voor release candidate?</u> |
− | Als er bij de externe test en review bevindingen | + | Als er bij de externe test en review bevindingen zijn die leiden tot een aanpassing van de functionele en/of technische producten, moeten deze eerst worden ontwikkeld, intern gereviewd, gepubliceerd en extern getest en gereviewd – een herhaling van stappen 11 t/m 15 en indien nodig ook stap 5 en 6. Als er na de laatste externe review en test geen bevindingen worden gemaakt die leiden tot herontwikkeling, kan een akkoord worden gegeven op het doorzetten naar de ontwikkeling van de release candidate. |
| | | | ||
Regel 323: | Regel 305: | ||
<li><p>''' '''</p></li></ol> | <li><p>''' '''</p></li></ol> | ||
− | | Informatieanalist / Specialist gegevensuitwisseling / | + | | Informatieanalist / Specialist gegevensuitwisseling / Kwalificatiespecialist |
| <u>Ontwikkelen release candidate</u> | | <u>Ontwikkelen release candidate</u> | ||
− | Kwalificatiematerialen toevoegen aan de | + | Kwalificatiematerialen toevoegen aan de opgeleverde producten uit stap 5. |
− | |||
− | |||
| Ada | | Ada |
Versie van 25 apr 2025 om 10:33
Dit materiaal is in ontwikkeling en nog niet geschikt voor gebruik! |
1 Procesdoel
Het doel van dit proces is:
- Het volgens een uniform beheerst proces ontwikkelen van een implementeerbare informatiestandaard
- die voldoet aan de eisen van relevante stakeholders en
- is goedgekeurd door deze stakeholders
Randvoorwaarden:
- Eenheid van taal
- Implementeerbaar
- Bruikbaar
- Heldere afspraken over beheer:
- een vastgestelde invulling van de rollen houder, autorisator, beheerder (waaronder productmanager) en experts
- dit geldt voor zowel doorontwikkeling als nieuwe informatiestandaarden
- Goedkeuring door daartoe bevoegde stakeholders
Dit proces sluit aan op het proces 'Verkennen' dat de inhoudelijke verkenning heeft uitgevoerd.
1.1 Proceseigenaar
Ontwikkelen: Lilian Brouwer
Testen: Arianne van de Wetering
2 Proces
2.1 Procesdiagram
2.2 Procesactiviteiten
Nr | Verantwoordelijk | Activiteit | Hulpmiddel |
---|---|---|---|
Projectleider /Productowner / Productmanager |
Voltooien projectplan
|
Template Projectplan [Download] | |
Autorisator | Akkoord houder/autorisator. Goedkeuren projectplan
|
||
Projectleider / Productmanager / Productowner | Inrichten projectorganisatie
|
||
Informatieanalist | Analyseren zorgproces/richtlijn:
|
||
Informatieanalist / Specialist gegevensuitwisseling | Ontwikkelen alpha-release:
Informatieanalist is verantwoordelijk voor het uitwerken van functionele producten:
Specialist gegevensuitwisseling is verantwoordelijk voor het uitwerken van technische producten:
Het functioneel ontwerp is leidend. Het uitwerken van de producten gebeurt iteratief, in afstemming met externe experts (vastgesteld in stap 3) en eventuele andere Nictiz-specialisten. De oplevering van de producten gebeurt in ART-DECOR, wiki en Simplifier.
|
Template Functioneel ontwerp [Download]
oXygen
| |
Informatieanalist / Specialist gegevensuitwisseling / expert groep | Interne review alpha release
Informatieanalisten, Specialisten gegevensuitwisseling en de deelnemers aan de expertgroep reviewen de in de vorige stap ontwikkelde producten. |
Jira (BITS) | |
Projectleider / Productmanager | Gereed voor publicatie?
Als er bij de interne review bevindingen zijn die leiden tot een aanpassing van de functionele en/of technische producten, herhalen de stappen 5 en 6. Als er na de laatste interne review geen bevindingen zijn die leiden tot herontwikkeling, kunnen de Projectleider en Productmanager het akkoord geven op de publicatie van de alpha release. Omdat externe stakeholders nu nog geen substantiële inspanning en investering hoeven te doen, is een akkoord van de Projectleider / Productmanager afdoende. |
||
Projectleider / Productmanager | Publicatie alpha release
De alpha release wordt gepubliceerd en gecommuniceerd naar alle in- en externe stakeholders |
||
Externe stakeholders | Externe review
Externe stakeholders zoals leveranciers en koepelorganisaties reviewen de producten in de alpha-release zoals beschreven in het sjabloon testplan. Indien nodig registreren zij bevindingen. Het projectteam beoordeelt deze samen met de externe stakeholders. Bevindingen kunnen leiden tot wijzigingen aan / herontwikkeling van producten. Voor die wijzigingen gaan we terug naar stap 5. |
Jira (BITS) | |
Autorisator | Gereed voor bèta release
Als er vanuit de externe review nog bevindingen zijn die leiden tot een aanpassing van de functionele en/of technische producten, moeten deze eerst stappen 5 t/m 9 doorlopen. Als er na de laatste externe review geen bevindingen zijn die leiden tot herontwikkeling, kan de Autorisator akkoord geven op het ontwikkelen van de bèta release. |
||
Informatieanalist / Specialist gegevensuitwisseling | Ontwikkelen bèta release
Testmaterialen toevoegen aan de op te leveren producten uit stap 5.
|
Ada
XSLT | |
Informatieanalist / Specialist gegevensuitwisseling / expertgroep | Interne test/review bèta release
Intern uitvoeren van testen, waarmee we zowel de producten van de informatiestandaard als ook de testmaterialen zelf valideren. Bij benodigde wijzigingen aan overige op te leveren producten (zie stap 5) ook daarvoor interne review uitvoeren, zie stap 6. Met andere woorden: hiervoor wordt stap 5 en 6 ook uitgevoerd. |
Kwalificatie.nictiz.nl
| |
Autorisator | Gereed voor publicatie?
Als er bij de interne review bevindingen zijn die leiden tot een aanpassing van de functionele en/of technische producten, moeten deze eerst worden ontwikkeld en intern gereviewd – een herhaling van stappen 5 en 6 en/of 11 en 12. Als er na de laatste interne review geen bevindingenzijn die leiden tot herontwikkeling, kan het akkoord worden gegeven op de publicatie van de bèta release. De Autorisator beslist of de ontwikkelde producten gereed zijn voor publicatie omdat aan de externe reviewers nu wel substantiële inspanning en investering wordt gevraagd.
|
||
Projectleider / Productmanager | Publicatie bèta release
Publiceren van bèta release en communiceren naar alle in- en externe stakeholders |
||
Externe deelnemers aan testen bèta-release / Informatieanalist / Specialist gegevensuitwisseling | Externe test/review bèta release
De gepubliceerde producten extern reviewen en testen. Dit betekent dat leveranciers daadwerkelijk de specificaties gaan inbouwen en testen. Ook ketentesten horen hier bij. Het zijn nog wel testen in testomgeving(en). |
Jira (BITS) | |
Gereed voor release candidate?
Als er bij de externe test en review bevindingen zijn die leiden tot een aanpassing van de functionele en/of technische producten, moeten deze eerst worden ontwikkeld, intern gereviewd, gepubliceerd en extern getest en gereviewd – een herhaling van stappen 11 t/m 15 en indien nodig ook stap 5 en 6. Als er na de laatste externe review en test geen bevindingen worden gemaakt die leiden tot herontwikkeling, kan een akkoord worden gegeven op het doorzetten naar de ontwikkeling van de release candidate. |
|||
Informatieanalist / Specialist gegevensuitwisseling / Kwalificatiespecialist | Ontwikkelen release candidate
Kwalificatiematerialen toevoegen aan de opgeleverde producten uit stap 5. |
Ada
XSLT | |
Informatieanalist / Specialist gegevensuitwisseling / expert groep / kwalificatiespecialist | Interne test/review release candidate
Intern uitvoeren van de kwalificatietesten, waarmee we deze materialen zelf valideren. Bij wijzigingen aan overige op te leveren producten (zie stap 11) ook daarvoor review uitvoeren, zie stap 12. |
Jira (BITS) | |
Autorisator | Gereed voor publicatie
Als er bij de interne review bevindingen worden gemaakt die leiden tot een aanpassing van de functionele en/of technische producten, moeten deze eerst worden ontwikkeld en intern gereviewd – een herhaling van stappen 17 en 18. Als er na de laatste interne review geen bevindingen worden gemaakt die leiden tot herontwikkeling, kan het akkoord worden gegeven op het doorzetten naar de publicatie van de release candidate.
De autorisator beslist of de ontwikkelde producten gereed zijn voor publicatie omdat aan de externe reviewers substantiële inspanning en investering wordt gevraagd.
|
||
Publicatie release candidate
De release candidate wordt gepubliceerd en gecommuniceerd naar alle externe stakeholders |
|||
Externe stakeholders | Productie testen
De gepubliceerde producten testen in een productiesituatie. Dit betekent dat leveranciers en gebruikers in een gecontroleerde omgeving de nieuw ingebouwde materialen gaan gebruiken en valideren. |
Jira (BITS) | |
Autorisator | Gereed voor definitieve publicatie
Als er bij de productietesten bevindingen worden gemaakt die leiden tot een aanpassing van de functionele en/of technische producten, moeten deze eerst worden ontwikkeld, intern gereviewd, gepubliceerd en extern getest en gereviewd – een herhaling van stappen 17 t/m 21. Als er na de laatste externe review geen bevindingen worden gemaakt die leiden tot herontwikkeling, kan een akkoord worden gegeven op het doorzetten naar de definitieve publicatie. |
||
Publiceren
Zie proces Publiceren. |
3 Context
Het proces ‘Ontwikkelen van een informatiestandaard’ gebeurt in een iteratie met het proces ‘Testen van een informatiestandaard’. Testen maakt deel uit van ontwikkelen. Bij ontwikkelen en testen van een informatiestandaard trekken Productmanager, Projectleider en Adviseur, als onderdeel van het integrale team, nadrukkelijk samen op. Waar nodig worden (andere) interne en externe experts betrokken.
Van ontwikkelen van een informatiestandaard is sprake indien de ontwikkeling een nieuwe informatiestandaard betreft of een nieuwe usecase binnen een bestaande informatiestandaard. Indien de ontwikkeling een bestaande usecase(s) binnen een bestaande informatiestandaard betreft, is sprake van doorontwikkeling, zie hiervoor de proceskaart ‘Beheren van een informatiestandaard’.
Hierbij wordt de volgende definitie van een usecase aangehouden: Een usecase is de beschrijving van een praktijksituatie waarbij voor een concrete situatie het vastleggen en/of uitwisselen van informatie wordt beschreven. Een usecase bevat: een ontwerp in de vorm van een procesbeschrijving en een beschrijving van de bedrijfsrollen, een implementatiescenario met bijbehorende systemen en systeemrollen, transacties en transactiegroepen inclusief dataset, en mogelijk een technisch ontwerp.
4 Procesrisico’s en beheersmaatregelen
Indicator | Norm | Hoe gemeten? |
---|---|---|
De standaard is juist ontwikkeld (procesmatig) | Altijd conform plan van aanpak | Interne evaluatie (of interne audit) van doorlopen proces
|
De standaard bevat de juiste inhoudelijke onderdelen (volledigheid) | Altijd conform plan van aanpak | Testen van de standaard
|
De standaard is binnen de tijdsplanning ontwikkeld | Altijd conform plan van aanpak | Interne evaluatie van planning versus realisatie |
In het ontwikkelproces heeft voldoende afstemming met stakeholders plaatsgevonden | Altijd conform plan van aanpak | Opstellen communicatie-matrix
|
Er bestaat consensus bij stakeholders over de ontwikkelde standaard | De (belangrijkste) stakeholders zijn geconsulteerd en/of hebben goedkeuring gegeven aan de standaard | Continue afstemming met stakeholders in ontwikkelproces
|
Stakeholders zijn tevreden over het doorlopen ontwikkelproces | N.t.b. | Verzamelen feedback van stakeholders |
Stakeholders zijn tevreden over de ontwikkelde informatiestandaard (inhoudelijk) | N.t.b. | Verzamelen feedback van stakeholders |
De informatiestandaard wordt gebruikt door eindgebruikers en leveranciers (adoptie) | N.t.b. | Aantal gekwalificeerde leveranciers
|
5 RACI-tabel
PMO
(Technisch beheerder) |
Projectleider
(Technisch beheerder) |
Productmanager
(Functioneel beheerder) |
Product owner | Informatieanalist
(Technisch beheerder) |
Specialist Gegevensuitwisseling
(Technisch beheerder) |
ZIB Centrum | Adviseur
(Technisch beheerder) |
(Andere) Nictiz-specialisten
(Technisch beheerders) |
Privacy Officer
(Technisch beheerder) |
Autorisator
(Autorisator) |
Externe experts
(Experts) |
Eigenaar informatiestandaard
(Houder) |
Leveranciers en gebruikers
(Gebruikers) | ||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Nr. | Activiteit | ||||||||||||||||
1 | Vervolmaken projectplan | R | R/A | C | R | C | C | I | C | C | C | C | C | C | |||
2 | Beoordelen projectplan | I | R | A | |||||||||||||
3 | Inrichten projectorganisatie | R | R/A | C | R | C | |||||||||||
4 | Analyseren richtlijn | C | A | R | C | C | C | C | |||||||||
5 | Ontwikkelen Alpha release | ||||||||||||||||
Functioneel ontwerp | I | A | R | R | C | I | C | C | C | ||||||||
Dataset | I | A | R | R | C | C | I | C | C | C | |||||||
Transactiegroepen | I | A | R | R | C | I | C | C | C | ||||||||
6 &7 | Intern reviewen Alpha release | I | A | R | R | R | C | C | |||||||||
8 | Publiceren Alpha release | I | A | R | R | R | C | ||||||||||
9 & 10 | Reviewen door externe partijen | I | A | R | C | C | C | R | R | ||||||||
11 | Ontwikkelen Beta release | ||||||||||||||||
Functioneel ontwerp | I | A | R | R | C | I | C | C | C | ||||||||
Dataset | I | A | R | R | C | I | I | C | C | C | |||||||
Transactiegroepen | I | A | R | R | C | I | C | C | C | ||||||||
Technisch ontwerp – FHIR implementatiegids | I | A | R | C | R | I | C | C | C | ||||||||
Testmateriaal | I | A | R | R | R | I | C | C | C | ||||||||
12 & 13 | Intern reviewen/testen Beta release | I | A | R | R | R | I | C | |||||||||
14 | Publiceren Beta release | I | A | R | R | R | C | ||||||||||
15 & 16 | Reviewen/testen door externe partijen | I | A | R | C | C | C | R | R | ||||||||
17 | Ontwikkelen Release Candidate | ||||||||||||||||
Functioneel ontwerp | I | A | R | R | C | I | C | C | C | ||||||||
Dataset | I | A | R | R | C | I | I | C | C | C | |||||||
Transactiegroepen | I | A | R | R | C | I | C | C | C | ||||||||
Technisch ontwerp – FHIR implementatiegids | I | A | R | C | R | I | C | C | C | ||||||||
Testmateriaal | I | A | R | R | R | I | C | C | C | ||||||||
Kwalificatiemateriaal | I | A | R | R | R | I | C | C | C | ||||||||
18 & 19 | Intern reviewen/testen Release Candidate | I | A | R | R | R | I | C | |||||||||
20 | Publiceren Release Candidate | I | A | R | R | R | C | ||||||||||
21 & 22 | Productietesten | I | A | R | C | C | C | R | R |
6 Instructies en templates
Ontwikkelen Template Projectplan [Download] |
Testen |
7 Release notes
In onderstaande tabel staan alle wijzigingen met betrekking tot Quality Assurance (QA) Proces X.