Support og vedligehold - NSP



Support og vedligehold - NSP


Aftale om at xx varetager Support og vedligehold på xx service for Sundhedsdatastyrelsen på den Nationale Serviceplatform (NSP)





Parter


Aftalen er Indgået mellem følgende parter:


Sundhedsdatastyrelsen

Afdelingen for Udvikling, Strategi og Arkitektur

Xxxxxxxx Xxxxxxxxx 0

2300 København S

(herefter benævnt Kunden)


og


[…]

(herefter benævnt Leverandøren)


Opgavebeskrivelse – løbende ydelser

Den Nationale Service Platform (NSP) er en teknisk platform, der sammen med en række standarder og aftaler gør det muligt at udbyde et antal services til offentlige og private it-systemer.


NSP’en beror på et unikt samarbejde mellem flere parter. Samarbejdet er baseret på høj grad af gensidig tillid, serviceminded og fleksibel indstilling til at understøtte og løse opgaverne. Opgaveløsningen respekterer de roller og kompetencer partnerne har og bringer ind i samarbejdet.


Leverandøren indgår i den del af opgaveløsningen, der vedrører Support og vedligehold af de komponenter, der er listet ovenfor. Ved Support forstås i denne kontekst, support af anvendere og samarbejdspartnere vedr. Incidents (P1-P4) og Service requests. Ved vedligehold forstås almindelige vedligeholdelsesopgaver og mindre videreudvikling af de listede komponenter. Support og vedligehold ydes alene inden for normal åbningstid, 8-16 (ma-to) og 8-15.30 fredage.


NSP’en indgår som en kritisk del af infrastrukturen for Sundhedsvæsenets parter. Der er derfor opstillet en række servicemål for NSP’en, som dels betyder krav til oppetid på 99,8% på alle produktionssystemer og dels til løsningstid for incident håndtering – eks. 2 timer for P1 Incidents. Servicemål og rapportering kan ses her:

xxxxx://xxx.xxxxx.xx/xxxxxxx/xxx/Xxxxxxxxxxxxxxxxxx.


NSP’en udstiller en række datasamlinger og services, der har personfølsom karakter eks. datasamlinger som CPR, Yder og Sikrede og eksterne nationale services som STS, DDS og DRS.


For en uddybende beskrivelse af NSP henvises til:

xxxxx://xxx.xxxxx.xx/xxxxxxx/xxx/XxxxxxxxxxxxxxxxxXXX-xxxxxxxxxx


Den overordnede opgave har til formål, efter følgende prioritering at sikre:


1) support inden for opstillede servicemål

2) vedligeholdelse og mindre videreudvikling


af de listede komponenter. NSP operatøren/SDS vil som hovedregel prioritere supportopgaver over vedligehold og mindre udviklingsopgaver.


Supportopgaver

Det forventes, at Leverandørens konsulenter kan varetage support af dokumentdelings- og sikkerhedskomponenterne og følge de etablerede processer for disse. Supportopgaver følger SDS Incident Management processen xxxxx://xxx.xxxxx.xx/xxxxxxx/xxx/XXXxXxxxxxxxxXxxxxxxxxx for incidents (P1-P4) og for service requests, der er indmeldt fra de enheder, der supporterer brugere af de systemer, som SDS stiller til rådighed for parter i sundhedsvæsenet. Dette gælder således Produktions-, test- og uddannelsesmiljøer.


Processen sikrer en ensartet, struktureret, effektiv og dokumenteret behandling af incidents og service requests vedrørende de relevante løsninger. Processen skal være gennemskuelig for alle involverede parter. Samtidigt skal processen sikre en afstemt og præcis kommunikation til alle relevante interessenter for alle incidents. Dette gælder både udmeldinger på NSPOP og direkte kommunikation med primære interessenter.




Supportopgaverne indbefatter:

  • Fast kontaktperson i forhold til NSP Operatøren/SDS, Driftsleverandøren, NSP-leverandøren og Nationale Service Desk med responstid på 1 time i forhold til supportopgaver m.v

  • Løsning af supportopgaver, fejlsøgning og fejlrettelse påbegyndes efter forudgående aftale og godkendelse hos NSP Operatøren/SDS. Aftalen vil typisk indeholde analyse, forslag til løsning, ressource estimat og tidsplan.

  • Leverandøren har initiativpligt til med rettidig omhu, at oplyse såfremt servicemål ikke kan nås

  • Leverandøren er pligtig til at anvende registrerings- og samarbejdsværktøjer fastlagt af NSP Operatøren/SDS. Der anvendes bl.a. Jira, Confluence og SVN.

  • Månedlige opgørelser udfyldt i skabelon udleveret fra SDS med angivelse af tid, dato og reference til Jiranr, SDS-aktivitetsgruppe . og konsulentkategori anvendt på supportopgaver, senest 5. arbejdsdag efter månedsskifte eller i henhold til aftale med SDS.

  • 24/7 support og tilkaldevagt efter nærmere aftale med NSP Operatør/SDS og sædvanligvis med 30 dages varsel (eks. i forbindelse med releases). Rent undtagelsesvist kan der varsles med kortere frist (eks. i forbindelse med opståede forsinkelser eller kritiske situationer). Det tilstræbes, at disse vagtperioder begrænses til 3-4 gange årligt

Vedligeholdelsesopgaver

Vedligeholdelse indbefatter almindelig vedligeholdelsesopgaver, samt mindre videreudvikling af komponenterne. Vedligeholdelsesopgaver gennemføres i henhold til en agil samarbejdsform, som er nærmere beskrevet i afsnit Xxxxxx for leverandørens opgave. Den agile proces skal sikre en løbende grooming af backlog af vedligeholdelsesopgaver, samt afstemning af løsning før igangsætning.


Vedligeholdelsesopgaverne indbefatter:

  • Fast kontaktperson i forhold til NSP Operatøren/SDS, Driftsleverandøren, NSP-leverandøren og Nationale Service Desk med responstid på 1 time i forhold til vedligeholdelsesopgaver m.v.

  • Leverandøren forventes at indgå i en agil samarbejdsform jfr. afsnit Rammer for leverandørens opgave.

  • Igangsætning af vedligeholdelsesopgaver påbegyndes efter forudgående aftale og godkendelse hos NSP Product Owner og/eller NSP Operatør, i henhold til kriterier for Definition of Ready, som beskrevet i afsnit Xxxxxx for leverandørens opgave.

  • Leverandøren er pligtig til at anvende registrerings- og samarbejdsværktøjer fastlagt af NSP Operatøren/SDS. Der anvendes bl.a. Jira, Confluence og SVN.

  • Deltagelse og varetagelse af ad hoc vurdering af ændringsanmodninger efter nærmere aftale med NSP Operatør/SDS.

  • Deltagelse i periodevise CAB-møder samt i ad hoc CAB-møder i tilfælde af behov for hastebehandling.

  • Deltagelse i fysiske møder efter aftale med NSP Operatør/SDS.

  • Månedlige opgørelser udfyldt i skabelon udleveret fra SDS med angivelse af tid, anvendt på vedligeholdelsesopgaver, reference til dato, Jiranr, SDS-aktivitetsgruppe nr og konsulentkategori, samt forecast for kommende måned senest 5. arbejdsdag efter månedsskifte eller i henhold til aftale med SDS.

Rammer for leverandørens opgave

SDS har som mål at anvende en agil samarbejdsform i relation til NSP og forventer denne implementeret i løbet af 2018. Den agile samarbejdsform er dels inspireret af scrum og kanban, men tilpasset de arbejdsvilkår som vedligeholdelse af NSP komponenter fordrer. Det forventes, at leverandøren bidrager til implementeringen af denne samarbejdsform, herunder understøttelse af continuos integration (CI) og continuos deployment (CD).


Rollefordeling

SDS vil varetage rollen som product owner og vil således være ansvarlig for, at product backlog er opdateret og prioriteret. Det forventes, at leverandøren varetager rollen som scrum master.


Product Backlog

SDS vedligeholder en product backlog med support og vedligeholdelsesopgaver. Det er scrum masters ansvar, at sikre at disse opgaver (product backlog items) groomes, estimeres og nedbrydes i sprint backlogs.


Grooming

Grooming af product backlog items foretages på initiativ af leverandørens scrum master. Grooming aktiviteter planlægges som opgaver i spring backlog og har til formål, at sikre korrekt forståelse, nedbrydning, prioritering og omprioritering af opgaver fra backlog. Typisk vil grooming aktiviteter planlægges ind i sprints umiddelbart før det sprint, hvor udviklingen planlægges at skulle foregå.




DoR – Definition of Ready

Før udvikling af en opgave fra product backlog kan påbegyndes, skal opgaven først groomes og kriterierne for Definition og Ready skal være opfyldt, med mindre andet aftales. SDS har fastlagt følgende kriterier for Definition of Ready:

  • Godkendt beskrivelse af funktionelle krav (evt. i form af user stories), samt non-funktionelle krav

  • Godkendt løsningsbeskrivelse og estimat

  • Beskrivelse af evt. interfaces er klar

  • Product backlog item skal være nedbrudt i sprint backlog items i JIRA

  • Test cases/plan klar


Sprints

Sprints forventes, at have en længde på 3-4 ugers varighed. Hvert sprint startes med sprint planlægningsmøde og afsluttes med et sprint evalueringsmøde. Der vil blive afholdt statusmøder med SDS product owner, eller i henhold til aftale med SDS.


DoD – Definition of Done

Definition of Done beskriver de kriterier, der skal være opfyldte før en product backlog item anses for at være færdigudviklet. SDS har fastlagt kriterier for Definition of Done angivet i afsnit Afprøvning.


Løbende håndtering af support sager og incidents

Det vil være forventeligt, at der kan komme support sager og incidents, som skal løses inden for et igangværende sprint. Support sager og incidents forventes prioriteret over vedligeholdelses- og udviklingsopgaver i sprintet i henhold til prioriteringer angivet af SDS/NSP Operatør.


Standarder og retningslinjer

Leverandøren forventes at overholde følgende standarder og retningslinjer.


Kort beskrivelse af it-miljø og it-strategi


For en beskrivelse af NSP it-miljø henvises til:

xxxxx://xxx.xxxxx.xx/xxxxxxx/xxx/XxxxxxxxxxxxxxxxxXXX-xxxxxxxxxx

Leverandøren forventes at udvikle op i mod NSP’s subversion.

SDS planlægger, at udviklingen skal foregå i SDS udviklings- og testmiljøer – efter CI/CD principper. Dette forventes at være implementeret i løbet af 2018.

Dokumentation og opfølgning på ændringer, incidents og support sager skal foregå i SDS og/eller Driftsleverandørs incidentsystemer.

Udvikling baseret på 3. parts biblioteker som er godkendt af SDS. Anvendelse af andre biblioteker, som ikke er SDS whitelisted, kræver godkendelse af SDS arkitekturfunktion.


Efterspurgte IT-konsulenter

Efterspurgte IT-konsulenter – Løbende Ydelser

[Leverandøren vil som udgangspunkt foreslå det team og den fordeling imellem konsulentkategorier, Leverandøren mener bedst muligt kan varetage Kundens opgave ud fra sit kendskab til de enkelte IT-konsulenter.

Ved køb med betaling efter medgået tid KAN Kunden vælge at angive, hvilke(n) IT-konsulentkategorier, der ønskes. Såfremt nedenstående skema er udfyldt, betragtes det angivne som Mindstekrav.]




Projektleder

Løsningsarkitekt

Sikkerhedskonsulent

Seniorkonsulent

Konsulent

Juniorkonsulent

Domæneekspert

Operatør

Systemintegrator



Junior- konsulent

Antal konsulenter

[…]

[…]

[…]

[…]

[…]

[…]

[…]

[…]

[…]


[Kunden tilretter skemaet før igangsættelse]


[Såfremt Kunden ønsker at holde antallet af tilbudte IT-Konsulenter på et defineret maksimum angives her det maksimale antal IT-konsulenter, der ønskes aftale på. Det skal bemærkes, at Leverandøren har adgang til ved hastetilkald midlertidigt at udskifte de tilbudte IT-konsulenter.]


For at sikre og fastholde kompetence på komponenter og miljø, forventes at Leverandøren indestår for relevante kompetencer i forbindelse med kurser, ferie, sygdom m.v.

Tidsmæssige rammer

Opgavens forventede start og slutdato

[Her indsætter Xxxxxx sin forventede tidsplan for Opgaven. Tidsplanen bør indeholde et start- og forventet sluttidspunkt og kan indeholde en liste over opgavens milepæle. Sluttidspunktet kan af Kunden angives som et mindstekrav.

Løbende Ydelser – aftalens varighed

[Her indsætter Kunden varigheden af aftalen. Starttidspunktet vil, som udgangspunkt, altid være det tidspunkt, hvor projektopgaven afsluttes. Alternativt ved Delkontraktens indgåelse, eller umiddelbart derefter, såfremt den tilbudte Ydelse udelukkende består af Løbende Ydelser.]

Kundens fleksibilitet

[Her indsætter Xxxxxx oplysning om planer er ufravigelige eller om ændringer i planerne kan accepteres. Kan ændringer i planerne accepteres angives rammerne for de acceptable ændringer for hele eller dele af Opgaven.]

Eksempel: Kunden kan angive, at dele af IT-arkitektur aktiviteterne skal udføres på en planlagt workshop en fastlagt dato, men at de øvrige aktiviteter blot skal udføres i en samlet tidsmæssig sammenhæng, således at aktiviteterne afsluttes inden en fastsat deadline. Implementeringen skal kunne udføres enten på dato XX eller dato YY, hvor der er vindue for implementering af udviklingsaktiviteter. Arbejdet skal være afsluttet senest den dato, som er angivet som afslutningsdato for opgaven.

Kundens dokumentationskrav

Det forventes at leverandøren vedligeholder dokumentation på Confluence i henhold til de retningslinjer der, er beskrevet i NSP Dokumentationskrav og NSP husregler:

Månedlige opgørelser af tid anvendt på opgaver/projekter, samt forecast for kommende måned senest 5. arbejdsdag efter månedsskifte eller i henhold til aftale med SDS.

Udførelsessted – evt. remote adgang til Kundens IT miljø

Det forventes, at leverandøren supporterer og vedligeholder komponenterne fra eget kontor via remote adgang til NSP’ systemer. Udvikling, build, dokumentation og versionsstyring skal foregå på SDS miljøer.

I det omfang det skønnes nødvendigt, vil konsulenter få adgang til relevante systemer hos NSP.

Afprøvning

[Her indsætter Kunden hvilke overordnede acceptkriterier, der skal gælde for leverancen omfattet af Delkontrakten samt hvilke prøver, der skal gennemføres]


Liste over acceptkriterier og overtagelsesprøver

Nr.

Beskrivelse

Opfyldelse

1

Kode review er gennemført uden bemærkninger i henhold til SDS husregler


[…]

2

Confluence dokumentation er opdateret i henhold til SDS dokumentationskrav

[…]

3

Change Set er commit’et til SVN.


4

Funktionel- og/eller regressionstest er gennemført succesfuldt

[…]

5

Alle Unit tests er gennemført succesfuldt med en code coverage på over 80%

[…]

6

I tilfælde af fejlrettelse skal der være implementeret unit test der eksplicit tester fejlrettelse

[…]

7

I tilfælde af nødvendig fejlrettelse p.b.a. mangelfuld/fejlbehæftet leverance, som ikke kan godkendes af SDS QA, forventes leverandør som udgangspunkt at foretage denne rettelse u.b.

[…]



Timer og timepris:

For opgaver der vederlægges efter medgået tid med et prisestimat inkluderer samlet pris Timeforbrug (antallet af timer jf. nedenstående skema multipliceret med antallet af måneder jf. nedenstående skema og multipliceres med den tilbudte timepris jf. nedenstående skema.


Månedligt antal timer er [...]

Månedligt vederlag er DKK [...]

Antal måneder: [...]



Skema til opgørelse af samlet pris for opgaver, der vederlægges efter medgået tid med prisestimat

Konsulentkategori

Antal timer pr måned

Antal måneder

Tilbudt timepris i DKK* ex moms

I alt DKK ex moms for kontraktperioden

[…]

[…]

[…]

[…]

[…]

[…]

[…]

[…]

[…]

[…]

[…]

[…]

[…]

[…]

[…]

Samlet prisestimat for konsulenter

[…]


Kundens kontaktperson(er):

Følgende person(er) er hos Kunden primær kontaktperson(er) i relation til opgavens udførelse:


Navn: Xxxxx Xxxxxxxx Xxxx

Tlf.:

Titel: NSP-systemansvarlig

Dir. tlf.:

Adresse: Xxxxxxxx Xxxxxxxxx 0

Xxxxx:

Postnr./by: 2300 København S

E-mail: xxxx@xxxxxxxxxxxx.xx

Funktionsbeskrivelse: NSP-systemansvarlig



Navn: Xxxxxx Xxxx-Xxxxxx

Tlf.: 0000 0000

Titel: IT-Løsningsarkitekt

Dir. tlf.:

Adresse: Xxxxxxxx Xxxxxxxxx 0

Xxxxx: 0000 0000

Postnr./by: 2300 København S

E-mail: xxxx@xxxxxxxxxxxx.xx

Funktionsbeskrivelse: IT arkitekt


Navn:

Tlf.:

Titel:

Dir. tlf.:

Adresse: Xxxxxxxx Xxxxxxxxx 0

Xxxxx:

Postnr./by: 2300 København S

E-mail:

Funktionsbeskrivelse: Product owner


Navn: Xxxxxx Xxxxxxxxx

Tlf.: 0000 0000

Titel: NSP Operatør

Dir. tlf.:

Adresse: Xxxxxxxx Xxxxxxxxx 0

Xxxxx:

Postnr./by: 2300 København S

E-mail: xxx.xx@xxx.xx

Funktionsbeskrivelse: NSP Operatør


Leverandørens kontaktperson(er):

Følgende person(er) er hos leverandøren primær kontaktperson(er) i relation til opgavens udførelse:


Navn:

Tlf.:

Titel:

Dir. tlf.:

Adresse:

Mobil:

Postnr./by:

E-mail:

Funktionsbeskrivelse: […]


Navn:

Tlf.:

Titel:

Dir. tlf.:

Adresse:

Mobil:

Postnr./by:

E-mail:

Funktionsbeskrivelse: […]


Samarbejdsorganisation:

I forbindelse med opgavens gennemførelse, er den nedenfor anførte samarbejdsorganisation etableret mellem parterne.


Antages udfyldt af leverandør


[…] (Angivelse af projektorganisation, hvis parterne i fællesskab bliver enige om etablering af en sådan.)




Beskrivelse af komponenter

I dette afsnit gives en overordnet beskrivelse af hver af de komponenter, som er indbefattet af nærværende aftale. Referencer til detaljeret dokumentation og kildekode er angivet for hver komponent.




Ikrafttræden og ændringer

Aftalen træder i kraft ved parternes underskrift. Parterne kan ændre/opsige aftalen med x måneders varsel.



Underskrifter


For Leverandør

Dato


Titel og navn



Underskrift




For SDS

Dato


Titel og navn



Underskrift






Ver. 1.0


Document Metadata

Filed: September 4th, 2018