Het maken van software bij het DSO-LV
Software voortbrenging DSO-LV
Deze notitie beschrijft de voortbrenging van software bij het DSO-LV in algemene zin.
Om de uitvoering van de Omgevingswet mogelijk te maken is het Digitaal Stelsel Omgevingswet (DSO) ontwikkeld. Dit stelsel bevat een centrale ‘kern’, de landelijke voorziening (DSO-LV) met daarop aangesloten de bevoegde gezagen, burgers en bedrijven. Het geheel noemen we het DSO, de landelijke voorziening het DSO-LV. Gezagen zijn aangesloten middels software van commerciële partijen, de software leveranciers of kortweg leveranciers. Deze leveranciers zijn er in een aantal smaken, voor plansoftware, voor Toepasbare regels en voor VTH software (Vergunning Toezicht en Handhaving) en andere partijen op basis van het ‘open stelsel’. Het DSO-LV is dus het gedeelte van het stelsel zonder de commerciële leveranciers. Het DSO-LV biedt naast de aansluitingen met leveranciers een aantal API’s (Advanced Programming Interfaces). Deze API’s kunnen gebruikt worden om zelf applicaties te maken die met het DSO-LV kunnen communiceren. Een aantal partijen doet dat en heeft voor eigen of commercieel gebruik handige toepassingen gemaakt. Het DSO-LV kan direct worden geraadpleegd middels een loketfunctie. Via het Loket kunnen burgers informatie over omgevingsplannen en regels opvragen en vergunningen aanvragen.
Veranderingen van de DSO-LV ontstaan vanuit het gebruik, omdat men dingen anders wil qua functionaliteit, of vanuit onderhoud, dingen kunnen beter of goedkoper. Daarnaast kunnen vanuit operationeel beheer ook wijzigingen worden aangedragen, zoals de bouw van gereedschap om beheer te kunnen doen en monitoring maar ook bevindingen op het gebied van security of performance. Het kan ook zijn dat men nieuwe toepassingen heeft bedacht of nieuwe dingen wil realiseren. Hoe dan ook, als er aanpassingen gedaan moeten worden moet daar werk voor verricht worden.
Het hele proces van deze aanpassingen, van idee tot en met de realisatie wordt beschreven in het portfolio- en funnelproces. In dit proces wordt onder andere vastgelegd hoe een idee of oplossing voor iets gerealiseerd kan worden, wat de uitgangspunten zijn, wat het kost, wie daar voor betaalt en welke waarde het levert (dat hoeft niet altijd geld te zijn). Hoe de financiënstroom precies loopt is beschreven in de P&C cyclus (planning en control). In het proces is ook vastgelegd hoe bepaald wordt wat het eerst gerealiseerd wordt en wat later. Met andere woorden wat het meeste prioriteit krijgt. Bij dit proces van vaststellen óf en wat er gedaan wordt zijn de koepels (rijk, UvW, IPO en VNG) intensief betrokken. Net als bij het vaststellen en goedkeuren van wat er is opgeleverd en of dat voldoet.
Voortbrenging DSO-LV
Het maken en aanbrengen van software aanpassingen noemen we de voortbrenging. Zoals gesteld is het proces uitvoerig beschreven en is het financieel getoetst door KPMG (P&C cyclus).
Het komt er op neer dat er een lijst wordt opgesteld met functionaliteiten (features) en werkzaamheden (non functionals) die allen op de één of ander manier ‘waarde’ leveren. Dat kunnen ook taken vanuit beheer zijn. Die lijst noemen we de backlog. De backlog is de bron van alle werkzaamheden voor de teams van het DSO-LV. De prioriteit van de zaken op de backlog volgt uit het portfolioproces en daarmee uit de bestuurlijke roadmaps en de noodzakelijkheid van de lifecycle van componenten, technieken en applicaties en wordt afgestemd met de vertegenwoordigers van de koepels. Er wordt steeds gewerkt met planningen van 12 weken. De zogenoemde Program Increments (PI’s). Een PI bestaat uit 6 ‘sprints’ van 2 weken. Aan het begin van een PI wordt er voor dit hele PI een planning gemaakt met daarin alle afhankelijkheden opgenomen en afgestemd. Afgestemd met elkaar en met de koepelvertegenwoordigers. Elke sprint wordt deze planning op voortgang en afhankelijkheden bekeken en waar nodig bijgesteld in de komende sprints. Dit zonder het doel van het PI uit het oog te verliezen. Tijdens deze sprintwissels laten de teams zien wat ze gemaakt hebben middels een demo) en review sessie (met zoveel mogelijk werkende software. Hierin wordt het opgeleverde besproken met de opdrachtgever/gebruiker en dit is ook het moment dat het opgeleverde beoordeeld en geaccepteerd wordt. We noemen dat ‘valideren’. Alles wat gepland was en niet gerealiseerd in een PI gaat terug naar de backlog om opnieuw ingepland te worden in een volgend PI.
Wil men invloed hebben op wat er in een PI gedaan gaat worden dan zal men voorafgaand aan dat PI de invloed moeten aanwenden bij het prioriteren van de features op de backlog. Voor de koepels loopt dat via de Business Liasion Managers (BLM). Zie verder het portfolio/funnel en backlog proces.
Acceptatie
Zodra een functionaliteit gereed is gekomen wordt deze gedemonstreerd tijdens een sprintdemo. Dit is het moment dat de acceptatie plaatsvind. De product manager en de BLM accepteren als gemandateerde voor het DSO-LV en de gezagen. Na goedkeuring wordt de vervaardigde software zo snel mogelijk naar productie uitgerold zodat er direct geprofiteerd kan worden van de waarde die geleverd wordt. Uitrollen van software naar productie gebeurt zoveel mogelijk door de OBO’s zelfstandig onder regie van TBO. Met name bij onderlinge afhankelijkheden en als afstemming nodig is. Dit verloopt via het releaseproces.
Testen
Natuurlijk moet de software aan een bepaalde kwaliteit voldoen. Om de kwaliteit te borgen en aan te tonen wordt er gedurende het realiseren in verschillende stadia getest. Dit wordt gedaan conform het testbeleid. Naast dat er getest wordt of alles blijft werken (regressietesten) en werkt zoals bedoeld worden er ook testen gedaan om aan te tonen dat de software aan bepaalde eisen voldoet (veiligheid, performance, robuustheid, programmacode etc). Of het ‘compliant’ is. Dit wordt gedaan met o.a. code reviews, penetratie testen en ISO norm toetsen (ISO25010). Deze testen worden deels uitgevoerd door externe onafhankelijke organisaties.
Binnen het DSO-LV wordt de software beheerd en gemaakt door de Operationeel Beheer Organisaties (OBO’s) onder regie van de tactisch Beheer Organisatie (TBO) voor de OBO overstijgende dingen. De OBO’s hebben een eigen verantwoordelijkheid bij het maken en beheren van onderdelen van het DSO-LV. Zij hebben elk hun eigen manier van voortbrengen waarbij zij voldoen aan de gestelde eisen. Zij voeren zelf de testen uit in hun eigen (test)omgevingen. Binnen het DSO-LV is een omgeving die representatief is voor de productieomgeving en waar de laatste stap van de vervaardiging is dat alle componenten in samenhang getest worden over de gehele keten van interacties en samenwerkingen. De zogenaamde ketentesten. Als de software van voldoende kwalitatief niveau bevonden wordt , wordt de software uitgerold (gedeployed) naar de productie en externe test omgevingen. Externe test omgevingen zijn omgevingen die qua software versies gelijk zijn aan productie en die een bepaald doel hebben zoals oefenen met content, testen van aansluitingen door leveranciers, geven van demo’s.
Maken, testen en uitrollen van software gebeurt continue elke sprint (elke twee weken) voor één of meerdere componenten. Mochten er bevindingen zijn in één van de omgevingen dan worden deze vastgelegd en gezien als productieverstoringen. Het verhelpen hiervan komt als werk op de backlog met de hoogste prioriteit voor de bevindingen uit de productieomgeving.
Voortbrenging DSO
Decentraal, buiten de DSO-LV wordt het DSO gevormd door software, systemen en infrastructuur van de leveranciers (plansoftware, VTH en ‘derden’ Open stelsel ) en gezagen. Binnen het DSO wordt daarnaast gebruik gemaakt van bepaalde generieke (overheids)diensten zoals oa DigiD, eHerkenning etc. Dit geheel kan niet centraal vanuit de DSO-LV gestuurd worden simpelweg omdat deze partijen zich buiten de invloed van de DSO-LV bevinden. Het zijn immers veelal commerciële partijen met verschillende belangen en onderlinge concurrentie. De gezagen en andere partijen zullen zelf de verantwoordelijkheid moeten nemen, al dan niet in gezamenlijkheid, om te zorgen dat de leveranciers die zij selecteren en de pakketten die zij gebruiken voldoen aan hun eisen en aansluiten bij hun werkwijze. De DSO-LV zorgt voor een kwalitatief goede centrale voorziening met aansluitpunten waarop aangesloten kan worden om informatie te leveren of op te halen. Deze aansluitpunten noemen we koppelvlakken.
De informatie die via de koppelvlakken wordt uitgewisseld is volgens bepaalde afspraken opgebouwd. Die afspraken noemen we standaarden. Als er wijzigingen nodig zijn in die standaarden dan wijzigt er meestal ook iets aan de koppelvlakken. In deze gevallen zal de DSO-LV bij de ontwikkeling samen optrekken met, in elk geval, een aantal partijen dat gebruik maakt van die koppelvlakken en de mogelijkheid geven de informatie uitwisseling eerst te testen in een externe testomgeving alvorens dit in productie wordt geïmplementeerd. Conform het DSO-LV testbeleid.
Om er zorg voor te dragen dat partijen informatie op een goede manier kunnen uitwisselen zal het DSO-LV zogenaamde conformiteitstoetsen ontwikkelen. De toetsen dienen er zorg voor te dragen dat partijen informatie kunnen ophalen en overdragen aan het DSO-LV op een manier die voldoet aan de standaard en zodanig dat de systemen van het DSO-LV ermee kunnen omgaan. Met deze toetsen wordt dan aangetoond dat een partij kan voldoen aan de normen en op een goede manier inhoud aan het stelsel kan leveren of afnemen. De toetsen zullen, indien mogelijk, geautomatiseerd gedaan worden met speciaal daarvoor ontwikkelde inhoud (content) zodat de beheerinspanning minimaal is.
Acceptatie van software over de DSO keten
Bij middelgrote en grote wijzigingen van de voornaamste koppelvlakken, gebaseerd op de standaarden STOP (TPOD) en bv STTR, bestaat het idee om samen met één of meerder leveranciers de ontwikkeling te doen binnen de kaders van deze aangepaste standaarden. Op deze wijze ontstaat een richtlijn om de vernieuwde standaard toe te passen en te implementeren. Deze richtlijn wordt dan op zichzelf een soort standaard. Een implementatie standaard (Implementation candidate).
Met het software (SW) leveranciers veld wordt dan afgesproken dat de niet in de ontwikkeling participeerde SW leveranciers deze implementatie standaard volgen (als uitgangspunt nemen voor hun ontwikkeling). Hierdoor kan het aantal varianten van informatieoverdracht met de DSO-LV worden beperkt en daarmee de ontwikkel- en beheerkosten.
In dit proces kan ook een (vanuit de koepels formele) acceptatie worden georganiseerd, die in enige mate lijkt op de werkwijze die werd gevolgd bij het doen van de indringende keten testen (IKT). Verdere uitwerking hiervan zal met koepels en leveranciers gedaan dienen te worden.