qa:Ontwikkelen en Testen: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
(Procesdoel)
(Procesdoel)
Regel 27: Regel 27:
  
 
= Procesdoel =
 
= Procesdoel =
Het doel van dit proces is om het volgens een uniform beheerst proces ontwikkelen van een implementeerbare informatiestandaard. Deze informatiestandaard voldoet aan de eisen van en is goedgekeurd door relevante stakeholders.
+
Het doel van dit proces is:
 +
* Het volgens een uniform beheerst proces ontwikkelen van een implementeerbare informatiestandaard  
 +
* Deze informatiestandaard voldoet aan de eisen van en is goedgekeurd door relevante stakeholders
  
 
Randvoorwaarden:  
 
Randvoorwaarden:  
  
* Eenheid van taal;
+
* Eenheid van taal
* Implementeerbaar;
+
* Implementeerbaar
* Bruikbaar;
+
* Bruikbaar
* Heldere afspraken over beheer;
+
* Heldere afspraken over beheer
* Goedkeuring door daartoe bevoegde stakeholders.
+
* Goedkeuring door daartoe bevoegde stakeholders
  
 
== Proceseigenaar ==
 
== Proceseigenaar ==

Versie van 25 apr 2025 om 09:31


Hoofdproces


Proceskaart Ontwikkelen Proceskaart Testen


1 Procesdoel

Het doel van dit proces is:

  • Het volgens een uniform beheerst proces ontwikkelen van een implementeerbare informatiestandaard
  • Deze informatiestandaard voldoet aan de eisen van en is goedgekeurd door relevante stakeholders

Randvoorwaarden:

  • Eenheid van taal
  • Implementeerbaar
  • Bruikbaar
  • Heldere afspraken over beheer
  • Goedkeuring door daartoe bevoegde stakeholders

1.1 Proceseigenaar

Ontwikkelen: Lilian Brouwer

Testen: Arianne van de Wetering


2 Proces

2.1 Procesdiagram

1234×453px

2.2 Procesactiviteiten

Nr Verantwoordelijk Activiteit Hulpmiddel
1.

Projectleider /Productowner / Productmanager
  • Vervolmaken projectplan
  • Dit proces sluit aan op de in proces ‘Verkennen van het veld’ uitgevoerde inhoudelijke verkenning.
  • Randvoorwaardelijk is een vastgestelde invulling van de rollen houder, autorisator, beheerder (waaronder productmanager) en experts. Dit geldt voor zowel doorontwikkeling als nieuwe informatiestandaarden
  • Verkennen heeft een versie van het projectplan opgesteld. Hierin zijn de hoofdstukken ingevuld conform acceptatiecriteria.
  • Ontwikkelen & Testen vervolmaakt dit projectplan en dan met name:
  • Communicatieplan
  • Testplan
  • Teststrategie
  • Detail planning & budgettering
  • Risico
  • Aanzet tot implementatie
  • Projectplan reviewen door in- en externe experts, goedkeuren door autorisator (namens de houder)


Template Projectplan [Download]

Template Teststrategie [Download]

Template Testplan [Download]

Acceptatiecriteria (QA tracker)

Autorisator Akkoord houder/autorisator. Goedkeuren projectplan
  • Autorisator beoordeelt projectplan
  • Bij goedkeuren loop het proces door
  • Bij afkeuren hangt het af van de situatie wat de vervolgactie is
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 zorgproces/richtlijn:
  • 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 in het prototype door.
Informatieanalist / Specialist gegevensuitwisseling Ontwikkelen alpha-release:

Informatieanalist is verantwoordelijk voor uitwerken functionele producten:

  • Functioneel ontwerp (FO)
  • Usecase(s)
  • Dataset, inclusief terminologie in afstemming met terminoloog
  • Scenario's, transactiegroepen, transacties

Specialist gegevensuitwisseling is verantwoordelijk voor uitwerken technische producten:

  • Technisch ontwerp (TO)
  • FHIR-profielen
  • HL7v3-templates.

Het functioneel ontwerp is in principe 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

Wiki

Forge

Simplifier

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 Akkoord voor publicatie alpha-release

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 5 en 6. 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 alpha release.


Omdat er geen substantiële inspanning en investering wordt gevraagd aan de externe stakeholders is een akkoord van de projectleider/product manager afdoende.

Projectleider / Productmanager Publicatie alpha-release

De alpha release wordt gepubliceerd en gecommuniceerd naar alle externe stakeholders

Externe stakeholders Externe review

Externe stakeholders zoals leveranciers en koepelorganisaties reviewen alle producten in de alpha-release zoals beschreven in het sjabloon testplan. Zij registreren 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 doorontwikkeling naar bèta release

Als er bij de externe review 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 gereviewd – een herhaling van stappen 5 t/m 9.

Als er na de laatste externe review geen bevindingen worden gemaakt die leiden tot herontwikkeling, kan de autorisator akkoord geven op het doorzetten naar de ontwikkeling 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 / expert groep Intern test/review beta-release

Intern uitvoeren van de 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)


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 11 en 12. 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 bèta release.


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 bèta-release

De bèta-release wordt gepubliceerd en gecommuniceerd naar alle externe stakeholders

Externe deelnemers aan testen bèta-release / Informatieanalist / Specialist gegevensuitwisseling Externe test/review beta-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 doorontwikkeling naar release candidate

Als er bij de externe test en review 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 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 op te leveren producten uit stap 5 en 11.

11

Ada

XSLT

Wiki

Kwalificatie.nictiz.nl

Conformancelab

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.
Dit is de laatste teststap voor definitieve publicatie, na definitieve publicatie volgt brede uitrol.

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
  • 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

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]

Template Functioneel ontwerp [Download]

Instructie opstellen Dataset

Testen

Template Teststrategie [Download]

Template Testplan [Download]

7 Release notes

In onderstaande tabel staan alle wijzigingen met betrekking tot Quality Assurance (QA) Proces X.