VERA 3.0. Verkenning - Release- en Versiebeleid. Versie: 3.0 Datum: Status: Definitief

Transcriptie

1 VERA 3.0 Versiebeleid Versie: 3.0 Datum: Status: Definitief Stichting VERA Veenendaal

2 Inhoudsopgave 1 Inleiding Doel van het document Uitgangspunten Opmerkingen richting VERA Stuurgroep VERA Beheer en Onderhoud op hoofdlijnen VERA Belanghebbenden Releasebeleid Versiebeleid... 9 Bijlage A Beheer-, onderhouds- en vernieuwingsprocessen A.1 Procesoverview Bijlage B Informatievoorziening rondom VERA Bijlage C Versienummering VERA onderdelen Bijlage D Begrippen en afkortingen Versiebeheer Versie Datum Toelichting Creatie Versiebeleid 2

3 1 Inleiding VERA zorgt voor uniforme gegevensuitwisseling tussen ICT-systemen door implementeerbare gegevensdefinities beschikbaar te stellen en is hiermee de technische vertaalslag van CORA (COrporatie Referentie Architectuur). VERA versie 2.0 is vanaf 26 september 2013 (Corporatieplein 2013) beschikbaar. VERA versie 3.0 is in 2014 gepubliceerd, en het release- en versiebeleid (dit document) is een verkenning bij deze release. De verwachting is dat het aantal woningcorporaties en ICT-leveranciers dat zich conformeert aan de VERA standaard zal groeien. Daarom is het noodzakelijk dat het beheer en onderhoud voor alle belanghebbenden inzichtelijk en transparant is, duidelijk belegd is en de doorontwikkeling releasematig plaatsvindt. Dit document geeft hier invulling aan en beschrijft een verkenning van het release- en versiebeleid van VERA. In dit document komen de volgende onderwerpen aan bod: scope van het beheer, de te beheren objecten van VERA; releasebeleid; versiebeleid; organisatie, participatievormen, processen voor het beheer en onderhoud; informatievoorziening t.b.v. belanghebbenden inclusief communicatie en publicatie. Voor het opstellen van dit document is gebruik gemaakt van het standaard ASL raamwerk. Dit raamwerk is geselecteerd op basis van good practices van vergelijkbare standaardisatiecomités en in het bijzonder StUF. 1.1 Doel van het document Dit document beschrijft (onderdelen van) het beheermodel van VERA. Het geeft alle belanghebbenden inzicht in het release- en versiebeleid, in de wijze waarop het beheer van VERA is belegd, hoe het proces van wijzigen en releaseplanning van de VERA standaard eruit ziet en hoe de besluitvorming en participatie is georganiseerd. Daarnaast komen aanvullende onderwerpen aan de orde zoals versienummering en publicatie van en informatievoorziening rond VERA. Door dit inzicht kunnen de belanghebbenden beter rekening houden met - en aansluiten op - de VERA standaard. Voor sommige direct belanghebbenden, zoals ICT-leveranciers, is dit beheermodel van belang voor hun productmanagement en de planning van ontwikkeling en onderhoud van hun softwareproducten. Woningcorporaties en ketenpartijen die VERA gebruiken zullen, ieder op hun eigen manier, rekening moeten houden met het beheermodel. Zij moeten immers als opdrachtgever hun ICT-leveranciers aansturen. In Hoofdstuk 2 is het beheer op hoofdlijnen beschreven. Daarin komen aan de orde: de afbakening van het beheer; de verschillende belanghebbenden; de structuur van participatie en ondersteuning en het releasebeleid. In Bijlage A zijn de beheer- en onderhoudsprocessen beschreven, in Bijlage B de informatievoorziening rond de VERA standaard, Bijlage C licht de versienummering toe en in Bijlage D wordt het gehanteerde begrippenkader toegelicht. Versiebeleid 3

4 1.2 Uitgangspunten Dit document is opgesteld met als uitgangspunt de veronderstelde werkwijze rond de vrijgave van VERA 3.0. De schrijvers zijn bekend met discussies binnen de VERA Stuurgroep over de wijze waarop de volgende release en de bijbehorende releaseplanning kunnen worden opgesteld. Vanwege het projectmatige karakter van het releasebeleid van VERA worden deze nieuwe inzichten niet in deze release van het release- en versiebeleid verwerkt, zonder een formele vaststelling van een wijziging. 1.3 Opmerkingen richting VERA Stuurgroep In dit document komt een aantal adviezen terug, vooral voor de inrichting van de beheerprocessen, die momenteel nog niet zijn ingevuld. Wij geven de stuurgroep het advies mee om dit wel ter hand te nemen. De adviezen zijn (vooral) gebaseerd op good practices, en veel van de adviezen zijn gelijkvormig met de inrichting bij StUF. Versiebeleid 4

5 2 VERA Beheer en Onderhoud op hoofdlijnen 2.1 VERA VERA richt zich op gegevensuitwisseling in processen en voor procesinformatie. Om deze gegevensuitwisseling te standaardiseren en mogelijk te maken is VERA opgebouwd uit een aantal verschillende (inhoudelijke) onderdelen. Onderstaande figuur schetst deze onderdelen op typeniveau. CORA Koppelvlak Koppelvlak Koppelvlak Koppelvlak methodiek Gegevensmodel Gegevensmodel Gegevensmodel Kengetal methodiek Kengetal Kengetal Kengetal Fysieke schema s Servicecontracten StUF Figuur 1 VERA onderdelen Deze set aan onderdelen biedt corporaties en software leveranciers een standaard set hulpmiddelen bij het opzetten van koppelingen tussen (ICT) systemen zowel binnen als buiten het corporatielandschap. In VERA 3.0 zijn de volgende onderdeeltypes (ook wel configuration item types genoemd in de context van het beheerproces configuratiebeheer) concreet aanwezig: Koppelvlak: WSDL s die de koppelvlakken beschrijven en XSD s die overeenkomen met de gegevensdefinities uit het gegevensmodel. Gegevensmodel: Documenten die de gegevensdefinities en code- en waardelijsten bevatten. Kengetal: Documenten die beschrijven op welke wijze kengetallen kunnen worden afgeleid in termen van gegevens uit het gegevensmodel aangevuld met (bedrijfs)regels om deze afleiding te doen. Ontbrekend in de figuur zijn de documenten die de context beschrijven en de (interne) processen om VERA te ontwikkelen en in stand te houden, zoals dit document. Ook deze onderdelen zijn Configuratie Items (CI s) die onderhevig zijn aan het release- en versiebeleid van VERA. 2.2 Belanghebbenden Verschillende partijen hebben direct dan wel indirect belang bij de ontwikkeling, de implementatie en het gebruik van de onderdelen uit VERA. Dit geldt dus ook voor het beheer en onderhoud ervan. In de hierna volgende figuur zijn de belanghebbenden aangegeven. Versiebeleid 5

6 Figuur 2 Belangen en belanghebbenden van VERA De VERA standaard wordt in stand gehouden en doorontwikkeld door participatie van de belanghebbenden. Ruwweg zijn drie rollen te onderkennen, de vraagkant, de aanbodkant en de ondersteuningskant. De vraagkant bestaat uit organisaties die behoefte hebben aan informatie-uitwisseling en daarvoor VERA koppelingen en kengetallen gebruiken voor de eigen informatievoorziening. Logischerwijs zijn dit vooral de woningcorporaties en andere vastgoedbeheerorganisaties, aangevuld met ketenpartijen die VERA koppelingen willen gebruiken. De aanbodkant bestaat uit ICT-leveranciers die VERA koppelingen inbouwen in software. De ondersteuningskant bestaat uit de beheerders van één of meerdere VERA onderdelen. Afhankelijk van eigen doelstellingen, verantwoordelijkheden en belangen zullen belanghebbenden op een andere wijze participeren. 2.3 Releasebeleid Onder releasebeleid wordt in dit document verstaan: Het (beheer)proces dat zorg draagt voor een gecontroleerde, beheersbare en voorspelbare release van een verzameling configuratie items in een gedefinieerde versie richting belanghebbenden. De voornaamste te beheren VERA onderdelen, zoals genoemd in paragraaf 2.1, zullen gezamenlijk en afzonderlijk onderhevig zijn aan doorontwikkeling, beheer en onderhoud. Versiebeleid 6

7 Het releasebeleid dat gehanteerd wordt voor aanpassingen van deze VERA onderdelen is als volgt: Participatie 1 Uitbreidingen en aanpassingen in de te beheren VERA onderdelen (zie paragraaf 2.1) komen tot stand door actieve participatie van de verschillende belanghebbenden. 2 Belanghebbenden kunnen op verschillende manieren participeren, zoals in de rollen van: reviewer, stuurgroeplid, adviseur of sparringpartner of anders. De wijze van participatie staat beschreven in de statuten van VERA.. Nieuwe releases 3 Wijzigingsaanvragen kunnen door belanghebbenden worden ingediend bij Beheer, Onderhoud en Doorontwikkeling VERA (ook wel Stichting VERA). Daarbij wordt onderscheid gemaakt tussen technische en semantische wijzigingen. 4 De VERA Werkgroepen zijn verantwoordelijk voor de beoordeling van ingediende wijzigingsaanvragen, uitwerken ervan in RFC s en de inhoudelijke (door)ontwikkeling van de te beheren VERA onderdelen. 5 De VERA Stuurgroep beoordeelt de door de VERA Werkgroepen geselecteerde en uitgewerkte RFC s; de VERA Stuurgroep maakt de keuze voor de inhoud van een release. 6 De VERA Stuurgroep beoordeelt de releasevoorstellen en stelt het beleid en de lifecycleplanning van nieuwe versies van VERA-onderdelen vast in het releaseplanningsproces. 7 Bij het vaststellen van de inhoud van een nieuwe versie van (een onderdeel van) VERA wordt gestreefd naar consensus in de VERA Werkgroepen. Als consensus uitblijft zal de VERA Stuurgroep de inhoud van een nieuwe versie vaststellen. 8 Maximaal kunnen twee (opéénvolgende) versies van een VERA onderdeel gelijktijdig de status In Gebruik hebben. Het releasemoment van een nieuwe release wordt minimaal 6 maanden vooraf bekendgemaakt. 9 Maximaal krijgt één versie van een VERA onderdeel het advies VERA Aanbeveling. Dit is altijd de laatst vastgestelde versie van de standaard met de status In gebruik. 10 Op dit moment hebben alle VERA onderdelen één releasetermijn; dit wil zeggen dat met een vaste heartbeat (regelmaat) een versie van VERA wordt gereleased en dat alle VERA onderdelen met deze heartbeat meelopen. Er wordt (nog) geen rekening gehouden met de individuele veranderlijkheid van de verschillende VERA onderdelen. 11 In bijzondere gevallen kan van de releasetermijn worden afgeweken, maar steeds met een besluit van de VERA Stuurgroep. 12 Omdat de berichtentiteiten (de kernschema's) de basis vormen voor alle functionaliteit in VERA mogen ze niet onaangekondigd wijzigen binnen één versie van VERA. Uiteraard mogen fouten in deze schema's wel conform de errata-procedure worden verbeterd. Functionele wijzigingen worden slechts beperkt toegestaan binnen een major release van VERA. Zie ook paragraaf 2.4 voor een duiding van het versiebeleid. 13 Een release wordt gedefinieerd als de verzameling van configuration items met bijbehorende versienummers (zie paragraaf 2.1 voor de in VERA onderkende configuration item types). 14 Een release krijgt een releasenummer zodat naar elke unieke release verwezen kan worden. 15 Uit het releasenummer is de mate van wijziging en/of impact af te leiden en daarmee ook de mate waarin de in de release opgenomen C.I. s zijn gewijzigd t.o.v. de vorige release. Versiebeleid 7

8 16 In de koppelvlakken wordt de beschrijving van stabiele (data-georiënteerde) horizontale modellen en vaker veranderende (proces-georiënteerde) verticale modellen gehanteerd. In de toekomst is het verstandig om deze als losse CI s te identificeren en potentieel ook in losse releaseplanningen onder te brengen. Aansluiting op andere standaarden VERA sluit aan op onderstaande standaarden. De aansluiting vindt plaats binnen de vastgestelde releasetermijnen van de VERA onderdelen. 17 VERA volgt de ontwikkeling van internationale standaarden (zoals W3C) in het algemeen en die voor XML, CORA en StUF in het bijzonder. Publicatie 18 De VERA Werkgroepen zullen na besluitvorming in de VERA Stuurgroep de lifecycleplanning en de specificaties van de betreffende VERA onderdelen publiceren. 19 In de publicatie wordt per VERA onderdeel onderscheid gemaakt in vijf statussen van ontwikkeling. De te onderscheiden statussen zijn: Status VERA Status van een VERA Beschrijving van de status onderdeel IV In Verkenning Een (nieuwe versie van een) VERA onderdeel is In Verkenning als de specificaties al wel met de buitenwereld zijn gedeeld (en eventueel de specificaties al zijn gerealiseerd), maar nog niet formeel is vastgesteld dat (deze versie van) het VERA onderdeel ook a) gereleased zal worden en b) gegarandeerd wordt dat releasegaranties met betrekking tot versioneren en backward compatibility van toepassing zijn. IO In Ontwikkeling Een (nieuwe versie van een) VERA onderdeel is In Ontwikkeling wanneer er met medeweten en medewerking van de stuurgroep VERA aan gewerkt wordt en wanneer dit onderdeel of deze versie nog niet voor de buitenwereld is gepubliceerd. IG In Gebruik Wanneer een (nieuwe versie van een) VERA onderdeel gereed is, stelt de VERA Stuurgroep de status In Gebruik vast en wordt een VERA onderdeel opgenomen in een VERA release. Door deze vaststelling worden gebruikers en ICT-leveranciers opgeroepen deze nieuwe versie op te nemen in software en in gebruik te nemen. EO Einde Ondersteuning Het VERA onderdeel met de status Einde ondersteuning wordt niet meer ondersteund door de VERA beheerder. De kennis en informatie voor vragen en support is bij de beheerder niet langer beschikbaar. TG Teruggetrokken Een VERA onderdeel krijgt de status Teruggetrokken indien een versie van een VERA onderdeel niet bruikbaar blijkt (bijvoorbeeld vanwege implementatieproblemen). Versiebeleid 8

9 Implementatie en gebruik 20 Leveranciers geven zo spoedig mogelijk na vaststelling van een nieuwe versie van een VERA onderdeel aan wanneer, in welke softwareproducten en in welke softwareversie de nieuwe VERA versie zal worden ingebouwd. Leveranciers verstrekken hun productinformatie (o.a. planning en configuratie) binnen drie maanden na de releasedatum van een VERA release. De verstrekte gegevens worden door de beheerder van de VERA standaard gepubliceerd. 21 Leveranciers geven in hun productinformatie aan welke versies van VERA (sub)onderdelen worden ondersteund. 22 Leveranciers en gebruikers wordt geadviseerd de meeste recente versie met de Status In Gebruik zo spoedig mogelijk in software te implementeren respectievelijk deze voor te schrijven. 23 De keuze voor een VERA configuratie is een verantwoordelijkheid van de gebruiker. 24 Om migraties te vereenvoudigen wordt gebruikers geadviseerd om in hun programma s van eisen op te nemen dat applicaties, die gericht zijn op integratie, ten minste twee opeenvolgende VERA configuraties gelijktijdig moeten ondersteunen. Het betreft hierbij applicaties zoals middleware, brokers, service bus en distributiesystemen. 25 Gebruikers of leveranciers die extra elementen aan VERA willen toevoegen, melden dit aan de VERA Stuurgroep. Overige principes 26 Aanpassingen aan VERA voldoen aan de door het Forum Standaardisatie vastgestelde criteria van een open standaard. Zie criteria voor de selectie van standaarden op De twee belangrijkste zijn bovenvermelde punten 23 en Er zijn geen toetredingscriteria van toepassing om te participeren in de ontwikkeling van VERA. 28 Over VERA onderdelen inclusief specificaties en andere relevante documenten kan vrijelijk en op royalty-free basis worden beschikt. Alle informatie is beschikbaar op of via de website portal van VERA (kunnen ook verwijzingen zijn naar informatie elders). 29 Er zijn geen beperkingen omtrent het hergebruik van VERA. Het is echter niet wenselijk dat er afgeleide dialecten of varianten van VERA onderdelen ontstaan. Wanneer leveranciers afwijken van de VERA standaard zullen zij deze afwijkingen openbaar maken en motiveren. 30 Het beheer en onderhoud van VERA verloopt volgens nog vast te leggen processen (zie Bijlage A) en informatievoorziening (zie Bijlage B). 2.4 Versiebeleid Onder versiebeleid wordt in dit document verstaan: Versiebeleid 9

10 Het (beheer)proces dat voorschrijft op welke wijze en in welke volgorde wijzigingen (changes) worden doorgevoerd op de verschillende onderdelen (configuration items) van VERA. De voornaamste configuration item types (CI types) worden beschreven in paragraaf 2.1. Ieder CI type is de classificatie van een verzameling Configuratie items (CI s) die met iedere release van VERA wordt gewijzigd, uitgebreid of verkleind. Dit hoofdstuk beschrijft de (voornaamste) richtlijnen die worden toegepast in het wijzigingsproces voor wat betreft het gebruik van versies en versienummers. Bijlage C beschrijft de wijze waarop versienummering wordt toegepast op de verschillende VERA onderdelen. Het versiebeleid 1 dat gehanteerd wordt voor aanpassingen van deze VERA onderdelen is als volgt: 1. Een nieuw major versienummer is vereist in geval een wijziging op het CI dusdanig disruptive is dat er niet van mag worden uitgegaan dat gerelateerde CI s zonder wijzigingen kunnen blijven bestaan dan wel dat bestaande versies compatibel blijven met de nieuwe versie. 2. Een nieuw minor versienummer is vereist in het geval van alle andere wijzigingen dan van toepassing bij punt 1. Dit betekent dat wijzigingen die geïsoleerd blijven tot alleen het CI waarin de wijziging wordt doorgevoerd, of die geen invloed hebben op de compatibiliteit, leiden tot een verhoging van het minor versienummer. 3. In voorkomende gevallen heeft een wijziging een dermate hoge urgentie, dat deze versneld moet worden doorgevoerd en gereleased. In deze gevallen (vaak als gevolg van technische problemen bij implementaties) kan een CI worden aangepast, zonder dat dit leidt tot een verhoging van het major en minor versienummer. Het mag duidelijk zijn dat dit soort wijzigingen hoog-riskant is, en dat er een duidelijke en gestructureerde errata-procedure aanwezig moet zijn en gevolgd moet worden om de releasing hiervan gecontroleerd te laten verlopen. 1 Zie ook document VERA Bijlage A - Standaarden en richtlijnen voor inhoudelijke maatregelen die het versiebeleid faciliteren. Versiebeleid 10

11 Bijlage A Beheer-, onderhouds- en vernieuwingsprocessen A.1 Procesoverview De hoofdprocessen voor het beheer en onderhoud van VERA (de VERA standaard) zijn in onderstaande figuur schematisch aangegeven. De hoofdprocessen worden in een volgende versie van het releasebeleid nader uitgewerkt. Figuur 3 Procesoverzicht Bovengenoemde (hoofd)processen zijn afkomstig uit ASL, en komen overeen met de hoofdprocessen zoals ook bij StUF ingericht. Gezien de gelijkvormigheid van de te beheren standaard ligt het voor de hand om deze good practice als uitgangspunt te selecteren. De processen worden in (deze versie van) dit release- en versiebeleidsplan niet nader uitgewerkt maar worden als aanwijzing aan de stuurgroep meegeleverd. De getoonde processen zijn echter op dit moment al relevant voor VERA en geadviseerd wordt om de processen op een hoog niveau uit te werken. Als extra aanwijzing wordt meegegeven dat VERA aansluit op andere standaarden (zoals CORA, StUF); bij de inrichting van de hoofdprocessen moet rekening worden gehouden met de wijze waarop wordt aangesloten bij de beheerprocessen van andere standaarden. Versiebeleid 11

12 Bijlage B Informatievoorziening rondom VERA Op verschillende plaatsen is informatie over VERA te vinden. Ter ondersteuning van het beheer, het gebruik van de VERA standaard en ten behoeve van de communicatie is de informatievoorziening rond VERA ingericht. De informatievoorziening voorziet de verschillende belanghebbenden van informatie. Hiervoor worden drie doelgroepen onderscheiden: 1. Gebruikers van de standaard (en geïnteresseerden) 2. Leden van Beheer & Onderhoud VERA, het Bestuur, de VERA Stuurgroep en de VERA Werkgroepen en daarnaast de leden van de VERA Expertise groep. 3. ICT-Leveranciers In de huidige situatie is er één hoofdkanaal ingericht, ter ondersteuning van de communicatie met al deze drie doelgroepen. Dit is de website Daarnaast wordt gebruik gemaakt van Dropbox door leden van Beheer & Onderhoud. Dit kanaal deelt alle in ontwikkeling zijnde versies van configuratie items, onderdeel van een VERA release. Geadviseerd wordt om een doelgroepenanalyse uit te voeren en de inrichting van de informatievoorziening rondom VERA te laten aansluiten op de behoeftes van de verschillende doelgroepen. Hierbij kan de input van StUF worden gebruikt als referentiepunt. Versiebeleid 12

13 Bijlage C Versienummering VERA onderdelen Versienummering is voor VERA belangrijk en van een cruciale betekenis voor planning ontwikkeling onderhoud en beheer van applicaties en voor operationele systemen die de versienummers gebruiken binnen de verwerking. VERA hanteert voor elk VERA configuratie item een viercijferig of zescijferig versienummer. Viercijferige versienummers worden gebruikt voor alle CI-types anders dan SCI-types. Zescijferige versienummers worden gebruikt voor SCI-types. Versienummers zijn opgenomen in de berichtdefinities en worden in sommige applicaties gebruikt bij de geautomatiseerde verwerking, vertaling en/of bij de validatie van ontvangen berichten. Mede hierom wordt de versienummering door VERA deskundigen bepaald. In de bestandsnaam van elk bestand dat gerelateerd is aan een bepaald onderdeel van VERA moet duidelijk te zien zijn om welk VERA onderdeel en om welke versie het gaat. Opbouw en betekenis versienummer XX.YY.ZZ XX YY ZZ Hoofdversienummer van een omvangrijke hoofd (of major) release van een VERA onderdeel. Een nieuwe hoofdrelease heeft meestal een grote impact op bestaande software. Een wijziging in een VERA onderdeel die leidt tot een noodzakelijke niet compatibele aanpassing in een aantal VERA onderdelen moet in alle gevallen leiden tot een nieuw hoofdversienummer van de betreffende onderdelen. Een chronologisch volgnummer van wijziging van het betreffende VERA onderdeel. Het gaat hierbij meestal om de wijziging van één of meerdere wijzigingsverzoeken (RFC s) of het toevoegen van functionaliteit zonder de compatibiliteit te breken. Het volgnummer zegt niets over een eventuele afhankelijkheid met andere VERA onderdelen. Een bouwnummer (buildnumber), specifiek voor SCI s, dat een versie aanduidt van een bestaand CI waar bijvoorbeeld bugs in gefixt zijn. Er bestaat een kleine kans dat deze bugfixes ook een disruptive karakter hebben. Versiebeleid 13

14 Bijlage D Begrippen en afkortingen Afkortingen ASL C.I. CORA RFC S.C.I. VERA WSDL XSD Application Service Library, een Public Domain standaard voor het beheer en onderhoud van applicaties (zie ook Configuration Item; iedere component die beheerd moet worden als onderdeel van de VERA standaard Corporatie Referentie Architectuur Request for Change; Synoniem voor Wijzigingsverzoek Software Configuration Item; in dit document wordt met een SCI-type bedoeld alle CI-types die direct impact hebben het gedrag van software systemen Volkshuisvesting Enterprise Referentie Architectuur Web Service Definition Language; een XML-taal waarmee de interfaces van webservices kunnen worden beschreven. XML Schema Definition; een taal voor het beschrijven van de structuur van XML-documenten, vastgelegd in standaarden van het W3C. Versiebeleid 14