Bilaga 2 Beskrivning av projektet och dess leveranser

Storlek: px
Starta visningen från sidan:

Download "Bilaga 2 Beskrivning av projektet och dess leveranser"

Transkript

1 Bilaga 2 Beskrivning av projektet och dess leveranser 1 (28) PVS / Bilaga 2 Beskrivning av projektet och dess leveranser

2 Bilaga 2 Beskrivning av projektet och dess leveranser 2 (28) PVS / INNEHÅLL 1 DETTA DOKUMENT Begrepp PROJEKT DIGITAL ARKIVTJÄNST Bakgrund Projektbeskrivning Intressenter PROJEKTORGANISATION Organisation Styrgrupper LEVERANS AV SYSTEMET LEVERANSETAPPER Etappernas leveranser och tidplaner Etapp Etapp Etapp Etapp OPTIONER Ny lagringslösning Option integrering med lagringslösning Option migrering ÖVRIGA ÅTAGANDEN Resurser Utförande i beställarens lokaler Kompetensöverföring Testdata Grunddata ÖVERLÄMNING OCH STÄNGNING AV PROJEKT Överlämning till beställaren Projektavslut PROJEKTDOKUMENTATION OCH RAPPORTERING Projektdokumentation Statusrapportering Finansiell rapportering KOMMUNIKATIONSPLAN... 27

3 Bilaga 2 Beskrivning av projektet och dess leveranser 3 (28) PVS / shistorik Datum Ändring Handläggare Ann Rosenlind

4 Bilaga 2 Beskrivning av projektet och dess leveranser 4 (28) PVS / Detta dokument Detta dokument beskriver projekt med tillhörande delprojekt i form av Leverantörens införandeprojekt. Dokumentet ger en bakgrundsbeskrivning, beskrivning av främst Införandeprojektets leveranser med ansvarsfördelning mellan Rikspolisstyrelsen (RPS) och Leverantören samt beskrivning av optioner vad gäller integrering med lagringslösning samt migrering. 1.1 Begrepp För e-arkivets centrala begrepp finns en begreppsmodell framtagen. Begreppsmodellen omfattar: - arkivredovisning, - e-arkivets funktionsområden För begrepp se bilaga 9, Begreppsmodell för e-arkivet. Inom RPS projekt används två centrala begrepp: e-arkiv samt. Med e-arkiv avses Systemet. omfattar både e-arkivet och arkiveringsprocessen, riktlinjer och handläggarstöd för att arbeta i e-arkivet. Figur 1 Förhållande e-arkiv

5 Bilaga 2 Beskrivning av projektet och dess leveranser 5 (28) PVS / Projekt Syftet med avsnitt 2 är att ge allmän information om projektet Digital arkivtjänst. 2.1 Bakgrund Polisens anställda använder sig dagligen av ett eller flera systemstöd för att utföra sina arbetsuppgifter. Totalt skapas ca 1,8 miljoner nya pappersakter per år. Trots att det mesta av verksamhetens information inkommer eller upprättas digitalt är det enbart en mindre del som hanteras digitalt under hela informationens livscykel. Arkivering sker istället nästan uteslutande på papper. Rikspolisstyrelsen (RPS) bedriver ett omfattande moderniseringsarbete och inför digitala processer inom Polisen. Förändringsarbetet innebär att ett antal äldre system behöver kunna ställa av sin information till ett e-arkiv och att system löpande behöver kunna leverera till ett e-arkiv. Även den polisdatalag som trädde i kraft 1 mars 2012 driver införandet av ett e-arkiv. Lagen reglerar hur Polisen får behandla personuppgifter i sin brottsbekämpande verksamhet. Bland annat införs regler för när uppgifter ska gallras eller överföras till ett e-arkiv. Med hänsyn taget till övergångsregler måste det blivande e-arkivet vara i full drift och ha tagit emot bevarandematerial från system som omfattas av polisdatalagen senast 31/ RPS projekt för ansvarar för att: - Implementera ett för Polisen nationellt e-arkiv - Beskriva en arkiveringsprocess - Utforma riktlinjer och verksamhetsstöd för digital arkivering - Produktionssätta tjänsten på alla myndigheter inom Polisen - Genomföra anslutning av fyra centrala system - Överlämning till drift och förvaltning Inom ramen för RPS projekt för ingår också ett delprojekt för införande. Införandeprojektet ägs och drivs av Leverantören och innefattar att leverera ett standardsystem 1 med tillhörande anpassningar för att möta överenskomna krav. Leverantörens införandeprojekt har ett antal definierade leveranser t.o.m. produktionssättning. 1 För Polisens definition av standardsystem se avsnitt Teknik och förvaltningsmål

6 Bilaga 2 Beskrivning av projektet och dess leveranser 6 (28) PVS / Projektbeskrivning Polisens vision är en nationell digital tjänst för långsiktig bevarande av information och i vilken arkivering sker på ett säkert, effektivt och juridiskt korrekt sätt över hela polisväsendet. Detta på ett sätt som stödjer kärnverksamheten. Som en följd av har Polisen upphört att arkivera på papper, cd- och dvd-skivor och filkataloger RPS projekts effektmål Nedan listas s effektmål: Säker informationshantering - Hållbart över tid: informationen ska finnas kvar och vara läsbar över tid, trots mjuk- och hårdvaruuppdateringar. - Autentiskt: informationen ska vara oförvanskad och behöriga personer ska komma åt rätt information. Effektiv informationshantering - Enkelt det ska vara enkelt att söka och hitta informationen i systemet. - Samlade ärenden lösningen ska möjliggöra att all information om ett ärende lagras och hämtas på ett ställe. - En samlad arkivredovisning lösningen ska kunna redovisa både elektronisk och analog information. - Enkelt att ansluta och leverera det får inte vara för höga hinder för att ansluta till e-arkivet samt att det ska vara beskaffat med flera anslutningssätt. Behovet från verksamheten och möjligheten att möta behovet ska styra. Juridiskt korrekt informationshantering - Logiskt avskild information - e-arkivet ska vara gemensamt för alla myndigheter inom Polisen, men respektive myndighet ska kunna ha var sitt arkiv, logiskt avskilt från de andra. - Stödja olika leveransscenarion lösningen ska kunna ta emot leveranser av information när verksamheten behöver leverera för att bland annat uppfylla polisdatalagens krav Projektmål för För att möta upp till bestämda effektmål ska RPS projekt för Digital arkivtjänst leverera både en teknisk lösning för e-arkivering samt därtill kopplade verksamhetsregler i form av en gemensam digital arkiverings-

7 Bilaga 2 Beskrivning av projektet och dess leveranser 7 (28) PVS / process med tillhörande delprocesser och riktlinjer och rutiner för att leverera, ta emot, förvalta/framtidssäkra och tillhandahålla information samt etablera och lämna över till en förvaltning Teknik och förvaltningsmål Utifrån målsättningarna i Polisens nationella it-strategi år ska e- arkivet bygga på ett standardsystem. Med standardsystem avses ett system som innehåller ett antal väldefinierade och färdigutvecklade funktioner med tillhörande gränssnitt för att kunna ta emot, lagra, vårda, söka och lämna ut handlingar. Med färdigutvecklade funktioner avses kod som tillhandahålls, supporteras, underhålls och vidareutvecklas av leverantören. Ett standardsystem kan anpassas till Polisens verksamhet utan att förstöra eller försvåra möjligheter till införande av nya releaser från leverantören. Ett standardsystem kan i sin tur, av leverantören, vara sammansatt av flera komponenter såsom olika system, plattformar, 3:e parts produkter etc. Ur RPS perspektiv är standardsystemet dock en helhet med en leverantör och där RPS inte ska behöva hantera eventuella problem mellan ingående komponenter. Utifrån förvaltningsmål ska det standardsystem som leverantören tillhandahåller i så hög grad som möjligt kunna driftas och förvaltas utan beroende av leverantören. Det kräver att leveransen innehåller tillräckligt med dokumentation och kunskapsöverföring för att Polisen själva ska kunna ta över ansvaret. Det kräver också att standardsystemet är så uppbyggt att det i hög grad kan förvaltas och driftas genom konfiguration tillgängliga via någon form av applikation. För ett högt leverantörsoberoende specifikt för ett e- arkiv menas att RPS själva ska kunna definiera och sätta upp på vilket sätt systemet ska kunna ta emot leveranser, hur informationen ska vårdas samt kunna genomföra en komplett utlämning/ flytt av information till andra plattformar eller andra arkiv. I leverantörsoberoende inbegrips även att om leverantörens verksamhet avslutas ska RPS kunna få tillgång till koden för standardsystemet.

8 Bilaga 2 Beskrivning av projektet och dess leveranser 8 (28) PVS / Intressenter För har följande intressenter identifierats: Figur 2 Intressenter för 3 Projektorganisation 3.1 Organisation RPS projekt för drivs inom ramen för programmet Effektiv allmän ärendehantering (EIM-A). Programmet ägs av Rikspolisstyrelsens Rättsavdelning. Se nedanstående organisationsskiss:

9 Bilaga 2 Beskrivning av projektet och dess leveranser 9 (28) PVS / Figur 3 Projektorganisation (EIM-A) 3.2 Styrgrupper Styrning sker på två nivåer, på programnivå och projektnivå med följande frekvens enligt nedan. Leverantörens representant ska delta vid dessa möten. Projektstyrgrupp Frekvens: 1 gång per månad Styrgruppsordförande: RPS affärsansvarig Föredragande: Deltar: Inriktning: Projektledaren för och projektledaren för Leverantörens införandeprojekt Representanter RPS och Leverantörens affärsansvarig Uppföljning projekt (status, planering, risk) frågeställningar och beslut inom ramen för definierade mål, tids- och kostnadsramar. Rekommendationer till strategiska frågor och förändringar av projektets ramar. Programstyrgrupp Frekvens: 1 gång per månad Styrgruppsordförande: Programägare Föredragande: Deltar: Programledare Representanter RPS och polismyndigheter

10 Bilaga 2 Beskrivning av projektet och dess leveranser 10 (28) PVS / Inriktning: Uppföljning projekt (status, planering, risk) Beslut strategiska frågeställningar, initiering och avslut av projekt samt förändringar av ingående projektens ramar. 4 Leverans av Systemet För varje överenskommet krav ska RPS acceptanstesta och godkänna Leverantörens leveranser. För acceptanstest se vidare under bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 5 Leveransetapper RPS projekt för är indelat i sex leveransetapper, varav Leverantören kommer att vara delaktig i de fyra första leveransetapperna. Projektplanering sker under hösten 2012 och planerad start för införande projektet sker tidigast 7 januari I nedanstående bild beskrivs leveranserna översiktligt där RPS leveranser är markerade med grått och Leverantörens med gult. Figur 4 Leveransetapper Leverantören - RPS

11 Bilaga 2 Beskrivning av projektet och dess leveranser 11 (28) PVS / Etappernas leveranser och tidplaner Utifrån Leverantörens införandeprojekt listas nedan, per leveransetapp; omfattning, förväntade leveranser av såväl RPS som Leverantör, avtalade tider samt godkännandepunkter. Angivna avtalade tider avser den bortre gränsen för en leverans. Acceptanstest ska dock kunna påbörjas senast åtta (8) månader 2 från införandeprojektets start. 5.2 Etapp 1 Etapp 1 startar enligt ramavtal Etappens omfattning Etapp 1 omfattar projektuppstart och projektetablering. Vidare omfattar etappen att Leverantören tillgängliggör e-arkivet med standardkonfiguration samt utbildar RPS projektmedlemmar i systemet. Baserad på denna installation acceptanstestar RPS gjord leverans. Detta ska göras i testmiljö hos RPS Leverans av standardsystem i etapp 1 Det standardsystem som Leverantören ska kunna tillhandahålla direkt vid avtalstecknande ska vara fullt körbart på en av Leverantören definierad testmiljö hos RPS. Funktionaliteten för det standardsystem som levereras ska omfatta minst 65 % av samtliga skall-krav och minst 50 % av de bör-krav som Leverantören angivit i bilaga 1 Kravspecifikation. Standardsystemet ska tillhandahållas med standardkonfiguration, standard inleveransspecifikation samt tillhandahållet testdata RPS leveranser RPS leveranser etapp 1 i relation till Leverantörens införandeprojekt: 1. uppdaterad projektplan, inklusive aktivitetsplan och riskanalys, 2. uppsatt test- och utbildningsmiljö enligt Leverantörens anvisningar, 3. medverkande vid installation av standardsystem i test- resp. utbildningsmiljö, 4. testplan och testfall, 2 En (1) månad definieras som trettio (30) kalenderdagar

12 Bilaga 2 Beskrivning av projektet och dess leveranser 12 (28) PVS / acceptanstest av standardsystem, 6. testprotokoll med tillhörande testrapporter avseende acceptanstester av standardsystem Leverantörens avtalade leveranser Leverantörens avtalade leveranser för etapp 1: 1. etablerad projektorganisation, 2. projektplan, inklusive aktivitetsplan och riskanalys, 3. dokumenterad anvisning på uppsättning av en test- och en utbildningsmiljö 3, 4. stöd vid uppsättning av test- och utbildningsmiljö, 5. installation av standardsystem etapp 1 med tillhörande standardkonfiguration, testdata på uppsatt test- respektive utbildningsmiljö 4, 6. verifiering att standardsystemet är korrekt uppsatt på test- respektive utbildningsmiljö, 7. leverans av dokumentation enligt Avtal och tillhörande standardsystem, 8. utbildning av projektmedlemmar på standardsystem, max 10 personer, 9. stöd under RPS acceptanstestperiod, 10. analys och felsökning av inkomna skriftliga testrapporter, 11. felavhjälpning, 12. om identifierade fel skriftlig åtgärdsplan för identifierade fel, 13. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö Avtalade tider Avtalade tider etapp 1: - Leverantörens installation och verifiering av standardsystem ska ske inom fjorton (14) kalenderdagar efter installerad test- och utbildningsmiljö. - Acceptanstest och leveransgodkännande av standardsystemet i etapp 1 ska vara genomförd inom en (1) månad efter installerat standardsystem. 3 Avser installation av hårdvara, operativsystem och databaser. 4 För vad som omfattas i systemleveransen se ovan avsnitt Leverans av standardsystem i etapp 1.

13 Bilaga 2 Beskrivning av projektet och dess leveranser 13 (28) PVS / Godkännande För godkännande av leverans standardsystem, etapp 1: - För godkännande av standardsystem får det inte finnas några fel/brister på nivå 1 Blockerande eller nivå 2 Hindrande. Om det finns fel/brister på nivå 1 eller 2 efter avtalad acceptanstestperiod varvid ett leveransgodkännande inte kan ges räknas detta som leveransförsening. Därtill ska åtgärder av fel/brister på nivå 3 Störande, max få uppgå 10 st. i en överenskommen restlista, samt ha en överenskommen åtgärdstid. - Fel/brister på nivå 4 Kosmetiska hindrar inte godkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 5.3 Etapp 2 Etapp 2 startar omedelbart efter godkänd etapp Etappens omfattning Etappen omfattar att färdigställa och leverera avtalat system och avtalad dokumentation. Leveransen omfattar alla anpassningar för RPS. Anpassningar kan levereras både i form av konfiguration eller utveckling. Vilka krav som kräver anpassningar och därmed behöver detaljspecificering och eventuell teknisk design framgår i definierade krav i bilaga 1, Kravspecifikation på två sätt: 1. I kolumn F, Anmärkning, har RPS angett "Innehåll detaljspecificeras" om kravet innehållsmässigt behöver RPS-anpassas genom konfigurering av en standard- eller av Leverantören utvecklad funktion. Detta kan innebära att RPS anger värden eller urval. Exempel på det som avses: kravet är en gallringsfunktion, men vilka gallringsregler som ska kunna tillämpas måste detaljspecificeras och sedan realiseras. 2. I kolumn K, Realiseras, har Leverantören angett behov av detaljspecificering genom att ange K = konfiguration (ingår i standardsystemet, men måste konfigureras för RPS räkning) eller U = utveckling (måste utvecklas för RPS räkning). Har Leverantören i angiven kolumn istället angett: S = standard (ingår i standardsystemet) så förutsätts att kravet inte behöver detaljspecificeras. Utöver att genomföra anpassningar som framgår från kravspecifikation i bilaga 1 ingår även i etappen att realisera de integrationer som definieras

14 Bilaga 2 Beskrivning av projektet och dess leveranser 14 (28) PVS / nedan under avsnitt Integrationer med omvärlden. För detta ansvarar Leverantören. Vidare omfattar etappen att Leverantören i RPS verifierar avtalad prestanda samt att RPS acceptanstestar hela leveransen hos RPS samt granskar avtalad dokumentation Leverans av avtalat system och dokumentation i etapp 2 Leveransen för etapp 2 omfattar 100 % av alla skall-krav och 100 % av alla överenskomna bör-krav definierade i bilaga 1, Kravspecifikation. För framtagning av en detaljerad kravspecifikation och tillhörande teknisk designspecifikation ansvarar Leverantören och RPS deltar. Framtagna specifikationer ska godkännas av RPS. Senast på avtalad leveransdag ska avtalat System vara installerat i RPS testmiljö och all avtalad dokumentation överlämnad. Till avtalad leveransdag ska Leverantören också visa på att avtalad prestanda kan uppnås i en produktionsmiljö. Detta genom att verifiera på ett sådant sätt att testen blir så produktionslik som möjligt. Behövs speciell programvara för att påvisa prestandan ska denna tillhandahållas av Leverantören under testperioden. Denna programvara ska efter godkänd prestandatest avinstalleras från RPS miljö. RPS ansvarar för att grunddata är levererad eller registrerad enligt Leverantörens dokumenterade anvisningar Integrationer med omvärlden Leverantörens åtagande innefattar realisering av nedanstående integrationer. Kravkolumnen refererar till relaterade krav i bilaga 1 Kravspecifikation. Integration Refererade krav Kommentar Behörighetssystem IFS 228- IFS 238 Active Directory med Kerberosverifiering Polisens händelselogg IFS 205 IFS 226 E-post IFT 242 F 309 Inleveransarea F 216 Anslutning pilotsystem Exchange Server Bilaga 4, Inleveransspecifikation

15 Bilaga 2 Beskrivning av projektet och dess leveranser 15 (28) PVS / Övervakning, fånga systemmeddelande IFT 239 IFT 241 Adobe LiveCycle ES3 F 281 F RPS leveranser RPS leveranser etapp 2 i relation till Leverantörens införandeprojekt: 1. uppsatt produktionsmiljö enligt Leverantörens anvisningar 5, 2. deltagande i detaljering av krav och teknisk designarbete, 3. skriftligt godkänna detaljkrav- och teknisk designspecifikation, 4. tillhandahållande och registrering av grunddata enligt Leverantörens anvisningar, 5. medverka i genomförande av integrationer med omvärlden, 6. medverka vid installation av avtalat system i test-, utbildningsmiljö, 7. installation av avtalat system i produktionsmiljön, 8. testplaner och testfall, 9. testdata, 10. acceptanstest av avtalad leverans, exklusive prestandatester, 11. testprotokoll med tillhörande testrapporter avseende acceptanstest av avtalad leverans Leverantörens avtalade leveranser Leverantörens avtalade leveranser för etapp 2: 1. detaljkravspecifikation och teknisk designspecifikation utifrån avtalad leverans, 2. vara RPS behjälplig med vilken grunddata och hur denna ska läggas in. Vid större register ska Leverantören vara behjälplig att läsa in grunddata, 3. vid behov uppdateringar av anvisningar på hur test-, utbildnings- och produktionsmiljö sätts upp, 4. leverans av avtalat System inkluderande anpassningar 6, 5. leverans av integrationer med omvärlden 7, 6. installation av avtalat System i test- och utbildningsmiljö, 5 Avser installation av hårdvara, operativsystem och databaser. 6 För vad som omfattas i systemleveransen se ovan avsnitt Leverans av avtalat System och avtalat dokumentation i etapp 2 7 För vad som omfattas, se ovan avsnitt Integrationer med omvärlden

16 Bilaga 2 Beskrivning av projektet och dess leveranser 16 (28) PVS / stöd vid installation av avtalat System i produktionsmiljö, 8. verifiering av avtalad prestanda i produktionsmiljö utifrån avtalade krav, 9. skriftlig rapport på hur verifiering av prestanda har genomförts, utfall och eventuell åtgärdsplan, 10. verifiering att avtalad leverans är korrekt uppsatt i alla tre definierade miljöer, 11. stöd under RPS acceptanstestperiod, 12. analys och felsökning av inkomna skriftliga testrapporter, 13. felavhjälpning, 14. om identifierade fel - skriftlig åtgärdsplan för identifierade fel, 15. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö samt stödja införande av rättningsreleaser i produktionsmiljö Avtalade tider Avtalade tider för etapp 2: - Leveransdag av avtalad leverans ska ske senast åtta (8) månader efter Avtalets undertecknande. - Acceptanstest av leverans i etapp 2 ska vara genomförd inom en (1) månad efter faktiskt leveransdag Godkännande För godkännande av avtalad leverans, etapp 2: - För godkännande av avtalad leverans etapp 2 får det inte finnas några fel/brister på nivå 1 Blockerande eller nivå 2 Hindrande. Om det finns fel/brister på nivå 1 eller 2 efter avtalad acceptanstestperiod varvid ett leveransgodkännande inte kan ges räknas detta som leveransförsening. Därtill ska åtgärder av fel/brister på nivå 3 Störande, max få uppgå 10 st. i en överenskommen restlista, samt ha en överenskommen åtgärdstid. - Fel/brister på nivå 4 Kosmetika hindrar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 5.4 Etapp 3 Etapp 3 startar omedelbart efter godkänd etapp 2.

17 Bilaga 2 Beskrivning av projektet och dess leveranser 17 (28) PVS / Etappens omfattning Etappen omfattar att verifiera hela processen och systemlösningen genom att från tre piloter (källsystem) leverera in skarp produktionsdata till e-arkivet. Pilotanslutningar kommer att drivas av RPS. Under etappen ska också eventuella överenskomna restpunkter från ett leveransgodkännande vara åtgärdade och verifierade av Leverantören samt acceptanstestade av Beställaren RPS leveranser RPS leveranser etapp 3 i relation till Leverantörens införandeprojekt: 1. rensning av testdata i produktionsmiljö, 2. testplaner och testfall, 3. inläsning av leveranser från tre pilotsystem, 4. acceptanstester av genomförda leveranser, 5. testprotokoll med tillhörande testrapporter avseende acceptanstester av genomförda leveranser, Om överenskommelse om restpunkter från ett leveransgodkännande etapp 2: 6. medverka vid ominstallation av avtalat system i test-, utbildningsmiljö, 7. acceptanstester verifiering av att överenskomna restpunkter är åtgärdade, 8. testprotokoll med tillhörande testrapporter avseende acceptanstester, överenskomna restpunkter är åtgärdade Leverantörens avtalade leveranser Leverantörens avtalade leveranser för etapp 3: 1. rensning av testdata i produktionsmiljö, 2. testning av skarpt testdata, 3. beredskap för ändringshantering utifrån resultat av testning på skarpt testdata, Om överenskommelse om restpunkter från ett leveransgodkännande etapp 2: 4. installation av nya releaser efter korrigerande åtgärder av avtalat system i test- och utbildningsmiljö 8, 8 Är restpunkten av prestandakaraktär ansvarar Leverantören av verifieringen på motsvarande sätt som under etapp 2.

18 Bilaga 2 Beskrivning av projektet och dess leveranser 18 (28) PVS / releaseförteckning över förändrad funktionalitet, 6. verifiering att avtalat system är korrekt uppsatt i test- och utbildningsmiljö, 7. uppdatering av avtalade dokument utifrån överenskomna restpunkter, 8. stöd på plats under RPS acceptanstestperiod, 9. felavhjälpning, 10. analys och felsökning av inkomna skriftliga testrapporter, 11. om identifierade fel - skriftlig åtgärdsplan för identifierade fel Avtalad tidplan Avtalad tidplan för etapp 3: - Åtgärder på eventuella överenskomna restpunkter ska vara levererade och verifierade inom två (2) månader efter leveransgodkännande av etapp 2. - Acceptanstester av åtgärdade restpunkter ska vara genomförd inom en (1) månad efter faktisk leveransdag. - Acceptanstester av leveranser från tre pilotsystem ska vara genomförd tre (3) månader efter godkänd leverans etapp Godkännande För godkännande av avtalad leverans, etapp 3: - För godkännande avtalad leverans etapp 3 får det inte finnas några fel/brister på nivå 1 Blockerande, nivå 2 Hindrande eller på nivå 3 Störande. Om det finns fel/brister på nivå 1-3 efter avtalad acceptanstestperiod varvid ett leveransgodkännande inte kan ges räknas detta som leveransförsening. - Fel/brister på nivå 4 Kosmetika hindrar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 5.5 Etapp 4 Etapp 4 startar omedelbart efter godkänd etapp 3.

19 Bilaga 2 Beskrivning av projektet och dess leveranser 19 (28) PVS / Etappens omfattning Etappen omfattar att produktionssätta e-arkivet och överlämna slutgiltig dokumentation från Leverantörens införandeprojekt RPS leveranser RPS leveranser etapp 4 i relation till Leverantörens införandeprojekt: 1. eventuell rensning av testdata i produktionsmiljö, 2. installera leveransgodkänd release från testmiljö till produktionsmiljö, 3. officiellt ta systemet i produktion, 4. produktionssättningsprotokoll, 5. påbörja inläsning av leveranser från de tre pilotsystemen, inledningsvis från pilotmyndigheterna, 6. överlämning av produktionssatta delar till förvaltning och drift Leverantörens avtalade leveranser Leverantörens avtalade leveranser för etapp 4: 1. eventuell rensning av testdata i produktionsmiljö, 2. uppdatering av leveransgodkänd release i produktionsmiljö, 3. medverka vid produktionssättning och under två veckor efter produktionssättning, 4. slutgiltig överlämning av avtalad dokumentation, 5. överlämning av all projektdokumentation som tas fram i projektet, 6. slutrapport för projektet, 7. avslut av Leverantörens införandeprojekt. Om fel uppkommer vid produktionssättning eller inom två veckor från produktionssättning: 8. analys och felsökning av inkomna skriftliga testrapporter, 9. felavhjälpning, 10. om identifierade fel - skriftlig åtgärdsplan för identifierade fel, 11. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö samt stödja införande av rättningsreleaser i produktionsmiljö.

20 Bilaga 2 Beskrivning av projektet och dess leveranser 20 (28) PVS / Avtalad tidplan Avtalad tidplan för etapp 4: - Produktionssättning ska ske inom en (1) månad efter godkännande av etapp 3. - Leverantörens införandeprojekt ska vara avslutat inom en (1) månad efter godkänd produktionssättning Godkännande För godkännande av hela leveransen, etapp 4: - För godkännande avtalad leverans etapp 4 får det inte finnas några fel/brister på nivå 1 Blockerande, nivå 2 Hindrande eller på nivå 3 Störande. Om det finns fel/brister på nivå 1-3 efter avtalad acceptanstestperiod varvid ett leveransgodkännande inte kan ges räknas detta som leveransförsening. - Fel/brister på nivå 4 Kosmetika hindrar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 6 Optioner Inom upphandlingens ram finns följande optioner: - Utökade Licenser, support- & underhåll - Utökad supporttjänst - Tilläggstimmar för specificerade roller - Utbildning. - Förbereda nya leveranser. - Integrering med lagringslösning och migrering. Samtliga optioner definieras i bilaga 1 Kravspecifikation fliken Prisangivelser. Nedan beskrivs optionen Integrering med lagringslösning samt migrering mer detaljerat då dessa kan ha ett beroende till projektets etapper. 6.1 Ny lagringslösning RPS arbetar med att införa en ny lagringslösning där man går från traditionell filbaserad lagring till en objektrelaterad lagringslösning. Då det är osäkert när detta skrivs om genomförande av ligger i fas med införande av en ny lagringslösning hanteras anslutning av Systemet

21 Bilaga 2 Beskrivning av projektet och dess leveranser 21 (28) PVS / till Polisens Lagringslösning som en option. Denna anslutning omfattas i Option integrering med lagringslösning. Antingen kan Option integrering med lagringslösning avropas så att den levereras i anslutning till Leverantörens införandeprojekt, etapp 2, eller så kan optionen avropas som ett mindre fristående uppdrag vid ett senare tillfälle inom avtalsperioden. Om avrop av optionen sker efter genomförande av Leverantörens införandeprojekt och därmed efter produktionssättning måste även Option migrering avropas. Denna option handlar om att flytta redan arkiverad information in i den nya lagringslösningen. 6.2 Option integrering med lagringslösning Option integrering med lagringslösning avropas antingen så att den levereras i anslutning till Leverantörens införandeprojekt, Etapp 2 eller som en fristående leverans. Om leverans ska kunna ske i anslutning till Leverantörens införandeprojekt ska avropet ske före påbörjande av Etapp Optionens omfattning Optionen omfattar att ansluta e-arkivet till RPS nya objektorienterade lagringslösning. Vid avrop under projektet ingår prestandatester och produktionssättning som del i Leverantörens införandeprojekt Etapp 2 respektive Etapp 4. Vid avrop i förvaltningsläge ingår prestandatester och produktionssättning som en del av Option - migrering Leverans Leverantörens åtagande innefattar realisering av nedanstående krav anpassat till Polisens Lagringslösning. Kravkolumnen refererar till relaterade krav i bilaga 1 Kravspecifikation. Integration Refererade krav Kommentar Lagringslösning IFT 212 IFT 215 IFT 217 IFT IFT 220

22 Bilaga 2 Beskrivning av projektet och dess leveranser 22 (28) PVS / RPS leveranser RPS leveranser Option integrering med lagringslösning i relation till Leverantörens leverans av optionen: 1. teknisk dokumentation kring Polisens Lagringslösning. 2. genomgång med Leverantören om Polisens Lagringslösning. 3. deltagande i detaljering av krav och teknisk designarbete, 4. skriftligt godkänna detaljkrav- och teknisk designspecifikation, 5. medverka vid installation av avtalat System innehållande funktion som stödjer optionen i test-, utbildningsmiljö, 6. testplaner och testfall, 7. testdata, 8. acceptanstest av avtalad leverans, exklusive prestandatester, 9. testprotokoll med tillhörande testrapporter avseende acceptanstest av avtalad leverans Leverantörens avtalade leveranser Leverantörens avtalade leveranser för Option integration med lagringslösning: 1. detaljkravspecifikation och teknisk designspecifikation utifrån avtalad leverans, 2. vid behov uppdateringar av anvisningar på hur sätta upp test-, utbildnings- och produktionsmiljö, 3. leverans av avtalat System innehållande funktion som stödjer optionen inkluderande anpassningar till Polisens Lagringslösning, 4. installation av avtalat System innehållande funktion som stödjer optionen i test- och utbildningsmiljö, 5. verifiering att avtalad leverans är korrekt uppsatt i alla definierade miljöer, 6. stöd under RPS acceptanstestperiod, 7. analys och felsökning av inkomna skriftliga testrapporter, 8. felavhjälpning, 9. om identifierade fel - skriftlig åtgärdsplan för identifierade fel, 10. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö samt stödja införande av rättningsreleaser i kommande produktionsmiljö.

23 Bilaga 2 Beskrivning av projektet och dess leveranser 23 (28) PVS / Avtalad tidplan Avtalad tidplan för Option integration med lagringslösning: - Om avrop sker med leverans inom Leverantörens införandeprojekt ska optionen levereras samtidigt och med samma förutsättningar som leverans inom etapp 2. - Om avrop sker med leverans efter Leverantörens införandeprojekt ska leverans ske senast fyra (4) månader efter avrop Godkännande För godkännande av hela leveransen, Option integration med lagringslösning: - För godkännande av avtalad leverans Option integration med lagringslösning får det inte finnas några fel/brister på nivå 1 Blockerande eller nivå 2 Hindrande. Därtill ska åtgärder av fel/brister på nivå 3 Störande ha en överenskommen åtgärdstid. Åtgärdstiden får inte vara längre än 1 månad. - Fel/brister på nivå 4 Kosmetika hindrar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 6.3 Option migrering Option - migrering avropas om anslutningen till Polisens Lagringslösning ska ske efter genomförande av Leverantörens införandeprojekt Optionens omfattning Optionen omfattar att leverera ett fristående projekt, genomföra prestandatester, produktionssätta samt flytta redan arkiverad information så att den lagras i Polisens nya lagringslösning Leverans Leverantörens åtagande innefattar realisering av nedanstående krav anpassat till Polisens Lagringslösning. Kravkolumnen refererar till relaterade krav i bilaga 1, Kravspecifikation. Integration Refererade krav Kommentar Lagringslösning IFT 213 IFT 214

24 Bilaga 2 Beskrivning av projektet och dess leveranser 24 (28) PVS / RPS leveranser RPS leveranser Option - migrering i relation till Leverantörens leverans av optionen: 1. testplaner och testfall, 2. testdata, 3. acceptanstest av avtalad leverans; - exklusive prestandatester och testprotokoll, - samt med tillhörande testrapporter avseende acceptanstest av avtalad leverans. 4. installation av leveransgodkänd release i produktionsmiljö, 5. verkställa så att redan arkiverad information lagras in i Polisens Lagringslösning, 6. ta ny release i drift 7. produktionssättningsprotokoll, 8. överlämning av produktionssatta delar till förvaltning och drift Leverantörens avtalade leveranser för Option - migrering Förutsättningar för prestandatester avseende programvara är de samma som vid etapp 2: 1. Verifiering av avtalad prestanda utifrån avtalade krav, 2. skriftlig rapport på hur verifiering av prestanda har genomförts, utfall och eventuell åtgärdsplan, 3. verifiering att avtalad leverans är korrekt uppsatt i alla definierade miljöer, 4. stöd under RPS acceptanstestperiod, 5. analys och felsökning av inkomna skriftliga testrapporter, 6. felavhjälpning, 7. om identifierade fel - skriftlig åtgärdsplan för identifierade fel, 8. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö. 9. stöd vid installation av leveransgodkänd release i produktionsmiljö, 10. extra beredskap vid produktionssättning och under två veckor efter produktionssättning, 11. överlämning av teknisk dokumentation, 12. slutrapport för uppdraget.

25 Bilaga 2 Beskrivning av projektet och dess leveranser 25 (28) PVS / Om fel uppkommer vid produktionssättning eller inom två veckor från produktionssättning: 12. analys och felsökning av inkomna skriftliga testrapporter, 13. felavhjälpning, 14. om identifierade fel - skriftlig åtgärdsplan för identifierade fel, 15. om identifierade fel rättningsreleaser installerade på test- och utbildningsmiljö samt stödja införande av rättningsreleaser i kommande produktionsmiljö Avtalad tidplan Avtalad tidplan för Option - migrering: - Option integrering med lagringslösning och Option - migrering ska tillsammans levereras senast fyra månader efter avrop Godkännande För godkännande av hela leveransen, Option - migrering: - För godkännande av avtalad leverans Option - migrering får det inte finnas några fel/brister på nivå 1 Blockerande eller nivå 2 Hindrande. Därtill ska åtgärder av fel/brister på nivå 3 Störande ha en överenskommen åtgärdstid. Åtgärdstiden får inte vara längre än 1 månad. - Fel/brister på nivå 4 Kosmetika hindrar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. För definition av fel/brister se bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering. 7 Övriga åtaganden 7.1 Resurser Leverantören har ansvar för att säkra att det finns tillräckligt med resurser med rätt kompetens som skyndsamt kan utföra åtaganden enligt avtal. Följande resurser från Leverantören har preliminärt bedömts behövs: resurser för projektledning, teknisk installation av standardsystem, konfigurering, utveckling integrationsarbete, prestandatester, detaljspecificering och design, samt stöd i testarbete.

26 Bilaga 2 Beskrivning av projektet och dess leveranser 26 (28) PVS / RPS har ansvar för att säkra att det finns tillräckligt med resurser med rätt kompetens som skyndsamt kan utföra åtaganden enligt avtal. Följande RPS-resurser har preliminärt bedömts behövs: projektledare, verksamhetsspecialister, arkivarie, arkitekt, säkerhetsexpert, testansvarig och testare, jurist, kommunikatör, konfigurationsansvarig, blivande förvaltare, experter på miljöer som ska integreras, förvaltare och utvecklare från levererande system samt tekniker. 7.2 Utförande i beställarens lokaler Allt projektarbete som inte omfattar utveckling och underhåll av standardsystemet ska genomföras i RPS lokaler. Det betyder att Leverantören kan behöva en utvecklingsmiljö hos RPS. Detta ska påtalas för RPS vid projektstart. Leverantören är själv ansvarig för installation och underhåll av denna miljö. RPS ansvarar för att tillhandahålla miljöer, arbetsplatser och nödvändig utrustning för projektmedlemmar. Detta med undantag av programvara för prestandatester, se leveranser etapp Kompetensöverföring Leverantören har ett ansvar att löpande arbeta med kompetensöverföring till RPS. Målet är att RPS i hög grad ska klara sig själva när införandeprojektet är avslutat. Det betyder att RPS ska kunna ansluta ett nytt system eller ta fram en ny inleveransspecifikation utan stöd av Leverantören. 7.4 Testdata Under projektets etapp 1 ska Leverantören tillhandahålla testdata. Denna testdata behöver inte vara specifik för RPS. Från och med etapp 2 tillhandahåller RPS testdata för de tester som utförs inom Polisen. 7.5 Grunddata Under projektets etapp 1 ska Leverantören tillhandahålla grunddata. Denna grunddata behöver inte vara specifik för RPS. Från och med etapp 2 så tillhandahåller RPS grunddata efter anvisningar från Leverantören. 8 Överlämning och stängning av projekt 8.1 Överlämning till beställaren Varje leverans i etapp 1-4 godkänns skriftligt av programstyrgrupp.

27 Bilaga 2 Beskrivning av projektet och dess leveranser 27 (28) PVS / Projektavslut Leverantörens införandeprojekt avslutas enligt plan efter etapp 4 efter godkännande i programstyrgruppen. Förutsättningar för avslut är att det finns skriftliga leveransgodkännanden för etapp Projektdokumentation och rapportering 9.1 Projektdokumentation - Krav och design ska finnas dokumenterade. - Beslut ska protokollföras. - Projektdokumentation ska finnas sammanförda i ett projektbibliotek hos RPS. - Dokument ska versionshanteras. 9.2 Statusrapportering Leverantören ska leverera en statusrapport till varje projektstyrgrupp. Statusrapporten ska innehålla rubrikerna: - Uppföljning utifrån planerade aktiviteter och leveranser. - Planerade aktiviteter och leveranser. - Projektet i förhållande till tidplan. - Resursläge. - Risker med förslag till åtgärd. - Framsteg och möjligheter. 9.3 Finansiell rapportering Leverantören ska leverera en finansiell rapportering till varje projektstyrgrupp. I rapporten ska framgå vad som är beställt, hur mycket som är förbrukat och hur detta står i förhållande till färdigställandegraden. 10 Kommunikationsplan En kommunikationsplan kommer att tas fram och omfatta kommunikationsinsatser för hela Polisen.

28 Bilaga 2 Beskrivning av projektet och dess leveranser 28 (28) PVS / Nedan listas de kommunikationsinsatser som Leverantören medverkar vid inom ramen för Leverantörens införandeprojekt: - Informationstillfälle, med demonstration, för arkivarier inom Polisen. - Informationstillfälle, med demonstration, för projektets projektstyrgrupp. - Informationstillfälle, med demonstration, för projektets programstyrgrupp. - Informationstillfälle, med demonstration, för projektgruppen. - Informationstillfälle för arkitekter, drift samt säkerhetsgruppen.

29 Bilaga 3, Samverkan och styrning 1 (14) PVS / Bilaga 3 Samverkan och styrning

30 Bilaga 3, Samverkan och styrning 2 (14) PVS / INNEHÅLL 1 SYFTE MED DETTA DOKUMENT SAMVERKAN LEVERANTÖRSSAMVERKAN Strategisk nivå Taktisk nivå Operativ nivå Under införandeprojektet Projektmodell I förvaltningsläge Förvaltnings- och Supporthantering SERVICENIVÅER (SLA) Tillämpning Omfattning support och underhåll Underhållstjänst standardsystem Underhållstjänst avseende anpassningar till standardsystem Underhållstjänst avseende ingående 3:e partsprodukter Kundstöd Support Prioriterings- och servicenivåer störningsärenden Prioriterings- och servicenivåer övriga ärenden Mätning, rapportering, återkoppling Ansvarsfrihet Ändring av SLA-nivåer... 14

31 Bilaga 3, Samverkan och styrning 3 (14) PVS / shistorik Datum Ändring Handläggare Ann Rosenlind

32 Bilaga 3, Samverkan och styrning 4 (14) PVS / Syfte med detta dokument Syftet med detta dokument är att beskriva samarbetet mellan Leverantören och Rikspolisstyrelsen (RPS). 2 Samverkan RPS:s förutsätter en hög grad av samverkan, i projektet för Digital arkivtjänst och i förvaltningsläget, med ett gemensamt ansvar för ett lyckat resultat, men där RPS och Leverantör har sina tydliga roller och tydliga leveranser. RPS beskriver nedan övergripande hur samverkan och styrning ska genomföras. RPS ser positivt på ett arbetssätt som är ITIL-baserat. 3 Leverantörssamverkan För att uppnå god samverkan mellan RPS och Leverantören ska båda parter säkerställa att ansvariga på strategisk, taktisk och operativ nivå tillsätts. Namn och kontaktuppgifter på dessa personer hos Leverantören ska anges. 3.1 Strategisk nivå Syftet med den strategiska nivån är att diskutera strategisk framtid, verksamhetsutveckling, relationsfrågor. Den strategiska nivån är den högsta nivån på för eskalering av gemsamma frågor. På strategisk nivå ska Leverantören säkerställa att det för avtalet med RPS finns representation från Leverantörens verkställande ledning och en ansvarig Avtalsägare för att teckna avtal, samt en Huvudkontaktperson med huvudansvarig för Leverantörens samtliga leveranser till RPS. RPS ska säkerställa att det vid RPS finns en ansvarig Avtalsägare som kan teckna avtal samt en huvudansvarig Huvudkontaktperson för kontakter med Leverantören och som kan diskutera leveranser utifrån fastställda strategier. Samverkan sker när endera parten finner behov att lyfta strategiska frågor eller eskalera problem och centrala frågeställningar. Byte av Avtalsägare eller Huvudkontaktperson ska kommuniceras skriftligt till andra parten. Ingen ersättning utgår för Avtalsägares/Huvudkontaktpersons tid eller omkostnader.

33 Bilaga 3, Samverkan och styrning 5 (14) PVS / Taktisk nivå På den taktiska nivån säkerställs avtalsfrågor, kvalitetsuppföljning, prognoser, uppföljning av eget åtagande enligt avtal samt styrning av kompetens och resurser. Den taktiska nivån är den mellersta nivån för eskalering av gemsamma frågor. På taktisk nivå ska Leverantören säkerställa att det finns en Affärsansvarig för RPS som är ansvarig för Leverantörens utförande enligt avtal, ansvarig för att hantera klagomål samt ansvarig för kommunikation. Den affärsansvariga ska inom ramen för avtalet ha mandat att företräda Leverantören kring affärsmässiga frågor i relation till RPS. RPS ska säkerställa att det från deras sida finns en Affärsansvarig med ansvar för uppföljning av att leverans sker enligt avtal, ansvarig för Leverantörsstyrning samt ansvarig för kommunikation. Den affärsansvariga ska inom ramen för avtalet ha mandat att företräda RPS kring affärsmässiga frågor i relation till Leverantören. Under införandeprojektet deltar Leverantörens affärsansvarig i projektstyrgruppen, med frekvens en (1) gång per månad och i vilken RPS:s affärsansvarig sitter som styrgruppsordförande. Vid behov sammankallas till separata möten där avtalsmässiga frågor hanteras mellan parternas affärsansvariga. I support och förvaltningsläge sker samverkansmöten mellan affärsansvariga minst två gånger per år. Vid mötena ska bland annat uppföljning göras av hur samverkan avlöper, uppföljning av SLA:er (Service Level Agreement), planer för nya releaser och behov av större ändringar hanteras. Parterna har också att informera varandra om planerade större förändringar som kan påverka samverkan eller leveransen. Byte av Affärsansvarig ska kommuniceras skriftligt till andra parten. Ingen ersättning utgår för affärsansvariges tid eller omkostnader. 3.3 Operativ nivå På den operativa nivån genomförs operativt planerade, förebyggande och uppföljande arbete, samt hantering av utredningar vid ändringar och problem. Den operativa nivån är den lägsta nivån på för eskalering av gemsamma frågor. På operativ nivå ska Leverantören säkerställa att det finns en kontaktperson. RPS ska ha motsvarande kontaktperson. Rollerna för kontaktpersonerna ser något annorlunda ut om man befinner sig i projektläge eller i förvaltningsläge, se nedan för närmare beskrivning.

34 Bilaga 3, Samverkan och styrning 6 (14) PVS / Under införandeprojektet Under införandeprojektet ska Leverantören ha en utsedd Projektledare med projektansvaret för Leverantörens leveranser. Projektledaren ska också ha mandat att företräda Leverantören inom överenskomna projektramar kring operativa frågor. I arbetet innefattas att planera, leda och följa upp Leverantörens införandeprojekt och dess leveranser. Projektledaren ska ha mandat att ta beslut för att lösa problem och en definierad ram inom vilken projektledaren kan ta direkta beslut om ändringshantering. Leverantörens projektledare förväntas sitta i RPS:s lokaler under införandeprojektets genomförande. Ersättning för projektledarens tid och omkostnader ingår i ersättning för Leverantörens införandeprojekt. RPS ska ha en motsvarande Projektledare som har till ansvar att planera, leda och följa upp RPS:s projekt och dess leveranser. Projektledaren ska ha mandat att ta beslut för att lösa problem och en definierad ram inom vilken projektledaren kan ta direkta beslut om ändringshantering. Samverkan sker via löpande projektmöten mellan respektive parts projektledare. RPS:s projektledare är sammankallande. Rapportering sker via projektstyrgrupp där båda projektledarna är föredragande Projektmodell RPS tillämpar projektmodellen PROPS (XLPM). Leverantörens införandeprojekt och förvaltning ska drivas på svenska. Personal som deltar i leverantörens införandeprojekt och kommande förvaltning samt support ska därför kunna tala och skriva svenska I förvaltningsläge I förvaltningsläge ska Leverantören tillhandahålla en Samordningsansvarig som hanterar operativa frågeställningar. Samordningsansvarig har ansvaret för Leverantörens leveranser och mandat att företräda Leverantören inom överenskomna support- och förvaltningsramar kring operativa frågor. Ersättning för kontaktpersonens tid och omkostnader ingår i ersättning för support och förvaltning.

35 Förfrågning Ärende Lösning Ärende Uppgjord av Bilaga 3, Samverkan och styrning 7 (14) PVS / Motsvarande kontaktperson hos RPS är Förvaltningsansvarig som ska säkerställa att det från RPS finns en ansvarig för uppföljning, en ansvarig för tjänster samt en ansvarig för hantering av incidenter och problem. Samverkan sker via löpande avstämningar samt minst fyra avstämningsmöten per år. Vid mötena ska bland annat volym/trendstatistik, uppföljning av inrapporterade fel och brister, uppföljning av SLA:er, planer för nya releaser och behov av ändringshantering hanteras. 3.4 Förvaltnings- och Supporthantering RPS har en supportorganisation som innebär: Användare inom RPS RPS Helpdesk (1 st line support) Support/Förvaltning (2 nd line support) Tjänstegränssnitt för SLA Leverantör (3 rd line support) Figur 1 Supportorganisation 4 Servicenivåer (SLA) Detta avsnitt beskriver de servicenivåer (SLA) som gäller för leverans av förvaltningsstödjande tjänster för Polisens e-arkiv. 4.1 Tillämpning SLA -nivåerna skall mätas och följas upp kvartalsvis, rapporteras till RPS samt utgör underlag för ständiga förbättringar av tjänster och tjänstehantering. Detta dokument beskriver en servicenivå, benämnd normal nivå.

36 Bilaga 3, Samverkan och styrning 8 (14) PVS / Brister och fel i servicenivå kan ligga till grund för viten, specificerade i Avtalet. 4.2 Omfattning support och underhåll Detta avsnitt reglerar omfattning av underhåll och support. Ersättning sker via en underhålls- och supportavgift, se bilaga 1 Kravspecifikation. Vid varaktigt eller ofta förekommande överskridande av SLA-nivåerna ska Leverantören vidta de åtgärder som krävs för att uppnå och hålla de överenskomna nivåerna Underhållstjänst standardsystem Följande ingår: - Rätt att använda det avtalade standardsystemet inom Polisen enligt den omfattning definierad i Avtalet. - Rätt till nya uppdateringar och uppgraderingar av det avtalade standardsystemet. - Underhållstjänsten inkluderar nya eller reviderade standardunderhållsreleaser av det standardsystem som Leverantören kan komma att släppa från tid till annan. Minst med frekvens en (1) komplett release per år innehållande förbättrad funktionalitet. Underhållsreleaser omfattar versioner, releaser och servicereleaser. - Eventuella frakter och mediakostnader för nya standardunderhålls releaser ingår. - Leverantören ska hålla Polisen informerad om nya standardunderhållsreleaser av programmet samt göra dem tillgänglig för Polisen Underhållstjänst avseende anpassningar till standardsystem Anpassningar till standardsystem ägs av Polisen, men Leverantören säkerställer att de anpassningar som Leverantören har utfört upprätthålls och fungerar genom att: - Garantera att anpassningar som Leverantören utfört enligt avtalet och avrop på detta avtal fortsatt fungerar enligt överenskommen specifikation efter uppdatering av standardunderhållsreleaser. Detta gäller så länge inte Polisen själv har förändrat anpassningarna. - Säkerställa att anpassningar som Leverantören har utfört fortsatt fungerar enligt överenskommen specifikation inför varje ny leverans av en standardunderhållsrelease.

37 Bilaga 3, Samverkan och styrning 9 (14) PVS / Underhållstjänst avseende ingående 3:e partsprodukter I underhållstjänsten ingår underhåll för i ingående 3:e partsprodukter enligt definition i bilaga 1 Kravspecifikation. Anpassningar av standardsystemet till versioner av ingående 3:e-partsprodukter säkerställs genom att Leverantören garanterar att standardsystemet anpassas till nya versioner av ingående 3:e-partsprodukter. Eftersläpningen av anpassningar är maximalt två (2) versioner bakåt gentemot ingående 3:e-partsprodukt. Slutar tillverkaren av en 3:e-partsprodukt att underhålla produkten ska Leverantören tillhandahåll en ersättningsprodukt med motsvarande funktionalitet till samma kostnad för RPS. Leverantören säkerställer att ingående 3:e-partsprodukter fungerar i samband med nya standardunderhållsreleaser genom att genomföra tester. Leverantören ska informera och planera för eventuella förändringar, då plattformskrav förändras som påverkar avtalat standardsystem Kundstöd Leverantören håller en uppbyggd kundstödsorganisation för avtalat standardsystem med dess kundunika anpassningar, som Polisen kan vända sig till med problem, fel, frågor, förbättringsförslag eller när det i övrigt finns behov av stöd. Kontakt med kundstöd kan ske via mail eller telefon. Förfrågningen till Leverantörens kundstöd kommer från Polisens 2 nd line support enligt Figur 1 Supportorganisation. Leverantörens åtagande för kundstöd omfattar registrering av alla inrapporterade ärenden i anvisat ärendehanteringssystem, initial analys, prioritering av anmälda ärenden, problemavhjälpning, initiering av fördjupad problemanalys där så krävs, bevakning avseende åtgärdstider, eskaleringsrutiner etc. i syfte att bibehålla avtalade servicenivåer, löpande uppdatering om ärendets status/åtgärdsplaner tillgängliggjord till anmälaren och Polisens förvaltare samt avslut och slutrapportering om orsak och åtgärd till Polisen på inrapporterade ärenden. Partnerna skall upprätta en förteckning över administratörer hos Polisen som är behöriga att begära support av Leverantören. Polisen har tillgång till personlig assistans från Leverantörens kundstöd varje helgfri vardag under kontorstid kl

38 Bilaga 3, Samverkan och styrning 10 (14) PVS / Utöver ordinarie helgdagar betraktas även midsommarafton, julafton och nyårsafton som helgdagar. Polisen ska utanför kontorstid kunna skicka in anmälningar. Svarstid för Kundstöd via telefon ska i genomsnitt vara kortare än två (2) minuter. Med svarstid avses kontakt med personal som tar hand om anmälan av ärende/besvarar ställd fråga Support Leverantören håller en uppbyggd supportorganisation som hanterar teknikoch applikationsstöd för avtalat standardsystem. Vid anmälningar av störningar i form av problem eller fel ska Polisen genomföra en egen felanalys innan anmälan genomförs till Leverantören. Efter anmälan ansvarar Leverantören för felanalys och åtgärd vid konstaterat fel. Polisen ansvarar för att förse Leverantören med information och underlag för att Leverantören ska kunna genomföra en sådan analys. Leverantören ska vid behov, efter överenskommelse, ges möjlighet att på plats i Polisens lokaler genomföra en felanalys i produktionsmiljö. Leverantören ansvarar för korrigering av konstaterat programfel i avtalat standardsystem. Detta inkluderar ingående tredjepartsprodukter, anpassningar för vilket Leverantören ansvarat och i vilka RPS inte genomfört några förändringar. Rättningar ska levereras i form av rättningsfiler, eller i nästkommande huvudrelease. Support ges på de två senaste versionerna av Leverantörens standardsystem Prioriterings- och servicenivåer störningsärenden Vid registrering av ärende i Leverantörens ärendehanteringssystem ska ärendet klassificeras med avseende på hur verksamhetskritiskt en störning bedöms vara. Med störning avses här problem såväl som fel. Klassificeringen sker utifrån nedanstående fyra definierade kategorier och styr prioritering av inkommande ärenden. Målet är alltid att återupprätta normal drift, så snart som möjligt och att minimera skadlig påverkan på verksamheten. Parterna ska enas om en bedömning av prioritetskategori vid en störningsanmälan. Om parterna inte kan enas gäller den kategori som Polisen anser. Vid loggning av ärenden ska det indikeras om prioriteringskategorin har ändrats.

39 Bilaga 3, Samverkan och styrning 11 (14) PVS / En störning kan temporärt åtgärdas med hjälp av en tillfällig lösning, en så kallad workaround. Denna workaround får endast användas under en begränsad tid innan den permanenta lösningen är tagen i bruk. Workaround får endast införas efter överenskommelse med förvaltningsansvarig och ska dokumenteras i ärendeloggen. Konsekvensen av att sätta in en workaround kan innebära att själva störningsärendet kvarstår, men sätts om till en lägre prioritetskategori än ursprungligt. Med arbetstid avses helgfria vardagar klockan För anmälda störningar finns fyra definierade prioriteringskategorier med tillhörande påbörjad felsökning och åtgärdstider: 1 Kritisk störning Påverkan på verksamheten är total. Applikationen är otillgänglig eller funktionaliteten mycket allvarligt nedsatt. Verksamhetskritiska funktioner kan inte utföras. Påbörjan av felsökning: Störningen ges högsta prioritet och felsökning påbörjas snarast, och maximalt inom två (2) arbetstimmar. Hanteringstid: Hantering av rapporterade störningar enligt kategori 1 ska per rullande kvartal genomsnittligt understiga sex (6) arbetstimmar. Tiden räknas från att ärendet anmäldes tills att ärendet återrapporterades med RPS godkännande av åtgärd eller enligt överenskommelse prioriterades ner på grund av en införd workaround. Åtgärdsgaranti: Åtgärdsgarantitiden för rapporterade störningar enligt kategori 1 för ett enskilt ärende uppgår till sexton (16) arbetstimmar. Tiden räknat från att ärendet anmäldes. Garantin gäller för de problem som kan hänföras till fel: - I standardsystemet. - I anpassningar för vilka Leverantören ansvarar. - Orsakat av Leverantörens handgrepp på RPS installation av systemet. Åtgärd innebär att störningen är löst permanent eller genom en workaround. 2 Allvarlig störning Påverkan på verksamheten är omfattande. Delar av systemet är otillgängligt eller funktionaliteten är allvarligt nedsatt. Delar av verksamhetskritiska funktioner är inaktiva, fungerar felaktigt eller har svarstider som avviker väsentligt från normala nivåer.

40 Bilaga 3, Samverkan och styrning 12 (14) PVS / Påbörjan av felsökning: Störningen ges hög prioritet och felsökning påbörjas inom sex (6) arbetstimmar. Hanteringstid: Hantering av rapporterade störningar enligt kategori 2 ska per rullande kvartal genomsnittligt understiga tolv (12) arbetstimmar. Tiden räknas från att ärendet anmäldes tills att ärendet återrapporterades med RPS godkännande av åtgärd eller enligt överenskommelse prioriterades ner på grund av en införd workaround. Åtgärdsgaranti: Åtgärdsgarantitiden för rapporterade störningar enligt kategori 2 för ett enskilt ärende uppgår till trettiotvå (32) arbetstimmar. Tiden räknat från att ärendet anmäldes. Garantin gäller för de problem som kan hänföras till fel: - I standardsystemet. - I anpassningar för vilka Leverantören ansvarar. - Orsakat av Leverantörens handgrepp på RPS installation av systemet. Åtgärd innebär att störningen är löst permanent eller genom en workaround. 3 Medelstor störning Användarna kan arbeta, men kan inte uppnå en normal produktivitet. Funktionell störning i systemet, om kan kringgås så att systemet trots detta kan användas. Påbörjan av felsökning: Felsökning ska påbörjas inom tjugofyra (24) arbetstimmar Hanteringstid: Hantering av rapporterade störningar enligt kategori 3 ska per rullande kvartal genomsnittligt understiga åttio (80) arbetstimmar. Tiden räknas från att ärendet anmäldes tills att ärendet återrapporterades med RPS godkännande av åtgärd eller enligt överenskommelse prioriterades ner på grund av en införd workaround. 4 Mindre allvarlig störning Påverkan på verksamheten är begränsad. Funktionalitet som inte har direkt påverkan på verksamheten fungerar inte som den ska eller behöver förändras. Hanteringstid: Hantering av rapporterade störningar enligt kategori 4 ska per rullande kvartal genomsnittligt vara åtgärdade till nästkommande ordinarie versionsuppdatering eller senast sex (6) månader efter anmälan.

41 Bilaga 3, Samverkan och styrning 13 (14) PVS / Prioriterings- och servicenivåer övriga ärenden Ärenden som inte relaterar till störningar klassificeras enligt nedanstående: 5 teknik- och applikationsstöd Ärenden av typen teknik- och applikationsstöd och som inte är att hänföra till någon störning. Hanteringstid: Svarstiden på ställda teknik- och applikationsstödsfrågor enligt kategori 5 ska per rullande kvartal genomsnittligt understiga åtta (8) arbetstimmar. 6 allmän fråga Ärenden av typen frågor som inte är att hänföra till någon störning. Hanteringstid: Svarstiden på ställda frågor enligt kategori 6 ska per rullande kvartal genomsnittligt understiga åtta (8) arbetstimmar. 7 Förbättringsförslag Ärenden av typen förbättringsförslag på standardsystemet. Hanteringstid: Återkoppling på ställda förslag till förbättringar görs löpande. Förslaget behandlas även på avstämningsmöten på operativ nivå. Vid återrapporteringen presenterar Leverantören hur man ser på inkommet förslag och om Leverantören är positiv till förslaget ett förslag till genomförandeprioritering och till vilken release lösningen planeras Mätning, rapportering, återkoppling Leverantören ska kontinuerligt mäta avtalade servicenivåer. I ärendehanteringssystemet hos Leverantören sker uppföljning, rapportering och återkoppling av alla ärenden. Månadsvis avrapporteras statistik, planerade aktiviteter och eventuella öppna ärenden till RPS förvaltningsansvarig. Uppföljning av uppfyllande av servicenivåer och övriga avstämningar sker i samband med avstämningsmöten mellan RPS förvaltningsansvarig och Leverantörens samordningsansvarig. Rapportering Följande information ska finnas att rapportera: - Hanteringstid och orsak för respektive ärende kategori Antal ärenden per respektive kategori.

42 Bilaga 3, Samverkan och styrning 14 (14) PVS / Genomsnittlig Påbörjan felsökning per respektive kategori Genomsnittlig Hanteringstid per respektive kategori. - Antal öppna ärenden, svarstider och andel ärenden som kunnat avslutas vid första kontakt. - Genomsnittlig svarstid för kundtjänst via telefon. - Även problem och kända fel ska ingå i rapporten. Vid behov ska det bakomliggande underlaget kunna granskas. 4.3 Ansvarsfrihet SLA-nivåerna skall mätas i de gränssnitt från vilken Leverantören har leveransansvar. Faktorer som ligger utanför Leverantörens kontroll, som påverkar användarnas upplevelse av tjänsten negativt, ska inte belastas Leverantören. Sådana faktorer kan till exempel vara brister i kommunikationstjänst som utnyttjas för att nå tjänsten, men som ligger utanför Leverantörens ansvar och kontroll. 4.4 Ändring av SLA-nivåer Parterna kan överenskomma om ändring av SLA-nivåer, inom avtalets ramar. Sådan överenskommelse ska vara skriftlig och hanteras enligt processen för förändringshantering. Under speciella omständigheter, som till exempel vid större uppgraderingar, kan parterna överenskomma om minskning i servicenivå under en begränsad tidperiod. En sådan överenskommelse skall vara skriftlig.

43 Bilaga 4 Inleveransspecifikation 1 (25) PVS /12 V1.0 Bilaga 4 Inleveransspecifikation För pilotsystemen K-RAR samt DurTvå

44 Bilaga 4 Inleveransspecifikation 2 (25) PVS /12 V1.0 Innehållsförteckning INNEHÅLL 4 1 Dokumentets syfte 4 2 Inledning Förklaring av tabeller Tillvägagångssätt 5 3 Vid leverans från DurTvå & K-RAR 6 4 Objekt Karta över objekten 7 5 Generellt brottsmålsschema Ärende Involverad person Anmälan Gods Engagerad personal 12 6 Specifikt DurTvå Ärende Involverad person Anmälan Engagerad personal Kallelse Tvångsmedel PM Rapport Protokoll Externt dokument Egna anteckningar 21 7 Specifikt K-RAR Ärende Involverad person Anmälan 24

45 Bilaga 4 Inleveransspecifikation 3 (25) PVS /12 V1.0 Datum Ändring Handläggare Ann Rosenlind

46 Bilaga 4 Inleveransspecifikation 4 (25) PVS /12 V1.0 INNEHÅLL 1 Dokumentets syfte För att säkerställa att leverans till e-arkivet är korrekt kontrolleras SIP mot schema (xds). Syftet med detta dokument är att beskriva informationssamband och förklara informationen som upprättas i två av Polisens brottsutredande system, K-RAR och DurTvå. Båda systemen, samt Bilder Inom Polisen BIP, ingår i införandeprojektet som pilotanslutningar till e-arkivet. 2 Inledning Information som idag upprättas i en brottsutredning är spridd över flera system. Ärendeprocessen beskrivs översiktligt i bilaga 10 Övergripande verksamhetsbeskrivning. Information tillhörande DurTvå, K-RAR presenteras här och tabellerna beskriver vad som ska ingå i inleveransen. Schemat tillåts justeras utifrån Leverantörens lösning för inleveransspecifikation men får inte frångå RPS krav på hantering av informationsobjekten. 2.1 Förklaring av tabeller Objektens relationer förklaras med hjälp av en övergripande karta. Objekten förklaras i detalj i tabellform nedan för respektive system och ordningen på objekten följer den övergripande kartan. Tabeller i gul färg representerar objekt, de i blå färg är specifika för DurTvå och de gröna är specifika för K-RAR. Gemensamt objekt Objekt specifikt DurTvå Objekt specifikt K-RAR Tabellens kolumner är: Namn Namnet på elementet/attributet. Om fet stil är elementet ett eget objekt E/A E om det är ett element och A för attribut S Om potentiellt sökbart Kard Anger objektets kardinalitet, d v s antal förekomster som kan finnas T Type: S (Text), N (Siffror), D (Datum), O (Objekt), B(Boolean), St (Struktur, CDatafält), Bi (Bilaga),

47 Bilaga 4 Inleveransspecifikation 5 (25) PVS /12 V1.0 Beskrivning An(Anteckning), Ad(Administrativt), Be(Berördperson), U(Uppgiftslämnare) Användning och kommentar CDatafält Element som är av typen St (Struktur) är CDatafält. CDatafält används där informationen inte behöver vara strukturerad men ändå ska vara med. Informationen sparas då som en XML-sträng men där strukturen på strängen inte kontrolleras direkt av schemat. Det går att validera strukturen i ett CDatafält också. Då behövs ett eget schema vilket kan följa med leveransen. Exempel på där CDatafält bedöms vara till hjälp är Gods. Gods finns i flera huvudkategorier där flertalet underkategorier finns i flera nivåer. Information i godsobjektet är inte relevant för att återsöka ärendet. Hur denna mängd av information kan struktureras tas därför inte hand av scheman beskrivna i detta dokument. Bilaga Bilaga kallas alla de handlingar, dokument, protokoll som ingår i ärendet. Dessa utgör egna objektstyper. Anteckning I DurTvå går det att som handläggare lägga till anteckningar till olika informationsobjekt. Detta är en egen objektstyp. Administrativt I DurTvå ligger information som kallas för Administrativt på flera informationsobjekt. Detta är en egen objektstyp. Svenska tecken Svenska tecken i elementens namn undviks. Defaultvärden och listor Ingen användning av defaultvärden, godkända format och strängar är definierade. Detta kommer att definieras tillsammans med verksamheten. 2.2 Tillvägagångssätt För systemen K-RAR och DurTvå visas i figur 2 en karta över hur informationen hänger ihop i systemen. Kartan visar hur objekten kommer att relatera till varandra när de levererats till e-arkiv. Scheman som beskrivs i detta dokument ska spegla allt det som syns systemen, även om samma information finns i bifogade handlingar. Till stor del kommer därför informationen att levereras i xmlformat men även komma med i olika sammanställningar (handlingar som rapporter och protokoll).

48 Bilaga 4 Inleveransspecifikation 6 (25) PVS /12 V1.0 Informationen har samlats in via; dokumentation om systemen, tillgång till DurTvå testmiljö, databastabeller i viss mån, systemdemonstration av respektive förvaltning. Aktiviteter för att skapa scheman hitta objekt och dess relationer hitta objektens attribut och definiera typer och antal skapa schema som speglar objekten och dess relationer 3 Vid leverans från DurTvå & K-RAR När DurTvå och K-RAR ska börja leverera till e-arkivet ska detta dokument och tillhörande scheman ligga till grund för hur informationen ska packas ihop. Men det återstår arbete med kvalitetssäkring och eventuell anpassning av scheman för systemens förvaltningar i samarbete med sektionen för ärendehantering. Ytterligare en aktivitet inför leverans är att tillsammans med verksamheten gå igenom och kategorisera vilka metadata som ska vara sökbara och ingå i xml-schemat och vilka metadata som endast ska ingå i handlingarna. Figur 1 Metadata i XML-schema och handlingar

49 Bilaga 4 Inleveransspecifikation 7 (25) PVS /12 V1.0 De scheman, för DurTvå och K-RAR, tillåts ändras beroende på vald Leverantörs lösning för inleveransspecifikation. 4 Objekt Här beskrivs objekten vars information hanteras i källsystemen DurTvå och K-RAR, i bilagan omnämnda som systemet/systemen. 4.1 Karta över objekten Figur 2 Karta över objekten

50 Bilaga 4 Inleveransspecifikation 8 (25) PVS /12 V1.0 Flera av objekten återfinns i de olika systemen. Objekten ser lika ut vad gäller relationer men informationen i skiljer sig en del beroende på system. Detta innebär att viss information kan komma att levereras från de båda systemet. Som beskrivs nedan är information som hör ihop uttagna till egna komplexa element. Det kan vara så att de är ett av de definierade objekten, se kartan ovan, men det kan också vara för att ge schemat en bättre struktur, ett sätt att undvika upprepningar. 5 Generellt brottsmålsschema Figur 3 Generella sobjekt som innehåller potentiellt sökbara element.

51 Bilaga 4 Inleveransspecifikation 9 (25) PVS /12 V Ärende Ärende är huvudobjekt i informationsstrukturen. Ärende med sitt diarenummer är det som binder ihop information levererat från olika system. Ärende har en 1 till 1 relation med anmälan vilket betyder att ett ärende endast har och kan ha en anmälan. Ärende kan ingå som underliggande ärende i ett annat ärende eller vara huvudärende och då ha ärenden som ingår i sig. Namn E/A Kard S T Beskrivning diarienr A 1 S S ingariarende E 0..1 S S Om ärendet är kopplat till ett annat ärende som är huvudärende/målnummer står dess diarienummer här. aklagarens E 0..1 S S Åklagarens diarienummer handlaggandeenhet E 1 S Handläggande enhet. Förkortning. underliggandearende E 0..* S S Flera ärenden kan höra ihop men det är alltid ett utsett till huvudärende/målnummer. Diarienummer på underliggande ärenden. atkomstskydd E 0..1 S historik E 1 St CDatafält, Ärendehistorik från DurTvå beskriver vad som hänt med ärendet under handläggning. RAR s historik är mer av en logg vad som gjorts med ärendet i systemet, exempelvis att en utskrift har gjorts beslut E 1 St CDatafält, Ärendebeslut från K-RAR och DurTvå skiljer sig åt till stor del och inget anses styra sökningen. involveradperson E 1..* O anmalan E 1 O Det finns alltid endast en anmälan kopplad till ett ärende. gods E 0..* O engageradpersonal E 1..* O Myndighetsanställd som är engagerad i ärendet Involverad person Involverad person är fysisk eller juridisk (kallad organisation i tabell nedan) med roll kopplad till ärendet. Exempelvis kan ett ärende involvera en fysisk person av rollen misstänkt, en juridisk person med rollen målsägare och en fysisk person med rollen vittne. En misstanke är alltid kopplad till ett brott. I xmlfilen kommer ärendets involverade personer tidigt och det är för att eventuella misstankar som tillhör brott och anmälan ska kunna referera till personen i fråga genom personens unika tekniska nyckel.

52 Bilaga 4 Inleveransspecifikation 10 (25) PVS /12 V1.0 Namn E/A Kard S T Beskrivning id A 1 Unikt tekniskt id på personen typ E 1 S Lista: Person, Företag/organisation eller Okänd personnr E 0..1 S S organisationsnr E 0..1 S S Gäller organisation verksamhet E 0..1 S Gäller organisation namn E 0..1 S Gäller organisation kon E 0..1 S Lista, M eller K skyddadpuppgift E 0..1 B Skyddad personuppgift fornamn E 0..1 S S Tvingande om typen är person efternamn E 0..1 S S Tvingande om typen är person mellanamn E 0..1 S S tilltalsnamn E 0..1 S S kallasfor E 0..1 S S oknamn E 0..1 S S medborgarskap E 0..1 S medborgarskap kod A 0..1 S Lista på landskoder fodelseland E 0..1 S fodelseland kod A 0..1 S fodelseort E 0..1 S organisation E 0..1 O Person kan vara juridisk adress E 0..* O telefon E 0..* O ombud E 0..* O Objekt, bara en av typen försvarare men flera annars. dagsbotsuppgifter E 0..1 O arbetsgivare E 0..1 O roll E 1..* O Adress Namn E/A Kard S T Beskrivning adress E 0..1 S Gatunamn och nummer postnr E 0..1 S ort E 0..1 S land E 0..1 S co E 0..1 S C/O Telefon Namn E/A Kard S T Beskrivning typ E 1 S nr E 0..1 S hemligt E 1 B epost E 0..1 S Går bara att fylla i om typ är e-post Dagsbotsuppgifter Namn E/A Kard S T Beskrivning civilstand E 0..1 B egenarsinkomst E 0..1 N sambosarsinkomst E 0..1 N

53 Bilaga 4 Inleveransspecifikation 11 (25) PVS /12 V1.0 taxeradarsinkomst E 0..1 N sambostaxarsinkomst E 0..1 N Make/maka/sambos taxerade inkomst kontrolldatumtax E 0..1 D taxeringsar E 0..1 D Bara datum, ingen tid taxkontrollavnamn E 0..1 S skulder E 0..1 N formogenhet E 0..1 N bidrag E 0..1 S barnhemmaunder18ar E 0..1 N forsorjningsplikt E 0..1 S taxeringskontrollutford E 0..1 S Eventuellt bara från K-RAR anteckningar E 0..1 S Eventuellt bara från K-RAR Roll En involverad person kan ha flera roller i ett och samma ärende. Namn E/A Kard S T Beskrivning namn E 1 S S Lista, namn på rollen id A 1 S Anmälan En anmälan ingår i ett ärende. Namn E/A Kard S T Beskrivning typ E 1 S Lista regdatum E 1 S D brottstidtill E 0..1 S D brottstidfran E 0..1 S D anmaltdatum E 1 S D Datum då anmälan gjordes. områdeskod E 1 S S brottsplatsadress E 1 S S brottsplatspostadress E 1 S S beskrivning E 1 S Fritextfält brott E 1..* O administrativt E 1 O Brott Varje anmälan innehåller en eller flera brottsrubriceringar med tillhörande brotsskoder. Namn E/A Kard S T Beskrivning brottskod E 1 S S brottsrubricering E 1 S S misstanke E 0..* O

54 Bilaga 4 Inleveransspecifikation 12 (25) PVS /12 V Misstanke Till varje brott kan en eller flera misstankar höra. En misstanke gäller endast en fysisk person(involveradperson), okänd eller känd. Namn E/A Kard S T Beskrivning brottsmisstankenr E 1 S misstanktperson E 1 S Ref till involverad person misstankebeslut E 1..* O Misstankebeslut Namn E/A Kard S T Beskrivning beslutsfattare E 1 S Namn på engagerad personal beslutsfattare A 1 S Titel på beslutsfattare titel beslutsdatum E 1 D myndighetskod E 1 S Ex 0800 beskrivning E 0..1 S Motivering beslutstyp E 1 S Lista Gods Föremål, huvudgrupp, undergrupp och antal är generella element för allt gods. Beroende på vilka grupper godset tillhör tillkommer fler element. Dessa element sparas ner i ett CDatafält vilket innebär att de inte definieras i detta schema. Ingen specifik information kommer från DurTvå. Namn E/A Kard S T Beskrivning id E 1 S foremal E 1 S huvudgrupp E 1 S undergrupp E 1 S antal E 1 N varde E 0..1 N Eventuellt bara från K-RAR anteckning E 0..1 S Eventuellt bara från K-RAR refgodspunkt E 0..1 S Eventuellt bara från K-RAR, Nummer på godspunkt nationelltsokbar E 1 B Eventuellt bara från K-RAR specinfo E 1 St CDatafält Engagerad personal Myndighetsanställd. Namn E/A Kard S T Beskrivning id E 1 S Unik teknisk nyckel, möjliggör referenser inom leveransen. namn E 1 S S Efternamn, förnamn namn titel A 0..1 S tjanstenr E 0..1 S telefon E 0..1 S

55 Bilaga 4 Inleveransspecifikation 13 (25) PVS /12 V1.0 orgenhet E 0..1 S S myndighetskod E 0..1 S 6 Specifikt DurTvå Leveranser som kommer från DurTvå behöver kontrolleras av två scheman som det är uppdelat här. Först av det gemensamma för brottsutredande system sedan av det som är specifikt DurTvå. Det som är specifikt DurTvå är bl.a. rapporter och protokoll, se de blå objekten i kapitel Karta över objekten vilket matchar de blå tabellerna nedan. Strukturen, hur alla objekt relaterar till varandra, är kvar i det specifika schemat för att objekten ska hamna i rätt kontext. Bilaga Bilaga är ett element som blir inkluderade av flera andra. Namn E/A Kard S T Beskrivning skapad E 1 D Datum rubrik E 0..1 S mediatyp E 0..1 S storlek E 1 S namn E 1 S beskrivning E 0..1 S forsattsbladmed E 0..1 B referense E 0..1 S Anteckning Anteckning är ett element som blir inkluderade av flera andra. Namn E/A Kard S T Beskrivning datum E 0..1 D Datum text E 0..1 S Fritext forfattare E 1 S Namn på författare rubrik E 0..1 S typ E 1 S Administrativt Adminstrativt är ett element som blir inkluderade av flera andra. Namn E/A Kard S T Beskrivning atnr E 0..1 S ejdurtva E 0..1 B enhet E 1 S

56 Bilaga 4 Inleveransspecifikation 14 (25) PVS /12 V1.0 Berörd person Berörd person är ett element som blir inkluderade av flera andra. Namn E/A Kard S T Beskrivning namn E 1 S Datum namn typ A 1 S Uppgiftslämnare Uppgiftslämnare är ett element som blir inkluderade av flera andra. Namn E/A Kard S T Beskrivning namn E 1 S Datum namn typ A 1 S 6.1 Ärende Elementen är beskrivna i det gemensamma, här beskrivs endast objekt. Namn E/A Kard S T Beskrivning prioritet E 0..1 N Eventuellt inte intressant information när ärendet är slutredovisat. En siffra. status E 1 S Utgår eventuellt då det antagligen alltid stängt när det skickas till arkivet, automatiskt ifyllt. fuledning E 1 Förundersökningsledning, Automatiskt ifyllt. rubrik E 0..1 S Ärenderubrik bevakningsdatum E 0..1 D Ett valt datum för att hitta ärenden värda att bevaka. senastparverkat E 1 D Automatiskt ifyllt. involveradperson E 1..* O anmalan E 1 O Det finns alltid endast en anmälan kopplad till ett ärende. gods E 0..* O engageradpersonal E 1..* O Myndighetsanställd som är engagerad i ärendet. arendebeslut E 1..* O Minst ett ärendebeslut finn i ärendet Involverad person Namn E/A Kard S T Beskrivning avliden E 0..1 B 0 eller 1 efternamntidigare E 0..1 S S bytear A 0..1 S Det år efternamn byttes Foraldrar E 0..1 S utbildning E 0..1 S anstallning E 0..1 S arbetsforhet E 0..1 S kompluppgifter E 0..1 S

57 Bilaga 4 Inleveransspecifikation 15 (25) PVS /12 V1.0 fotograferadar E 0..1 D Bara år daktadar E 0..1 D Bara år titel E 0..1 S svmedborgarear E 0..1 S S eller N forsakringsbolag E 0..1 S korkortsland E 0..1 S korkortsland kod A 0..1 S korkortsklass E 0..1 S civilstand E 0..1 B egenarsinkomst E 0..1 S sambosarsinkomst E 0..1 S skulder E 0..1 S formogenhet E 0..1 S bidrag E 0..1 S barnhemmaunder18ar E 0..1 N forsorjningsplikt E 0..1 S organisation E 0..1 O adress E 0..* O arbetsgivare E 0..1 O ombud E 0..* O Objekt, bara en av typen försvarare men flera annars. ersättningsansprak E 0..1 O forhor E 0..* O taxeringskontroll E 0..1 O roll E 1..* O Organisation Involverad person kan vara av typen juridisk. Organisationsnr och verksamhet har med objektet organisation att göra men det ligger som element på det gemensamma objektet InvolveradPerson. Namn E/A Kard S T Beskrivning type E 0..1 S landbokstav E 0..1 S kontaktperson E 0..1 S Adress Namn E/A Kard S T Beskrivning intervall E 0..1 S adresstyp E 1 S Lista aktuellfrandatum E 0..1 D Ej tid. utskriftsadress E 0..1 B beskrivning E 0..1 S Arbetsgivare En involveradperson kan ha endast en arbetsgivare men för att underlätta strukturen är elementen sammansatta till ett eget objekt.

58 Bilaga 4 Inleveransspecifikation 16 (25) PVS /12 V1.0 Namn E/A Kard S T Beskrivning namn E 0..1 S gatunamn E 0..1 S postnr E 0..1 S postort E 0..1 S tel E 0..1 S Ombud En involveradperson kan ha flera ombud men endast en av typen försvarare. Namn E/A Kard S T Beskrivning typ E 1 S Lista firma E 0..1 S forordnaddatum E 0..1 D Förordnad från datum. namn E 1 S Ersättningsanspråk Namn E/A Kard S T Beskrivning datum E 1 D Datum och tid. ersattningbrott E 0..1 S Beskrivning. ersattningbrott A 0..1 S kod rubrik E 0..1 S foretradare E 0..1 S talanaklagare E 0..1 B Talan önskas förd av åklagare. uppgiftslamnare E 1 S Namnet på uppgiftslämnaren. uppgiftslamnare A 1 S typ ansprak E 0..1 S preciseratansprak E 1 S Beskrivning, fri text. bilaga E 0..* Bi anteckning E 0..* An administrativt E 1 Ad Förhör Namn E/A Kard S T Beskrivning datum E 1 D Datum och starttid. forhorsledare E 1 S Namn. sluttid E 0..1 D tolk E 0..1 S tolksprak E 0..1 S plats E 0..1 S typ E 1 S Förhörstyp, Lista. dokumentationtele E 0..1 B Kan vara tomma. dokumentationljud E 0..1 B dokumentationvideo E 0..1 B dokumentationkonc E 0..1 B utskrivetav E 0..1 S

59 Bilaga 4 Inleveransspecifikation 17 (25) PVS /12 V1.0 forhorsvittne E 0..1 S Efternamn, fornamn. forhorsvittne Typ A 0..1 S Lista, personal eller annan. berattelse E 0..1 S Fritext. rubrik E 0..1 S hordperson E 1 O Hörd person Namn E/A Kard S T Beskrivning idkontrollerat E 0..1 B kontrollsatt E 0..1 S rolliforhor E 1 S Lista misstanktunder18 E 1 B stallningtillpart E 0..1 S underrattadmisstanke E 0..1 B Underrättad om misstanke. delgiveninfo E 0..1 B Delgiven info om förenklad delgivning. underrattadforsvarare E 0..1 B Underrättad om rätt till försvarare. godtarforsvarare E 0..1 B Godtar försvarare rätten förordnar. anledning E 1 S Underrättad om vad misstanken avser, Fritext. anteckningforsvarare E 0..1 S Namn eller kommentar, fritext. forsvararenarvarande E 0..1 B inkomforhor E 0..1 D Datum och tid. undervardnadsh E 0..1 B undersocmisstanke E 0..1 B undersoctid E 0..1 B foraldrarunder20 E 0..1 S Föräldrar/Vårdnadshavare för person under 20 år. Fritext Taxeringskontroll Namn E/A Kard S T Beskrivning inkomst E 0..1 N sambosinkomst E 0..1 N Make/maka/sambos taxerade inkomst. kontrolldatum E 0..1 D ar E 0..1 D Taxeringsår, endast år. kontrollutfordav E 0..1 S Anmälan En anmälan ingår i ett ärende. Namn E/A Kard S T Beskrivning franrardatum E 1 D Datum då ärendet kom från RAR rubrik E 0..1 S brott E 1..* O administrativt E 1 Ad Brott Namn E/A Kard S T Beskrivning

60 Bilaga 4 Inleveransspecifikation 18 (25) PVS /12 V1.0 benamning E 1 S? S antal E 1 N antalkvarejredovisade E 1 N prioritet E 0..1 N Flera siffror. brottsbeslut E 0..* O misstanke E 0..* O Brottsbeslut Namn E/A Kard S T Beskrivning beslutsfattare E 1 S Efternamn, förnamn. beslutsfattare A 1 S titel myndighetskod E 1 S resovisaantal E 1 N antalkvar E 1 N Antal kvar ej redovisade. beslutsdatum E 1 D Datum med tid. beslutstyp E 1 S Lista nedlaggningsgrund E 0..1 S Lista beskrivning E 0..1 S Motivering Misstanke Namn E/A Kard S T Beskrivning okandman E 0..1 B Okänd man. okandkvinna E 0..1 B Okänd kvinna. misstanktu15 E 0..1 B Misstänkt under 15 år. status E 1 S overtagen E 0..1 B Övertagen misstanke. idkontrollerat E 0..1 B kontrollsatt E 0..1 S tidigareantal E 1 N Tidigare antal på valt brott. antaltidigarem E 1 N Antal tidigare registrerade misstankar. misstankebeslut E 1..* O Misstankebeslut Namn E/A Kard S T Beskrivning nedlaggningsgrund E 1 S Lista Engagerad personal Namn E/A Kard S T Beskrivning status E 0..1 S Lista, anställd, inlånad eller slutad. funktion E 1 S Lista beslutsfattare E 0..1 S beslutsfattare A 0..1 S titel beslutsdatum E 0..1 D Datum och tid.

61 Bilaga 4 Inleveransspecifikation 19 (25) PVS /12 V Kallelse Namn E/A Kard S T Beskrivning skickatillmalsman E 0..1 B Skicka kallelse till målsman. personnr E 0..1 S namn E 1 S Efter och förnamn. gatunamnplats E 0..1 S gatunr E 0..1 S postnr E 0..1 S ort E 0..1 S land E 0..1 S co E 0..1 S C/O typ E 1 S Kallelsetyp, Lista, radioknappar. handlaggare E 1 S För och efternamn. datum E 0..1 D Datum och tid. telefon E 0..1 S telefon2 E 0..1 S adress E 0..1 S anledning E 1 S Anledning till kallelse Tvångsmedel Tvångsmedel kan levereras med eget schema kopplat till ärende. Om informationen levereras tillsammans med DurTvå kan det se ut så här. Namn E/A Kard S T Beskrivning grupp E 1 S Reella eller Personella tvångsmedel. typ E 1 S Lista beslutsdatum E 0..1 S Finns bara om typen ingår i gruppen reella tvångsmedel. namn E 0..1 S Om med i gruppen personella tvångsmedel. status E 1 S Olika listor beroende på grupp. statusdatum E 0..1 D Om med i gruppen personella tvångsmedel. tvangsmedeldata E 1 St CDatafält administrativt E 1 Ad beslut E 1 O historik E 1 O Beslut Kopplat till Tvångsmedel. Namn E/A Kard S T Beskrivning avser E 1 S Lista, typ av tvångsmedel. beslutsdatum E 1 S Datum och tid. beslutsfattare E 1 S beslutsdata E 1 St CDatafält

62 Bilaga 4 Inleveransspecifikation 20 (25) PVS /12 V Historik Kopplat till Tvångsmedel. Namn E/A Kard S T Beskrivning registreratdatum E 1 D anvandare E 1 S beslutsfattare E 1 S beslutsdatum E 1 D handelse E 1 S forandring E 1 S PM Namn E/A Kard S T Beskrivning datum E 1 D Datum och tid. beslagverkstallt E 0..1 B typ E 1 S Lista mtrlforanalys E 0..1 B uppgiftenavser E 0..1 S Kort beskrivning. uppgiftslamnare E 1 U Efternamn, förnamn. berordperson E 0..1 Be Efternamn, förnamn. rubrik E 0..1 S uppgift E 0..1 S anteckning E 0..* An bilaga E 0..* Bi administrativt E 1 Ad handelseuppgift E 0..1 O uppgiftenmottagen E 0..1 O Händelseuppgift Namn E/A Kard S T Beskrivning intraffatstart E 0..1 D intraffatslut E 0..1 D gatunamn E 0..1 S gatunr E 0..1 S ort E 0..1 S platsbeskrivning E 0..1 S UppgiftenMottagen Namn E/A Kard S T Beskrivning datum E 0..1 D Datum och tid eller tid för sig. uppgiftlamnadvia E 0..1 S Lista paplats E 0..1 S Fri text, På plats.

63 Bilaga 4 Inleveransspecifikation 21 (25) PVS /12 V Rapport Rapporter: ärendehistorik, brottsrapport, offentliga dagboksuppgifter, involverade personer och engagerad personal. Det blir en rapport av varje per ärende (5 stycken). Namn E/A Kard S T Beskrivning typ E 1 S Vilken typ av rapport. bilaga E 1 Bi Protokoll Av ärendets utredningsuppgifter kan handläggare sammanställa ett eller flera protokoll (huvudprotokoll, tilläggsprotokoll etc). De uppgifter som vid sammanställning inte ingår i protokollet samlas som uppgifter som inte ingår i protokoll. Om ingen sammanställning av protokoll görs samlas alla ärendets utredningsuppgifter i uppgifter som inte ingår i protokoll. Namn E/A Kard S T Beskrivning typ E 1 S Vilken typ av protokoll. Exempelvis Huvudprotokoll eller tilläggsprotokoll. handlaggare E 1 S Förnamn, efternamn skapad E 1 D Datum då förundersökningsprotokoll skapats. fup E 0..1 Bi Bilaga slask E 0..1 Bi Bilaga Externt dokument Namn E/A Kard S T Beskrivning uppgiftslamnare E 0..1 U Efternamn, fornamn berordperson E 0..1 Be Efternamn, fornamn Beskrivning E 0..1 S inkomdatum E 0..1 D forvaringsplats E 0..1 S bilaga E 1 Bi handelseplats E 0..1 O Händelseplats Namn E/A Kard S T Beskrivning adress E 0..1 S gatunr E 0..1 S ort E 0..1 S platsbeskrivning E 0..1 S Egna anteckningar Namn E/A Kard S T Beskrivning typ E 1 S Lista datum E 1 D Redovisas ej i DurTvå.

64 Bilaga 4 Inleveransspecifikation 22 (25) PVS /12 V1.0 forfattare E 1 S Efternamn, fornamn rubrik E 0..1 S anteckning E 0..1 S 7 Specifikt K-RAR K-RARs egna objekt, som bara kommer från K-RAR är färgade i grönt, liksom bilden i kapitel Karta över objekten. De som är gula är gemensamma objekt men där K-RAR har en del egen information. 7.1 Ärende Ärende är huvudobjekt i informationsstrukturen. Ärende med sitt diarenummer är det som binder ihop information levererat från olika system. Ärende har en 1 till 1 relation med anmälan vilket betyder att ett ärende endast har och kan ha en anmälan. Ärendet kan ingå i andra ärenden eller ha ärenden under sig. Till ärendet i K-RAR hör fuledare och handläggare, dessa återfinns i objektet engagerad personal. Namn E/A Kard S T Beskrivning diarienrannanm E 0..* S S Diarienummer annan polismyndighet myndighetskod E 1 S slutredovisningsdatum E 1 D balansfortur E 0..1 S balans E 0..1 S balansansvarig E 0..1 S aklforbeslutfu E 0..1 S enhet E 1 Handläggande enhet aklagaremyndighet E 0..1 S Namnet på åklagarens myndighet. aklagaremyndighet kod A 0..1 S datumlottning E 0..1 D remiss E 0..1 S fubeslut E 1 S fubeslutsdatum E 1 D Datum och tid fubeslutsfattare E 1 S Efternamn, förnamn bildibip E 1 B Ja/Nej det finns bild sparad. totaltgodsvarde E 0..1 S involveradperson E 1..* O anmalan E 1 O Det finns alltid endast en anmälan kopplad till ett ärende. arendebeslut E 1..* O Minst ett ärendebeslut finns i ärendet. engageradpersonal E 1..* O Myndighetsanställd som är engagerad i ärendet. gods E 0..* O anteckning E 0..* O Slutredovisningsanteckningen. historik E 1 O

65 Bilaga 4 Inleveransspecifikation 23 (25) PVS /12 V Involverad person Namn E/A Kard S T Beskrivning yrke E 0..1 S S Yrke/Titel arbetsplats E 0..1 S under15 E 1 S B J eller N. idstyrkt E 1 B J eller N. styrktsatt E 0..1 S Id styrkt på vilket sätt. fodelseland E 0..1 S fodelseort E 0..1 S adress E 0..* O Objekt telefon E 0..* O Objekt dagsbotsuppgifter E O Objekt underrattelseinfo E 0..1 O Objekt roll E 1..* O Objekt anteckning E 0..1 O Objekt, Fuk Underrättelseinfo Namn E/A Kard S T Beskrivning fuk13a E 1 S broschyr E 1 S kanantasbrottsofferstod E 1 B kontaktbrottsofferstod E 1 S infomalsagarbitrade E 1 B onskasmalsagarbitrade E 1 B forordnatmalsagarbitrade E 1 S forordnatmalsagarbitradetfn E 1 S inforbesoksforbud E 1 S fuk13cgripenanhallenavviker E 1 B fuk13cannat E 1 S lamnadav E 1 S Namn lamnadav titel A 1 S lamnaddatum E 0..1 D kontaktbrottsofferstod E 1 O fuk13b E 1 O anhorigkontaktperson E 0..1 O KontaktBrottsofferstöd Namn E/A Kard S T Beskrivning onskarkontakt E 1 B brottsofferstod E 1 S annatbrottsofferstod E 1 S fuk13b (Förundersökningskungörelse 13b) Namn E/A Kard S T Beskrivning tillfragad E 1 B villunderrattas E 1 B fuejinleds E 1 B funedlagges E 1 B atalejvacks E 1 B tidpunkthuvudforhandling E 1 D dom E 1 S

66 Bilaga 4 Inleveransspecifikation 24 (25) PVS /12 V AnhörigKontaktperson Namn E/A Kard S T Beskrivning efternamn E 0..1 S mellannamn E 0..1 S fornamn E 0..1 S tilltalsnamn E 0..1 S co E 0..1 S adress E 0..1 S postnr E 0..1 S ort E 0..1 S land E 0..1 S tfnbostad E 0..1 S tfnarb E 0..1 S yrke E 0..1 S anteckningar E 0..1 S Anmälan En anmälan ingår i ett ärende. Vid sökning är alltid inskrivningsdatum med. Namn E/A Kard S T Beskrivning upptagandemyndighet E 1 S Upptagande p-myndighet upptagandemyndighet kod A 1 S upptagandemyndighetenhet E 1 S anmalningssatt E 1 S upptagenav E 1 S inskrivenav E 1 S inskrivendatum E 1 S D Datum och tid handlaggandemyndighet E 1 S handlaggandeenhet E 1 S bilagor E 0..1 S Text om bilagor brott E 1..* O tillaggsanmalan E 0..* O Tillägg till anmälan ajourforing E 0..* O Upprättas då ändring görs i anmälan Brott Namn E/A Kard S T Beskrivning hatbrott E 1 S B Om brottet är ett hatbrott misstanke E 0..* O Misstankebeslut Namn E/A Kard S T Beskrivning pblad E 0..1 B Personblad underrmisstankt E 0..1 B Underrättelse misstänkt. underrmalsagare E 0..1 B Underrättelse målsägare. aklagarmyndihetensdnr E 0..1 S beslutsgrund E 0..1 S overlamning E 0..1 S redovisning E 1 O aterupptagning E 1 O

67 Bilaga 4 Inleveransspecifikation 25 (25) PVS /12 V Redovisning Namn E/A Kard S T Beskrivning fuprot E 0..1 S fuant E 0..1 S rb23:22 E 0..1 S Återupptagning Namn E/A Kard S T Beskrivning beslutsfattare E 0..1 S Namn beslutsfattare A 0..1 S titel datum E 0..1 D Tilläggsanmälan Tillkommande uppgifter i en anmälan. Namn E/A Kard S T Beskrivning upptagandemyndighet E 1 S Upptagande polismyndighet upptagandemyndighet kod A 1 S upptagandemyndighetenhet E 1 S anmalningsdatum E 1 D anmalningssatt E 1 S upptagenav E 1 S inskrivenav E 1 S inskrivendatum E 1 D Datum och tid. inskrivenenhet E 1 S uppgiftlamnare E 1 S Namn, oftast målsägaren. beskrivning E 0..1 S Händelsebeskrivning i fritext. bilagor E 0..1 S Ajourföring Ändrade uppgifter i en anmälan. Namn E/A Kard S T Beskrivning inskrivenav E 1 S inskrivendatum E 1 D Datum och tid inskrivenenhet E 1 S ajourforingtext E 0..1 S De förändrade uppgifterna.

68 Bilaga 5, IT-miljö inom RPS PVS / Bilaga 5 IT-miljö inom RPS

69 Bilaga 5, IT-miljö inom RPS PVS / Innehåll INNEHÅLL 2 1. SYFTE MED DETTA DOKUMENT 4 2. OPERATIVSYSTEM Limbo Microsoft Windows 4 3. HÅRDVARUPLATTFORMAR 4 4. INTEGRATIONSPLATTFORMAR 4 5. BACKUP 4 6. ÖVERVAKNING 5 7. VIRTUALLISERINGSPRODUKTER 5

70 Bilaga 5, IT-miljö inom RPS PVS / Datum Ändring Handläggare Ann Rosenlind

71 Bilaga 5, IT-miljö inom RPS PVS / Syfte med detta dokument Detta dokument beskriver de IT-tekniska plattformarna som används inom RPS och som e-arkivet ska ha stöd för. I bilagan specificeras vilka plattformar som används inom Polisen. Denna bilaga ska accepteras i Anbudsformuläret. 2. Operativsystem 2.1 Limbo SLES 11 (SuSE Linux Enterprise Server (inkl. OES) Apache (den version som ingår i SLES 11) Jboss EAP 5 (Enterprise Application Platform) RSA Access Manager Apache Web Agent 4.8 RSA Access Manager Jboss SSO Agent 2.2 MySQL 5.5 eller Oracle 11 Java JDK/JRE 6 (64-bit) 2.2 Microsoft Windows Windows Server 2008 R2 X64 Microsoft SQLServer 2008 R2 X64 Microsoft Windows 7 3. Hårdvaruplattformar 3.1 Strategisk plattform x86 Intel/AMD x64 Intel/AMD 4. Integrationsplattformar 4.1 Strategisk plattform SHS IBM Websphere Message Broker 5. Backup 5.1 Strategisk plattform

72 Bilaga 5, IT-miljö inom RPS PVS / Symantec Netbackup 6. Övervakning 6.1 Strategisk plattform HP Operation Manager HP Business Availability Center HP Network Node Manager (NNM/NNMi) HP Performance Manager HP System Insight Manager MS System Center Operations Manager 7. Virtualliseringsprodukter 7.1 Strategisk plattform VMware

73 Bilaga 6, Kvalitetsdokument 1 (11) PVS / Bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering

74 Bilaga 6, Kvalitetsdokument 2 (11) PVS / INNEHÅLL 1 SYFTE MED DETTA DOKUMENT KVALITETSSTYRNING Leverantörens kvalitetsstyrning Kvalitetsansvarig Kvalitetsarbete i leveranser Leverantörsinspektioner KVALITETSARBETE I UTVECKLING Krav och design Leverantörens tester Releasenoteringar KVALITETSARBETE I SUPPORT KVALITETARBETE KRING SÄKERHET KVALITETARBETE GENOM RISKHANTERING ACCEPTANSPROCEDUR Acceptansprocedur Klassning av fel och brister Godkännande ÄNDRINGSHANTERING OCH AVROP Ändringsprocedur Besluts- och ändringslogg Beslut... 11

75 Bilaga 6, Kvalitetsdokument 3 (11) PVS / shistorik Datum Ändring Handläggare Ann Rosenlind

76 Bilaga 6, Kvalitetsdokument 4 (11) PVS / Syfte med detta dokument Detta dokument beskriver hur Leverantören ska arbeta med kvalitet. Vidare definieras kvalitetsarbete genom riskhantering, acceptanstestproceduren och proceduren för ändringshantering och avrop. 2 Kvalitetsstyrning 2.1 Leverantörens kvalitetsstyrning För att säkerställa efterfrågad kvalitet i uppdraget ska Leverantören arbeta efter ett kvalitetssystem med dokumenterade rutiner för kvalitetsstyrning av sin verksamhet. Leverantörens kvalitetssystem kan antingen vara i form av en ISO-certifiering för SS EN-ISO 9001, motsvarande eller i form av ett eget dokumenterat kvalitetssystem. Kvalitetsstyrning av en verksamhet innebär att Leverantören har ett dokumenterat system som bland annat omfattar företagets organisatoriska strukturer, roller och ansvar. Vidare innefattas processer, rutiner och riktlinjer för kravarbete, utveckling, test, systemdokumentation, användardokumentation, releasearbete, helpdesk, och hur risker/fel/ brister tas om hand/åtgärdas, men också processer, rutiner och riktlinjer för områden som t.ex. rekrytering av medarbetare och underleverantörer, kompetensutveckling av medarbetare, avvikelserapportering, hantering av kundklagomål samt uppföljning av kvaliteten på avtalade leveranser. RPS ställer särskilt höga krav på att alla aspekter kring informationssäkerhet. Leverantören ska därmed särskilt kunna påvisa rutiner och styrning inom detta område, såsom att Leverantören använder SS-IEC/ISO som ledningssystem för informationssäkerhet (LIS), motsvarande eller har hanteringen inbyggt i sitt kvalitetssystem och ska då omfatta säkerhetspolicys, riktlinjer och rutiner avseende sitt informationssäkerhetsarbete.

77 Bilaga 6, Kvalitetsdokument 5 (11) PVS / Kvalitetsansvarig Leverantören ska ha en utsedd kvalitetsansvarig. Det är kvalitetsansvarigs ansvar att löpande följa upp kvalitetsmålen och påtala behov av kvalitetsåtgärder. Det gäller såväl utveckling och underhåll av standardsystemet som Leverantörens leverans till RPS. 2.3 Kvalitetsarbete i leveranser Kvalitetsaktiviteter ska arbetas in i Leverantörens leveranser till RPS. Detta avser både i såväl projekt- som förvaltningsläge. 2.4 Leverantörsinspektioner RPS äger själv eller genom tredje man rätten att genomföra inspektion av Leverantörens verksamhet och tjänster. Inspektionsrätten omfattar även de underleverantörer som är berörda av leveransen till RPS. Sedan januari 2012 genomför RPS leverantörsinspektioner baserade på den struktur som finns i ISO Vid inspektionen granskas även Leverantörens arbete i relation till avtalade leveranser till RPS. Särskild inspektion kan även förekomma kring säkerhet. Figur 1 Inspektionsprocessen Under planeringsfasen skickar RPS en agenda för inspektionen samt uppgifter om när den kommer att genomföras. Leverantören ska inom rimlig tid efter RPS underrättelse ge RPS, eller sådan tredje man som avses ovan, tillgång till all dokumentation och/eller tillträde de lokaler som Leverantören eller dennes underleverantör använder vid utförande. Leverantören ska vidare tillhandahålla access till Leverantörens personal och Leverantörens underleverantörs personal. Resultat från inspektionen dokumenteras i ett protokoll, vilket sammanfattar vilka eventuella brister som Leverantören ska åtgärda. Leverantören ska inom rimlig tid inkomma med svar hur eventuella brister ska åtgärdas.

78 Bilaga 6, Kvalitetsdokument 6 (11) PVS / I de fall RPS och Leverantören inte kan kommer överens om åtgärder eller tidplan för när bristen ska vara åtgärdad eskaleras frågan vidare: - I projektläge till projektets styrgrupp, - I förvaltningsläge till ett samverkansmöte. 3 Kvalitetsarbete i utveckling 3.1 Krav och design För funktionalitet som utvecklas speciellt för RPS ska krav och design dokumenteras av Leverantören och godkännas av RPS. Framtagen dokumentation ska vara författad på svenska och levereras till RPS i av RPS godkända format. 3.2 Leverantörens tester Vid varje leverans till RPS, av Systemet, ny release eller delar därav, ska Leverantören kunna visa upp en testplan med tillhörande testfall. Vidare ska Leverantören bifoga ett testprotokoll till leveransen som visar att testplanen är genomförd och resultatet därav. Testerna ska alltid omfatta ett antal huvudtester, som verifierar ett helt systemflöde. Vid leverans av nya releaser innehållande tillkommande eller förändrad funktionalitet ska särskilda tester kunna uppvisas på den tillkommande eller förändrade funktionaliteten. Innefattar den nya releasen förändringar i standardsystemet, inklusive ingående tredjepartsprodukter, ska standardfunktionalitet testas om. Vid förändringar av funktionalitet i standardsystemet ska Leverantören via tester säkerställa att specialutvecklad kod för RPS fortfarande fungerar och att systemet fungerar på den systemplattform med hårdvara, operativsystem, databas och driftsrelaterade produkter parterna är överens om utgör en grundplattform. 3.3 Releasenoteringar För varje hel eller delar av release som levereras till RPS ska dokumentation bifogas som beskrivs vad releasen omfattar och vad som är förändrat.

79 Bilaga 6, Kvalitetsdokument 7 (11) PVS / Kvalitetsarbete i support Leverantören ska ha en bemannad supportfunktion som kan ta emot och systematiskt hantera anmälda fel och brister samt svara på frågeställningar om standardsystemet. Leverantören ska tillhandahålla ett supportsystem där alla anmälningar loggas, prioriteras och eskaleras, kan följas samt avrapporteras med uppgift om när/hur anmälda fel/brist är åtgärdad. I samma kanal ska även anmälningar om förbättringar i standardsystemet kunna rapporteras in och där den fortsatta hanteringen ska kunna följas. RPS ska kunna följa statusframskridandet av en anmälning. 5 Kvalitetarbete kring säkerhet Leverantören ska ha fastställda rutiner för rapportering av säkerhetsbrister för standardsystemet. Detta inkluderar även ingående tredjepartsprodukter. Leverantören ska inhämta kontinuerligt information om tekniska sårbarheter rörande standardsystemet, inklusive ingående tredjepartsprodukter och informera RPS om förslag på åtgärder. Leverantören ska kontinuerligt och utan fördröjning rapportera säkerhetsincidenter till RPS till angiven kontaktadress. 6 Kvalitetarbete genom riskhantering Parterna ska tillsammans löpande analysera och dokumentera genomförande- och systemrisker tillsammans med åtgärdsplaner. Under projektläge är en av de första aktiviteterna vid projektstart att genomföra en gemensam riskanalys. Därefter ska riskerna kontinuerligt följas upp och dokumenteras inom ramen för varje gemensamt projektmöte och operativt samordningsmöte. Risker ska löpande presenteras på projektstyrgruppsmöten respektive samverkansmöte på affärsmannanivå.

80 Bilaga 6, Kvalitetsdokument 8 (11) PVS / Acceptansprocedur 7.1 Acceptansprocedur För varje systemleverans, ny release eller delar av därav som levereras ska de installeras i RPS testmiljö för genomförande av en acceptanstest. RPS är ansvariga för att genomföra acceptanstester och som utgör grunden för godkännande av leveranser. Annan överenskommelse kan finnas avseende prestandatester. Acceptanstestprotokoll ska vara skriftliga och på ett format som båda parterna är överens om. Varje identifierad fel/brist ska vara klassificerat enligt definierande nivåer nedan under avsnitt Om inget annat är överenskommet ska RPS:s acceptanstest och återkoppling till Leverantören vara genomförd senast trettio (30) kalenderdagar efter mottagen leverans. Funna fel/brister rapporteras dock löpande för att maximera tiden för felrättning. Leverantören svarar för felsökning, men RPS ska underlätta arbetet genom att bland annat bereda tillgång till testfall och testdata för hur testerna är genomförda. Om inget annat är överenskommet ska Leverantören skriftligt återkoppla med åtgärdsplan senaste fjorton (14) kalenderdagar efter överlämnat acceptanstestprotokoll. 7.2 Klassning av fel och brister Definition av fel och brister Med fel och brister avses avvikelse från bilaga 1 Kravspecifikation, där fel avser ett felaktigt realiserat krav medan brist avser att kravet inte har realiserats. Till fel och brister räknas oförmåga hos Leverantören att uppfylla aktuell kravspecifikation även vid felaktigheter eller brister i tredjepartsprodukter såsom operativsystem och databashanterare. Till fel och brister räknas inte tillfällig funktionsnedsättning orsakad av driftförhållande eller hårdvarufel för vilket RPS ansvarar Klassificering av fel och brister RPS kommer att klassificera fel och brister i följande nivåer:

81 Bilaga 6, Kvalitetsdokument 9 (11) PVS / Blockerande stoppande fel/brister. Det går inte att färdigställa en uppgift. Vid prestanda klassas felet som blockerande om genomförda tester visar på mer än fyrdubbla tiden i angivet krav. 2. Hindrande allvarliga fel/brister, men uppgiften går att färdigställa via work around. Vid prestanda klassas felet som hindrande om genomförda tester visar på mer än dubbla tiden i angivet krav. 3. Störande fel/brist, men hindrar inte användaren/systemet att genomföra en uppgift. Vid prestanda klassas felet som störande om genomförda tester visar på upp till dubbla tiden i angivet krav. 4. Kosmetika mindre fel/brist som enbart påverkar användargränssnittet såsom ledtexter och färger. 7.3 Godkännande Formellt skriftligt leveransgodkännande för respektive avtalad leverans under projektläge görs av RPS:s programstyrgrupp. Formellt leveransgodkännande för respektive avtalad leverans under förvaltningsläge görs av RPS:s affärsansvarig. Förutsättningar för godkännande: - Fel/brist nivå 1 och 2 ska rättas innan leveransgodkännande lämnas. - Fel/brist nivå 3 innebär att en leveransgodkännande kan lämnas, men felet/bristen ska åtgärdas av Leverantören inom överenskommen åtgärdstid. - Fel/brist nivå 4 påverkar inte leveransgodkännande, men de ska vara åtgärdade till nästkommande kompletta release. 8 Ändringshantering och avrop I detta avsnitt specificeras rutiner för ändringshantering. 8.1 Ändringsprocedur Syftet med proceduren för ändringshantering är att säkerställa att ändringar och tillägg behandlas enhetligt och kontrollerat.

82 Bilaga 6, Kvalitetsdokument 10 (11) PVS / Ändringarna och tilläggen kan omfatta såväl funktionalitet, som resursallokering, aktivitetsplaner etc., men också innefatta avrop av t.ex. en utbildning. Diskussion om inkomna förslag hanteras på projektmöten/samordningsmöten eller på särskilda möten vid större omfattning. Akuta frågor behandlas per e-post och telefon. Principbeslut och diskussioner om ambitionsnivåer ska hanteras i projektstyrgruppen under projektläge och i samverkansmöte på affärsmannanivå i förvaltningsläge. 8.2 Besluts- och ändringslogg Varje överenskommelse om förändring ska vara skriftliga och föras in i en Besluts- och ändringslogg som RPS ansvarar för. Loggen innehåller uppgifter till alla förslag till förändringar. För varje inkommet förslag tas beslut om: Utreds, Genomförs, Avslås, eller Avvaktar. Därtill anges uppgift om prioritet och komplexitet. Innan beslut tas måste ändringsförslaget vara tydligt och konsekvenserna kända. För varje inkommet förslag tas därför beslut om frågan ska/behöver utredas närmare. I detta beslut fastställs även vem som ska utreda och om ansvaret ligger på Leverantören ska det tydligt framgå om utredningen innefattas i Leverantörens åtagande eller om detta är ett tillägg. Om inget annat avtalas omfattas diskussioner och enkla verifieringar på vad ändringar får för konsekvenser i Leverantörens åtagande. Detta innefattar även att ta fram en kostnadskalkyl på vad en ändring kräver för tidsåtgång i genomförande. Större utredningar kräver överenskommelse kring omfattning av utredningsinsats och vem som står för kostnaden. 8.3 Avrop RPS kan avropa optioner vilka är specificerade i bilaga 1, Kravspecifikation. Optionerna kan avropas både under projektet och i förvaltningsläge Avropsvillkor Samtliga avrop som RPS gör ska Leverantören kunna påbörja inom trettio (30) kalenderdagar från det att avrop gjorts. För avvikande inställelsetider se avsnitt Avropsvillkor i projektläge.

83 Bilaga 6, Kvalitetsdokument 11 (11) PVS / Leverantören ska fjorton (14) kalenderdagar innan start lämna till RPS uppgifter om utpekade resurser som ska genomföra uppgiften. Avbeställning av gjorda avrop, från RPS:s sida, ska senast göras fjorton (14) kalenderdagar innan planerat genomförande. Uppsägningstiden är fjorton (14) kalenderdagar och Leverantören erhåller ersättning för beställt arbetet under uppsägningstiden. Både beställning och avbeställning av avrop ska ske skriftligt enligt avtal Avropsvillkor inom projekttiden för Avropsvillkor för optionerna Integration med lagringslösning samt Migrering specificeras i bilaga 2 Beskrivning av projektet och dess leveranser. Vid avrop av timmar, inom projekttiden, ska Leverantören ha beredskap att avsätta resurser med en inställelsetid på 2 dagar. 8.4 Beslut För att öka effektivitet tilldelas RPS:s projektledare/förvaltningsansvariga ett mandat inom vilka ramar denne direkt kan fatta beslut för. Leverantörens projektledare/samordningsansvarig ska ha motsvarande mandat. Hur mandaten ser ut ska dokumenteras vid igång av projektläge respektive förvaltningsläge. För större beslut, men inom ramen för avtalad leverans har RPS:s affärsansvarig mandat att ta beslut. Leverantörens affärsansvarig ska ha motsvarande mandat. Beslut förs in i Besluts- och ändringsloggen. För mindre enstaka beslut som omfattar mindre än åtta (8) timmar godtas ett bekräftande e-post räcka. För större omfattning krävs ett underskrivet besluts/avropsunderlag. Är parter inte överens kan ena parten eskalera frågan till högre nivå, enligt bilaga 3 Samverkan och styrning.

84 Rikspolisstyrelsen 1(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS /12 Bilaga 7 Arkitekturbeskrivning E-arkivet

85 Rikspolisstyrelsen 2(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning Innehållsförteckning PVS /12 INLEDNING SYFTE OMFATTNING TILLÄMPNING ARKITEKTURENS MÅL LOGISK VY ÖVERSIKT LAGERINDELNING Klientlager Affärslogiklager Integrationslager Datalager... 6

86 Rikspolisstyrelsen 3(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning shistorik Datum Ändring Handläggare Ann Rosenlind PVS /12

87 Rikspolisstyrelsen 4(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS /12 Inledning 1.1 Syfte Syftet med dokument är att beskriva RPS e-arkivs arkitektur och dess samverkan med andra befintliga verksamhetssystem. Dokumentet ska stödja kommunikation mellan beställare, arkitekter, utvecklare samt leverantör. 1.2 Omfattning Dokumentet fokuserar på att visa kritiska och signifikanta mekanismer kring arkitektur och infrastruktur. 1.3 Tillämpning En anbudsgivare ska genom detta dokument få en förtydligande bild av RPS tekniska krav på e-arkivet och hur det bäst integreras i RPS systemmiljö. Dokumentet ger med andra ord ytterligare information om vissa aspekter utöver de funktionella- och icke-funktionella krav som redan angivits i bilaga 1 Kravspecifikation. 2 Arkitekturens mål Beskrivningen av arkitekturen för e-arkivet syftar till att förtydliga e-arkivets utformning så att det passar in i RPS övergripande arkitektur och för att underlätta integration med andra verksamhetssystem och processer. E-arkivet är flexibelt avseende driftsmiljöns konfiguration och bakomliggande teknik. Viktiga mål för arkitekturen är att e-arkivet ska: Vara generellt och utbyggbart. Vara anpassningsbart till underliggande tjänsters förändringar. Tillgodose ställda krav på prestanda och samtidighet. Tillgodose ställda krav på tillförlitlighet. Tillgodose ställda krav på säkerhet och loggning. Vara lätt att underhålla. Viktiga mål för säker informationshantering: Hållbart över tid - informationen måste finnas kvar och vara läsbar över tid, trots mjuk- och hårdvaruuppdateringar. Autentiskt - informationen ska vara oförvanskad och behöriga personer ska komma åt rätt information. Viktiga mål för effektiv informationshantering: Sökning e-arkivet ska ha effektiv funktion för att kunna söka och hitta informationen. Samlade ärenden lösningen möjliggör att all information om ett ärende lagras och hämtas på ett ställe. En samlad arkivredovisning e-arkivet kan redovisa både elektronisk och analog information. Enkelt att ansluta och leverera det får inte vara för höga hinder för att ansluta till tjänsten och vara beskaffat med flera anslutningssätt. Behovet från verksamheten och möjligheten att möta behovet ska styra.

88 Rikspolisstyrelsen 5(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning Viktiga mål för juridiskt korrekt informationshantering: PVS /12 Logiskt avskild information lösningen för e-arkivet ska vara gemensam för alla myndigheter inom Polisen, men respektive myndighet ska kunna ha var sitt arkiv, logiskt avskilt från de andra. Stödja olika leveransscenarion lösningen kan ta emot leveranser av information när verksamheten behöver leverera för att bland annat uppfylla polisdatalagens krav. 3 Logisk vy Den logiska vyn, i figur 1, innefattar en statisk struktur som visar hur olika fundamentala verksamhetssystem hänger ihop. 3.1 Översikt För att få e-arkivet att passa in i RPS arkitektur är det viktigt att identifiera vilka delar av e-arkivet som använder sig av generell funktionalitet, dvs. sådana funktioner som återkommer och är likartad i flera andra av RPS system. Användare gränssnitt Anslutande system som levererar / hämtar information E-Arkivet Användartjänster (AD,LDAP...) Medelandetjänster (E-post,SMS..) Logg (Central Säkerhets-Logg) Fig. 1. E-arkivet har sitt eget användargränssnitt som kan anropas från andra verksamhetssystem. Bilden visar en översikt över E-arkivets kopplingar till andra verksamhetssystem. 3.2 Lagerindelning Följande kapitel beskriver kort en tänkt uppdelning av e-arkivets inre logiska lager, och vilka arkitekturella krav RPS har inom respektive område. Varje lager är skalbart och kan skalas upp vid behov för att minimera risken till eventuella framtida prestandaproblem. Lastbalansering är att föredra mellan logiska lager.

89 Rikspolisstyrelsen 6(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS /12 Fig. 2. Bilden visar en översikt över e-arkivets inre logiska lager med koppling till Databaslagret, utanför e-arkivet Klientlager E-Arkivet har en tunn, webbaserad klient. All kommunikation mellan klient och server sker företrädelsevis med HTTPS och SOAP (dvs via web services med två-vägs-autentiserad SSL), för att tillåta en så enkel integration som möjligt och vara anpassningsbar i RPS gällande infrastruktur Affärslogiklager E-arkivet implementerar logiken och verksamhetsreglerna som är kravställda. Affärslagret är uppdelat i flera moduler, så som en integrationsmodul, en modul för workflow, en för mottagning Mottag, en för arkivvård/förvaltning/redovisning Administration, en för åtkomst Access, en för lagring/migrering osv. Några av dessa moduler beskrivs ytterligare nedan Integrationslager E-arkivet samlar alla sina kopplingar mot andra verksamhetssystem i en särskild logisk modul för integration. Detta för att förenkla underhåll och administration. Desto öppnare och flexiblare denna integrationsmodul är desto bättre. RPS primära protokoll mot andra system är meddelandehantering via MQ och synkron kommunikation via web services över HTTPS. E-arkivet kan tillgängliggöra sin informationsdomän tjänstebaserat, t.ex. via web services eller via en asynkron meddelandehanterare. E-arkivet ska med andra ord vara öppet för integration från andra verksamhetssystem och processer. WSDL-filer är kompatibla enligt WS-I (Web Services Interoperability) Datalager Det finns en flexibilitet då det gäller val av databashanteraren så RPS kan byta databashanterare i framtiden. Inom Polisen är MySQL standard databashanterare. Det finns även installationer med Oracle samt några installationer med Microsoft SQL Server i drift. Databasen kan partioneras för att kunna hantera ett stort antal arkivobjekt och det är möjligt att bibehålla prestanda även fast volymen av arkivobjekt successivt kommer att öka.

90 Rikspolisstyrelsen 7(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS /12 Lagring av digitala filer Archival Storage kan ske mot olika typer av lagringsmedia för att garantera ett långsiktigt bevarande, integrationen mellan e-arkivet och datalagret är objektbaserad via REST, SOAP eller liknande gränssnitt som transparant lagrar informationen på lämpligt lagringsmedia. För information som mycket sällan efterfrågas är det möjligt att lagra på sekventiellt lagringsmedia såsom band, för information som frekvent efterfrågas är det möjligt att lagra på snabbt lagringsmedia såsom disksystem. Det är möjligt att migrera information mellan olika lagringsteknologier om åtkomstbehovet för lagrade filer förändras. Det finns en flexibilitet gällande kopplingen till lagringsskiktet så RPS har möjlighet att migrera till framtida lagringsteknologier eller tillverkare över tid. Exempel på verksamhetssystem som skulle kunna dra nytta av att dela datalager med e-arkivet är Mediatjänsten, ett tänkt system för kunna hantera lagring av stora volymer av exempelvis ljud, bild, video och speglade hårddiskar. Information som lagras i Mediatjänsten kan tillhöra pågående ärenden. Detta gör att flera och helt andra användare än e-arkivets behöver tillgång till Mediatjänsten vilket ställer högre krav på tillgänglighet och prestanda i förhållande till e-arkivet. I Mediatjänsten måste fler format än de som tillåts i e-arkivet lagras. Det är inte heller alltid möjligt att följa standardformat på filer som lagras eftersom de kan ha källor som Polisen inte råder över. Detta ställer höga krav på tillgång till och bevarande av presentationsapplikationer då de kan vara svårt att formatkonvertera. Om konvertering genomförs finns det behov att spara ursprungsexemplaret för att ha full spårbarhet och minimera risken till informationsförlust. Mediatjänsten kommer att lagrar stora filer och stora informationsmängder vilket ställer höga krav både på prestanda och på lagringsvolymer.

91 Bilaga 8 Användningsfall 1 (24) PVS / Bilaga 8 Användningsfall

92 Bilaga 8 Användningsfall 2 (24) PVS / Innehållsförteckning 1 ANVÄNDNINGSFALLSÖVERSIKT Begrepp Aktörer Arkivadministration Lokal arkivfunktion Drifts- och förvaltningsorganisation Konsument Producent E-arkivet Leveransapplikation Avgränsning Process: Leverera SIP... 7 AF01. Testa SIP Process: Ta emot SIP... 8 AF02. Administrera leverans... 9 AF03. Ta emot SIP Process: Vårda och framtidssäkra AF04 Administrera valideringsregler...11 AF05 Administrera gallringsregler...12 AF06 Administrera konverteringsregler...13 AF07 Validera AIP...13 AF08 Gallra AIP...14 AF09 Konvertera AIP...15 AF10a Förändra AIP...15 AF10b Skriva notering till AIP...16 AF11 Hämta statistik och rapporter Process: Förvalta och drifta AF12 Administrera behörigheter Process: Redovisa arkiv AF13 Administrera noder för arkivredovisning...20 AF14a Upprätta arkivredovisning...20 AF14 b Redovisa arkivobjekt Process: Söka AIP AF15 Söka AIP Process: Tillhandahålla DIP AF16 Tillhandahålla DIP...23 AF 17 Tillhandahålla tillfällig behörighet...24

93 Bilaga 8 Användningsfall 3 (24) PVS / Datum Ändring Handläggare Ann Rosenlind

94 Bilaga 8 Användningsfall 4 (24) PVS / Användningsfallsöversikt Detta dokument beskriver de användningsfall som har identifierats för Polisens e-arkiv. Syftet med denna sammanställning är att ge en översiktlig bild av möjliga framtida scenarion för hur polisen jobbar i e-arkivet, komplement till kraven. Polisens miljöer dvs de plattformar och teknik som e-arkivet ska anpassas till finns beskrivna i bilaga 7 Arkitekturbeskrivning. Användningsfallen är grupperade under de processer som e-arkivet ska stödja. Som en ingång till användningsfallen beskrivs varje process kortfattat. Följande processer har definierats: - Leverera SIP - Ta emot SIP - Vårda och framtidssäkra arkivobjekt (AO) - Förvalta och drifta e-arkivet - Redovisa arkivobjekt - Söka arkivobjekt - Tillhandahålla DIP Figur 1 E-arkivet med tillhörande processer och användningsfall

95 Bilaga 8 Användningsfall 5 (24) PVS / Begrepp I detta dokument används centrala begrepp för e-arkivet. Vissa av dessa bygger på begrepp från OAIS-modellen (ISO :2003). Begreppen finns sammanställda i en begreppsmodell, bilaga 9 Begreppsmodell. 1.2 Aktörer Följande aktörer har identifierats. - Arkivadministration - Lokal arkivfunktion - Drifts- och förvaltningsorganisation - Konsument - Producent - E-arkivet - Leveransapplikation Arkivadministration Arkivadministrationen är den aktör som bl.a. administrerar och förbereder e- arkivet för nya leveranser samt sätter upp regler för arkivredovisning. Aktören administrerar nya regler för konvertering, validering samt gallring Lokal arkivfunktion Vid varje polismyndighet finns en arkivfunktion. Den lokala arkivfunktionen upprättar arkivredovisning samt söker och lämnar ut DIP från e-arkivet till allmänheten och medarbetare inom myndigheten Drifts- och förvaltningsorganisation Denna aktör sköter drift och förvaltning av e-arkivet och kommer bl.a. att hantera säkerhetskopiering, behörighetshantering och övervakning Konsument Konsumenten är den aktör som söker i e-arkivet och tar del av arkivobjekten. En konsument kan vara: - Handläggare som söker AO via Polisens intranät, Intrapolis. - Arkivarier vid de lokala arkivfunktionerna.

96 Bilaga 8 Användningsfall 6 (24) PVS / Arkivarier vid arkivadministrationen. - Anslutande verksamhetssystem Producent Producenten är den aktör som levererar SIP till e-arkivet. En producent kommer i de flesta fall att utgöras av ett levererande verksamhetssystem med förvaltning E-arkivet E-arkivet är den aktör som tar emot och validerar SIP vid Mottag. E-arkivet exekverar även satta regler eller utför andra aktörers kommandon Leveransapplikation Fristående applikation som kommer att validera SIP, normalisera metadata samt konvertera filer inför leverans till e-arkivet. Varje aktör kommer att interagera med e-arkivet på följande sätt. Figur 2 Sammanställning över aktörer och hur de interagerar med e -arkivet i form av användningsfall.

97 Bilaga 8 Användningsfall 7 (24) PVS / Avgränsning Översikten utgår endast från normalflöden, även om alternativa flöden och felhantering finns har dessa inte beskrivits. 1.4 Process: Leverera SIP Processen startar med ett beslut att påbörja leverans och slutar när leveransen är godkänd och lagrad i e-arkivet. Processen utförs av producenten. Inför en leverans förhandlar producenten och arkivadministrationen fram en leveransöverenskommelse vilken reglerar: - Vad som ska levereras - Omfattning på leveransen - Hur SIP ska utformas (sökbegrepp, struktur, format m.m.) - Vilken typ av leverans som ska göras med avseende löpande eller engångsleverans Det är producenten som ansvarar för skapa SIP, vilken ska följa givna inleveransspecifikationer för att kunna tas emot av e-arkivet. För att underlätta för producenten att kontrollera SIP inför leverans tillhandahåller e-arkivet en leveransapplikation. Applikationen hjälper till att konvertera handlingar, validera SIP samt normalisera metadata. Genom att producenten kan konvertera och validera SIP i ett tidigt skede i leveransapplikationen undviks att felaktiga leveranser stoppar upp flödet till e-arkivet. Leveranser till arkivet kan ske på olika sätt, synkront eller asynkront. Synkron överföring innebär att information levereras kontinuerligt via en integration mellan leverande verksamhetssystem och e-arkivet t.ex. så snart ett ärende avslutats. En synkron överföring innebär att producenten erhåller kvitto på leveransen synkront. Asynkron leverans kan göras i form av stora batchkörningar vid bestämda tidpunkter t.ex. årliga uttag från personal- och ekonomisystem. En asynkron leverans sker till en filarea där SIP antingen hämtas med automatik eller manuellt av e-arkivet. Vid en leverans kan kvitto skickas på olika sätt via mail eller att kvitto läggs på filarean. Ansvaret att driva igenom varje leverans kommer att ligga på arkivadministrationen.

98 Bilaga 8 Användningsfall 8 (24) PVS / AF01. Testa SIP Detta användningsfall beskriver hur en producent använder leveranspapplikationen för att validera SIP, konvertera handlingar till godkända arkivformat samt eventuellt normalisera metadata. Användningsfallet startar när producenten skapat SIP och levererat den till leveransapplikationen och valt vilken inleveransspecifikation som SIP ska valideras mot. Exempelförlopp - Aktör väljer att validera SIP. - Aktör väljer valideringsregel/-regler och startar. - SIP valideras och valideringsrapport (kvitto) med resultat presenteras. - Aktör väljer att konvertera handlingar. - Leveransapplikationen visar konverteringsalternativ. - Aktör väljer vilken konvertering som ska genomföras. - Handlingar konverteras och konverteringsrapport (kvitto) med resultat presenteras. - Aktör väljer att normalisera metadata ex. utformning av datum. - Metadata normaliseras och rapport (kvitto) med resultat presenteras. - Leveransapplikationen påför metadata om vilka valideringsregler som SIP passerat. Användningsfallet avslutas när leveransapplikationen avger kvitto på hur aktiviteterna gått. 1.5 Process: Ta emot SIP Processen startar med att producenten och arkivadministrationen påbörjar förhandlingar om leverans och slutar då leveransen är mottagen. Inför en leverans förhandlar arkivadministrationen och producenten fram villkor för leveransen, ex vilken data som ska levereras, volymer, kostnader för leveranser, tidpunkt för leverans, regler för hantering av AO, inleveransspecifikation gällande för leveransen. Förhandlingen slås fast i en leveransöverenskommelse.

99 Bilaga 8 Användningsfall 9 (24) PVS / SIP levereras till en nod (FE) i arkivredovisningen. En FE kan innehålla andra FE eller arkivobjekt. Till en FE kan endast en typ av SIP levereras vilka valideras utifrån en inleveransspecifikation. Efter validering lagras SIP som AIP. När förhandlingar är genomförda förbereds e-arkivet för att kunna ta emot SIP. Först skapas nod (FE) till vilken SIP ska levereras. Till FE knyts vilka regler om hantering som ska gälla ex. validering, konvertering, gallring, vilka metadata som ska vara sökbara samt vilken inleveransspecifikation som ska gälla för FE. Att driva förhandlingar med producenten samt förbereda e-arkivet för leverans ansvarar arkivadministrationen för. AF02. Administrera leverans Användningsfallet beskriver hur en aktör administrerar ny leverans dvs. skapar och förbereder FE, som SIP ska levereras till, samt knyter regler för hantering till FE. Att förbereda leveranser kan göras samlat i ett gränssnitt. En förutsättning för att användningsfallet kan starta är att e-arkivet vet vilken inleveransspecifikation den ska validera emot. Användningsfallet startar när en aktör väljer att förbereda leverans dvs. skapa och sätta regler för FE. Exempelförlopp - Aktör väljer att skapa ny FE som SIP ska levereras till. - E-arkivet visar gällande inleveransspecifikationer som SIP kan valideras mot. - Aktör väljer inleveransspecifikation. - Aktör väljer valideringar som ska knytas till FE. - Aktör väljer vilken metadata, utifrån inleveransspecifikationen, som ska vara sökbar eller icke sökbar för FE. - Aktör väljer konverteringsregel och knyter till FE. - Aktör väljer gallringsregel och knyter till FE. - Aktör väljer att spara uppgifter. - E-arkivet validerar inmatade uppgifter.

100 Bilaga 8 Användningsfall 10 (24) PVS / E-arkivet loggar händelsen. - E-arkivet sparar uppgifterna. Användningsfallet avslutas när samtliga regler är kopplade till FE. AF03. Ta emot SIP Detta användningsfall beskriver hur e-arkivet validerar och arkivlägger SIP. I mottag skapas AIP då teknisk metadata påförs SIP. Mottag lagrar AIP under rätt FE. För att kunna hålla samman AIP:er som har relationer ex. samma diarienummer skapas i mottag AIC (relationer/referenser). En förutsättning för att användningsfallet kan starta är att leveranser har förberetts enligt AF02. Användningsfallet startar när en producent levererar SIP. Exempelförlopp - E-arkivet tar emot inkommen SIP från producenten. - E-arkivet validerar SIP mot inleveransspecifikation knuten till den FE som SIP ska levereras till. - E-arkivet validerar SIP enligt satta valideringsregler knutna till utpekad FE. - E-arkivet påför SIP teknisk metadata. - E-arkivet skapar AIP/AIP:er från SIP. - E-arkivet skapar/relaterar AIC till AIP. - E-arkivet lagrar AIP/AIP:er under utpekad FE. - E-arkivet lagrar uppgifter om hur leveransen tagits emot (ex. antal AO, leveransdatum, valideringsresultat). - E-arkivet returnerar kvitto till producenten på att SIP har godkänts och AIP lagrats i e-arkivet. - E-arkivet loggar händelsen. - Om SIP inte godkänns skickas hela leveransen tillbaka till producenten med felmeddelande. Användningsfallet avslutas när e-arkivet lagrat AIP och kvitto skickats till producenten.

101 Bilaga 8 Användningsfall 11 (24) PVS / Process: Vårda och framtidssäkra Arkivadministrationen vårdar och framtidssäkrar de arkiverade AIP:erna. Processen är ständigt pågående och startar så snart den första leveransen genomförts till e-arkivet. Arkivadministrationen ansvarar för att: - Valideringar genomförs ex. att dataintegriteten kan garanteras genom att kontrollera checksummor. - Konvertera handlingar till nya format. - Genomföra gallring i arkivet. Det är arkivadministrationen som bevakar vilka validerings-, konverteringsoch gallringsregler som kan exekveras. Samtliga regler kan sättas som engångsinsats men också schemaläggas och genomförs med olika intervaller. Som en vårdande insats kan metadata påföras/uppdateras på AIP ex. ändrade regler vad gäller sekretess. I processen ingår också att bevaka vilka nya filformat som standardiseras till arkivformat och andra inom området relevanta nya standarder. AF04 Administrera valideringsregler Användningsfallet beskriver hur en aktör kopplar valideringsregler till FE. E-arkivet är förberett med standardvalideringar. När SIP tas emot kontrolleras vilka valideringsregler som är kopplade till mottagande FE. Valideringsreglerna kan också exekveras på redan lagrade AIP:er. Validering kan göras som en engångsinsats men också schemaläggas och genomföras med olika intervall. Samma valideringsregel kan kopplas till flera FE. Användningsfallet startar när en aktör väljer att koppla en valideringsregel till FE. Exempelförlopp - Aktör väljer FE. - Aktör väljer valideringsregel. - Aktör sätter villkor, i detta fall tidsintervall, för valideringsregeln. - Aktör knyter valideringsregeln till vald FE.

102 Bilaga 8 Användningsfall 12 (24) PVS / Aktör väljer om valideringsregeln ska vara en engångsinsats eller om den ska schemaläggas och med vilket intervall. - E-arkivet validerar uppgifterna. - E-arkivet loggar händelsen. - E-arkivet sparar uppgifterna. Användningsfallet avslutas då e-arkivet har uppdaterat FE med valideringsregeln. AF05 Administrera gallringsregler Till e-arkivet kommer gallringsbar information att kunna levereras. Användningsfallet beskriver hur en aktör knyter gallringsregler till FE. Regler för gallring kan också medfölja från producenten. Gallringsregler kan sättas på hela eller delar av arkivobjekten. Gallring kan genomföras som en engångsinsats, eller schemaläggas med olika intervaller. Användningsfallet startar när en aktör väljer att administrera en ny gallringsregel. Exempelförlopp - Aktör väljer FE som regeln ska knytas till. - Aktör väljer att registrera en ny gallringsregel eller att ändra befintlig gallringsregel. - Aktör definierar hur gallringsfristen ska beräknas (villkor samt tidsfrist). - Aktör väljer om gallringsregeln ska vara en engångsinsats eller om den ska schemaläggas och med vilken intervall. - E-arkivet validerar uppgifterna. - E-arkivet loggar händelsen. - E-arkivet sparar uppgifterna och knyter gallringsregeln till FE. Användningsfallet avslutas då e-arkivet har uppdaterat FE med gallringsregeln.

103 Bilaga 8 Användningsfall 13 (24) PVS / AF06 Administrera konverteringsregler I e-arkivet kan AIP konverteras till nya format. Initialt är e-arkivet förberett med ett antal möjliga standardkonverteringar ex, word Pdf/A. Användningsfallet beskriver hur en aktör knyter en ny konverteringsregel till en FE. Regeln kan knytas till en eller flera FE. I e-arkivet kan man välja om ursprungsfilen ska bevaras eller gallras då konvertering genomförts och kontrollerats. Konverteringsregeln kan antingen exekveras som en engångsinsats, eller att den schemaläggs och är återkommande. Användningsfallet startar när en aktör väljer att koppla en konverteringsregel till en eller flera FE. Exempelförlopp - Aktör väljer till vilken/vilka FE som regeln ska knytas. - Aktör väljer vilken konvertering som ska genomföras. - Aktör väljer om ursprungsfilerna ska gallras efter konverteringen. - Aktör knyter konverteringsregeln till en eller flera FE. - Aktör väljer om konverteringen ska vara en engångsinsats eller om den ska schemaläggas och med vilket intervall. - E-arkivet validerar uppgifterna. - E-arkivet loggar händelsen. - E-arkivet sparar uppgifterna och knyter konverteringsregeln till FE. Användningsfallet avslutas då e-arkivet har uppdaterat FE med konverteringsregeln. AF07 Validera AIP Användningsfallet beskriver hur valideringsregler exekveras. Inför en validering sammanställer e-arkivet en lista. Det går att sätta upp en regel att listan ska godkännas innan validering genomförs. Användningsfallet startar då en valideringsregel exekveras, antingen manuellt eller genom ett schemalagt jobb. Exempelförlopp - E-arkivet startar valideringsfunktionen. - Valideringsfunktionen genomsöker e-arkivet.

104 Bilaga 8 Användningsfall 14 (24) PVS / Valideringsfunktionen sorterar ut de AIP: er som ska valideras enligt regeln och skapar en lista över aktuella AIP. - Aktör väljer att godkänna listan. - Valideringsfunktionen fortsätter att exekveras. - Resultatet dokumenteras i en valideringsrapport som bevaras i e- arkivet. - Valideringen loggas. Användningsfallet avslutas när valideringen är loggad och sammanställd i valideringsrapport. AF08 Gallra AIP Användningsfallet beskriver hur e-arkivet utför gallring av AIP. Inför en gallring sammanställer e-arkivet en lista. Det går att sätta upp villkor att listan ska godkännas innan gallring exekveras. Gallring ska kunna göras på hela eller delar av AIP. Användningsfallet startar när villkor och/eller tidsfrist infaller. Exempelförlopp - E-arkivet startar gallringsfunktionen. - Gallringsfunktionen genomsöker e-arkivet. - Gallringsfunktionen sorterar ut de AIP som ska gallras enligt gallringsreglerna och skapar lista över aktuella AIP. - Aktör godkänner listan och gallringsfunktionen fortsätter att exekvera gallring. - Resultatet dokumenteras i en gallringssrapport som bevaras i e- arkivet. - Gallringen loggas. Användningsfallet avslutas när AIP är gallrade och gallring är loggad samt sammanställd i gallringssrapport.

105 Bilaga 8 Användningsfall 15 (24) PVS / AF09 Konvertera AIP Detta användningsfall beskriver hur e-arkivet genomför konvertering. Inför att en konvertering exekveras sammanställer e-arkivet en lista. Det går att sätta upp villkor för att listan ska godkännas innan konvertering exekveras. Användningsfallet startar då en konverteringsregel exekveras, antingen manuellt eller genom ett schemalagt jobb. Exempelförlopp - E-arkivet startar konverteringsfunktionen. - Konverteringsfunktionen genomsöker e-arkivet. - Konverteringsfunktionen sorterar ut de AIP som ska konverteras enligt regeln och skapar lista över aktuella objekt. - E-arkivet visar lista över de utsorterade AIP. - Aktör godkänner listan och konverteringsregeln fortsätter att exekvera regeln. - E-arkivet kontrollerar konverteringen. - E-arkivet gallrar ursprungsfilerna. - E-arkivet sammanställer resultatet av konverteringen i en konverteringsrapport vilken sparas i e-arkivet. - E-arkivet loggar konverteringen och gallring. I de fall ursprungsformatet ska bevaras skapar/uppdaterar e-arkivet en AIC som håller relationen mellan de båda arkivobjekten. Användningsfallet avslutas då AIP är konverterade och konverteringen är loggad. AF10a Förändra AIP Användningsfallet beskriver hur en aktör förändrar AIP. Utifrån personuppgiftslagens bestämmelser måste personuppgifter som är felaktigt registrerade kunna tas bort, även då handlingarna har levererats till e-arkivet. I e-arkivet kan förändringar av AIP utföras genom att ett metadata uppdateras eller att en handling tillförs, ex. med rättade personuppgifter. Efter uppdatering går det att välja (lösning enligt OAIS);

106 Bilaga 8 Användningsfall 16 (24) PVS / att endast förändringen sparas, dvs. genom en AIU, med en AIC till den ursprungliga AIP, för att undvika onödig dubbellagring eller - spara en ny version av AIP med en referens mellan de båda versionerna, dvs. genom en AIC Då AIP förändras måste orsak till förändringen kunna skrivas in samt att följande loggas: - Vad som uppdaterats alt vad som tillförts. - Tidpunkt. - Vem som gjort förändringen Användningsfallet startar när en aktör sökt fram aktuell AIP för att rätta felaktiga uppgifter i en handling. Exempelförlopp - E-arkivet hämtar AIP. - Aktör väljer vilken handling som ska uppdateras. - Aktör registrerar in ny uppdaterad handling. - Aktör väljer att endast uppdaterade handlingen sparas, inte skapa ny AIP. - E-arkivet skapar AIU av uppdateringen. - E-arkivet skapar AIC mellan AIP och AIU. - Aktör väljer att ursprunglig handling gallras. - E-arkivet gallrar ursprunglig handling. - E-arkivet loggar uppdatering och gallring. - E-arkivet sparar AIU samt AIC. Användningsfallet avslutas när e-arkivet har sparat AIU samt AIC. AF10b Skriva notering till AIP Till AIP kan det göras noteringar, dvs löpande anteckningar. Exempel på noteringar kan vara referens till annat ärende. Noteringarna har en referens

107 Bilaga 8 Användningsfall 17 (24) PVS / till AIP så att notering och AIP kan presenteras samlat om önskemålet finns. Användningsfallet beskriver hur en aktör gör en notering om AIP. Användningsfallet startar när aktör valt aktuell AIP Exempelförlopp - E-arkivet hämtar AIP. - Aktör öppnar noteringsfilen. - Aktör skriver in notering. - Aktör sparar och stänger noteringsfältet - E-arkivet sparar noteringen - E-arkivet loggar uppdateringen Användningsfallet avslutas när e-arkivet loggat och sparat noteringen. AF11 Hämta statistik och rapporter I e-arkivet sker en omfattande loggning av händelser. Loggningen kommer att utgöra grunden till den statistik som kan tas fram. Detta användningsfall beskriver hur aktören sammanställer rapporter. Initialt är e-arkivet förberett med standardrapporter, exempel på rapporter är antal lagrade arkivobjekt för en myndighet, antal sökningar, aktuell lagringsstorlek (totalt för arkivet eller per myndighet) etc. Det går också att ta fram nya rapportmallar. Användningsfallet startar när aktören väljer att sammanställa en rapport. Exempelförlopp - Aktör väljer att ta ut rapport. - E-arkivet visar en lista över tillgängliga rapporter. - Aktör väljer rapporttyp. - E-arkivet visar eventuella inmatningsfält som begränsar urvalet. - Aktör fyller i inmatningsfälten och startar sökningen. - E-arkivet sammanställer rapporten. - E-arkivet loggar händelsen.

108 Bilaga 8 Användningsfall 18 (24) PVS / Sammanställd rapport sparas till fil och/eller skrivas ut. Användningsfallet avslutas när rapporten presenterats på skärmen eller har sparats till fil. 1.7 Process: Förvalta och drifta Att drifta och förvalta e-arkivet ansvarar PVIT för. Gränsdragningen mellan PVIT och Arkivadministrationen är i dagsläget inte klarlagt. Processen är inte framtagen. AF12 Administrera behörigheter Detta användningsfall beskriver hur en aktör administrerar behörigheter till e-arkivet. Behörigheterna sätts i form av roller. En roll kan ges olika begränsningar ex. tillgång att se olika delar i arkivet eller kunna genomföra aktiviteter i e-arkivet (sätta gallringsregler, upprätta kontrakt osv). E-arkivets behörighetssystem stämmer överens med Polisens AD som bl.a. administreras i systemet ITAC. Samtliga behörigheter knyts till noder i arkivredovisningen. Nya roller med tillhörande befogenheter kan läggas till. I e-arkivet går det att ge tillfälliga behörigheter till utpekade noder eller AIP. Användningsfallet startar då en aktör väljer att lägga till en ny behörighet eller uppdatera en befintlig. Exempelförlopp - Aktör väljer att administrera behörigheter. - E-arkivet visar aktuella roller. - Aktör väljer att ändra en befintlig roll eller lägga till en ny roll. - Aktör väljer att ändra eller lägga till behörighet till olika delar av arkivet till rollen. - Aktör väljer att ändra eller lägga till behörighet till olika aktiviteter till rollen. - Aktör väljer att koppla aktörer till rollen. - Aktör väljer att spara behörigheten. - E-arkivet loggar händelsen. - E-arkivet uppdaterar behörighetsregistret. Användningsfallet avslutas när e-arkivet har uppdaterat behörighetsregistret.

109 Bilaga 8 Användningsfall 19 (24) PVS / Process: Redovisa arkiv Denna process delas mellan arkivadministrationen och de lokala arkivfunktionerna. Arkivadministrationen ansvarar för att sätta regler för arkivredovisningen och de lokala myndigheterna upprättar sina respektive arkivredovisningar. E-arkivet kan hantera hela Polisens arkivredovisning dvs. klassificeringsstruktur (KS) och arkivförteckning i enlighet med Riksarkivets föreskrifter. I e-arkivet kan digitala och analoga arkivobjekt redovisas. Processens första steg är att arkivadministrationen definierar vilka typer av strukturenheter, handlingsslag, handlingstyper samt förvaringsenheter som kan väljas. Därefter ansvarar varje lokal arkivfunktion för att sätta samman klassificeringsstruktur samt arkivförteckning. Redovisningen delas upp mellan den del som klassificerar handlingarna, klassificeringsstruktur, och den del som redovisar handlingarna, arkivförteckning. Klassificeringsstrukturen är en logisk redovisning av verksamheten och som byggs upp av strukturenheterna verksamhetsområden, processgrupper och processer. En process har en eller fler aktiviteter. Varje process avsätter handlingar vilka utgör ett handlingsslag. Ett handlingsslag kan innehålla en eller flera handlingstyper. Arkivförteckningen redovisar handlingarna. Denna redovisning består av noderna handlingsslag, handlingstyper samt förvaringsenheter i flera nivåer. Förvaringsenhet kommer att vara utgångspunkt för var AIP kommer att lagras. Redovisning av FE kan göras utan att den övriga arkivredovisningen är upprättad. Nedanstående bild förklarar förhållandet mellan arkivredovisning, klassificeringsstruktur samt arkivförteckning. Figur 4 Förenklad bild av arkivredovisningens delar

110 Bilaga 8 Användningsfall 20 (24) PVS / AF13 Administrera noder för arkivredovisning Detta användningsfall beskriver hur en aktör skapar eller uppdaterar arkivredovisningens nodtyper, d.v.s. upprättar nodtyper och definierar metadata samt regler för nodtypen. Användningsfallet startar när en aktör väljer att upprätta en ny nodtyp. Exempelförlopp - Aktör väljer att skapa ny nodtyp. - Aktör kan antingen välja att skapa en ny nodtyp eller uppdatera en redan befintlig. - Aktör väljer att skapa en ny nodtyp. - Aktören definierar beteckning för noden, vilka regler som ska gälla och vilken metadata som ska vara obligatorisk samt valbar för noden. - E-arkivet validerar uppgifterna. - E-arkivet loggar händelsen. - E-arkivet sparar uppgifterna. Användningsfallet avslutas när e-arkivet har sparat uppgifterna och listan över valbara nodtyper är uppdaterad. AF14a Upprätta arkivredovisning Detta användningsfall beskriver hur en aktör sätter samman en klassificeringsstruktur eller arkivförteckning utifrån fördefinierade nodtyper enligt AF 13. Användningsfallet startar när en aktör väljer att upprätta en nod i arkivredovisningen. Exempelförlopp - Aktör väljer nodtyp och utifrån den skapar en nod. - Aktör registrerar obligatorisk metadata på noden, specificerad i nodtypen. - Aktör väljer att spara uppgifterna. - E-arkivet loggar händelsen.

111 Bilaga 8 Användningsfall 21 (24) PVS / E-arkivet validerar och sparar uppgifterna. Användningsfallet avslutas när e-arkivet har sparat uppgifterna och uppdaterat myndighetens arkivredovisning. AF14 b Redovisa arkivobjekt Detta användningsfall beskriver hur en aktör uppdaterar arkivförteckningen med analoga arkivobjekt. Användningsfallet startar när en aktör väljer att uppdatera arkivförteckningen. Exempelförlopp - E-arkivet visar myndighetens arkivförteckningar. - Aktör väljer den arkivförteckning som ska uppdateras. - Aktör väljer under vilken FE som AO ska registreras. - Aktör väljer att registrera in nya AO. - Aktör registrerar in antal AO samt hur de ska numreras. - Aktör registrerar obligatorisk metadata för AO. - Aktör väljer att spara uppgifterna. - E-arkivet loggar händelsen. - E-arkivet validerar och sparar uppgifterna. Användningsfallet avslutas när e-arkivet har sparat uppgifterna och myndighetens arkivförteckning är uppdaterad. 1.9 Process: Söka AIP Denna process utförs av konsumenten. Processen startar med att en fråga ställs till e-arkivet och slutar med att en träfflista presenteras. Sökning i arkivet kan göras via följande kanaler: - Ett verksamhetssystem Ett verksamhetssystem kan ansluta, enligt överenskommelse, till e- arkivet för sökning under utpekad FE. - Intrapolis (Polisens intranät)

112 Bilaga 8 Användningsfall 22 (24) PVS / Öppen information kan sökas i och hämtas från e-arkivet via Intrapolis. I anslutning till sökfunktionen finns möjlighet att beställa ej öppen information ex. sekretessbelagt eller åtkomstskyddad. Rutiner för hur beställningar ska göras är i dagsläget inte fastslaget. - E -arkivets egna sökgränssnitt Via detta gränssnitt kommer arkivfunktionen att kunna söka AIP. När en sökning genomförs måste konsumenten först välja övergripande kategori av FE. Därefter kan aktören antingen välja att gå nedåt i strukturen med FE eller söka direkt på AIP ex. genom diarienummer. Figur 5 Struktur för FE AF15 Söka AIP Användningsfallet beskriver hur en aktör söker ett eller flera AIP/-er genom att först navigera till rätt FE. Förutsättning för att kunna söka under en FE styrs av behörigheter. I de fall en aktör inte har behörighet till en FE kommer inte denna FE vara valbar för aktören. Användningsfallet startar när en aktör valt vilket arkiv som AIP ska sökas från. Exempelförlopp - E-arkivet visar lista på de övergripande kategorierna av FE (t.ex. brottsutredningar, ekonomi). - Aktör navigerar i listan och väljer FE, Brottsutredningar.

Bilaga 2 Beskrivning av projektet och dess leveranser

Bilaga 2 Beskrivning av projektet och dess leveranser Bilaga 2 Beskrivning av projektet och dess leveranser 1 (29) Bilaga 2 Beskrivning av projektet och dess leveranser Bilaga 2 Beskrivning av projektet och dess leveranser 2 (29) INNEHÅLL 1 SYFTE MED DETTA

Läs mer

Exempel på verklig projektplan

Exempel på verklig projektplan Exempel på verklig projektplan Detta är ett exempel på en proffessionell projektplan hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och mycket av

Läs mer

E-utvecklingsråd i Jönköpings län

E-utvecklingsråd i Jönköpings län E-utvecklingsråd i Jönköpings län RAPPORT Projekt Gemensamt e-arkiv i Jönköpings län, Etapp 1 Rapport 1.0 2 av 8 Innehåll 1 Projektläge och syftet med rapporten 3 1.1 Delprojekt Juridiska förutsättningar

Läs mer

Helhetsåtagande underhåll och drift

Helhetsåtagande underhåll och drift SID (0) Bilaga b Helhetsåtagande underhåll och drift Förfrågningsunderlag Upphandling av ett helhetsåtagande avseende IT-stöd för pedagogiskt genomförande inom Skolplattform Stockholm Box 09, 0 Stockholm.

Läs mer

Avropsavtal MedBorgarAssistent

Avropsavtal MedBorgarAssistent Avtalsstruktur Medborgarassistent MedBorgarAssistent Samarbetsavtal Sambruk-TE Bilaga Sambruks rabatter Bilaga Mall Avropavtal Mall 2. Svarsbrev 2 TietoEnator 3. Frågebrev 2 TietoEnator 4. Svarsbrev 1

Läs mer

Aktiviteter vid avtalets upphörande

Aktiviteter vid avtalets upphörande SID 1 (10) Bilaga 4h Aktiviteter vid avtalets upphörande Förfrågningsunderlag Upphandling av ett helhetsåtagande avseende IT-stöd för pedagogiskt genomförande inom Skolplattform Stockholm Box 22049, 104

Läs mer

Projektprocessen. Projektprocess

Projektprocessen. Projektprocess Dnr Mahr 19-2014/563 1 (av 6) Projektprocess Datum: Version: Dokumentansvarig: 150116 1.0 Jenny Wendle Stöddokument för det grafiska dokumentet Projektprocessen grafisk 1.0 Projektprocessen Projektprocessen

Läs mer

Införande av Primula på Malmö högskola

Införande av Primula på Malmö högskola 2014-11-19 1 (7) Införande av Primula på Malmö högskola Projekt- och aktivitetsplan 2014-11-19 2 (7) Innehåll Införande av Primula på Malmö högskola... 1 1 Basfakta... 3 2 Beskrivning av projektet, mål

Läs mer

Byta system bli klar i tid och undvik onödiga kostnader

Byta system bli klar i tid och undvik onödiga kostnader Byta system bli klar i tid och undvik onödiga kostnader Registratorskonferens 19 maj 2015 Elisabeth Jarborn Arkivchef och verksamhetsutvecklare, Danderyds kommun På två månader kan ni ha ny teknisk lösning

Läs mer

Bilaga 4c. Utveckling. Upphandling av IT-stöd för barn- och elevregister inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN. Förfrågningsunderlag

Bilaga 4c. Utveckling. Upphandling av IT-stöd för barn- och elevregister inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN. Förfrågningsunderlag UTBILDNINSFÖRVLTNINEN SID 1 (1) Bilaga 4c Utveckling Förfrågningsunderlag Upphandling av IT-stöd för barn- och elevregister inom Skolplattform Stockholm Box 049, 104 Stockholm. Besöksadress Hantverkargatan

Läs mer

Vårdval primär hörselrehabilitering i Östergötland

Vårdval primär hörselrehabilitering i Östergötland Vårdval primär hörselrehabilitering i Östergötland IT-bilaga till Regelboken Handläggare: Verksamhet: Datum: 2015-06-03 Diarienummer: LiÖ 2014-1276 www.regionostergotland.se Innehållsförteckning 1 Syfte...

Läs mer

Förnyad förvaltning, ändamålsenlig driftbild. 2013-04-17 Östersund Jonas Brorsson

Förnyad förvaltning, ändamålsenlig driftbild. 2013-04-17 Östersund Jonas Brorsson Förnyad förvaltning, ändamålsenlig driftbild 2013-04-17 Östersund Jonas Brorsson Agenda»Om Förnyad förvaltning»förslag till drift och support Om Förnyad förvaltning Effektmål Beskriva en förvaltning som:

Läs mer

Bilaga 1. Definitioner

Bilaga 1. Definitioner 1 (6) Bilaga 1 Definitioner 2 (6) Definitioner inom Ramavtal e-förvaltningsstödjande tjänster Definitionerna gäller även för Leveransavtal under detta Ramavtal. Anbudsgivare Användare Användbarhet Applikation

Läs mer

Allmänna villkor. för Mina meddelanden. Bilaga 4 Servicenivåer (SLA) version 1.0 (Gäller fr.o.m. 2015-11-11)

Allmänna villkor. för Mina meddelanden. Bilaga 4 Servicenivåer (SLA) version 1.0 (Gäller fr.o.m. 2015-11-11) Allmänna villkor för Mina meddelanden Bilaga 4 Servicenivåer (SLA) version 1.0 (Gäller fr.o.m. 2015-11-11) 2 1. Bakgrund och syfte Skatteverket tillhandahåller en myndighetsgemensam infrastruktur för säkra

Läs mer

Bilaga 4a. Införande. Upphandling av IT-stöd för hantering av frånvaro och närvaro inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN

Bilaga 4a. Införande. Upphandling av IT-stöd för hantering av frånvaro och närvaro inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN SID 1 (29) Bilaga 4a Införande Förfrågningsunderlag Upphandling av IT-stöd för hantering av frånvaro och närvaro inom Skolplattform Stockholm Box 22049, 104 22 Stockholm. Besöksadress Hantverkargatan 2

Läs mer

Processbeskrivning - Incident Management

Processbeskrivning - Incident Management ProcIT-P-009 Processbeskrivning - Incident Management Lednings- och kvalitetssystem Fastställt av 2012-06-20 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Incident Management-processen

Läs mer

Innehåll (3) Innehåll (2) Innehåll (5) Innehåll (4) Innehåll (6) Innehåll (7) Dokumenthistorik. beställare, Översiktlig beskrivning av projektet

Innehåll (3) Innehåll (2) Innehåll (5) Innehåll (4) Innehåll (6) Innehåll (7) Dokumenthistorik. beställare, Översiktlig beskrivning av projektet Bilden hämtad från http://www.liu.se/cul-resurser/lips/kartor/fore.htm Projektplanering Om inte projektet planeras noga, kommer det garanterat att misslyckas Projektplanen Krav på en projektplan Beskriver

Läs mer

Ramverk för projekt och uppdrag

Ramverk för projekt och uppdrag Peter Yngve IT-centrum 2011-02-10 1.0 1 (9) Ramverk för projekt och uppdrag Peter Yngve IT-centrum 2011-02-10 1.0 2 (9) BAKGRUND/MOTIV... 3 MÅL OCH SYFTE... 3 DEFINITIONER AV PROJEKT... 3 MODELL FÖR PROJEKTSTYRNING...

Läs mer

Bilaga 4a. Införande. Upphandling av ett helhetsåtagande avseende IT-stöd för pedagogiskt genomförande inom Skolplattform Stockholm

Bilaga 4a. Införande. Upphandling av ett helhetsåtagande avseende IT-stöd för pedagogiskt genomförande inom Skolplattform Stockholm SID 1 (29) Bilaga 4a Införande Förfrågningsunderlag Upphandling av ett helhetsåtagande avseende IT-stöd för pedagogiskt genomförande inom Skolplattform Stockholm Box 22049, 104 22 Stockholm. Besöksadress

Läs mer

Bilaga 9. Överenskommelse om tjänstenivåer (SLA)

Bilaga 9. Överenskommelse om tjänstenivåer (SLA) 1 (7) Bilaga 9 Överenskommelse om tjänstenivåer (SLA) Innehåll 2 (7) Överenskommelse om tjänstenivå 3 1 Inledning 3 1.1 Tillämpning 3 1.2 Ansvarsfrihet 3 1.3 Ändring av tjänstenivåer 2 Servicenivåer 2.1

Läs mer

Bilaga 11. Mall för leveransavtal

Bilaga 11. Mall för leveransavtal 1 (9) Bilaga 11 Mall för leveransavtal Innehåll 2 (9) 1 Mall leveransavtal... 3 2 Bakgrund och syfte... 3 3 Leveransavtalets handlingar... 4 4 Kontaktpersoner... 5 5 Avtalsperiod... 5 6 Omfattning... 5

Läs mer

Vid avrop kan krav komma att ställas som är relaterade till arbetsmiljö till exempel ljud, ljus, ergonomi, strålning m.m.

Vid avrop kan krav komma att ställas som är relaterade till arbetsmiljö till exempel ljud, ljus, ergonomi, strålning m.m. 1 Kravkatalog Följande lista av krav kan avropande kund komma att tillämpa vid avrop vid förnyad konkurrensutsättning utöver de krav som tillämpas i denna upphandling. Tillämpningen kan ske både som obligatoriska

Läs mer

Examensarbeten hösten 2014

Examensarbeten hösten 2014 Examensarbeten hösten 2014 2/8 Förslag till examensarbeten på SPV Hos oss kan du ansöka om att skriva uppsats inom flera olika ämnesområden. För oss är uppsatsen ett bra sätt att få delar av vår verksamhet

Läs mer

Processbeskrivning Test

Processbeskrivning Test ProcIT-P-017 Processbeskrivning Test Lednings- och kvalitetssystem Fastställt av Sven Arvidson 2012-06-20 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Testprocessen 4 2.1

Läs mer

Bilaga 4f. Gemensamma processer. Upphandling av IT-stöd för hantering av elevdokumentation inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN

Bilaga 4f. Gemensamma processer. Upphandling av IT-stöd för hantering av elevdokumentation inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN UTBILDNINSFÖRVLTNINEN FÖRFRÅNINSUNDERL SID 1 (13) Bilaga 4f emensamma processer Förfrågningsunderlag Upphandling av IT-stöd för hantering av elevdokumentation inom Skolplattform Stockholm Box 22049, 104

Läs mer

Ladok3 på GU. Rollbeskrivning i projektorganisationen

Ladok3 på GU. Rollbeskrivning i projektorganisationen Ladok3 på GU Rollbeskrivning i projektorganisationen och befogenheter Y2013/13 Projektorganisation, roller Filnamn: L3_roller i projektet_bilaga 4_20131022.docx Gemensamma förvaltningen Utgåva B Ladok3

Läs mer

Preliminär projektdefinition Bygglovsleveranser 2010-04-09/bj

Preliminär projektdefinition Bygglovsleveranser 2010-04-09/bj INNEHÅLLSFÖRTECKNING 1. BAKGRUND... 2 2. SYFTE... 2 3. MÅL... 3 4. OMFATTNING OCH RESULTAT... 4 5. KOPPLINGAR TILL OCH BEROENDEN AV ANDRA PROJEKT... 5 6. PLAN FÖR GENOMFÖRANDE... 6 Sida 1 1. BAKGRUND Denna

Läs mer

Projektregler Gemensamma förvaltningen Projektkontoret Sida: 1 (9) 2011-07-11. Projektregler. för den universitetsgemensamma projektverksamheten

Projektregler Gemensamma förvaltningen Projektkontoret Sida: 1 (9) 2011-07-11. Projektregler. för den universitetsgemensamma projektverksamheten Projektkontoret Sida: 1 (9) Projektregler för den universitetsgemensamma projektverksamheten Projektkontoret Sida: 2 (9) Innehåll Syfte och bakgrund...4 1.1 Syfte...4 1.2 Bakgrund...4 2 Regler för projekt...4

Läs mer

ATEA. Tjänstekoncept. Arbetsplats och utskrift som funktion. Ateas tjänsteleverans till Kammarkollegiet. Version 2010-08-25

ATEA. Tjänstekoncept. Arbetsplats och utskrift som funktion. Ateas tjänsteleverans till Kammarkollegiet. Version 2010-08-25 ATEA Tjänstekoncept Arbetsplats och utskrift som funktion Ateas tjänsteleverans till Kammarkollegiet Version 2010-08-25 Innehåll Ateas koncept för IT-tjänster... 3 Syfte och mål... 3 Övergripande... 3

Läs mer

Metodstöd www.informationssäkerhet.se 2

Metodstöd www.informationssäkerhet.se 2 Projektplanering www.informationssäkerhet.se 2 Upphovsrätt Tillåtelse ges att kopiera, distribuera, överföra samt skapa egna bearbetningar av detta dokument, även för kommersiellt bruk. Upphovsmannen måste

Läs mer

Projektmodell. 1. Riktlinjer projektmodell 1 (6) 2010-03-12

Projektmodell. 1. Riktlinjer projektmodell 1 (6) 2010-03-12 12 1 (6) Projektmodell Projektmodell Projektmodell... 1 1. Riktlinjer projektmodell... 1 2. Projektförutsättningar... 2 2.1 Uppdragsgivaren... 2 2.2 Direktiv... 2 2.3 Förstudie... 2 2.4 Beslut... 2 2.5

Läs mer

1 Avropsförfrågan, BI-system

1 Avropsförfrågan, BI-system 1/6 1 Avropsförfrågan, BI-system Specifika uppgifter för aktuell förfrågan Nr. 1 Beskrivning med uppgifter specifika för denna avropsförfrågan Avropets utskicksdatum 2 Myndighetens diarienummer för avropet

Läs mer

Projektdirektiv samverkansprojektet Svensk geoprocess

Projektdirektiv samverkansprojektet Svensk geoprocess Projektdirektiv 201 2014-03-12 Sida: 1 (6) Projektdirektiv samverkansprojektet Svensk geoprocess 2014-03-12 Sida: 2 (6) Innehåll 1 Bakgrund... 3 2 Resultat och effekter... 3 3 Styrning och dokumentation...

Läs mer

HP Data Replication Solution Service för Continuous Access P9000 XP-diskfamiljen

HP Data Replication Solution Service för Continuous Access P9000 XP-diskfamiljen HP Data Replication Solution Service för Continuous Access P9000 XP-diskfamiljen HP Care Pack Services Teknisk information Genom tjänsten HP Data Replication Solution Service for Continuous Access utförs

Läs mer

Avrop från ramavtal E-förvaltningsstödjande tjänster

Avrop från ramavtal E-förvaltningsstödjande tjänster Kinna den 28 december 2012 Avrop från ramavtal E-förvaltningsstödjande tjänster 1. Bakgrund Marks kommun har under tre år genomfört ett pilotprojekt med systemstöd för arbete och presentation av målsättning,

Läs mer

E-arkiv Kronoberg och Blekinge

E-arkiv Kronoberg och Blekinge Dnr Elin Jonsson arkivarie Tel. 0470-413 07 Förstudie E-arkiv Kronoberg och Blekinge - Projektplan KOMMUNKANSLIET Kommunledningsförvaltningen 1 (12) Postadress Box 1222, 351 12 Växjö Besöksadress Västra

Läs mer

Inbjudan till dialog avseende drift och kundstöd

Inbjudan till dialog avseende drift och kundstöd samhällsskydd och beredskap 1 (5) Myndigheten för samhällsskydd och beredskap 651 81 KARLSTAD Telefonväxel: 0771-240 240 E-post: registrator@msb.se Inbjudan till dialog avseende drift och kundstöd Inledning

Läs mer

Förstudie: Övergripande granskning av ITdriften

Förstudie: Övergripande granskning av ITdriften Revisionsrapport Förstudie: Övergripande granskning av ITdriften Jönköpings Landsting Juni 2013 Innehållsförteckning Sammanfattning... 1 1. Inledning... 2 1.1. Bakgrund... 2 1.2. Uppdrag och revisionsfrågor...

Läs mer

Examensarbeten hösten 2015

Examensarbeten hösten 2015 Examensarbeten hösten 2015 2/6 Förslag till examensarbeten på SPV Hos oss kan du ansöka om att skriva uppsats inom flera olika ämnesområden. För oss är uppsatsen ett bra sätt att få delar av vår verksamhet

Läs mer

Utgåva Ändringsnot Datum. 2 Denna riktlinje är omarbetad och ersätter den gamla TR08:01 version A med publiceringsdatum 2008-06-30.

Utgåva Ändringsnot Datum. 2 Denna riktlinje är omarbetad och ersätter den gamla TR08:01 version A med publiceringsdatum 2008-06-30. Uppdateringar Utgåva Ändringsnot Datum 2 Denna riktlinje är omarbetad och ersätter den gamla TR08:01 version A med publiceringsdatum 2008-06-30. 2012-06-20 2/12 Innehåll 1 Allmänt... 4 1.1 Bakgrund...

Läs mer

Riktlinjer Projektmodell fo r Kungä lvs kommun

Riktlinjer Projektmodell fo r Kungä lvs kommun Riktlinjer Projektmodell fo r Kungä lvs kommun Riktlinjerna är antagna av förvaltningsledningen 2013-01-28 och gäller tillsvidare. (Dnr KS2012/1542) Ansvarig för dokumentet är chefen för enheten Utveckling,

Läs mer

Projektplan, Cykelgarage

Projektplan, Cykelgarage Projektplan, Cykelgarage Johan Anderholm, (dt08ja5@student.lth.se) Jon Andersen (dt08ja8@student.lth.se) Marcus Carlberg (dt08mc4@student.lth.se) Simon Ekvy (dt08se2@student.lth.se) Stefan Johansson (dt08sj7@student.lth.se)

Läs mer

Projektplan. LiTH Reglering av Avgaser, Trottel och Turbo 2008-02-11. Fredrik Petersson Version 1.0. Status. Reglerteknisk Projektkurs RATT LIPs

Projektplan. LiTH Reglering av Avgaser, Trottel och Turbo 2008-02-11. Fredrik Petersson Version 1.0. Status. Reglerteknisk Projektkurs RATT LIPs Fredrik Petersson Version 1.0 Status Granskad 2008-02-11 NL, PA Godkänd 1 2 PROJEKTIDENTITET VT 2008, RATT-Gruppen Linköpings tekniska högskola, ISY- Fordonssystem Namn Ansvar Telefon E-post Daniel Ahlberg

Läs mer

Projekt- och kvalitetsstyrning på Frontec

Projekt- och kvalitetsstyrning på Frontec Projekt- och kvalitetsstyrning på Frontec Detta dokument beskriver hur Frontec bedriver utvecklingsprojekt med kvalitetssäkring FSAB_LS020_Projekt och kvalitetsstyrning A.doc Sida 1(6) Frontec kan projekt

Läs mer

PROJEKTDIREKTIV. Uppgradering av epostsystemet Exchange

PROJEKTDIREKTIV. Uppgradering av epostsystemet Exchange direktiv Sid 1 (6) PROJEKTDIREKTIV Uppgradering av epostsystemet Exchange Webbadress https://www.samarbetsyta.umu.se/adm/itenheten/projects/exchange2013/sitepages/start sida.aspx namn Uppgradering av epostsystemet

Läs mer

Frågor och svar. Programvaror och tjänster 2014 - Systemutveckling. Statens inköpscentral vid Kammarkollegiet

Frågor och svar. Programvaror och tjänster 2014 - Systemutveckling. Statens inköpscentral vid Kammarkollegiet Frågor och svar Köpare Upphandling Köpare: Statens inköpscentral vid Kammarkollegiet Namn: Handläggare: Daniel Melin Referensnr: 96-36-2014 Programvaror och tjänster 2014 - Systemutveckling Telefon: +46

Läs mer

Ramavtal. E-arkiv. AVTALSUNDERLAG Bilaga 12 Diarienr (åberopas vid korrespondens)

Ramavtal. E-arkiv. AVTALSUNDERLAG Bilaga 12 Diarienr (åberopas vid korrespondens) Polisens verksamhetsstöd Administrativa enheten Upphandlingssektionen AVTALSUNDERLAG Bilaga 12 Diarienr (åberopas vid korrespondens) Ärendebeteckning 1192 Ramavtal E-arkiv INNEHÅLLSFÖRTECKNING 1 PARTER...

Läs mer

STADSLEDNINGSKONTORET SOA SDK IT-AVDELNINGEN VERSION 2.1. Läs mig först. Stockholms stad SOA-plattform. Sida 1 (5)

STADSLEDNINGSKONTORET SOA SDK IT-AVDELNINGEN VERSION 2.1. Läs mig först. Stockholms stad SOA-plattform. Sida 1 (5) Läs mig först Stockholms stad SOA-plattform 1 (5) Innehållsförteckning 1 Beskrivning av SDK 3 1.1 Software Developer Kit för Utvecklare... 3 1.2 Support för... 3 1.3 Omfattning... 4 1.4 Versionshantering...

Läs mer

Upphandling av It stöd för samordnad vård- och omsorgplanering

Upphandling av It stöd för samordnad vård- och omsorgplanering Gemensam IT samordningsfunktion 49 kommuner i Västra Götaland och Västra Götalandsregionen 1.0 Utgåva (1)5 Godkänt av : Godk datum: Styrgrupp SVPL 2014-04-02 Upphandling av It stöd för samordnad vård-

Läs mer

RIKTLINJER. Riktlinjer för styrning av IT-verksamhet

RIKTLINJER. Riktlinjer för styrning av IT-verksamhet RIKTLINJER Riktlinjer för styrning av IT-verksamhet RIKTLINJER 2 Riktlinjer för styrning av IT-verksamhet. 1 Inledning Håbo kommuns övergripande styrdokument inom IT är IT-policy för Håbo kommun. Riktlinjer

Läs mer

DoÄr E-arkivering. Projektplan

DoÄr E-arkivering. Projektplan Håkan Svensson Sida: 1 (6) DoÄr Projektplan Håkan Svensson Sida: 2 (6) Innehåll 1 Basfakta... 3 2 Projektidé och mål... 3 2.1 Bakgrund och projektidé... 3 2.2 Projektmål... 3 2.3 Avgränsningar... 4 3 Leverans

Läs mer

Förklarande text till revisionsrapport Sid 1 (5)

Förklarande text till revisionsrapport Sid 1 (5) Förklarande text till revisionsrapport Sid 1 (5) Kravelementen enligt standarden ISO 14001:2004 Kap 4 Krav på miljöledningssystem 4.1 Generella krav Organisationen skall upprätta, dokumentera, införa,

Läs mer

inava Teknik utför i huvudsak alla

inava Teknik utför i huvudsak alla Teknik inava Teknik utför i huvudsak alla uppdrag hos uppdragsgivaren eller på annan överenskommen plats. Samarbete med andra företag kan arrangeras och samordnas för att utföra uppdrag med större omfattning.

Läs mer

Rätt information till rätt person vid rätt tillfälle

Rätt information till rätt person vid rätt tillfälle Rätt information till rätt person vid rätt tillfälle System för samverkan, effektivitet och konkurrenskraft Du håller säkert med om att ditt företags kanske mest värdefulla tillgång består av all den information

Läs mer

Att samverka hur och varför. Anna Pegelow e-delegationen Anna Johansson - Tillväxtverket

Att samverka hur och varför. Anna Pegelow e-delegationen Anna Johansson - Tillväxtverket Att samverka hur och varför Anna Pegelow e-delegationen Anna Johansson - Tillväxtverket Grundläggande krav Myndighetsförordningen: 3 Myndighetens ledning ansvarar inför regeringen för verksamheten och

Läs mer

Projektarbete. Johan Eliasson

Projektarbete. Johan Eliasson Projektarbete Johan Eliasson Projekt Definition: En grupp av projektdeltagare utför under ledning av en projektledare en klart definierad uppgift, på en viss tid, med begränsade resurser Resurserna kan

Läs mer

Utveckling av gemensamma arbetsprocesser för högskolans verksamhetsstöd

Utveckling av gemensamma arbetsprocesser för högskolans verksamhetsstöd Dnr Mahr 19-2014/568 1 (av 10) Projektplan Beslutsdatum: Beslutande: Dokumentansvarig: 2015-03-27 Susanne Wallmark Jenny Wendle Revisionsinformation Version Datum Kommentar 1.0 150327 Slutgiltig projektplan

Läs mer

Konsultbolag1. Testplan för Europa version 2. Testplan Projekt Europa Sid 1 (av 9) 2009-05-14. Europa-projektet. Dokumenthistorik

Konsultbolag1. Testplan för Europa version 2. Testplan Projekt Europa Sid 1 (av 9) 2009-05-14. Europa-projektet. Dokumenthistorik Testplan Projekt Europa Sid 1 (av 9) Europa-projektet Testplan för Europa version 2 Dokumenthistorik Utgåva Datum Författare Kommentar 1 2008-12-16 Ulf Eriksson Ursprunglig version, utkast 2 2008-12-18

Läs mer

Projektplan. Behovsstyrt IKT (Inter Kommunikativ Teknik ) för äldre

Projektplan. Behovsstyrt IKT (Inter Kommunikativ Teknik ) för äldre Projektplan Behovsstyrt IKT (Inter Kommunikativ Teknik ) för äldre Info ÄO Projektplan-ITK-stöd för äldre.docm Socialförvaltningen Besöksadress: Riddarplatsen 5, 4 tr Vård och omsorg, Järfälla hemstöd

Läs mer

IT-Strategi 2004-10-12 1(7) IT-strategi 2005-01-14 KF 10/05

IT-Strategi 2004-10-12 1(7) IT-strategi 2005-01-14 KF 10/05 IT-Strategi 2004-10-12 1(7) IT-strategi 2005-01-14 KF 10/05 IT-Strategi 2004-10-12 2(7) Innehåll 1 Inledning...3 1.1 Bakgrund...3 2 Intention...3 3 Ledning och ansvar...4 4 Nuläge...5 5 Strategier och

Läs mer

Införandemetod Medverkaprojektet

Införandemetod Medverkaprojektet Införandemetod Medverkaprojektet Förbättring och digitalisering av Malmö stads ärendeprocess Detta dokument beskriver översiktligt projektprocessen för de införandeprojekt som bedrivits i varje förvaltning

Läs mer

Checklista inför beslut, BP1 JA NEJ

Checklista inför beslut, BP1 JA NEJ 1(6) Projektnamn: Resultatuppföljning på alla nivåer (delprojekt inom Ett lärande Väsby) Projektledare: Daniel Santesson, Strategisk Controller Checklista inför beslut, BP1 JA NEJ Projektorganisationen

Läs mer

ATT FASTSTÄLLA ARKIVANSVAR & ARKIVORGANISATION

ATT FASTSTÄLLA ARKIVANSVAR & ARKIVORGANISATION ATT FASTSTÄLLA ARKIVANSVAR & ARKIVORGANISATION en handledning för myndigheter i Göteborgs Stad & Västra Götalandsregionen Version 2, 2013-02-26 INNEHÅLL INLEDNING... 3 1 MYNDIGHETENS ARKIVORGANISATION...

Läs mer

Avropsförfrågan/anbudsformulär. Gismo med GeoPanelen till Tyresö kommun

Avropsförfrågan/anbudsformulär. Gismo med GeoPanelen till Tyresö kommun 1 (10) Avropsförfrågan/anbudsformulär Gismo med GeoPanelen till Tyresö kommun 2 (10) Innehåll 1 Anbudsförfrågan... 3 2 Anbudsformulär... 5 3 Leveransavtal... 7 4 Tillägg... 10 3 (10) 1 ANBUDSFÖRFRÅGAN

Läs mer

Riktlinjer för digital arkivering i Linköpings kommun

Riktlinjer för digital arkivering i Linköpings kommun 1 (8) E-Lin projektet 2014-06-05 Riktlinjer Riktlinjer för digital arkivering i Linköpings kommun 2 Innehåll Inledning och bakgrund... 3 Ansvar... 4 Systemupphandling... 4 Gallring... 5 Informationssäkerhet...

Läs mer

Er partner inom IT service management. Utbildningar e-learning Workshops Material Coachning

Er partner inom IT service management. Utbildningar e-learning Workshops Material Coachning Er partner inom IT service management Utbildningar e-learning Workshops Material Coachning Service Management En uppsättning specialiserade organisatoriska förmågor med syftet att leverera värde till kunderna

Läs mer

Gemensamt IT-stöd för diarieföring hos Sveriges domstolar. Jan Käll Produktförvaltare

Gemensamt IT-stöd för diarieföring hos Sveriges domstolar. Jan Käll Produktförvaltare Gemensamt IT-stöd för diarieföring hos Sveriges domstolar Jan Käll Produktförvaltare 1 Domstolsverket och Sveriges domstolar Domstolsverket är en statlig myndighet som lyder under regeringen och som fungerar

Läs mer

Förvaltningsplan för Ladok

Förvaltningsplan för Ladok 1 Förvaltningsplan för Ladok 2 1 INLEDNING 3 1.1 Revisionshistorik 3 1.2 Sammanfattning 3 2 FÖRVALTNINGSOBJEKTET 3 2.1 Förvaltningsperiod 3 2.2 Övergripande beskrivning 4 2.3 Förvaltningens omfattning

Läs mer

Projektspecifikation Malmö högskola konceptmiljö

Projektspecifikation Malmö högskola konceptmiljö 2010-10-29 Page: 1 (13) Projektspecifikation Malmö högskola konceptmiljö VERSION 1.0 2010-10-29 Page: 2 (13) Innehållsförteckning 1 Generell Information... 4 1.1 Godkännande av Projektspecifikation...

Läs mer

Dokument 1 till Kontrakt PROJEKTGENOMFÖRANDE

Dokument 1 till Kontrakt PROJEKTGENOMFÖRANDE Dokument 1 till Kontrakt 2011-04-20 Sid 1 (7) Dokument 1 till Kontrakt PROJEKTGENOMFÖRANDE Unicon 2011 Dokument 1 till Kontrakt 2011-04-20 Sid 2 (7) Innehåll: 1. PROJEKTLEDNING... 3 1.1. Allmänt... 3 1.2.

Läs mer

Processbeskrivning Avveckling

Processbeskrivning Avveckling ProcIT-P-021 Processbeskrivning Avveckling Lednings- och kvalitetssystem Fastställt av Sven Arvidson 2012-06-20 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Avvecklingsprocessen

Läs mer

Systemdrift och Systemförvaltning Centrala verksamhetssystem Service Desk

Systemdrift och Systemförvaltning Centrala verksamhetssystem Service Desk SID 1 (7) Bilaga 13A Instruktion för prissättning Förfrågningsunderlag Systemdrift och Systemförvaltning Centrala verksamhetssystem Service Desk 105 35 STOCKHOLM. Telefon 08-508 29 000. Fax 08-508 29 036.

Läs mer

VANLIGA FALLGROPAR I OUTSOURCINGAVTALET. Peter Nordbeck /Partner Caroline Sundberg /Associate 15 maj 2013

VANLIGA FALLGROPAR I OUTSOURCINGAVTALET. Peter Nordbeck /Partner Caroline Sundberg /Associate 15 maj 2013 VANLIGA FALLGROPAR I OUTSOURCINGAVTALET Peter Nordbeck /Partner Caroline Sundberg /Associate 15 maj 2013 2 Agenda vanliga fallgropar i Outsourcingavtalet Fallgropar i Outsourcingavtal Några goda råd på

Läs mer

Snabbguide - Region Skånes projektmodell webbplats:www.skane.se/projektmodell

Snabbguide - Region Skånes projektmodell webbplats:www.skane.se/projektmodell Snabbguide - Region Skånes projektmodell webbplats:www.skane.se/projektmodell BP = Beslutspunkt (Projektmodellen har fem beslutspunkter. Vid varje punkt tar beställare/styrgrupp beslut om stopp eller gå)

Läs mer

Kravställning på e-arkiv från informationssäkerhetsperspektiv

Kravställning på e-arkiv från informationssäkerhetsperspektiv Kravställning på e-arkiv från informationssäkerhetsperspektiv Författare: Delprojektgruppen informationssäkerhet Årtal: 2014 Författare: Delprojektgruppen informationssäkerhet Sammanfattning Inom ramen

Läs mer

Projektbeskrivning OpenDataUmea

Projektbeskrivning OpenDataUmea Projektbeskrivning OpenDataUmea Projektets syfte Projekt OpenDataUmea kommer att realisera PSI-direktivet lokalt i Umeå kommun. Projektet kommer att publicera minst 10 dataset men kommer också att ta fram

Läs mer

Beslut HSN 2013-12-11 HSN 1212-1455 BILAGA 2 Intern kontrollplan för Hälso- och sjukvårdsförvaltningen 2014

Beslut HSN 2013-12-11 HSN 1212-1455 BILAGA 2 Intern kontrollplan för Hälso- och sjukvårdsförvaltningen 2014 Intern kontrollplan för Hälso- och sjukvårdsförvaltningen 2014 Målkategori: Effektiv och ändamålsenlig verksamhetsstyrning Riskområde Riskbeskrivning Kontrollmoment Kontrollansvar Frekvens Rapportering

Läs mer

Övergripande granskning av ITverksamheten

Övergripande granskning av ITverksamheten Övergripande granskning av ITverksamheten Februari 2006 (1) 1. Inledning PricewaterhouseCoopers (PwC) har på uppdrag av kommunrevisionen i Borås Stad genomfört en övergripande granskning av Borås Stads

Läs mer

Statens servicecenter

Statens servicecenter Statens servicecenter Anslutning till Statens servicecenter åren 2017-2019 Thomas Pålsson Marie K Johansson Hans Tynelius Annica Schölund Storm Agenda Inledning Thomas Pålsson, Generaldirektör Vårt regeringsuppdrag

Läs mer

1 Ekonomisystem. ESV - Ekonomistyrningsverket Mall för prislista, Ekonomisystem Bilaga 5a till förfrågningsunderlag1/33

1 Ekonomisystem. ESV - Ekonomistyrningsverket Mall för prislista, Ekonomisystem Bilaga 5a till förfrågningsunderlag1/33 Mall för prislista, Ekonomisystem Bilaga 5a till förfrågningsunderlag1/33 Leverantörens namn: UNIT4 Agresso AB (SVAR 3.11.1.1 låst cell: MS SQL Server 2008 R2, Enterprise Edition) 149 Antal ifyllda prisuppgifter

Läs mer

Digital arkivering och historiklagring. 2010-12-06 Anastasia Pettersson och Anders Kölevik

Digital arkivering och historiklagring. 2010-12-06 Anastasia Pettersson och Anders Kölevik Digital arkivering och historiklagring 2010-12-06 Anastasia Pettersson och Anders Kölevik Generella principer för arkivering Informationsbärare: Analogt (papper) Digitalt (ettor och nollor på t ex ett

Läs mer

Förenklad förstudie och samarbetsförslag

Förenklad förstudie och samarbetsförslag Tjänsteskrivelse -02-21 KFN 2013.0096 Handläggare: Annelie Henriksson Förenklad förstudie och samarbetsförslag Sammanfattning Arbetet med införande av e-arkiv i Karlskoga kommun har påbörjats under hösten

Läs mer

Användarhandledning Standardfaktura SEB imail 1.1 Standardfaktura

Användarhandledning Standardfaktura SEB imail 1.1 Standardfaktura imail 1.1 Standardfaktura INNEHÅLL 1 INTRODUKTION... 3 2 ANSLUTNING... 3 2.1 Certifiering... 3 2.2 Test... 3 2.3 Produktionssättning... 4 3 PRODUKTION... 4 4 ARKIV OCH VIEWING... 5 5 FORMATBESKRIVNINGAR...

Läs mer

Regionalt befolkningsnav Utgåva P 1.0.0 Anders Henriksson Sida: 1 (6) 2011-09-20. Projektdirektiv

Regionalt befolkningsnav Utgåva P 1.0.0 Anders Henriksson Sida: 1 (6) 2011-09-20. Projektdirektiv Anders Henriksson Sida: 1 (6) Projektdirektiv Regionala nav för identitetsuppgifter och hantering av autentiserings- och auktorisationsuppgifter Anders Henriksson Sida: 2 (6) 1 Projektnamn/identitet Regionala

Läs mer

IT-generella kontroller i Agresso, skattekontosystemet, Moms AG och Tina

IT-generella kontroller i Agresso, skattekontosystemet, Moms AG och Tina 1 IT-generella kontroller i Agresso, skattekontosystemet, Moms AG och Tina Riksrevisionen har som ett led i den årliga revisionen av Skatteverket granskat IT-generella kontroller i ekonomisystemet Agresso,

Läs mer

Framgångsfaktorer Program Management inom FöreningsSparbanken. 23 mars 2004 Program Management v1.0 1

Framgångsfaktorer Program Management inom FöreningsSparbanken. 23 mars 2004 Program Management v1.0 1 Framgångsfaktorer Program Management inom FöreningsSparbanken 23 mars 2004 Program Management v1.0 1 Styrning av Program och Projekt Vision Initiering Definiera omfattning Formulera slutmål Precisera arbetssätt

Läs mer

Slutrapport Mobilitet Mobila tjänster

Slutrapport Mobilitet Mobila tjänster 1.00 Utgåva (1)9 Dokumenttyp: Projektdokument Dokumentbeskrivning: Projekt: Projektnummer (enligt esamordnare) Slutrapport Mobilitet Mobila tjänster i Göteborgs stad Utfärdat av: Utf datum: Godkänt av

Läs mer

Software Asset Management (SAM) Licenshantering i Göteborgs Stad

Software Asset Management (SAM) Licenshantering i Göteborgs Stad Software Asset Management (SAM) Licenshantering i Göteborgs Stad Vad är SAM? Software Asset Management beskriver alla de krav på infrastruktur och processer som krävs för en effektiv förvaltning, kontroll

Läs mer

Bilaga 1 Allmänna villkor för Socialnämnds anslutning till Sammansatt Bastjänst Ekonomiskt Bistånd (SSBTEK)

Bilaga 1 Allmänna villkor för Socialnämnds anslutning till Sammansatt Bastjänst Ekonomiskt Bistånd (SSBTEK) Bilaga 1 Allmänna villkor för Socialnämnds anslutning till Sammansatt Bastjänst Ekonomiskt Bistånd (SSBTEK) 1. Allmänt Dessa Allmänna villkor reglerar Socialnämndens anslutning till Sammansatt Bastjänst

Läs mer

Om organisationen. Vad är en multiprojektorganisation. Projektportföljen. Projektet i organisationen multprojektorganisering - kommunikation

Om organisationen. Vad är en multiprojektorganisation. Projektportföljen. Projektet i organisationen multprojektorganisering - kommunikation Projektet i organisationen multprojektorganisering - kommunikation anneli linde Om organisationen Vad är en multiprojektorganisation Hur fungerar en sådan organisation Vilka är de typiska utmaningarna

Läs mer

Inga krav utöver ISO 14001

Inga krav utöver ISO 14001 Förordning (2009:907) om miljöledning i statliga myndigheter Relaterat till motsvarande krav i ISO 14001 och EMAS De krav som ställs på miljöledningssystem enligt EMAS utgår från kraven i ISO 14001. Dessutom

Läs mer

Bilaga. Särskilda villkor för Molntjänst. Programvaror och tjänster 2014. Systemutveckling

Bilaga. Särskilda villkor för Molntjänst. Programvaror och tjänster 2014. Systemutveckling Sid 1 (7) 2014-11-07 Dnr 96-36-2014 Bilaga Särskilda villkor för Molntjänst Programvaror och tjänster 2014 Systemutveckling Sid 2 (7) Innehållsförteckning 1 Tillämplighet 2 2 Särskilt om kontraktshandlingar

Läs mer

Prioriterade nyckeltal

Prioriterade nyckeltal Dnr: MAHR 61-2014/600 1 (av 7) Projektplan Beslutsdatum: Beslutande: Dokumentansvarig: 2015-05-04 Styrgruppen Madeleine Hulting Revisionsinformation Version Datum Kommentar 1.1 2015-04-23 Utkast till projektgrupp

Läs mer

SLSO Utvärdering av Kompetenslyftet ehälsa i primärvården

SLSO Utvärdering av Kompetenslyftet ehälsa i primärvården SLSO Utvärdering av Kompetenslyftet ehälsa i primärvården Delrapport 1 31 januari 2012 Utvärdering av kompetenslyftet ehälsa i primärvården Projekt: Kompetenslyftet ehälsa Period: December 2011- januari

Läs mer

Leverera Förmånsinformation, LEFI Online. Service Level Agreement

Leverera Förmånsinformation, LEFI Online. Service Level Agreement Leverera Förmånsinformation, LEFI Online VO T, -tjänster Innehåll 1. DOKUMENTINFORMATION... 3 1.1 SYFTE... 3 1.2 BESKRIVNING AV -TJÄNSTEN... 3 1.3 OMFATTNING... 3 1.4 AVGRÄNSNINGAR... 3 1.5 BEROENDEN...

Läs mer

SUNETs Projektmodell. Syfte. Processer. Version: 2012-04-10

SUNETs Projektmodell. Syfte. Processer. Version: 2012-04-10 SUNETs Projektmodell Version: 2012-04-10 Syfte Syftet med denna modell för arbete med SUNETs tjänster är att ge användare och kunder en väl fungerande tjänst som uppfyller de mål som SUNET styrelse har

Läs mer

Kommunikationstorget för Västra Götalands kommuner närmare varandra

Kommunikationstorget för Västra Götalands kommuner närmare varandra Kommunikationstorget Västra Götalands kommuners samverkansnät Kommunikationstorget är upphandlat för att Västra Götalands kommuner (VGK) skall kunna kommunicera via ett från Internet avgränsat och kvalitetssäkrat

Läs mer

Bilaga 4e. Samarbetsformer och fora. Upphandling av IT-stöd för barn- och elevregister inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN

Bilaga 4e. Samarbetsformer och fora. Upphandling av IT-stöd för barn- och elevregister inom Skolplattform Stockholm UTBILDNINGSFÖRVALTNINGEN SID 1 (10) Bilaga 4e Samarbetsformer och fora Förfrågningsunderlag Upphandling av IT-stöd för barn- och elevregister inom Skolplattform Stockholm Box 22049, 104 22 Stockholm. Besöksadress Hantverkargatan

Läs mer

Vardagssamverkan Blåljus

Vardagssamverkan Blåljus U T V E C K L I N G A V S A M V E R K A N I S Y F T E A T T Ö K A S A M O R D N I N G E N A V S A M H Ä L L E T S R E S U R S E R F Ö R A T T F Ö R H I N D R A O C H L I N D R A S T Ö R N I N G A R I S

Läs mer