qa:Ontwikkelen en Testen

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)
  • dit geldt voor zowel doorontwikkeling als nieuwe (usecase(s) in) 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 Plan van aanpak Output van het proces Verkennen is een startversie van het (project)Plan van aanpak. Hierin zijn de hoofdstukken ingevuld conform acceptatiecriteria van proces 'Verkennen'. Ontwikkelen & Testen voltooit dit Plan van aanpak en dan met name: Heldere afspraken over beheer: een vastgestelde invulling van de rollen Houder, Autorisator, beheerder (waaronder Productmanager) én experts Communicatieplan Testplan Detail planning & budgettering Risico Aanzet tot implementatie Plan van aanpak reviewen door in- en externe experts Plan van aanpak goedkeuren door Autorisator (namens de Houder)	Template Plan van aanpak [Download] Template Testplan [Download] Acceptatiecriteria (QA tracker)
	Autorisator	Akkoord houder/autorisator. De Autorisator beoordeelt het Plan van aanpak Bij goedkeuren: door naar volgende stap Bij afkeuren: terug naar de vorige stap
	Projectleider / Productmanager / Productowner	Inrichten projectorganisatie 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. Het samenstellen van het projectteam en het betrekken van de stakeholders gebeurt in nauwe samenwerking met de Productmanager en Adviseur.
	Informatieanalist	Analyseren richtlijn De Informatieanalist voert op basis van het Plan van aanpak 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.
	Informatieanalist / Specialist gegevensuitwisseling	Ontwikkelen alpha release Informatieanalist is verantwoordelijk voor het uitwerken van functionele producten: Functioneel ontwerp (FO) Usecase(s) Dataset, inclusief terminologie in afstemming met Terminoloog Scenario's, transactiegroepen, transacties Specialist gegevensuitwisseling is verantwoordelijk voor het uitwerken van technische producten: Technisch ontwerp (TO) FHIR-profielen en/of HL7v3-templates Technische voorbeelden 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] Instructie opstellen Dataset ART-DECOR ART-DECOR Templates Wiki Forge Simplifier oXygen Richtlijn terminologie koppelen
	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) Template Testrapportage [Download]
	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) Template Testrapportage [Download]
	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 Wiki Kwalificatie.nictiz.nl Conformancelab
	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 Conformancelab Jira (BITS) Template Testrapportage [Download]
	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) Template Testrapportage [Download]
	Autorisator	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 Wiki Kwalificatie.nictiz.nl Conformancelab
	Informatieanalist / Specialist gegevensuitwisseling / expertgroep / Kwalificatiespecialist	Interne test/review release candidate Intern uitvoeren van de kwalificatietesten, waarmee we deze materialen zelf valideren. Bij eventuele benodigde wijzigingen aan overige op te leveren producten (zie stap 11) ook daarvoor review uitvoeren, zie stap 12.	Jira (BITS) Template Testrapportage [Download]
	Autorisator	Gereed voor prod 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 17 en 18. Als er na de laatste interne review geen bevindingen zijn die leiden tot herontwikkeling, kan de Autorisator akkoord geven op 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.
	Projectleider / Productmanager	Publicatie release candidate Het publiceren van de release candidate en communiceren 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. Dit is de laatste (test)stap voor definitieve publicatie.	Jira (BITS) Template Testrapportage [Download]
	Autorisator	Gereed voor definitieve publicatie Als er bij de productietesten 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 17 t/m 21. Als er na de laatste externe review geen bevindingen zijn die leiden tot herontwikkeling, kan de Autorisator akkoord geven op de definitieve publicatie.
		Publiceren Zie proces 'Publiceren'.

3 Context

Het proces ‘Ontwikkelen van een informatiestandaard’ gebeurt in samenhang met het proces ‘Testen van een informatiestandaard’. Testen maakt deel uit van ontwikkelen. Bij ontwikkelen en testen van een informatiestandaard werken Productmanager, Projectleider en Adviseur, als onderdeel van het integrale team, nauw samen. Waar nodig betrekken zij (andere) interne en externe experts.

Ontwikkelen van een informatiestandaard kan gaan over een hele nieuwe informatiestandaard maar ook over een nieuwe usecase in een bestaande informatiestandaard. Bij het wijzigen van bestaande usecase(s) gaat het om doorontwikkeling. Zie hiervoor de proceskaart ‘Beheren van een informatiestandaard’.

Met usecase bedoelen we: 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 Testen en acceptatietest uitvoeren
De standaard bevat de juiste inhoudelijke onderdelen (volledigheid)	Altijd conform plan van aanpak	Testen van de standaard Uitvoeren acceptatietest
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 Toetsen naleving communicatiematrix middels evaluatie/audit
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 Goedkeuring door Autorisator Uitvoeren open consultatie
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 Aantallen berichtenverkeer

5 RACI-tabel

Toelichting:

• In de tabel zijn per procesactiviteit de verantwoordelijke (Nictiz-)functies benoemd. Tussen haakjes achter de functienaam is steeds de overeenkomstige NEN 7522 rol aangeduid (indien van toepassing)
• R (Responsible) = verantwoordelijke voor de uitvoering van de activiteit
• A (Accountable) = eindverantwoordelijke voor de uitvoering van de activiteit
• C (Consulted) = geraadpleegde(n) bij de uitvoering van activiteit
• I (Informed) = geïnformeerde(n) over de uitvoering van de activiteit

				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 Plan van aanpak [Download]

Template Functioneel ontwerp [Download]

Instructie opstellen Dataset

Testen

Template Testplan [Download]

Template Testrapportage [Download]

7 Release notes

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.

Versie	Datum	Release notes