Bilaga om livscykelhantering för SDK

1. Inledning

En definierad och överenskommen livscykelhantering är viktig både för att SDK:s specifikationer och meddelandetyper ska kunna utvecklas över tid och tillgodose utvecklingsbehov, och för att deltagarorganisationer ska kunna planera för interna förvaltningsaktiviteter och anpassning av de anslutande system som tillämpar specifikationerna.

SDK:s livscykelhantering innefattar SDK anslutningsavtal, SDK regelverk, tekniska specifikationer och gemensamma komponenter (SDK adressbok och SDK testklient). Livscykelhanteringen beskriver olika typer av förändringar, processen för förändring samt regler för förändring (hur deltagarorganisation ska förhålla sig till/följa ändringen).

För att uppnå ett stabilt och kontinuerligt meddelandeutbyte mellan deltagarorganisationer behövs därför gemensamma principer för hur specifikationerna förändras över tid och kan samexistera.

Över tid finns det behov av att stödja:

• Hur befintliga avtal, regelverk, specifikationer och meddelanden (meddelandetyper/dokumenttyper) kan förändras och utvecklas.
• När nya avtal, regelverk, specifikationer och meddelanden (meddelandetyper/dokumenttyper) kan tillkomma.
• När avtal, regelverk, specifikationer och meddelanden (meddelandetyper/dokumenttyper) kan behöva avvecklas
• Förändringar i SDK-federationens gemensamma komponenter (SDK adressbok och SDK testklient).

2. Livscykelhantering

Livscykelhantering av SDK anslutningsavtal, regelverk och tekniska komponenter är en viktig process för att säkerställa att dessa är relevanta och uppdaterade under hela avtalets löptid.

2.1 Livscykelhantering av anslutningsavtal

Anslutningsavtal inom SDK innefattar följande avtal:

• Anslutningsavtal för deltagarorganisationer angående Säker digital kommunikation Länk till annan webbplats. – för offentliga aktörer
• Anslutningsavtal för deltagarorganisationer angående Säker digital kommunikation – för privata aktörer
• Anslutningsavtal Digg - Accesspunktsoperatör

2.2 Regelverksbilagor till anslutningsavtal

Regelverksbilagor spelar en avgörande roll i anslutningsavtalet eftersom de specificerar krav från SDK federationsägare, såsom tillgänglighetskrav eller IT-säkerhetskrav.

Bilagorna är levande dokument som kan behöva justeras och utvecklas när nya krav eller förutsättningar uppstår. Ändringarna dokumenteras noggrant i releasenotes.

Aktuella versioner av SDK regelverk:

• Regelverk för deltagarorganisationer inom SDK
• Regelverk för meddelandesystem Länk till annan webbplats.
• Regelverk för accesspunktsoperatörer

2.3 Livscykelhantering av tekniska komponenter

De tekniska komponenterna som används inom SDK-federationen består av SDK gemensamma komponenter (SDK adressbok och SDK testklient) samt gemensamma komponenter i Plattform för eDelivery Service Metadata Publisher (SMP) och PKI tjänst. Dessa komponentner genomgår även i en livscykelhantering.

För mer information om SDK:s tekniska komponenter och aktuella versioner se SDK adressbok handledning samt SDK testklient.

3. Typer av release

Varje release för SDK gemensamma komponenter samt styrande dokumentation inom SDK representeras av tre olika release-typer; major/stor, minor/mellan och subminor/liten.

Release typ: Stor/major (1.0)

En ”major-version” representeras av den första siffran i versionsnumret. Den ändras när det släpps en betydande ändring av anslutningsavtals- och regelverksändringar. En ny majorversion indikerar oftast strukturändringar som tekniskt bedöms påverka kompatibilitet med tidigare versioner och stora nya funktioner eller krav. En större förändring av avtalsinnehållet eller struktur.

• Exempel:
• När ett fält blir obligatoriskt (specifikation eller tekniskt protokoll)
• En ny obligatorisk regel införs som deltagare SKA följa

En majorversion medför att deltagarorganisationens meddelandeklient, meddelandetjänst eller accesspunkt påverkas och behöver anpassas. En majorversion medför att deltagarorganisationens meddelandeklient, meddelandetjänst eller accesspunkt påverkas och behöver anpassas.

Release typ: Mellan/minor (1.1)

En ”minor-version” representeras av den andra siffran i versionsnumret. Den ändras när mindre förbättringar eller nya funktioner läggs till utan att bryta kompatibilitet med tidigare versionera funktioner eller krav.

Ändringen påverkar inte avtalsinnehållet eller dess struktur.

Exempel:

• När ett nytt frivilligt fält har tillkommit där verksamheten inte bedöms påverkas av förändringen.
• En regel har fötydligats eller utökats utan det bedöms påverka deltagare eller dess tekniska implementation.

Release typ: Liten/subminor (1.0.1)

En ”subminor-version” representeras av den tredje siffran i versionsnumret. Endast mindre korrigeringar, rättelser och buggfixar.

• Exempel:
• Ändring av beskrivande texter
• Uppdatering av illustrationer

Dessa uppdateringar syftar till att förbättra stabilitet och tydlighet i SDK dokumentation samt gemensamma komponenter.

3.1 Principer för ärendehantering, utveckling och förvaltning av funktionalitet och regelverket för SDK

Följande principer gäller:

• Alla ändringar i SDK regelverket kommuniceras tydligt och i god tid till alla berörda parter.
• Samverkansforum för regelverks- och avtalsändringarändringar, utveckling och möjlighet att bidra med önskemål och förbättringsförslag erbjuds alla aktörer.
• Behovsdriven utveckling gäller för teknisk funktionalitet samt förändrat regelverk där behoven tydligt skall framgå för önskad utveckling. Utveckling beslutas och styrs av federationsägaren för SDK och sker sedan i samverkan med deltagarorganisationerna och aktörer anslutna till SDK.
• En ny release innehåller alltid en ändringslogg (releasenotes) som tydliggör vad som har ändrats och varför.
• Federationsägare SDK beslutar och ansvarar för produktionssättning av ny funktionalitet och regelverk enligt gällande releasehantering SDK.