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).

Roller och ansvar

• Federationsägare (SDK) ansvarar för utveckling och förvaltning av avtal, regelverk, specifikationer och gemensamma komponenter.
• Förvaltare av meddelandetyp ansvarar för förvaltning av meddelandetyper
  

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

SDKs anslutningsavtal omfattar:

• 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 specificerar krav från federationsägaren, exempelvis tillgänglighets- eller IT-säkerhetskrav. Dessa dokument uppdateras löpande och ändringar dokumenteras 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

SDK:s tekniska komponenter omfattar:

• SDK-adressbok.
• SDK-testklient.
• Gemensamma komponenter inom eDelivery Service Metadata Publisher (SMP) och PKI-tjänster.

För mer information om SDK:s tekniska komponenter och aktuella versioner se SDK System Architecture Design (SAD). Detaljerade specifikationer för SDKs gemensamma komponenter finns i PKI för accesspunkter – komponentspecifikationer, Certifikatspublicering – REST-binding till SMP, SDK Adressbok API Länk till annan webbplats., Transportmodell Utökad-bas med flera dokument.

3. Typer av release

Varje release av 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 versioners 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örtydligats 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 releasehantering

Följande principer gäller:

• Ändringar (major, minor) ska kommuniceras minst tre månader innan publicering.
• Ett samverkansforum erbjuds till alla aktörer, där ändringar och utveckling diskuteras.
• Aktörer förväntas aktivt delta, lämna feedback och rapportera eventuella hinder eller risker som kan påverka införandet av föreslagna ändringar.
• Behovsdriven utveckling gäller där behoven tydligt ska framgå för önskad utveckling.
• 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 nya versioner av funktionalitet, regelverk och specifikationer.
• Förvaltare av meddelandetyp beslutar och ansvarar för produktionssättning av meddelandetyper efter godkännande av meddelandetypen från federationsägaren.