Releasekalender en changeproces

Releasekalender

Het DSP kent een jaarlijkse release voor het DSP berichtenverkeer. Het streven is om ieder jaar in mei een release te realiseren.

Op dit moment is de volgende planning voor DSP 2.0 vastgesteld:

DSP 2.0 release schema en het BRM release schema

Release historie

Mei 2023: DSP release 1.36
08-03-2022: DSP Analytics 2.9
14-02-2020: DSP API 1.13
29-11-2019: DSP API
26-11-2019: DSP Analytics 2.2
28-10-2019: DSP Analytics 2.1.1
25-10-2019: DSP Analytics 2.1
10-10-2019: DSP Analytics 2.0
25-09-2019: DSP Analytics 1.7
17-09-2019: DSP Analytics 1.6
29-08-2019: DSP Analytics 1.5 en Routering Samenwerkingsverband
25-07-2019: DSP Analytics 1.4
08-06-2019: DSP Analytics 1.3
20-05-2019: DSP Suite 2.0 & Releaseweekend deelnemers 1.34
18-04-2019: Release 1.34 en Analytics 1.0
29-01-2018: Release 1.33

Uiterlijk november in het voorgaande jaar wordt door het Dagelijks Bestuur van Mijnaansluiting de inhoud van de release vastgesteld.

Besluiten

Op de pagina Besluiten vind je een samenvatting van de belangrijkste besluiten die genomen zijn in de diverse DSP sessies.

Changeproces

• Nieuwe changeverzoeken worden geregistreerd op de DSP backlog in Jira bij Mijnaansluiting door de PO DSP. Deze changeverzoeken kunnen door iedereen worden ingediend. Vraag naar de PO voor een actueel overzicht van de DSP backlog.

Berichtenrelease

• Bij voldoende animo voor onderwerpen worden er data voor workshops vastgesteld om deze onderwerpen uit te werken.
• Alle deelnemers van het DSP Deelnemersoverleg krijgen de gelegenheid om aan te sluiten bij deze workshops.
• De resultaten van deze workshops (voorgestelde changes) worden uitgewerkt en ter review gedeeld met het DSP Deelnemers.
• De gereviewde changes worden uitgewerkt door het DSP ontwikkelteam.
• Aan het einde van de reeks workshops wordt een eindworkshop gepland waarin de voorgesteld scope van de release wordt vastgesteld.
• De scope van de release wordt vervolgens vastgesteld door het Dagelijks Bestuur van Mijnaansluiting. Het DB is ook het escalatiepad (voor PO en/of deelnemers) wanneer er bij changes te weinig draagvlak is bij alle deelnemers
• Uiterlijk 6 maanden voor een release wordt door het Dagelijks Bestuur van Mijnaansluiting de inhoud van de release vastgesteld.

Overige changes (bijvoorbeeld Analytics)

• De gereviewde changes worden uitgewerkt door het DSP ontwikkelteam.
• De uitgewerkte changes worden gepland in de 8-wekelijkse PI-planning.
• Indien gepland worden deze changes gerelealiseerd in de sprintplanning van het DSP team.

Releasetypes

Major

Een major release heeft technische en/of functionele impact op alle deelnemers, waarbij ook de noodzaak aanwezig is dat de deelnemers deze release implementeren om aangesloten te blijven op het DSP.

Hieronder vallen:

• Nieuwe velden toevoegen
• Verwijderen waarden
• Nieuwe berichten
• Nieuwe processtappen

Minor

Een minor release heeft technische en/of functionele impact op de deelnemers, maar is van dien aard dat deelnemers niet direct de aanpassingen dienen te implementeren om aangesloten te blijven op het DSP.

Hieronder vallen:

• Optionele nieuwe velden toevoegen
• Uitbreiden Waardenlijsten
• Optioneel maken van al aanwezige verplichte velden
• Nieuwe procestypen

Belangrijk om te weten:

• Indien deelnemers gewijzigde velden of waarde lijsten naar deelnemers sturen die nog niet de minor ingeladen hebben kunnen er problemen ontstaan. Dit zou kunnen bij de aflevering door DSP of bij de verdere verwerking aan de deelnemer kant.
• Het DSP valideert niet welke deelnemers de minor release in geladen hebben.
• De deelnemers die baat bij de release hebben, gaan samen met MA aan tafel zitten om tot een release datum te komen.
• In de xml berichten en de Business rules in de BRM is alleen de Major release terug te vinden (x.xx)