Annoncering af drift, support, udvikling og implementering

Transkript

1 OS2 Offentligt digitaliseringsfællesskab c/o Aarhus Kommune DOKK1, Hack Kampmanns Plads Aarhus C os2@os2.eu OS2opgavefordeler Annoncering af drift, support, udvikling og implementering Copyright OS2 Offentligt digitaliseringsfællesskab. Dette værk er under en Creative Commons Kreditering- DelPåSammeVilkår 4.0 International licens. Besøg for at se en kopi af licensen.

2 Annonceringsramme OS2-fællesskabet annoncer opgaven for drift, support, udvikling og implementering af løsningen OS2opgavefordeler. Vi inviterer leverandører til at byde på opgaven, som beskrives i det følgende. Definitioner OS2-fællesskabet benævnes også som kunden. Kommuner som benytter løsningen omtales også som anvendere. Spørgsmål Spørgsmål bedes rettet til OS2-sekretariatet på os2opgavefordeler@os2.eu. Spørgsmål skal være os i hænde senest mandag d. 8/ kl. 12. Spørgsmål og svar publiceres i anonymiseret form på os2.eu senest fredag d. 12/ kl. 12. Deadline Deadline for modtagelse af besvarelser er onsdag d. 31/ kl. 12. Besvarelser sendes digitalt til os2opgavefordeler@os2.eu. Valg af leverandør Senest 14 dage efter forventes styregruppen for OS2opgavefordeler at vælge en leverandør, og det vindende bud annonceres på os2.eu. Det vindende bud vælges ud fra en vægtning mellem økonomi og opgavebesvarelse. Kontraktperioden Der indgås aftale for en 4-årig periode. Kunden er dog berettiget til at hæve aftalen med 3 måneders opsigelse ved skriftligt varsling. Overtagelse Det forventes at leverandøren kan levere fra senest den 1/ Nuværende anvenderkommuner OS2opgavefordeler benyttes i dag af følgende anvendere: Horsens kommune Skanderborg kommune Side: 2

3 Syddjurs kommune Norddjurs kommune Fredensborg kommune Ballerup kommune Anvenderne er ikke forpligtiget til at gå med på den fælles rammeaftale. Leverandørens kompetencer Leverandøren bedes medsende CV på de personer, som forventes at løfte opgaverne med videreudvikling af løsningen, samt CV på de personer som forventes at varetage implementering i samarbejde med anvenderne. Erklæringer Før aftaleindgåelse skal den valgte leverandør underskrive en OS2 - partneraftale og en OS2 - FLOSS aftale. OS2 - leverandørpartneraftale kan ses her OS2 - FLOSS aftalen kan ses her Besvarelse Leverandøren bedes angive priser på ydelserne i medsendte regneark. Priser på ydelserne angives efter en trappemodel for antallet af anvendere. Organisering OS2opgavefordeler er organiseret i OS2-fællesskabet. Organisering samt krav til løsningen følger OS2s governancemodel 1, hvor løsningen er placeret på niveau 2. Styregruppe Styregruppen er ansvarlig for produktet overfor OS2 og anvenderne. Styregruppens medlemmer udpeges blandt de deltagende anvendere, der ved styregruppens konstituering vælger en formand for styregruppen. Styregruppen har det overordnede ledelsesansvar for projektet og dets fremdrift, herunder at overvåge ressourcer, økonomi og leverancer. Det er styregruppens rolle at træffe centrale beslutninger, f.eks. ved milepæle, og at bidrage med ideer på centrale tidspunkter i løsningens livscyklus. Styregruppen er den højest 1 Side: 3

4 besluttende myndighed. Ved tvivlsspørgsmål i styregruppen har styregruppeformanden ansvaret for at tage den endelige beslutning. Styregruppens opgaver er: Valg af projektleder Godkendelse af budgetter og styring af økonomi Godkende udviklingsbeskrivelser Sikre ressourcer Skabe gode rammer for samarbejdet Sikre overholdelse af krav til løsningen (eks. arkitekturkrav mm.) Stille krav til kvalitet og leverancer i forbindelse med løsningen Sikre at væsentlige interessenter høres/ bidrager til løsningen Konflikthåndtering Løbende opfølgning på business case og gevinstrealisering Styregruppens sammensætning er: Jon Badstue Pedersen, Syddjurs Kommune (Formand) Mads Lund Torslev, Horsens Kommune Anders Schøler Kollin, Skanderborg Kommune Jens Kjellerup Hansen, Ballerup Kommune Koordinationsgruppe Koordinationsgruppen har til formål at koordinere de, under løsningen, deltagende anvenderes ønsker og behov for videreudvikling og vedligeholdelse. Koordinationsgruppens opgaver er: Sikre indsamling af anvendernes ønsker til udvikling af løsningen Igangsætte og eventuelt lukke udviklingsprojekter Varetage ansvaret for udvikling og drift med leverandøren Styring af økonomi i relation til de afsatte midler til udvikling Styring af økonomi i relation til indsamling af midler Indstille udviklingsprojekter til styregruppen Sikre videnopsamling og -deling anvenderne i mellem. Et vigtigt formål med koordinationsgruppen er at sikre engagement og positive energi omkring løsningen. Koordinationsgrupperne har en vigtig rolle i at sikre, at løsningen udvikles, og at løsningen lever. Koordinationsgruppen for OS2opgavefordeler varetage også OS2kle. Sammensætningen er: Mads Lund Torslev (Horsens Kommune) Jacob Hansen (Skanderborg Kommune) Jesper Vig Meyer (Ishøj Kommune) Henrik Bojsen (Syddjurs Kommune) Brian Jacobsen (Taxon) Joachim Eriksson (KL) Side: 4

5 OS2-sekretariatet Hver anvender betaler en fast årlig tilslutningsafgift til OS2, som på vegne af anvenderne administrerer leverandøraftalen og økonomien. OS2-sekretariatet er bindeleddet mellem de mange interessenter, og bidrager med støtte til styregruppe, koordinationsgruppe samt leverandøren. OS2-sekretariatet løser bl.a. følgende opgaver: Vedligeholder og sikrer kendskabet til OS2s governance Vedligeholder og sikrer anvendelsen af OS2-værktøjer og -skabeloner Bidrage til kommunikation af og om løsningen Understøtter tilslutningsprocessen Sikrer koordinationen mellem OS2opgavefordeler og OS2-bestyrelsen Understøtter opsamlingen af viden og erfaringer OS2-sekretariatet er: Rasmus Frey, Sekretariatschef Terese Lorentzen, Kommunikationsmedarbejder og projektkoordinator Side: 5

6 Løsningsbeskrivelse OS2opgavefordeler Følgende indeholder en løsningbeskrivelse af OS2opgavefordeleren. Beskrivelsen skal ses som et supplement til systemdokumentationen 2. Fokus er her på at beskrive brugen af OS2opgavefordelerens webbrugergrænseflade og de væsentligste API er, i forhold til integration med anvenderens øvrige IT-systemer. OS2opgavefordeleren udfylder to roller. Den ene er at varetage og vedligeholde distributionsregler, dvs. en mapning mellem KLE-numre og organisatoriske enheder, med henblik på fordeling af indkommende post. Den anden rolle er organisationsopmærkning, hvor der for hver organisatorisk enhed kan angives, hvilke KLE-numre enheden er ansvarlig for, samt hvilke KLE-numre enheden har adgang til. Disse to opmærkninger kaldes hhv. udfører og indsigt. For at udføre de to nævnte roller har OS2opgavefordeleren dels et webinterface dels en REST API. I webinterfacet kan hver anvender administrere og vedligeholde deres data, hvilket udover distributionsreglerne og organisationsopmærkningen også inkluderer en organisationsstruktur. REST API et bruges af anvenderens andre IT-systemer. Distributionsreglerne er udviklet med henblik på distribution af post til anvendernes øvrige ITsystemer. Eksempelvis anvender Horsens Kommune integrationsplatformen SBSIP til at håndtere post fra flere kilder (digital post, , scan mv.), journalisere og sende videre til relevante fagspecifikke systemer og organisatoriske enheder. SBSIP har et modul, der sender et KLE-nummer til OS2opgavefordelerens web-service, og får et svar tilbage indeholdende en organisatorisk enhed, der sidenhen kan benyttes til distribution. Organisationsopmærkning er en relativt nyudviklet feature. I forbindelse med bruddet på KMDs monopol indenfor IT systemer på kontanthjælps-, sygedagpenge- og sagsoverbliksområdet sigtes der imod en IT-arkitektur med mange undersystemer fra forskellige leverandører. Undersystemerne skal, afhængigt af den organisatoriske enhed, kunne begrænse adgangen til forskellige domæner. OS2opgavefordelerens organisationsopmærkning er tænkt som en komponent i denne adgangsstyring. Brugergrænseflade Brugergrænsefladen består af et webinterface, hvor man kan håndtere både distributionsreglerne og organisationsopmærkningen. Webinterfacet har også en administrationsdel, hvor man kan håndtere ens organisationsstruktur, API nøgle og lave anvenderspecifikke indstillinger. 2https://github.com/OS2Opgavefordeler/os2opgavefordeler/tree/develop/docs Side: 6

7 Distributionsregler Under fanen distributionsregler er det muligt at se en liste over alle KLE-numre og den tilhørende fordelingsregel, altså hvilken afdeling der er står som modtager af post indenfor dette KLE-nummer (Figur 1). Figur 1 Ved at klikke på fordeling, kan en fordelingsregel oprettes eller redigeres ( Figur 2). Bemærk at hvis der ikke eksplicit er sat en fordelingsregel for et givet KLE nedarves fordelingsreglen fra et KLE højere oppe i taxonomien. Eksempelvis kan KLE-nummer , Registrering i CPR, arve fordelingsreglen for KLE-nummer 23.05, Folkeregistrering, der igen kan arve fordelingsreglen for KLE-nummer 23, Borgerlige forhold. Figur 2 Side: 7

8 Opmærkning I opmærkningsviewet kan man fremsøge en enhed, og derefter vælge hvilke KLE-numre, enheden skal udføre, og hvilke den skal have indsigt i ( Figur 3 og Figur 4). Figur 3 Figur 4 Administrer kommune Administrer kommune -viewet giver adgang til forskellige administrative muligheder. Som f.eks. at uploade en organisationsstruktur, sætte API-nøgle og oprette kommunespecifikke KLEnumre. Side: 8

9 Figur 5 API nøgle API nøglen skal bruges til basic authentication i kald til REST API en. Eksempler på disse kald er givet i sektionen API. Upload JSON organisationsstruktur OS2opgavefordeleren skal have adgang til organisatoriske enheder, og disse uploades i et JSON format (Figur 5). Formatet er en træstruktur med to typer nodes, afdelinger og personer. Afdelingsnodes har følgende fields, businesskey, name, , phone, esdhid, esdhlabel, manager, employees og children. businesskey er ID for en afdeling, hvis distributionsreglerne er sat, og en ny organisationsstruktur uploades, vil reglerne blive opretholdt såfremt den samme businesskey findes i den nye struktur. manager er en person node. employees er en liste med person nodes. Endelig er children en liste med afdelinger. Personnodes har flg. fields businesskey, name, , phone, esdhid, og initials. { } "businesskey" : "272", "name" : "Horsens Kommune", " " : null, "phone" : " ", "esdhid" : "HORSENS", "esdhlabel" : "Horsens Kommune(HORSENS)", "manager" : null, "employees" : [ ], "children" : [... Side: 9

10 { "name" : "Lotte Møller Jensen", "businesskey" : "38421", " " : "joblmj@horsens.dk", "esdhid" : "38421", "initials" : null, "phone" : null } API OS2opgavefordeleren understøtter to API indgange svarende til de to roller opmærkning og distribution som defineret ovenfor. API adressen til interfacet er hhv. for testmiljøet og for produktionsmiljøet. API nøglen sættes i web-interfacet, og skal bruges som password i HTTP basic authentication. Distribution For at få en distributionsregel for et bestemt KLE-nummer gives KLE-nummeret med i en query string til API indgangen. Nedenstående er et eksempel på et kald til test serveren (authorizations strengen bwx0qghvcnnlbnmuzgs6ag9yc2vuc2fwaq== er base64 encodingen af mlt@horsens.dk:horsensapi): curl -X GET \ ' \ -H 'authorization: Basic bwx0qghvcnnlbnmuzgs6ag9yc2vuc2fwaq==' \ -H 'cache-control: no-cache' Side: 10

11 Svaret fra servicen er: { } "kle": { "number": "13.02", "name": "Vandforsyning" }, "org": { "manager": { "name": "Flemming Hausgaard Larsen", " ": "fhl@horsens.dk", "esdhid": "74865", "esdhname": null, "initials": "YHFHL ", "jobtitle": null }, "businesskey": "855227", "name": "Natur og Miljø", "esdhid": "NATUR TM", "esdhname": "Natur og Miljø(NATUR TM)", " ": null, "phone": " " }, "employee": null Opmærkning API indgangen til organisationsopmærkningen benytter en såkaldt businesskey til at lave opslag for hver organisatorisk enhed. businesskey er en del af det JSON format, der uploades (se sektionen API nøgle), men hverken API en eller webinterfacet tilbyder nogle muligheder for at fremsøge eller liste businesskey s. Nedenstående er et eksempel på et kald til test serveren, hvor er businesskey for IT Projekt og Udviklingsafdelingen. curl -X GET \ \ -H 'authorization: Basic agvqqghlai46ag9yc2vuc2fwaq==' \ -H 'cache-control: no-cache' {"PERFORMING":[],"INTEREST":[]} I produktionsmiljøet returnerer kaldet en fejl 500 Internal Server Error. Side: 11

12 Teknisk dokumentation For teknisk dokumentation henvises til github, Opgavebeskrivelse Vi ønsker et samlet tilbud på de følgende beskrevne opgaver. Hosting og drift af løsningen Kunden forventer, at OS2opgavefordeler leveres om SaaS til anvenderne. Det forventes, at leverandøren vælger infrastrukturen og levere en beskrivelse af den valgte løsning. Følgende kriterier indgår i bedømmelsen: Infrastructure-As-A-Service (IAAS) Cloud leverandør Audit En IAAS leverandør bør være underlagt årlige audits af tredje part. Dokumentation En IAAS leverandør bør som minimum kunne stille dokumentation for procedure, standarder, politikker og konfiguration til rådighed for setup, automatiserede procedure samt log- og monitoreringsinformation. Sikkerhed En IAAS leverandør bør som minimum kunne stille følgende til rådighed. Dokumenterede månedlige penetration tests. Beskrevne procedure for patch-management og håndtering af sårbarheder. Compliance En IAAS leverandør bør som minimum have følgende certificeringer Lovgivning CSA (Cloud Security Alliance) ISO 9001 ISO/IEC ISO/IEC ISO/IEC En IIAS levernadør bør være godkendt i følgende lovgivning Side: 12

13 Persondataloven Persondataforordning 2018 EU Data Protection Directive Support / SLA Leverandøren forventes at kunne levere support / SLA til kunden og anvenderne indenfor nedenstående kriterier. Oppetid Opgavefordelerens planlagte oppetid er 24/7/365 Der må være 1 planlagt servicevindue hver måned Servicevinduet skal planlægges til at falde i en weekend (dvs starte efter lørdag morgen kl 04:00, og slutte før mandag morgen kl 04.00) Servicevinduet må ikke være længere end 4 sammenhængende timer Servicevinduet skal meldes ud mindst 1 kalendermåned for det påbegyndes Opgavefordeleren skal være tilgængelig 99,5% af den planlagte oppetid (planlagte servicevinduer tæller ikke som nedetid) Svartider Brugergrænsefladen skal være brugervenlige svartider, hermed forstået, at indlæsning af enkelt-sider må ikke tage længere tid end 200 ms i gennemsnit. Der foretages svartidsmålinger af OS2opgavefordelerens brugergrænseflade i forbindelse med hver release, for at sikre at denne svartid kan overholdes. API et til opslag på en brugers roller skal have tilsvarende svartider, hermed forstået at opslag ikke må tage længere tid end 200 ms i gennemsnit. Der foretages svartidsmålinger af OS2opgavefordelerens API i forbindelse med hver release, for at sikre at denne svartid kan overholdes. SLA på standard ydelser Support foregår på , og svartiden på support-henvendelse er maksimalt 2 arbejdsdage. Supporten håndterer de nedenfor nævnte standardydelser, samt evt. tilkøbsydelser. SLA ved systemnedbrud Leverandøren er ansvarlig for automatisk overvågning af OS2opgavefordeleren og driftsmiljøet, og håndterer systemnedbrud med det samme, de opdages, også i weekend/helligdage. Leverandøren skal kunne reetablere driften indenfor maksimalt 12 timer efter, nedbruddet er opdaget, evt. ved at slå driften over på ny-etablerede images, med et restore af en database backup. Kontaktkanaler Den primære kontaktkanal ved support/drifts-henvendelser er gennem en formular i OS2opgavefordeleren. Alle indgående sager i denne formular resulterer i en automatisk oprettelse af en trouble-ticket i kundens trouble-ticketing system (pt. OS2s Jira). Kunde og anvendere skal stille en (eller flere) adresser til rådighed, hvor leverandøren kan sende driftsinformation vedrørende servicevinduer og lignende. Leverandøren vil sikre, at Side: 13

14 kunden holdes opdateret om alle drifts-relaterede hændelser via denne kanal. Kunden skal også have mulighed for at kontakte leverandøren på telefon, der er dog ingen SLA på svar telefonåbningstid, men leverandøren forventes at forsøge at ville besvare alle indkommende kald, samt ringe tilbage på ubesvarede kald, så snart som muligt. Hvis der oprettes en driftssag på baggrund af en telefonhenvendelse, opretter leverandøren en trouble-ticket på vegne af kunden, så driftssagen kan spores på samme måde, som hvis der var tale om en henvendelse. Testmiljø Leverandøren etablerer et tilsvarende test-miljø, der kan anvendes til kundetest af ny funktionalitet, inden denne idriftsættes på kundens driftsmiljø. Den enkelte anvenders opgaver ved ibrugtagning I forbindelse med ibrugtagning af OS2opgavefordeleren skal anvender levere følgende SAML metadata for den Identity Providers (fx AD FS) der skal anvendes til at logge anvenderens brugere på OS2opgavefordeleren. Et initialt JSON payload der indeholder anvenderens organisation i det format, som er angivet i OS2opgavefordelerens dokumentation. Dette payload kan enten leveres som en fil, som så indlæses af leverandøren, eller anvender kan indlæse det via OS2opgavefordelerens API. Anvender er ansvarlig for at vedligeholde egen organisation via det API, som udstilles på Rollekataloget. Standard ydelser Driftsvederlaget forventes at dække en række standard ydelser, som er beskrevet i dette afsnit. Assistance til udtræk af KLE opmærkninger gennem API. Udveksling af SAML metadata til håndtering af login til OS2opgavefordeleren. Bemærk at dette ikke inkluderer assistance til opsætning i anvenderens Identity Provider (men der medfølger en vejledning samt powershell scripts til at udføre opsætningen selv i Microsoft AD FS). Indlæsning af KLE emneplan. Når KLE emneplanen opdateres skal den nye version indlæses i OS2opgavefordeleren senest en uge efter den nye version er udkommet. Database restore på Kundens anmodning (fuldt restore restore af enkelt-elementer er en betalbar ydelse på timebasis). Assistance til re-etablering af en slettet opmærkning. Fuldt databaseudtræk fra OS2opgavefordeleren. Bemærk at et automatisk databaseudtræk (fx et natligt eller ugentligt udtræk) ikke er en standardydelse, og der alene er tale om enkeltudtræk, fx i forbindelse med hjemtagning af driften af OS2opgavefordeleren og/eller exit. Yderligere support/ydelser skal kunne tilkøbes på timepris. Leverandørens fakturering af yderligere supportopgaver Inden fakturering af løbende support opgaver skal leverandøren i samarbejde med koordinationsgruppe, foretage en vurdering af om opgaverne betales af kunden eller den enkelte anvender som har indrapporteret opgaven. Side: 14

15 Definitionen er, at supportopgaver som direkte relaterer sig til, at OS2opgavefordeler betales af kunden mens supportopgaver som relaterer sig til anvenderens eget driftsmiljø, integrationer osv. betales af anvenderen selv. Leverandørens misligholdelse Forsinkelse Såfremt leverandøren har påtaget sig at løse opgaven indenfor en bestemt tid, og leverandøren ikke overholder fristen, er leverandøren uden videre forpligtet til at betale kunden en bod. Boden beregnes pr. arbejdsdag af det samlede beregningsgrundlag. Boden udgør 0,25 % pr arbejdsdag forsinkelsen varer. Beregningsgrundlaget for ovennævnte bod er det beløb, som oprindeligt er aftalt for opgavens gennemførelse, dog højst det beløb, som leverandøren faktisk har faktureret kunden de seneste 12 måneder for den pågældende opgave forud for forsinkelsens indtræden. Kunden er ikke berettiget til anden erstatning eller bod grundet forsinkelse udover den overfor nævnte bod. Mangler Faktiske mangler Kunden er forpligtet til at undersøge, evaluere og teste det leverede, ved hver opgaves eller delopgaves afslutning. Der foreligger en faktisk mangel, når løsningen ikke lever op til fastsatte krav til funktion, omgang, ydelser eller kvalitet. Eller i de tilfælde hvor kravene ikke er udtrykkeligt reguleret, i forhold til hvad kunden med rimelighed kunne forvente af løsningen/de leverede opgaver. Reklamation Fejl eller mangler der opdages ved gennemgang af opgaverne udført i henhold til aftale, skal af kunden påberåbes straks og uden ugrundet ophold overfor leverandøren. Såfremt der foreligger en mangel ved de leverede ydelser, som må betegnes som væsentlig, og dette ikke burde være opdaget af kunden i forbindelse med leveringen, kan kunden påberåbe sig dette senest 12 måneder efter levering. Afhjælpning Leverandøren er forpligtet til at afhjælpe de fejl og mangler, der opdages ved overleveringen af opgaver omfattet af denne aftale. Mangler der konstateres efter leveringstidspunkt, er omfattet af de øvrige misligholdelses beføjelser. Udviklingsydelser Leverandøren bedes besvare nedenstående udviklingsønske med en løsningsbeskrivelse og pris. Udviklingsønske Ny login proces I dag anvender løsningen komponenten OS2sso til federeret login. Denne komponent ønskes udskiftet, og i stedet skal login indbygges som en del af opgavefordeleren. User Story Side: 15

16 Som medarbejder i en kommune vil jeg logge ind i OS2opgavefordeleren med min AD-bruger med færrest mulige klik. Acceptence Criteria OS2opgavefordeleren tilgår de kommunale AD gennem federated identity med OIOSAML, f.eks. igennem en opkobling til ADFS. Det er muligt at koble flere Federation Service komponenter på OS2opgavefordeleren fra den enkelte kommune, så en kommune f.eks. kan have 2 forskellige ADFS koblet på løsningen. Forbindelse mellem ADFS og OS2opgavefordeler kunne f.eks. ske gennem OIOSAML efter samme standarder som KOMBIT context handleren, da alle 98 kommuner allerede har en tilkobling, som kan håndtere denne slags. Ramme for fremtidig udvikling Leverandøren forventes at kunne levere estimat på de løbende udviklingsønsker, der fremsættes af styregruppen. Leverandøren forventes endvidere at have projektorganisationen til at realisere udviklingsønsker. Leverandøren bedes oplyse til hvilken timepris(er), der leveres. Side: 16

17 Den gode opgaveløsning Leverandøren forventes at benytte OS2s Jira og definitioner for den gode opgavebeskrivelse. Udviklingsønsker beskrives af anvenderne som en Story i OS2opgavefordelers JIRA. En user story består af: Som >rolle< ønsker jeg >behov< (skrives i Summary-feltet) Således at jeg kan nu kan >acceptancekriterier< (skrives i Description-feltet) En user story er uafhængig af alle andre user stories, værdifuld for brugeren, kan estimeres i form af indsats, tilpas lille så den kan passe ind i en sprint/iteration og er mulig at teste. Definition of done Leverandøren forventes at kunne efterleve følgende definition og done for udviklingsopgaver. 1. Gennemført test af det udviklede for en enkelt anvender i test og produktionsmiljø. 2. Kunden har accepteret test. 3. Gennemført test af det udviklede fra alle anvendere i test og produktionsmiljø. Kodereview Styregruppen for OS2opgavefordeler kan til en hver tid beslutte indkøbe kode review hos 3. part. Et eventuelt kode review skal sikre en høj standard for kodekvalitet, dokumentation og sikkerhed i løsningen. Implementeringsydelser Der er to generelle implementeringsydelser relateret til løsningen. 1. Støt nye anvendere i ibrugtagningen af løsningen 2. Støt eksisterende anvendere i at udvide brugen af løsningen Ydelsesbeskrivelse Når en ny anvender skal ibrugtage løsningen, har anvenderen brug for at forstå løsningens muligheder og afhængigheder. Mulighederne kan handle om opmærkning til postfordeling via KLE og opmærkning til adgangsstyring via KLE. Centrale afhængigheder er at støtte anvenderen i at udarbejde et JSON-udtræk af anvenderens organisationsstruktur og komme med eksempler på hvordan API erne kan støtte kommende arbejdsgange. Når en eksisterende anvender skal udvide brugen af løsningen, skal leverandøren kunne bistå med eksempelvis vejledning til hvordan, API erne kan støtte kommende arbejdsgange. Side: 17

18 Rettigheder til programmel og dokumentation Der stilles krav om, at foreningen OS2 Offentligt digitaliseringsfællesskab har alle nuværende og fremtidige rettigheder til OS2opgavefordeler specifikt programmel, dokumentation, design, rapporter og alt andet materiale, uden begrænsninger, der udarbejdes af leverandøren i forbindelse med opfyldelsen af aftalen. Dette gælder også kode, kildekode, udviklede værktøjer, dokumentation, detailspecifikationer, grænsefladespecifikationer, rapporter, design, data og databaser. Licensen for det, af leverandøren - til nærværende aftale - udarbejdede materiale, er MPL 2.0 (som er kompatibel med GPL v2) eller CC BY-SA. Parterne har en fælles forståelse for, at koden leveres og udarbejdes som open source under MPL 2.0-licensen ( samt underlagt aftalerne i OS2 - Offentligt digitaliseringsfællesskab. Licensen for alt andet er CC BY- SA. Kunden har brugsret til driftsmiljøet i aftalens løbetid. Tredjemands rettigheder Leverandøren forventes at indestå for, at det leverede ikke krænker andres rettigheder, herunder patenter eller ophavsrettigheder. Side: 18