Bilaga 2 Beskrivning av projektet och dess leveranser

Transkript

1 Bilaga 2 Beskrivning av projektet och dess leveranser 1 (29) Bilaga 2 Beskrivning av projektet och dess leveranser

2 Bilaga 2 Beskrivning av projektet och dess leveranser 2 (29) INNEHÅLL 1 SYFTE MED DETTA DOKUMENT Begrepp PROJEKT DIGITAL ARKIVTJÄNST Bakgrund Projektbeskrivning Intressenter PROJEKTORGANISATION Organisation Styrgrupper LEVERANS AV AVTALAT SYSTEM 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... 28

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

4 Bilaga 2 Beskrivning av projektet och dess leveranser 4 (29) 1 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 projektet används två centrala begrepp: e-arkiv samt. Med e-arkiv avses Systemet. Detta medan omfattar både den tekniska lösningen samt 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 (29) 2 Projekt Syftet med avsnitt 2 är att ge allmän information om projektet Digital arkivtjänst och resterade avsnitt utgör en del av avtalsunderlaget. 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/ Projekt 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 projektet 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. Införandeprojektet 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 (29) 2.2 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 har Polisen upphört att arkivera på papper, cd- och dvd-skivor och filkataloger Projektets effektmål Nedan listas projektets 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 att möta upp till bestämda effektmål ska projekt leverera både en teknisk lösning för e-arkivering samt därtill kopplade verk-

7 Bilaga 2 Beskrivning av projektet och dess leveranser 7 (29) samhetsregler i form av en gemensam digital arkiveringsprocess 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 för e-arkiv menas 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 en leverantör. 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 en leverantör, 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 en leverantör tillhandahåller i så hög grad som möjligt kunna driftas och förvaltas utan beroende av en leverantör. 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 (29) 2.3 Intressenter Inom projektet har följande intressenter identifierats: Figur 2 Intressenter för 3 Projektorganisation 3.1 Organisation Projektet 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 (29) 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 (29) 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 avtalat System Med avtalat System avses Leverantörens standardsystem med tillhörande anpassningar som uppfyller överenskomna krav definierade i bilaga 1 Kravspecifikation samt krav definierade enligt denna bilaga. Detta med hänsyn tagen till relaterad överenskommen ändringshantering. Anpassningar kan innebära konfiguration såväl som utveckling. 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 Projektet ä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 (29) 5.1 Etappernas leveranser och tidplaner Utifrån Införandeprojektet 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 tidigast 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 En (1) månad definieras som trettio (30) kalenderdagar

12 Bilaga 2 Beskrivning av projektet och dess leveranser 12 (29) 2. uppsatt test- och utbildningsmiljö enligt Leverantörens anvisningar, 3. medverkande vid installation av standardsystem i test- resp. utbildningsmiljö, 4. testplan och testfall, 5. 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: 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 (29) - 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 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. Exempel på det som avses: kravet är en gallringsfunktion, men vilka gallringsregler som ska kunna tillämpas måste detaljspecificeras och sedan realiseras.

14 Bilaga 2 Beskrivning av projektet och dess leveranser 14 (29) 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 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 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.

15 Bilaga 2 Beskrivning av projektet och dess leveranser 15 (29) Integration Refererade krav Kommentar Behörighetssystem IFS 028- IFS 032 Active Directory med Kerberosverifiering Polisens händelselogg IFS 005 IFS 026 E-post IFT 049 F 117 F 132 F 133 Inleveransarea F 016 Anslutning pilotsystem F 021 Övervakning, fånga systemmeddelande IFT 046 IFT 048 Exchange Server Bilaga 4, Inleveransspecifikation Adobe LiveCycle ES2 F 083 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: 5 Avser installation av hårdvara, operativsystem och databaser.

16 Bilaga 2 Beskrivning av projektet och dess leveranser 16 (29) 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ö, 7. 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 införandeprojektets startdatum. - Acceptanstest av leverans i etapp 2 ska vara genomförd inom en (1) månad efter faktiskt leveransdag. 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

17 Bilaga 2 Beskrivning av projektet och dess leveranser 17 (29) 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 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, med vid behov kommer RPS att avropa tjänster från Leverantören för att få stöd i anslutningsprojekten. 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,

18 Bilaga 2 Beskrivning av projektet och dess leveranser 18 (29) 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. stöd vid rensning av testdata i produktionsmiljö, 2. beredskap för stöd vid 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, 5. 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 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. 8 Är restpunkten av prestandakaraktär ansvarar Leverantören av verifieringen på motsvarande sätt som under etapp 2.

19 Bilaga 2 Beskrivning av projektet och dess leveranser 19 (29) - 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 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

20 Bilaga 2 Beskrivning av projektet och dess leveranser 20 (29) 1. stöd vid eventuell rensning av testdata i produktionsmiljö, 2. stöd vid uppdatering av leveransgodkänd release i produktionsmiljö, 3. extra beredskap 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ö 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.

21 Bilaga 2 Beskrivning av projektet och dess leveranser 21 (29) 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 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 2.

22 Bilaga 2 Beskrivning av projektet och dess leveranser 22 (29) 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 012 IFT 013 IFT 016 IFT 018 IFT IFT 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.

23 Bilaga 2 Beskrivning av projektet och dess leveranser 23 (29) 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ö 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

24 Bilaga 2 Beskrivning av projektet och dess leveranser 24 (29) 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 014 IFT 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ö,

25 Bilaga 2 Beskrivning av projektet och dess leveranser 25 (29) 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. 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ö.

26 Bilaga 2 Beskrivning av projektet och dess leveranser 26 (29) 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. 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.

27 Bilaga 2 Beskrivning av projektet och dess leveranser 27 (29) 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. 8.2 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 1-4.

28 Bilaga 2 Beskrivning av projektet och dess leveranser 28 (29) 9 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. 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,

29 Bilaga 2 Beskrivning av projektet och dess leveranser 29 (29) - informationstillfälle, med demonstration, för projektgruppen, - informationstillfälle för arkitekter, drift samt säkerhetsgruppen.

30 Bilaga 3, Samverkan och styrning 1 (14) Bilaga 3 Samverkan och styrning

31 Bilaga 3, Samverkan och styrning 2 (14) INNEHÅLL 1 SYFTE MED DETTA DOKUMENT SAMVERKAN LEVERANTÖRSSAMVERKAN Strategisk nivå Taktisk nivå Operativ nivå I projektläge Projektmodell I förvaltningsläge Förvaltnings- och Supporthantering TJÄNSTENIVÅ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 tjänstenivåer... 13

32 Bilaga 3, Samverkan och styrning 3 (14) shistorik Datum Ändring Handläggare Ann Rosenlind 1 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 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.

33 Bilaga 3, Samverkan och styrning 4 (14) 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. 3.2 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. I projektläge 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.

34 Bilaga 3, Samverkan och styrning 5 (14) 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 I projektläge I projektläge ska Leverantören ha en utsedd Projektledare med projektansvaret för Leverantörens leveranser och 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 delprojekt 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 projektets 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). Införandeprojektet och förvaltning kommer att drivas på svenska. Personal som deltar i införandeprojektet och kommande förvaltning samt support ska därför kunna tala och skriva svenska.

35 Förfrågning Ärende Uppgjord av Bilaga 3, Samverkan och styrning 6 (14) 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. 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) Ärende Lösning Tjänstegränssnitt för SLA Leverantör (3 rd line support) Figur 1 Supportorganisation 4 Tjänstenivåer (SLA) Detta avsnitt beskriver de tjänstenivåer (SLA) som gäller för leverans av förvaltningsstödjande tjänster för Polisens e-arkiv.

36 Bilaga 3, Samverkan och styrning 7 (14) 4.1 Tillämpning En överenskommelse om tjänstenivå beskriver de tjänstenivåerna som ska levereras i de tjänster som tillhandahålls. Tjänstenivå 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 omfattar en tjänstenivå, benämnd normal nivå. Brister och fel i tjänstenivå 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 tjänstenivåerna ska Leverantören vidta de åtgärder som krävs för att uppnå och hålla de överenskomna tjänstenivå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.

37 Bilaga 3, Samverkan och styrning 8 (14) 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 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

38 Bilaga 3, Samverkan och styrning 9 (14) 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 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.

39 Bilaga 3, Samverkan och styrning 10 (14) 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. 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.

40 Bilaga 3, Samverkan och styrning 11 (14) Å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, till anpassningar därav för vilket Leverantören ansvarat eller till problem 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. 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, till anpassningar därav för vilket Leverantören ansvarat eller till problem 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

41 Bilaga 3, Samverkan och styrning 12 (14) 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 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.

42 Bilaga 3, Samverkan och styrning 13 (14) 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 - 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 Tjänstenivå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 tjänstenivåer Parterna kan överenskomma om ändring av tjänstenivåer, inom avtalets ramar. Sådan överenskommelse ska vara skriftlig och hanteras enligt processen för förändringshantering.

43 Bilaga 3, Samverkan och styrning 14 (14) Under speciella omständigheter, som till exempel vid större uppgraderingar, kan parterna överenskomma om minskning i tjänstenivå under en begränsad tidperiod. En sådan överenskommelse skall vara skriftlig.

44 Bilaga 4 Inleveransspecifikation 1 (26) PVS /11 V1.0 Bilaga 4 Inleveransspecifikation För pilotsystemen K-RAR samt DurTvå

45 Bilaga 4 Inleveransspecifikation 2 (26) PVS /11 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 13 6 Specifikt DurTvå Ärende Involverad person Anmälan Engagerad personal Kallelse Tvångsmedel PM Rapport Protokoll Externt dokument Egna anteckningar 22 7 Specifikt K-RAR Ärende Involverad person Anmälan 25

46 Bilaga 4 Inleveransspecifikation 3 (26) PVS /11 V1.0 Datum Ändring Handläggare Ann Rosenlind

47 Bilaga 4 Inleveransspecifikation 4 (26) PVS /11 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 verksamhetssystem, 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 verksamhetssystem. Ä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

48 Bilaga 4 Inleveransspecifikation 5 (26) PVS /11 V1.0 T Beskrivning finnas Type: S (Text), N (Siffror), D (Datum), O (Objekt), B(Boolean), St (Struktur, CDatafält), Bi (Bilaga), 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 inom pilotprojektet att definieras tillsammans med verksamheten. 2.2 Tillvägagångssätt Projektet har gått igenom systemen K-RAR och DurTvå och skapat en karta över hur informationen hänger ihop i verksamhetssystemen. Kartan visar hur objekten kommer att relatera till varandra när de levererats till e-arkiv.

49 Bilaga 4 Inleveransspecifikation 6 (26) PVS /11 V1.0 Scheman som beskrivs i detta dokument ska spegla allt det som syns i verksamhetssystemen, ä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). Informationen har samlats in via; dokumentation om verksamhetssystemen, 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.

50 Bilaga 4 Inleveransspecifikation 7 (26) PVS /11 V1.0 Figur 1 Metadata i XML-schema och handlingar 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 systemen DurTvå och K- RAR. 4.1 Karta över objekten

51 Bilaga 4 Inleveransspecifikation 8 (26) PVS /11 V1.0 Figur 2 Karta över objekten 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.

52 Bilaga 4 Inleveransspecifikation 9 (26) PVS /11 V1.0 5 Generellt brottsmålsschema Figur 3 Generella sobjekt som innehåller potentiellt sökbara element.

53 Bilaga 4 Inleveransspecifikation 10 (26) PVS /11 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.

54 Bilaga 4 Inleveransspecifikation 11 (26) PVS /11 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

55 Bilaga 4 Inleveransspecifikation 12 (26) PVS /11 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

56 Bilaga 4 Inleveransspecifikation 13 (26) PVS /11 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

57 Bilaga 4 Inleveransspecifikation 14 (26) PVS /11 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 verksamhetssystem 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

58 Bilaga 4 Inleveransspecifikation 15 (26) PVS /11 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

59 Bilaga 4 Inleveransspecifikation 16 (26) PVS /11 V1.0 kompluppgifter E 0..1 S 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.

60 Bilaga 4 Inleveransspecifikation 17 (26) PVS /11 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 forhorsvittne E 0..1 S Efternamn, fornamn.

61 Bilaga 4 Inleveransspecifikation 18 (26) PVS /11 V1.0 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 benamning E 1 S? S

62 Bilaga 4 Inleveransspecifikation 19 (26) PVS /11 V1.0 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 Kallelse Namn E/A Kard S T Beskrivning

63 Bilaga 4 Inleveransspecifikation 20 (26) PVS /11 V1.0 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 Historik Kopplat till Tvångsmedel.

64 Bilaga 4 Inleveransspecifikation 21 (26) PVS /11 V1.0 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 Rapport Rapporter: ärendehistorik, brottsrapport, offentliga dagboksuppgifter, involverade personer och engagerad personal. Det blir en rapport av varje per ärende (5 stycken).

65 Bilaga 4 Inleveransspecifikation 22 (26) PVS /11 V1.0 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å. forfattare E 1 S Efternamn, fornamn rubrik E 0..1 S anteckning E 0..1 S

66 Bilaga 4 Inleveransspecifikation 23 (26) PVS /11 V1.0 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 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.

67 Bilaga 4 Inleveransspecifikation 24 (26) PVS /11 V1.0 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 AnhörigKontaktperson Namn E/A Kard S T Beskrivning efternamn E 0..1 S mellannamn E 0..1 S

68 Bilaga 4 Inleveransspecifikation 25 (26) PVS /11 V1.0 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 Redovisning Namn E/A Kard S T Beskrivning fuprot E 0..1 S

69 Bilaga 4 Inleveransspecifikation 26 (26) PVS /11 V1.0 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.

70 Bilaga 5, IT-miljö inom RPS 1(5) Bilaga 5 IT-miljö inom RPS

71 Bilaga 5, IT-miljö inom RPS 2(5) Innehåll INNEHÅLL 2 1. SYFTE MED DETTA DOKUMENT 4 2. OPERATIVSYSTEM Strategisk plattform 4 3. VIRTUALLISERINGSPRODUKTER Strategisk plattform 4 4. DATABASHANTERARE 4 5. HÅRDVARUPLATTFORMAR 4 6. APPLIKATIONS- OCH WEBBPLATTFORMAR 4 7. INTEGRATIONSPLATTFORMAR 5 8. BACKUP ÖVERVAKNING 5

72 Bilaga 5, IT-miljö inom RPS 3(5) Datum Ändring Handläggare Ann Rosenlind

73 Bilaga 5, IT-miljö inom RPS 4(5) 1. 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 Strategisk plattform Server SuSE Linux Enterprise Server 10 SP3 (inkl. OES) Windows 2008R2 Klient Windows 7 3. Virtualliseringsprodukter 3.1 Strategisk plattform VMware 4. Databashanterare 4.1 Strategisk plattform MySQL Oracle MS SQL Server 5. Hårdvaruplattformar 5.1 Strategisk plattform x86 Intel/AMD x64 Intel/AMD 6. Applikations- och webbplattformar 6.1 Strategisk plattform

74 Bilaga 5, IT-miljö inom RPS 5(5) Jboss Apache Tomcat Internet Information Server EpiServer 7. Integrationsplattformar 7.1 Strategisk plattform SHS IBM Websphere Message Broker 8. Backup 8.1 Strategisk plattform Symantec Netbackup 11. Övervakning 11.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

75 Bilaga 6, Kvalitetsdokument 1 (11) Bilaga 6 Kvalitetsarbete, acceptanstest och ändringshantering

76 Bilaga 6, Kvalitetsdokument 2 (11) 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

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

78 Bilaga 6, Kvalitetsdokument 4 (11) 1 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.

79 Bilaga 6, Kvalitetsdokument 5 (11) 2.2 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.

80 Bilaga 6, Kvalitetsdokument 6 (11) 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, innehållande en hel release eller del 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. Särskilda tester ska kunna uppvisas på releasens tillkommande eller förändrade funktionalitet. Innefattar 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 beskrivas vad releasen omfattar och vad som är förändrat.

81 Bilaga 6, Kvalitetsdokument 7 (11) 4 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å.

82 Bilaga 6, Kvalitetsdokument 8 (11) 7 Acceptansprocedur 7.1 Acceptansprocedur För varje hel eller delar av release som levereras ska den 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:

83 Bilaga 6, Kvalitetsdokument 9 (11) 1. 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.

84 Bilaga 6, Kvalitetsdokument 10 (11) Ä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.

85 Bilaga 6, Kvalitetsdokument 11 (11) 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 i projektläge 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.

86 Rikspolisstyrelsen 1(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS /11 Bilaga 7 Arkitekturbeskrivning E-arkivet

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

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

89 Rikspolisstyrelsen 4(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS /11 Inledning Inom Polisen finns anställda som dagligen använder sig av ett eller flera systemstöd för att utföra sina arbetsuppgifter. Trots att det mesta av verksamhetens information inkommer eller upprättas digitalt är det lite som hanteras digitalt under hela informationens livscykel. Arkivering sker istället nästan uteslutande på papper. De pappersbaserade arkiven innehåller till största delen brottmålsärenden, men även en stor mängd allmänna ärenden. Totalt skapas ca 1,8 miljoner nya pappersakter per år. Innan ett ärende skrivs ut på papper hanteras dessa i ett flertal olika IT-system. Hittills har ett tjugotal IT-system identifierats som innehåller information som ska bevaras i e-arkivet. Det rör sig om information från bl.a. ärendehanteringssystem, register, dokumenthanteringssystem och webbplatser. Arkiverade förundersökningar på papper, cd- och dvd-skivor tar stor plats. I en beräkning som gjordes 2006 skrev polismyndigheterna årligen ut 3 kilometer tätpackade handlingar. E-arkivet ska ge Polisen möjlighet att bevara information i digital form. Syftet med det nya systemet är att nå en enhetlig och effektiv arkivhantering. Samtidigt ska systemet passa in i Polisens nuvarande infrastruktur, och vara väl anpassat för Polisens kommande tjänstebaserade arkitektur baserad på öppna standarder. 1.1 Syfte Syftet med dokument är att beskriva RPS e-arkivs arkitektur och dess samverkan med andra befintliga system. 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å detta system 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 och begränsningar 2.1 Mål Målet med att ställa krav på e-arkivets utformning är att få systemet att passa in i RPS övergripande arkitektur och underlätta integration med andra system och processer. Vissa s.k. bastjänster finns redan idag i RPS tjänsteutbud, medan andra kommer införas i framtiden. Målet är att e-arkivet är en av dessa tjänster som på sikt kan anropas i flera andra verksamhetsprocesser utöver e-arkivets egen klient. Systemet är flexibelt avseende driftsmiljöns konfiguration och bakomliggande teknik.

90 Rikspolisstyrelsen 5(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS /11 Viktiga mål för arkitekturen är att systemet 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 systemet 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 lösningen 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. Viktiga mål för juridiskt korrekt informationshantering: 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 innefattar en statisk struktur som visar hur olika fundamentala delsystem hänger ihop. 3.1 Översikt För att få systemet att passa in i RPS arkitektur är det viktigt att identifiera vilka delar av systemet som använder sig av generell funktionalitet, dvs. sådana funktioner som återkommer och är likartad i flera andra av RPS system.

91 Rikspolisstyrelsen 6(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS /11 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 system. 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. Fig. 2. Bilden visar en översikt över e-arkivets inre logiska lager med koppling till Databaslagret, utanför e-arkivet.

92 Rikspolisstyrelsen 7(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS / 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 är det system som 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 system 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 system 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. 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. Det finns även exempel på system som skulle kunna dra nytta av att dela datalager med e-arkivet Mediatjänsten hos Polisen är 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 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ögre 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.

93 Rikspolisstyrelsen 8(7) Projekt Dokumentnamn Diarienummer Bilaga 7 Arkitekturbeskrivning PVS /11 Mediatjänsten kommer att lagrar stora filer och stora informationsmängder vilket ställer höga krav både på prestanda och på lagringsvolymer. För att kunna hantera arkivering av information från mediatjänsten är det möjligt att genomföra en inleverans till e-arkivet där endast systemägarskapet av en fil övertas av e- arkivet. Troligtvis kommer endast en pekare till filen flyttas till e-arkivet vid arkivering och att vid försök av åtkomst till filen från mediatjänsten hänvisas man till e-arkivet. Detta för att minimera flytt av filer över nätverket och mellan lagringssystem. För att underlätta detta så är det en fördel om e-arkivet och mediatjänsten bygger på liknande lagringslösning.

94 Bilaga 8 Användningsfall 1 (26) Bilaga 8 Användningsfall

95 Bilaga 8 Användningsfall 2 (26) 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...12 AF05 Administrera gallringsregler...13 AF06 Administrera konverteringsregler...14 AF07 Validera AIP...15 AF08 Gallra AIP...15 AF09 Konvertera AIP...16 AF10a Förändra AIP...17 AF10b Skriva notering till AIP...17 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...21 AF14 b Redovisa arkivobjekt Process: Söka AIP AF15 Söka AIP Process: Tillhandahålla DIP AF16 Administrera förfrågan på DIP...24 AF17 Tillhandahålla DIP...25 AF 18 Tillhandahålla tillfällig behörighet...25

96 Bilaga 8 Användningsfall 3 (26) Datum Ändring Handläggare Ann Rosenlind

97 Bilaga 8 Användningsfall 4 (26) 1 Användningsfallsöversikt Detta dokument beskriver de användningsfall som identifierats för Polisens e-arkiv under projektets initieringsfas. Syftet med denna sammanställning är att utgöra komplement till kravbilden och ge en översiktlig bild av e-arkivets funktioner. E-arkivets arkitektur beskrivs 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

98 Bilaga 8 Användningsfall 5 (26) 1.1 Begrepp I detta dokument används bl.a. begrepp från OAIS-modellen (ISO :2003) samtliga begrepp är 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. - Anslutande verksamhetssystem.

99 Bilaga 8 Användningsfall 6 (26) - Arkivarier vid de lokala arkivfunktionerna. - Arkivarier vid arkivadministrationen 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 system E-arkivet E-arkivet är den aktör som exekverar 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.

100 Bilaga 8 Användningsfall 7 (26) 1.3 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 ta fram SIP 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 system 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.

101 Bilaga 8 Användningsfall 8 (26) 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 på SIP 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 vilka regler som ska gälla för mottag av SIP samt vidare hantering av AIP. 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. SIP kan valideras utifrån inleveransspecifikationer i olika nivåer. Efter validering lagras SIP som AIP.

102 Bilaga 8 Användningsfall 9 (26) 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. Därefter regleras om SIP även ska valideras enligt inleveransspecifikation på övergripande nivå/-er. Nedanstående bild illustrerar hur struktur av noderna FE byggs upp till en arkivförteckning samt att varje FE kan hålla en inleveransspecifikation. Figur 3 Inleveransspecifikationer i flera nivåer. 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. Synkrona leveranser behöver endast administreras inför första leveransen. 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 samtliga inleveransspecifikationer, relevanta för leveransen, är inregistrerade.

103 Bilaga 8 Användningsfall 10 (26) 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 - E-arkivet visar en lista över befintliga FE. - 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 om leveranser ska valideras mot specifikationer knutna till ovanliggande FE i arkivförteckningen. - E-arkivet visar vilka valideringar som finns tillgängliga. - 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. - E-arkivet visar lista över möjliga konverteringsregler. - Aktör väljer konverteringsregel och knyter till FE. - E-arkivet visar lista på gallringsregler. - Aktör väljer gallringsregel och knyter till FE. - Aktör väljer att spara uppgifter. - E-arkivet validerar inmatade uppgifter. - 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).

104 Bilaga 8 Användningsfall 11 (26) 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 kontrollerar om nod (FE) utpekad i leveransen hänvisar till inleveransspecifikation knuten till nod (FE) högre upp i arkivförteckningen. - E-arkivet validerar SIP mot inleveransspecifikation knuten till FE högre upp i arkivförteckningen. - 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.

105 Bilaga 8 Användningsfall 12 (26) 1.6 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 samt att nya valideringsregler av enklare art (ex. kunna läsa av nya fält) kan läggas till. 1 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 - E-arkivet visar en lista på valbara FE. - Aktör väljer FE ur listan. - E-arkivet visar en lista på valbara valideringsregler. - Aktör väljer valideringsregel. 1 Användningsfall för hur nya valideringsmöjligheter läggs till har inte tagits fram. Hur detta kan göras uppmanas leverantören att beskriv i förfrågningsunderlaget.

106 Bilaga 8 Användningsfall 13 (26) - Aktör sätter villkor, i detta fall tidsintervall, för valideringsregeln. - Aktör knyter valideringsregeln till vald FE. - Aktör väljer om valideringsregeln 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. 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 - E-arkivet visar lista på FE. - Aktör väljer FE som regeln ska knytas till. - E-arkivet visar en lista över befintliga gallringsregler. - 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.

107 Bilaga 8 Användningsfall 14 (26) - E-arkivet sparar uppgifterna och knyter gallringsregeln till FE. Användningsfallet avslutas då e-arkivet har uppdaterat FE med gallringsregeln. 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 - E-arkivet visar en lista över vilka FE som finns. - Aktör väljer till vilken/vilka FE som regeln ska knytas. - E-arkivet visar en lista över befintliga konverteringsmöjligheter. - 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 vilken 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.

108 Bilaga 8 Användningsfall 15 (26) 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. - 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.

109 Bilaga 8 Användningsfall 16 (26) - 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. 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.

110 Bilaga 8 Användningsfall 17 (26) AF10a Förändra AIP Användningsfallet beskriver hur en aktör förändrar AIP. Som vårdande insatser kommer AIP att behöva ändras, antingen genom att metadata uppdateras eller att del av AIP förändras. En förändring kan antingen generera; - en ny version av AIP med en referens mellan de båda versionerna, dvs. genom en AIC, eller - att endast förändringen sparas, dvs. genom en AIU, med en AIC till den ursprungliga AIP. Då AIP förändras måste orsak till förändringen kunna skrivas in samt att följande loggas: - Vad som uppdaterats. - Tidpunkt. - Vem som gjort förändringen Användningsfallet startar när en aktör sökt fram aktuell AIP. Exempelförlopp - E-arkivet hämtar AIP. - Aktör uppdaterar metadata från sekretess till icke sekretess. - E-arkivet skapar AIU av uppdateringen. - E-arkivet skapar AIC mellan AIP och AIU. - E-arkivet loggar uppdatering. - 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 ligger som egna filer med referens 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

111 Bilaga 8 Användningsfall 18 (26) 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. - 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.

112 Bilaga 8 Användningsfall 19 (26) 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 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. 1.8 Process: Redovisa arkiv Denna process delas mellan arkivadministrationen och de lokala arkivfunktionerna. Arkivadministrationen ansvarar för att sätta regler för

113 Bilaga 8 Användningsfall 20 (26) 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 definiera 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 kan delas mellan en logisk redovisning och en fysisk redovisning vilka båda byggs som trädstrukturer av noder. Den logiska redovisningen utgörs av klassificeringsstruktur som byggs upp av strukturenheterna verksamhetsområden, processgrupper och processer. 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. Nedanstående bild förklarar förhållandet mellan arkivredovisning, klassificeringsstruktur samt arkivförteckning. Figur 4 Förenklad bild av arkivredovisningens delar 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.

114 Bilaga 8 Användningsfall 21 (26) 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. - E-arkivet visar lista för vilka nodtyper som finns. - Aktör kan antingen välja att skapa en ny nodtyp eller uppdatera en redan befintlig. - Aktör väljer att upprätta 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 KS. Exempelförlopp - E-arkivet visar vilka nodtyper som kan väljas. - 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ändelser. - E-arkivet validerar och sparar uppgifterna.

115 Bilaga 8 Användningsfall 22 (26) Användningsfallet avslutas när e-arkivet har sparat uppgifterna och uppdaterat listan över myndighetens KS. 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) Ö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

116 Bilaga 8 Användningsfall 23 (26) 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 Arkivförteckningens struktur AF15 Söka AIP Användningsfallet beskriver hur en aktör söker ett eller flera AIP/-er. 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. brottsmål, ekonomi). - Aktör väljer FE, Brottsmål. - E-arkivet visar gränssnitt (innehållande lista över underliggande FE samt sökmöjligheter) för FE, Brottsmål. - Aktör väljer underliggande FE i strukturen, Förundersökningar

117 Bilaga 8 Användningsfall 24 (26) - E-arkivet visar sökgränssnitt, vilken innehåller sökattribut för både övergripande FE samt vald FE. - Aktör skriver in sökparametrar. - E-arkivet utför en sökning. - E-arkivet loggar sökningen. - E-arkivet presenterar resultatet av sökningen i en träfflista. Användningsfallet slutar när sökresultatet levereras till aktören i form av en träfflista Process: Tillhandahålla DIP Att tillhandahålla DIP sker via e-arkivets accessfunktion. Processen startar när en konsument väljer att hämta en DIP (bestående av en eller flera AIP:er) från en träfflista. DIP kan antingen tillhandahållas genom att den: - skickas synkront till ett anslutande verksamhetssystem, - skickas via mail till konsumenten, - presenteras på skärm, eller - lämnas ut genom att en tillfällig behörighet läggs till utpekat arkivobjekt. Huvudspåret för processen är att DIP lämnas ut i digital form men utlämnande i pappersform kan också göras. Processen slutar när DIP har lämnats ut. I de fall en konsument har behörighet till en FE kan konsumenten själv välja att hämta/beställa DIP via sökresultatets träfflista. Saknas behörighet måste konsumenten göra en förfrågan om att få ta del av DIP. Detta kan göras via Intrapolis. Varje logisk instans av e-arkivet (lokal arkivfunktion) har sin egen inkorg för DIP-förfrågningar. AF16 Administrera förfrågan på DIP Användningsfallet beskriver hur en aktör tar emot och besvarar en förfrågan om att lämna ut DIP från e-arkivet. Användningsfallet startar när förfrågan inkommit till e-arkivets inkorg. Exempelförlopp - Aktör öppnar e-arkivets inkorg. - E-arkivet visar lista över inkomna förfrågningar.

118 Bilaga 8 Användningsfall 25 (26) - Aktör markerar och öppnar en förfrågan. - Aktör gör en sökning i e-arkivet utifrån förfrågan. - E-arkivet presenterar resultat av sökning. - Aktör väljer DIP (kan vara arkivobjekt och/eller träfflista). - Aktör bifogar DIP och skickar svar till konsumenten. - E-arkivet loggar sökningen - E-arkivet sparar förfrågan med tillhörande svar. I de fall efterfrågade AIP inte finns i e-arkivet skickas meddelanden till konsumenten. Även denna förfrågan med tillhörande svar sparas i e-arkivet. Användningsfallet avslutas när e-arkivet skickat svar till konsumenten. AF17 Tillhandahålla DIP Användningsfallet beskriver hur en aktör väljer att från e-arkivet hämta en eller flera kopior av en eller flera AIP. Användningsfallet startar när en aktör väljer från träfflista Exempelförlopp - Aktör väljer en eller flera AIP från träfflistan. - E-arkivet kopierar valda AIP. - E-arkivet paketerar DIP utifrån AIP. - E-arkivet presenterar DIP antingen på skärm eller som fil att bifoga mail, eller sparar ner till valfri filarea. - E-arkivet loggar utlämnandet av DIP. Användningsfallet avslutas när DIP är levererad antingen presenterad på skärm eller paketerad som fil. AF 18 Tillhandahålla tillfällig behörighet I de fall som omfattande arkivobjekt ska tillhandahållas, ex. en förundersökning som kan innehålla en ansenlig mängd data, kan handläggaren ges en tillfällig behörighet. En tillfällig behörighet ges för att undvika att stora mängder data återförs till verksamhetssystemet eller skrivs ut. Användningsfallet beskriver hur en aktör ger en tillfällig behörighet till ett arkivobjekt. Detta användningsfall föregås av AF16.

119 Bilaga 8 Användningsfall 26 (26) Användningsfallet startar när en aktör väljer att ge en tillfällig behörighet. Exempelförlopp: - Aktör söker fram aktuellt arkivobjekt - Aktör tilldelar utpekad handläggare en behörighet till arkivobjektet - Aktör tidsbegränsar behörigheten - Aktör dokumenterar skäl till behörigheten - E-arkivet uppdateras med behörigheten - E-arkivet loggar händelsen Användningsfallet avslutas då e-arkivet har uppdaterats med behörigheten.

120 Datum Ändring Handläggare Ann Rosenlind

121 Bilaga 10 Övergripande verksamhetsbeskrivning 1 (16) Bilaga 10 Övergripande verksamhetsbeskrivning

122 Bilaga 10 Övergripande verksamhetsbeskrivning 2 (16) INNEHÅLL 1 DOKUMENTETS SYFTE VERKSAMHETENS NULÄGE Arkivbildningsprocessen Problem med dagens arkivhantering ANVÄNDARE AV E-ARKIVET BEGREPPSMODELL OCH INFORMATIONSMODELL Informationsmodell för lagringsstrukturen Arkivobjektet Metadatauppsättning E-ARKIVET Börläge vid ny organisation Arkivbildningsprocessen - börläge INFORMATION SOM IT-STÖDET SKA HANTERA VOLYMER I E-ARKIVET... 15

123 Bilaga 10 Övergripande verksamhetsbeskrivning 3 (16) shistorik Datum Ändring Handläggare Ann Rosenlind 1 Dokumentets syfte Detta dokument innehåller en övergripande verksamhetsbeskrivning för. Verksamhetsbeskrivningen ska beskriva verksamhetens flöden och dess gränssnitt mot övriga delar av organisationen och system. 2 Verksamhetens nuläge Inom Polisen finns anställda som dagligen använder sig av ett eller flera systemstöd för att utföra sina arbetsuppgifter. Trots att det mesta av verksamhetens information inkommer eller upprättas digitalt är det lite som hanteras digitalt under hela informationens livscykel. Arkivering sker istället nästan uteslutande på papper. De pappersbaserade arkiven innehåller till största delen brottmålsärenden, men även en stor mängd allmänna ärenden. Totalt skapas ca 1,8 miljoner nya pappersakter per år. Det finns dock delar i polisens verksamhet som idag hanteras digitalt under hela informationens livscykel och det är bl.a. digitala stillbilder som lagras i Bildtjänsten. I tjänsten lagras bilder från brottsutredningar, fartkameror samt passbilder. Det finns också en stor mängd bilder som inte hanteras i Bildtjänsten. Rörliga bilder, digitalt ljud och s.k. speglade hårdiskar hanteras inte heller i Bildtjänsten. Det finns således en stor mängd digital information som inte hanteras i något systemstöd. I en utredning från Polismyndigheten i Stockholm från 2008/ 2009 visar inventeringen att det då fanns runt cd och dvd-skivor och 152 hårdiskar arkiverade runt om på de olika polismästardistrikten i Stockholm. Hur mycket som sparas på Polisens nätverk finns det inga uppgifter om, vilket innebär ett stort mörkertal. Arkiverade förundersökningar på papper, cd- och dvd-skivor tar stor plats. I en beräkning som gjordes 2006 skrev polismyndigheterna årligen ut 3 kilo-

124 Bilaga 10 Övergripande verksamhetsbeskrivning 4 (16) meter tätpackade handlingar. Arkivhandlingar förvaras ofta i arkivlokaler som är spridda geografiskt över myndigheten. Arkiven används frekvent, men oftast är det yngre information som efterfrågas. Förfrågningar på ärenden som förundersökningar och annat som är äldre än fem år är inte så vanligt. Detta kommer troligtvis att ändras, eftersom det från den 1 juli 2010 inte sker någon preskription av de grövsta brotten om de begåtts 1 juli 1985 eller senare och om gärningsmannen fyllt 21 år vid brottets begående. Ny teknik och metoder t.ex. DNA, gör det också möjligt att återuppta och på nytt utreda gamla ärenden. 2.1 Arkivbildningsprocessen Idag skiljer sig arkivbildningsprocessen åt beroende på vilket verksamhetssystem som hanterar informationen. Nedan beskrivs förenklat - den mest centrala ärendeprocessen, utredning av ett anmält brott. Polisen hanterar dock stora mängder information i andra processer, t.ex. tillståndsärenden, passansökningar, vapenärenden, administrativa ärenden (t.ex. personal och ekonomi) samt olika sorters informationsmaterial (t.ex. Polisens intranät och webbsidor). Ärendet initieras när en anmälan om ett brott upprättas i IT-systemet K- RAR. Anmälan kan initieras antingen genom att en person ringer, skriver eller besöker en polisstation, eller från en polis som skriver in anmälan direkt i K-RAR. I K-RAR finns endast registeruppgifter. Efter att anmälan skrivits in, granskas den av en särskilt utsedd granskare, som godkänner anmälan och skickar den vidare för utredning. Om en förundersökning ska inledas, kan ärendet skickas elektroniskt från RAR till polismyndighetens ärendehanteringssystem DurTvå. I DurTvå läggs skannade dokument, förhör, beslut, PM osv. DurTvå är det huvudsakliga utredningssystemet, men det finns många andra system som används i utredningen. När ärendet avslutas består det av en hybridakt utskrifter, pappershandlingar som inte skannats in, bilder i BIP, ljud- och videofiler på externa lagringsmedia. Ingen gallring sker i RAR eller DurTvå, all information som skrivits ut till akten finns också kvar digitalt. Efter slutredovisning skickas akten till ett närarkiv, där den ligger kvar i 2-3 år innan den skickas till centralarkivet. 2.2 Problem med dagens arkivhantering I dagens arkivhantering har följande problem identifierats:

125 Bilaga 10 Övergripande verksamhetsbeskrivning 5 (16) Det är svårt att ha kontroll över var den pappersbaserade informationen finns eller vem som har tillgång till den. Polisens nya utredningssystem kommer att ha en helt digital hantering. Att skriva ut ärenden på papper för arkivering skulle innebära att en av visionerna - en helt digital kedja inte kommer att uppfyllas. Dagens manuella pappershantering är mycket tidskrävande och innebär höga kostnader för bl.a. utskrift, sortering, arkivläggning, etikettering, samt gallring eller leveranser till arkivmyndighet av stora mängder pappershandlingar. Återsökning är personberoende, geografiskt kopplad och tidskrävande. Verksamhetssystem tyngs av gammal information. Det är ineffektivt och kostsamt att låta gamla system fortsätta vara i drift för att det saknas möjligheter att avställa informationen till en arkivlösning. Utan en digital arkivtjänst kommer Polisen inte att leva upp till kraven i den nya polisdatalagen och polisdataförordningen. De kräver att information avskiljs vid bestämda tidpunkter från den brottsbekämpande verksamheten och istället förs till ett digitalt arkiv. Lagen trädde i kraft 1 mars 2012, men övergångsbestämmelserna innebär att information måste överföras till e-arkivet först vid årsskiftet 2014/ Användare av e-arkivet Arkivadministrationen kommer bl.a. att hantera leveranser till e-arkivet (i samarbete med förvaltningarna för de levererande systemen), sätta upp regler för arkivredovisning samt vårda och framtidssäkra arkiverad information. Lokala arkivfunktioner kommer att sköta arkivredovisning, sökning i e- arkivet och utlämnande av information i e-arkivet till allmänheten men också till medarbetare inom Polisen. Arkivadministrationen och de lokala arkivfunktionerna kommer att ha en roll i e-arkivet som innebär att de har omfattande rättigheter vad det gäller tillgång till arkiverad information som omfattas av den nya polisdatalagen. Konsumenter (poliser och civilanställda) inom Polisen kommer att söka och ta fram ärenden och handlingar från e-arkivet, antingen via ett verksamhetssystem eller direkt i e-arkivet.

126 Bilaga 10 Övergripande verksamhetsbeskrivning 6 (16) Drifts- och förvaltningsfunktion kommer att sköta driften av e-arkivet och kommer bland annat att hantera säkerhetskopiering, behörighetstilldelning och felsökningar. Producenter är (i de flesta fall) verksamhetssystem som levererar sin information till e-arkivet. 4 Begreppsmodell och informationsmodell Den information som lagras i e-arkivet ska redovisas enligt Riksarkivets föreskrift RA-FS 2008:4. Projektet ProcArk som bedrivs på Rikspolisstyrelsen arbetar med att ta fram en ny redovisningsmodell för polismyndigheternas information. 4.1 Informationsmodell för lagringsstrukturen Nedan beskrivs hur arkivobjekten kan ordnas och kategoriseras i e-arkivet. Arkivobjekt är den enhet av information som lagras i e-arkivet t.ex. ett ärende med handlingar eller en fil. Det är den minsta enhet som behöver beskrivas för att kunna möta kraven på återsökning, informationsförvaltning (vårdinsatser) och utlämnande. Referensmodellen OAIS beskriver att varje leverans ska specificeras med uppgifter om sammanhang, ursprung, integritet och identitet. E-arkivets lösning innebär att tillföra så mycket av sammanhanget och ursprunget som möjligt i en på förhand upprättad lagringsstruktur bestående av förvaringsenheter (noder) och låta arkivobjekten bära information som gör det möjligt att identifiera och kategorisera dem som arkivobjekt. Lagringsstrukturen ska vara hierarkiskt skalbar. Det går inte att på förhand att veta vilka nivåer som kommer att behövas för att sätta varje polismyndighets information i en lämplig lagringsstruktur eftersom denna slås fast först vid leveranstillfället. Under förvaringsenheterna lagras antingen en förvaringsenhet eller en eller flera arkivobjekt. Bilden nedan visar förvaringsenhet och arkivobjekt med de metadata som är relevanta för förvaringsenheterna:

127 Bilaga 10 Övergripande verksamhetsbeskrivning 7 (16) Förvaringsenhet -Namn -Beteckning* -Gallringsbart -Myndighet* -Arkiv -Placering -Handlingsslag -Handlingstyp -Startdatum -Slutdatum -Informationsskyddsklass 0..* 1 Arkivobjekt Figur 1 Förvaringsenhet och arkivobjekt Förvaringsenheten ska kunna bestå av en hierarkisk struktur som i förekommande fall detaljerar omfånget på de lagrade arkivobjekten. 4.2 Arkivobjektet Uppskattningsvis 90 % av de arkivobjekt som kommer att lagras i e-arkivet kommer att vara ärenden och sökningar kommer i huvudsak att ske på ärendenivå. Med utgångspunkt i vad som identifierats om ärenden inom Polisen behöver arkivobjekten bestå av ett godtyckligt antal metadata och ett godtyckligt antal handlingar och filer, även de märkta med metadata. Godtyckligt i detta hänseende betyder att det inte är känt nu utan behöver definieras för varje levererande verksamhetssystem. Nedbrytning av ett arkivobjekt ger följande struktur:

128 Bilaga 10 Övergripande verksamhetsbeskrivning 8 (16) HuvudObjekt -Kan tillhöra * -Tillhör -Har 0..* -Kan ha UnderObjekt -Tillhör -Har Fil 1 0..* Figur 2 Huvudobjekt - Underobjekt Det viktigaste är att inte fastna i en fast struktur som tvingar till att behandla all information som lagras på samma sätt, utan som ger möjlighet att konfigurera och anpassa inför varje leverans. Ett Arkivobjekt består av följande informationsobjekt: HuvudObjekt och UnderObjekt. Varje informationsobjekt är av en typ, som via metadata definierar egenskaper som gäller för den typen. HuvudObjekt HuvudObjektet håller informationen om det överordnade objektet. Om HuvudObjektet är ett ärende hålls de grundläggande ärendebegreppen på det objektet. Om det t.ex. är en faktura, hålls grundläggande begrepp om fakturan på det objektet, om det är ett avtal hålls grundläggande avtalsinformation. UnderObjekt UnderObjekt är informationsobjekt som underordnar sig HuvudObjektet, dvs. det finns en rangordning. Ett tydligt exempel är förhållandet mellan HuvudObjektet Ärende och dess UnderObjekt Handling. UnderObjekt är inte obligatoriskt. I de fall det saknas ett naturligt UnderObjekt, t.ex. om informationsobjektet är en faktura, ska det utgöra HuvudObjektet. Fil filen som eventuellt arkiveras med arkivobjektet. Hur den struktur av relationer mellan arkivobjektets informationsobjekt och filer ska se ut vid inleverans beskrivs i en inleveransspecifikation. Exempel på arkivobjektstyper Information knutet till ett ärende lagras i dag i flera verksamhetssystem som vid leverans, på något sätt, måste kunna sammanföras. Respektive system kan leverera sin del av ärendet och i arkivtjänsten kopplas delarna ihop baserat på en nyckel. Ärendenummer är den gemensamma nämnaren.

129 Bilaga 10 Övergripande verksamhetsbeskrivning 9 (16) Anmälningsärende -Ärendenummer -Brottskod -Anmälningsdatum -Brottsplats -Anmälare -Personnummer Utredningsärende -Ärendenummer -Brottskod -Anmälningsdatum -Brottsplats -Bilagor Bildinformation -Ärendenummer -Bildnamn -Format -Skapatdatum Förundersökningsprotokoll -Protokollsnummer Brottsplats.jpg Protokoll.doc Förhörsprotokoll -Protokollsnummer Figur 3. Sammanhållet ärende Anmälningsärendet är ett huvudobjekt och har inga underordnade handlingar eller filer utan innehåller registeruppgifter från i detta fall K-RAR. Utredningsärendet är ett huvudobjekt som innehåller både ärendeinformation från DurTvå och har handlingar (underobjekt) med filer. Bildinformationen som också är ett huvudobjekt, kommer från BIP och består av en eller flera bilder. Ärendenummer återfinns på alla HuvudObjekt ovan och utgör den nyckel som håller ihop ärendet. 4.3 Metadatauppsättning OAIS-modellen är den referensmodell som använts för att specificera arkivet och dess egenskaper. Metadatauppsättningen bestäms utifrån de fyra punkter som nämndes i början av avsnittet om informationsmodellen: sammanhang, ursprung, integritet och identitet. Sammanhang och ursprung anges i första hand på förvaringsenheterna. Ursprung i form av t.ex. systemnamn kan, om det bedöms intressant, anges på arkivobjekten. Metadata på arkivobjekten är till stor del kopplat till den specifika leveransöverenskommelsen. En typ av information har andra förutsättningar än en annan typ. Uppsättningen styrs dock av möjligheten att bedöma och validera dataintegritet, verksamhetens sök- och sammanställningsbehov och behovet av att kunna förvalta informationen.

130 Bilaga 10 Övergripande verksamhetsbeskrivning 10 (16) 5 E-arkivet 2015 Polisen ett gemensamt e-arkiv på plats senast den 1 januari 2015 och som används av samtliga myndigheter inom Polisen. E-arkivet är leverantörs- och plattformsoberoende. Information som lagras i e-arkivet blir fristående från verksamhetssystemen, men har bibehållen läsbarhet och sökbarhet. E-arkivet innebär en säker hantering av information, loggning ger kontroll över vem som gör vad med informationen, säkerhetskopiering gör att information kan återskapas vid behov, ärenden och handlingar kan inte försvinna och bättre återsökningsmöjligheter bidrar till ökad rättssäkerhet. Möjligheterna att säkerställa läsbarhet på lång sikt ökar. Den säkra hanteringen gör att medarbetarna inom Polisen känner tilltro till e-arkivet. E-arkivet innebär en effektivisering på många områden och är det enda systemet för långsiktigt bevarande inom Polisen. Dubbellagringen är nästan eliminerad och pappersarkivering och arkivering på separata lagringsmedier har minskat drastiskt. Samtliga verksamhetssystem som innehåller information som ska bevaras eller som har längre gallringsfrister levererar sin information till e-arkivet. Figur 4. E-arkivet samt användningsfall. E-arkivet används i första hand av arkivarier vid Polisen. De ser till att information levereras, sköter arkivredovisningen, förvaltar informationen

131 Bilaga 10 Övergripande verksamhetsbeskrivning 11 (16) samt söker och lämnar ut information. Därmed uppnår Polisen en enhetlig arkivhantering vad gäller bl.a. arkivredovisning och gallring. E-arkivet regleras i en egen föreskrift som innehåller regler för hur leveranser ska gå till och vilka roller och ansvarsområden som finns. Utöver föreskriften finns fastställda rutinbeskrivningar som i detalj specificerar hur leveranser från verksamhetssystem till e-arkivet ska genomföras. En annan effektivisering är att e-arkivet underlättar för verksamhetssystemens förvaltning. Dels behöver verksamhetssystemen inte tyngas av gammal information, eftersom information som förts över från verksamhetssystem till e-arkivet tas bort från verksamhetssystemet. Dels kan nya system som utvecklas redan från början skapa rutiner för överföring. I samband med att gamla system tas bort och ersätts med nya kan man också välja att överföra information till e-arkivet för att slippa kostnader för migrering. E-arkivet tar i första hand emot information som ska bevaras och på sikt levereras till arkivmyndigheten (Riksarkivet). Men även information med långa gallringsfrister, t.ex. 10 år eller mer, kan levereras till e-arkivet. Därför är det viktigt att gallring kan ske på ett effektivt sätt även från e-arkivet. Införandet av e-arkivet innebär att Polisens arkiverade information hanteras juridiskt korrekt. Polisdatalagens krav på att information ska avskiljas från den brottsbekämpande verksamheten efterlevs tack vare regelbundna avställningar av information till arkivtjänsten. 5.1 Börläge vid ny organisation Eventuellt kommer Polisen inom några år att frångå systemet med en central förvaltningsmyndighet (RPS) och 21 lokala polismyndigheter. Då kommer de olika myndigheternas arkiv att avslutas, och ett eller flera nya arkiv kommer att skapas i e-arkivet för den nya myndigheten och dess olika avdelningar. Såsom arkivbildningsprocessen, lagringsstrukturen och arkivredovisningen är tänkt i e-arkivet, kommer en sådan övergång att gå smidigt. 5.2 Arkivbildningsprocessen - börläge För e-arkivet har processer identifierats och etablerats för att kunna: - Leverera SIP - Ta emot SIP - Vårda och framtidssäkra arkivobjekt - Förvalta och drifta e-arkivet - Redovisa arkivobjekt - Söka arkivobjekt

132 Bilaga 10 Övergripande verksamhetsbeskrivning 12 (16) - Tillhandahålla DIP Nedan beskrivs dessa processer översiktligt. En mer detaljerad beskrivning finns i Användningsfallen, bilaga 8. Leverera SIP I samarbete med förvaltningarna för levererande system kommer arkivadministrationen fram till hur en leverans ska gå till, vilket regleras i en leveransöverenskommelse. Överföring kan ske på olika sätt. För vissa typer av information gäller att den överförs kontinuerligt, t.ex. så snart ärendet avslutats. Vissa överföringar görs i form av stora batchkörningar t.ex. årliga uttag från ekonomisystem. För att underlätta för levererande system tillhandahåller e-arkivet en leveransapplikation för validering, konvertering och normalisering av SIP som ska till e-arkivet. Ta emot SIP När en SIP tas emot i e-arkivet har leveransapplikationen redan konverterat och validerat den, för att avlasta ingestfunktionen. En SIP lagras efter validering som en AIP i e-arkivet. AIP placeras i en i förväg bestämd (nod) förvaringsenhet och görs sökbar med hjälp av metadatauppsättningen för den aktuella förvaringsenheten och arkivobjektstypen. På förvaringsenheten sätts också regler för t.ex. gallring, konvertering och validering. Redovisa informationen Arkivtjänsten omfattar arkivredovisning i enlighet med Riksarkivets föreskrifter, RA-FS 2008:4. Varje polismyndighet har sina egna separata arkivredovisningar, eftersom varje myndighet har minst ett arkiv. Varje myndighet kan ha minst en klassificeringsstruktur med processbeskrivningar, samt arkivförteckning med beskrivning av handlingsslag och handlingstyper och förteckningar över förvaringsenheter: Figur 5. Arkivredovisning