...

Twee keer per jaar (op 30 april en 30 oktober) vindt een release voor afsprakenstelsel van MedMij plaats, hier . In de huidige situatie wordt gewerkt met het dakpanmodel. Het dakpanmodel houdt in dat op het releasemoment altijd twee releases van het afsprakenstelsel worden gepubliceerd, namelijk één optionele en één verplichte versie. Bij het volgende release moment wordt:

...

Op dit moment zijn dat de versies 1.5.1 en 1.6.0, waarbij versie 1.5.1 verplicht is voor alle deelnemers verplicht is en 1.6.0. de optionele versie is.

Voorafgaand aan het release moment wordt bepaald welke onderwerpen in de volgende release moeten worden verwerkt. 

...

Bovenstaande problemen kunnen niet los van elkaar worden opgepakt, omdat de oplossing voor het eerste probleem en de uitwerking van versioning impact hebben op het tweede probleem.

Probleemstelling

Doordat we foutief gebruik van oplopende versienummers combineren met twee gepubliceerde versies van het afsprakenstelsel, kunnen wij major en minor wijzigingen niet zomaar doorvoeren.

Definities

...

nu anderhalf jaar van tevoren bepalen wat er gereleased wordt kunnen we onvoldoende inspringen op de veranderende vraag uit het dynamische zorg ICT landschap en de wijzigingen binnen de VZVZ zelf.

Probleemstelling

Met de huidige release cycle kunnen we niet dynamisch inspringen op de veranderende vragen vanuit de praktijk.

De huidige methode van versienummering sluit niet aan bij de major-, minor- en patch nummering waardoor de traceability van wijzigingen moeilijk te herleiden is

Doordat we foutief gebruik van oplopende versienummers combineren met twee gepubliceerde versies van het afsprakenstelsel, kunnen wij major en minor wijzigingen niet zomaar doorvoeren.

Definities

• Patches: Kleine wijzigingen die geen invloed hebben op de functionaliteit en wel backwardscompatible zijn.
• Minors: Wijzigingen die wel invloed hebben op de functionaliteit en die wel backwardscompatible zijn.
• Majors: Wijzigingen die wel invloed hebben op de functionaliteit en die niet backwards compatible zijn.functionaliteit en die niet backwards compatible zijn. Een major kan ook wel backwards compatible zijn, maar dat de impact van deze wijziging dusdanig groot is dat deze als major behandeld wordt. In de voorbespreking wordt bepaald of een wijziging als major geclassificeerd wordt.

Doel:

We willen meer flexibiliteit introduceren bij het releasen van minors en patches en meer rekening houden met de implementatietijd van deelnemers voor majors.
Daarnaast willen we de deelnemers meer gestructureerd meenemen in de analyses en uitwerkingen van onderwerpen.

...

• De gekozen nieuwe release cycle wordt ondersteunt door de (nieuwe manier van) versioning die nu wordt uitgewerkt.

• Op de verplichte stelselversie publicatie worden geen major aanpassingen doorgevoerd tenzij... (bijvoorbeeld o.b.v. security, regelgeving of major bug-fix)Op de verplichte stelselversiepublicatie wordt een minimum aan minor aanpassingen met functionele impact doorgevoerd. De scope van de verplichte functionaliteit blijft zover mogelijk gelijk (geeft wel de optie om bv extensie aan te passen)... (bijvoorbeeld o.b.v. security, regelgeving of major bug-fix)
• Op de verplichte stelselversiepublicatie kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.

...

Ter verduidelijking, het feit dat pre-release momenten en verplichtstellingsmomenten beschikbaar zijn betekend betekent niet vanzelfsprekend dat deze ook gebruikt moeten worden.
Als er niets te publiceren is of er binnen het stakeholderoverleg wordt bepaald dat we bij het volgende verplichtstellingsmoment geen onderwerpen verplicht willen stellen dan hoeft dit ook niet.

...

Voor de verschillende oplossingsrichtingen hebben we bepaalde onderdelen gevarieerd. Deze onderdelen zijn:

...

...

...

...

...

...

...

...

...

...

...

Oplossingsrichting 1

Het verplichtingsmoment wordt bepaald in overleg met stakeholders, wel moet deze eens per seizoen plaatsvinden.

...