...
De stappen staan hieronder nader omschreven.
# | Stap | Omschrijving stap |
|---|---|---|
1 | Aanvragen wijziging | Een voorstel tot wijziging kan via de volgende routes kenbaar worden gemaakt:
|
2 | Bepalen impact | Mitz zorgt voor nadere specificatie van de wijzigingsverzoeken en legt ze vast in een Request for Change (RFC). Ook definieert Mitz een oplossing en brengt de impact in kaart. |
3 | Besluit wijziging door CAB | Vervolgens brengt het Mitz-productmanagement het wijzigingsvoorstel in een CAB in. Deze bestaat uit de Mitz-productmanager, de manager Operations en de Mitz-bedrijfsarchitect. Het CAB maakt de afweging of de wijziging wenselijk en verantwoord is. |
4 | Wijziging opnemen op releasekalender | RFC's worden - afhankelijk van de impact - uitgevoerd als fix of opgenomen in de releasekalender als onderdeel van een minor of major release. Deelnemers worden op tijd geïnformeerd en om feedback gevraagd over de changes in de volgende release en de impact op het gehele systeem. |
5 | Uitvoeren wijziging | Minor en major releases volgen een vast patroon conform de afgesproken releasekalender. Alle geïmplementeerde wijzigingen worden conform het testtraject van Mitz op de testomgeving getest, op de acceptatieomgeving geaccepteerd en bij goedkeuring van het CAB doorgevoerd op de productieomgeving. Een MC-leverancier heeft de verplichting om relevante wijzigingen te testen op hun testomgeving en te accepteren op de acceptatieomgeving. En om te participeren in de benodigde testen. Dit betreft een fix die de MC-leverancier raakt, een minor die de Mitz Connector raakt en alle major releases. De coördinatie van het doorvoeren van wijzigingen ligt bij de Servicedesk Mitz (zie Servicedesk Mitz | MC-leverancier). Zorgaanbieders zijn zelf verantwoordelijk voor de coördinatie en communicatie van wijzigingen met hun leveranciers (zoals US en XIS), het testen, accepteren en uitvoeren. Wijzigingen en releases worden bij niet-succesvolle testen, acceptaties en inproductienames niet doorgevoerd maar opnieuw ingepland. |
6 | Evalueren wijziging | Na het invoeren of uitstellen van een wijziging volgt een evaluatie. Hierbij wordt de wijziging geëvalueerd op alle aspecten zoals de impact, de coördinatie, het testen en de communicatie. En wordt input verzameld voor het eventueel bijstellen van de releasekalender. |
Releasemanagement
Wijzigingen in Mitz worden uitgerold in releases. Het change- en releasemanagementproces onderscheidt drie type wijzigingen, die in onderstaande tabel zijn weergegeven.
Categorie | Major change | Minor change | Fix |
|---|---|---|---|
Omschrijving | De verandering vereist een actie of aanpassing voor een groot deel van de MC-leveranciers, zorgaanbieders en/of burgers De koppelvlakken met Mitz moeten aangepast worden | De verandering vereist een actie of aanpassing voor een klein deel van de MC-leveranciers, zorgaanbieders en/of burgers Aanpassingen aan het toestemmingsregister en/of de toestemmingsapplicatie die geen impact hebben op de functionaliteit | Overige aanpassingen |
Releasenummering | Releaseverhoging Voorbeeld: release 3.x.x naar 4.0.0 | Versieverhoging Voorbeeld: versie 3.4.1 naar 3.5.0 | Subversieverhoging Voorbeeld: versie 3.4.1 naar 3.4.2 |
Mitz heeft compatibiliteit met de huidige en de vorige major release. Per jaar worden maximaal twee major releases uitgebracht.
...
Bij grote wijzigingen met grote impact en/of wijzigingen die de koppelvlakken en berichten raken, moet de MC-leverancier altijd een testtraject en heracceptatie uitvoeren. Zie /wiki/spaces/MA/pages/1056016493 Deelnemer | MC-leverancier.
Zorgaanbieder(systemen)
De zorgaanbieder is verantwoordelijk voor de eigen systemen (zoals US en XIS).
...