Changeproces en Roadmap DSP-A

Releasekalender DSP 3.0

Wijzigingen in de Business Rules net voor, of na het einde van de ketentestperiode (6-4-2026)? Neem contact op met de betrokken ketenpartners (aannemers) om gezamenlijk de impact en haalbaarheid te bepalen. Ook een ogenschijnlijk kleine wijziging kan veel impact hebben en hertesten noodzakelijk maken.

Releasemomenten Business Rules Manager (BRM)

De releasemoment voor de BRM zijn te vinden op: https://mijnaansluiting.atlassian.net/wiki/x/DoBsNQ

Changeproces

Wensen voor changes kunnen worden ingebracht bij de Product Owner (PO) DSP en worden opgenomen op het backlog bij Mijn Aansluiting.
Bij voldoende animo voor een onderwerp komt het op de roadmap om verder te gaan concretiseren. Doorgaans gebeurt dit middels workshops, waarin experts vanuit de deelnemers kunnen meedenken om te komen tot de gewenste specificatie-wijziging. De resultaten worden uitgewerkt en gedeeld met de DSP deelnemers. Per wijziging wordt bepaald of deze wordt doorgevoerd als uitbreiding op een actieve berichtversie, of wordt opgenomen in een nieuwe berichtversie.
De scope van de release van een nieuwe berichtversie wordt vastgesteld door het Dagelijks Bestuur (DB). Hier ligt ook het besluit om een nieuwe berichtversie door te voeren in het komende jaar, of de release uit te stellen vanwege een gebrek aan changes. Uiterlijk 6 maanden voor een release wordt de inhoud door het DB vastgesteld.
Changes die geen wijziging in de specificatie tot gevolg hebben (verbeteringen BRM/Beheerapp, nieuwe procesafspraken, etc) kunnen buiten de standaard releasecadans doorgevoerd worden, nadat de impact is getoetst bij de DSP deelnemers.

Roadmap

In dit onderdeel is te zien welke onderwerpen (mogelijke) doorontwikkelingen voor DSP aansluiting gaan worden. Mocht er een concrete planning zijn, staat dat in de tabel aangegeven.

Onderwerp	Status/planning

Onderwerp	Status/planning
Conversie-methodiek verbeteren Tot aan versie 3.0 is de gewoonte om bij een release alle oude-versie opdrachten te converteren middels een bijstellingsbericht met `bijstellingreden` “Conversie”. Deze methodiek kost de aannemers veel tijd, daarom wordt er gezocht naar een alternatief, waardoor converteren minder bewerkelijk wordt of niet meer nodig is.	Onderzoeken
BRM: Bijlagen bij TG en AGA kunnen aangeven Er is de wens om een manier te hebben om aan te geven welke bijlage(n) worden terugverwacht bij TG en AGA. Bij een TG kan dit bijvoorbeeld een foto van de meter zijn, de oude of de nieuwe meter, afhankelijk van het scenario. Op dit moment wordt dit middels procesafspraken geregeld, maar het zou helpen, ook bij de formulierinrichting als dit in de Business Rules Manager opgenomen kan worden.	Onderzoeken
Diepteligging in AGA / inmeetproces / Z-coördinaat. In de AGA worden op dit moment alleen horizontale coördinaten (X,Y) opgegeven. Voor een deel van de netbeheerders is het wenselijk om de diepteligging te registreren. Gebruikelijk is om dat te doen als Z-coördinaat, de diepte t.o.v. NAP.	Onderzoeken
Extra bericht: ‘verzoek vanuit Netbeheerder’ Nadat de netbeheerder de opdracht uitgezet heeft, kan de netbeheerder geen berichten meer sturen. Met dit bericht zou het voor de netbeheerder mogelijk zijn om de aannemer te verzoeken de opdracht bij te stellen. Zodat er een wijziging of annulering gedaan kan worden. Dit verzoek hoeft dan niet meer via mail/telefoon.	Onderzoeken
Productieregels in bijstelling t.b.v. meerwerk Een meerwerkmelding (bijstelling) wordt doorgaans gedaan door middel van een bijlage in een per netbeheerder uniek format. Door productieregels op te nemen in het bijstellingsformulier, kan het inlezen daarvan worden geüniformeerd en bij de netbeheerders geautomatiseerd.	Onderzoeken
Openbare verlichting via DSP Het plaatsen van openbare verlichting opnemen in de specificatie. Lichtmasten hebben unieke assetgegevens zoals lichtmastnummer en type armatuur.	Onderzoeken