...
- uniform woordgebruik
- controleren overeenkomen tabellen en afbeeldingen
- zins- en taalgebruik
Inleiding
Probleem:
Op dit in moment vind twee keer per jaar een release plaats, namelijk in week 18 en 44. In de huidige situatie moeten onderwerpen uitgewerkt zijn voor het release moment anders kunnen de onderwerpen pas een halfjaar later gepubliceerd worden en pas een jaar later verplicht gesteld.
Het release moment bepaalt dus de ontwikkel planning, en dit werkt niet ideaal aangezien de onderstaande problemen optreden:
- Vaste releasemomenten, waarin zoveel mogelijk onderwerpen doorgevoerd moeten worden.
- Kleine correcties op het afsprakenstelsel worden zonder ophoging van het versienummer doorgevoerd, minors en majors worden niet op de voorgeschreven manier toegepast.
- 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.
- 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.
Koppelingen
Wijzigingsverzoek
Gekoppelde onderwerpen
Huidige situatie:
In de huidige situatie wordt twee keer per jaar een release uitgebracht. Deze staan gepland op 30 april en 30 oktober. Vooraf wordt bepaald welke onderwerpen in de volgende release moeten worden verwerkt. Hierbij hebben we te maken met het dakpanmodel, waarbij altijd twee releases van het afsprakenstelsel zijn gepubliceerd één optionele en één verplichte versie. Op dit moment zijn dat de versies 1.5.1 en 1.6.0, waarbij versie 1.5.1. verplicht is voor alle deelnemers en 1.6.0. optioneel. Bij het volgende release moment wordt de verplichte versie ingetrokken, de optionele release wordt verplicht en de nieuwe optionele versie wordt gepubliceerd.
...
Koppelingen
Wijzigingsverzoek
Gekoppelde onderwerpen
- MO-6, Versionering van het afsprakenstelsel
- MO-17, Change Request, Aanpassing stelsel versienummer op basis van hybride epoch label plus SemVer
Inleiding
Huidige situatie:
Twee keer per jaar (op 30 april en 30 oktober) vindt een release voor afsprakenstelsel van MedMij plaats, hier 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:
- de verplichte versie ingetrokken,
- de optionele release wordt verplicht en
- de nieuwe optionele versie wordt gepubliceerd.
Op dit moment zijn dat de versies 1.5.1 en 1.6.0 , waarbij versie 1.5.1 verplicht is voor alle deelnemers en 1.6.0. de optionele versie.
Voorafgaand aan het release moment wordt bepaald welke onderwerpen in de volgende release moeten worden verwerkt.
| Inc drawio | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Probleem:
In de huidige situatie vindt twee keer per jaar een nieuwe release plaats, 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:
- Vaste releasemomenten, waarin zoveel mogelijk onderwerpen doorgevoerd moeten worden.
- Kleine correcties op het afsprakenstelsel worden zonder ophoging van het versienummer doorgevoerd, ook minors en majors worden niet op de voorgeschreven manier toegepast.
- 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.
- 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.
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.
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).
- Op de verplichte stelselversiepublicatie kunnen patches met procedurele en tekst aanpassingen worden doorgevoerd. De scope van de functionaliteit blijft gelijk.
Voorbehoud
Indien het noodzakelijk is om vanwege een gedegen reden op korte termijn af te wijken van het release schema dan kan worden afgeweken van het release- en verplichtstellingsschema.
Oplossingsrichtingen
...
Oplossingsrichtingen
Door meer releasemomenten per jaar mogelijk te maken willen we de flexibiliteit omtrent de releases van minors en patches te verhogen willen we meer releasemomenten per jaar mogelijk maken. Wij stellen voor om op regelmatige basis een stakeholder overleg in te plannen waar stakeholders inspraak hebben over de planning voor releases uitwerkingen van onderwerpen en de planning van releases.
Het proces zou als volgt in zijn werk gaan, zijn als onderwerpen zijn 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. Bij dit overleg zijn de product owner, de medewerker die het onderwerp heeft uitgewerkt en de verschillende stakeholders aanwezig.
...