...

Probleem

We kunnen binnen het afsprakenstelsel onvoldoende snel inspringen op de veranderende vraag uit de praktijk, doordat:

...

In de huidige situatie vindt twee keer per jaar een nieuwe release plaats

...

er gezamenlijk voor zorgen dat wij een anderhalf jaar tot een jaar van tevoren al vastleggen wat er gewijzigd gaat worden.

Ten gevolge hiervan treden verschillende kleinere problemen op namelijk:

...

, namelijk op 30 oktober en 30 april. Zijn de onderwerpen niet volledig uitgewerkt voor het eerst volgende release moment, dan kunnen de onderwerpen pas een halfjaar later gepubliceerd worden en pas een jaar later verplicht gesteld. Nu bepaalt het release moment dus de ontwikkel planning, en dit werkt niet ideaal aangezien de onderstaande problemen optreden:

1. Vaste releasemomenten, waarin zoveel mogelijk onderwerpen doorgevoerd moeten worden.
2. Kleine correcties op het afsprakenstelsel worden zonder ophoging van het versienummer doorgevoerd, ook minors en majors worden niet op de voorgeschreven manier toegepast.
3. Als er geen onderwerpen zijn om te releasen dan kunnen we alleen óf de optionele versie verplicht maken en geen wijzigingen doorvoeren voor de nieuwe optionele versie óf de release kan worden uitgesteld.
4. Vaste releasemomenten, waarin zoveel mogelijk onderwerpen doorgevoerd moeten worden.
5. Zijn de geplande onderwerpen niet volledig uitgewerkt voor het eerst volgende release moment, dan kunnen de onderwerpen pas een halfjaar later gepubliceerd worden en pas een jaar later verplicht gesteld, dit is onwenselijk omdat:
   a.  het voor bepaalde onderwerpen belangrijk is om deze op korte termijn op te nemen in het afsprakenstelsel. Als deze onderwerpen dus niet tijdens het geplande releasemoment gepubliceerd worden dan betekent dat een vertraging van minimaal een halfjaar.
   b. het de betrouwbaarheid van MedMij richting de deelnemers kan ondermijnen. Als wij beloven bepaalde stukken op te nemen in de optionele versie van het afsprakenstelsel en vervolgens leveren wij dit niet op dan kan dat de relatie van MedMij met de deelnemers schaden.
6. Deelnemers geven aan dat de termijn van een halfjaar tussen het opnemen in de optionele en het opnemen in de verplichte versie te kort is om impactvolle wijzigingen in het afsprakenstelsel door te voeren. 

Probleemstelling

Met huidige de vorm van release cycle management kunnen we onvoldoende inspringen op de veranderende vraag uit het dynamische Zorg ICT landschap en de wijzigingen binnen de MedMij zelf.

Doel:

...

1. Bij versiewijzigingen moet veel administratief werk verricht worden omdat er een volledige koppeling is met de code van de R&A en de in de R&A vastgelegde endpoints.

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.

Doordat we 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.

Doel:

We willen meer flexibiliteit introduceren bij het releasen van minors en patches en meer rekening houden met de implementatietijd van stakeholders voor majors.

Subdoelen

• Deelnemers en MedMij medewerkers meer gestructureerd meenemen in de analyses en uitwerkingen van onderwerpen.
• Pas de opname in het afsprakenstelsel plannen als het onderwerp al is uitgewerkt en daarmee de betrouwbaarheid richting deelnemers verhogen.

Definities

...

Kleine wijzigingen die geen invloed hebben op de functionaliteit en wel backwardscompatible zijn.

...

Wijzigingen die wel invloed hebben op de functionaliteit en die wel backwardscompatible zijn. De impact van een minor kan dusdanig groot zijn dat besloten wordt deze als major te behandelen. In de voorbespreking wordt bepaald of dit het geval is.

...

Wijzigingen die wel invloed hebben op de 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.

...

Het (twee-)maandelijks moment waarop de uitgewerkte onderwerpen gepubliceerd worden op de pre-release omgeving, hier kunnen de externe stakeholders zien welke stukken zijn uitgewerkt waarvoor of bepaald kan worden wanneer deze worden opgenomen in het afsprakenstelsel of wanneer deze al op planning staat om te worden opgenomen in het afspraken stelsel.

...

Aannames

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

• Op de verplichte stelselversiepublicatie kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.

Gewenste situatie

We willen meer releasemomenten per jaar mogelijk maken om zo deelnemers voor majors.
Daarnaast willen we de deelnemers meer gestructureerd meenemen in de analyses en uitwerkingen van onderwerpen.

Aannames

• 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 kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.
• kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.

4.1. 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. De impact van een minor kan dusdanig groot zijn dat besloten wordt deze als major te behandelen. In de voorbespreking wordt bepaald of dit het geval is.
• Majors: Wijzigingen die wel invloed hebben op de 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.

Gewenste situatie

Door meer releasemomenten per jaar mogelijk te maken willen we de flexibiliteit omtrent de releases van minors en patches verhogen. Wij stellen voor om op regelmatige basis een stakeholder overleg in te plannen waar stakeholders inspraak hebben over de planning voor uitwerkingen van onderwerpen en de planning van releases. 

Het proces zou als volgt in zijn werk gaan, wanneer een onderwerp is afgerond dan wordt binnen MedMij bepaald wat de impact van dit onderwerp is en op wat voor termijn volgens ons het onderwerp gereleased moet worden. Vervolgens wordt de uitwerking van het onderwerp gepubliceerd als een pre-release stuk. Stakeholders kunnen deze stukken lezen en bepalen of ze willen aansluiten bij het stakeholder overleg.

...

• Patch is het verplichtstellingsmoment moment meteen tegelijkertijd met de pre-release.
• Minor wordt tijdens de voorbespreking en het stakeholderoverleg besproken op welke termijn deze minor verplicht moet wordt. Stel we kiezen het eerst volgende verplichtingsmoment, dan zou het onderwerp een maand later tegelijkertijd met de pre-release verplicht gesteld worden. De minor dient in principe binnen twee verplichtstellingsmomenten verplicht gesteld worden, in samenspraak met stakeholders  kan hiervan worden afgeweken.
• Major wordt in de voorbespreking, het stakeholderoverleg en het deelnemersoverleg besproken tijdens welk verplichtstellingsmoment de major verplicht wordt gesteld. Stakeholders en deelnemers mogen niet oneindig majors uitstellen. In principe worden majors verplicht gesteld tijdens de verplichtstellingsmomenten, hiervan kan worden afgeweken mits er een gedegen reden hiervoor is (bijv. i.v.m. security redenen of een wijziging in wetgeving) of als minimaal 70% van alle aanwezige stakeholders en deelnemers hiermee instemt.

...