Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy for digitale arkivpakker

Transkript

1 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 1 av 18 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy for digitale arkivpakker Innhold Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy for digitale arkivpakker Innledning Anskaffelsens innhold Anskaffelsens formål Bakgrunn for behov Ordliste Forskjellige typer arkivløsninger Forskjellige typer arkiver Hva er ADDML? Om arkivdata, informasjonspakker og OAIS modellen Overordnet funksjonalitet av verktøyet Sekvens av operasjoner i verktøyet Hvilke kategorier av tester skal verktøyet utføre Overordnede mål og forventinger Strategiske føringer Detaljert kravmodell Overordnede krav Lesing og skriving av data Testing og logging Brukergrensesnitt... 18

2 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 2 av Innledning 1.1. Anskaffelsens innhold Riksarkivet har til hensikt å utvikle et nytt uttrekks- og testverktøy som skal distribueres til alle forvaltningsorgan i Norge. Målgruppen er arkivskapere i den statlige delen av offentlig sektor, foruten Riksarkivet selv. Det ferdige produktet skal være et verktøy med intuitivt brukergrensesnitt som gir lav terskel for bruk. Verktøyet skal brukes som et test- og dokumentasjonssystem ved uttrekk. Private aktører skal også kunne ta verktøyet i bruk. Det er en målsetning å redusere ressursbruken på overføring av arkivmaterialet. I dag medfører en overføring av arkivmateriale høy ressursbruk hos arkivskaper og hos Riksarkivet. Det gjøres oppmerksom på at det finnes en versjon 4 av programmet Arkade, utviklet i Java. Deler av funksjonaliteten i Arkade 5 vil kunne finnes i Arkade 4. En kopi av programkode for Arkade 4 kan leveres på forespørsel Anskaffelsens formål Målet med verktøyutviklingen er å forenkle testprosessene og å øke kvaliteten på arkivmaterialet som overføres. Ved overføring så sjeldent som hvert 5. til 10. år inneholder deler av arkivmaterialet gamle feil som er både vanskelige og ressurskrevende å rette opp i og å dokumentere. Det er en målsetning å avdekke feil i arkiv i testprosessen hos arkivskaper, slik at de kan rettes opp før uttrekket overføres fra forvaltningen til Riksarkivet. Umiddelbar tilbakemelding på kvalitet er sentralt for å bedre datakvaliteten og redusere kostnadene. Dette vil også føre til at forvaltningsorganene retter opp i teknisk-genererte feil umiddelbart, fremfor at man ender opp med mer ressurskrevende opprydding i etterkant. Sentralt i anskaffelsen er funksjoner og brukervennlighet Bakgrunn for behov Beregninger som er gjort gir grunnlag for å estimere at det for perioden vil være cirka avleveringspliktige arkiver i 21 departementer og 334 underliggende etater. Kostnader forbundet med avlevering av disse vil kunne reduseres betydelig gjennom utviklingen av et verktøy til bruk for arkivskapere ved testing av digitalt skapt arkivmateriale. Erfaringer viser at forvaltningsorganenes egne kostnader per uttrekk kan være i størrelsesordenen eller mer. For Riksarkivet ligger kostnaden per uttrekk mellom og for å ta imot, teste, dokumentere og lagre hvert uttrekk i digitalt sikringsmagasin. Totalt koster altså hvert arkivuttrekk statlig sektor anslagsvis kroner. I statlig sektor er det for perioden anslått at det i de 355 enhetene er opparbeidet et etterslep på uttrekk som ikke er avlevert til depot (kilde: Norsk Samfunnsvitenskapelig Datatjeneste).

3 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 3 av Ordliste For å lette lesningen av denne utlysning legger vi her ved en liten ordliste over sentrale begreper: ADDML ADDML er det norske arkivverkets standard for tekniske metadata. Forkortelsen står for Archival Data Description Markup Language. ADDML beskriver samlinger av datafiler organisert som flate filer, også kalt en strukturbeskrivelse. ADDML kan også benyttes til en overordnet beskrivelse av et datasett som inneholder andre typer filer enn flate filer. ADDML skal benyttes i Norge ved innlevering av digitalt skapt arkivmateriale til Riksarkivet. En slik innlevering defineres som en innleveringspakker eller overføringspakke. Standarden er XMLbasert. I ADDML kan man legge inn prosesser som fungerer som instruksjoner for et verktøy som tester pakkenes "velformethet" og innhold. AIP Archival Information Package (AIP), versjonen som innlemmes for bevaring i arkivdepotet. CSV Character-separated values (CSV) er et filformat som brukes for å lagre tabellarisk data hvor nummer og tekst lagres i ren tekstform som kan leses i et tekstredigeringsverktøy. Linjene i tekstfilen representerer radene i en tabell, og skilletegnene i en linje deler det som er felter i en tabellrad. dataobjects Dataobjekter er en betegnelse som benyttes på alle typer filer som ikke er flate filer. DIAS DIAS (Digital arkivpakkestruktur) ble gjennomført som et formalisert samarbeidsprosjekt mellom Riksarkivaren og 4 kommunale aktører for å etablere et felles norsk rammeverk for digitale arkivdepoter. DIAS-prosjektets hovedmål var å spesifisere en struktur for arkivpakker som lar seg anvende for lagring i statlige og kommunale arkivdepoter, samt å utvikle hjelpemidler for praktisk bruk av denne bevaringsstrukturen. DIP Dissemination Information Package er en AIP (eller flere) som gjøres tilgjengelig i bruksversjon. Dokument Dokumentbegrepet har en felles definisjon på tvers av det norske lovverket, slik det er formulert i bl a arkivloven, forvaltningsloven og offentlighetsloven som "en logisk avgrenset informasjonsmengde som er lagret på et medium for fremtidig lesing, avspilling, visning eller overføring". Ved at definisjonen er medium uavhengig spiller det ingen rolle hvorvidt dokumentet finnes på papir eller i form av et digitalt format som pdf eller png. Ut fra arkivloven med forskrifter er det i Norge kun tillatt å deponere eller avlevere et begrenset antall dokumentformater (Riksarkivarens forskrift kap VIII, paragrafene 17-20).

4 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 4 av 18 EAC-CPF EAC-CPF star for Encoded Archival Context - Corporate bodies, Persons and Families. Den er en XML-standard til bruk for koding av informasjon om aktører rundt et arkiv, f eks en organisasjon eller en privatperson, inkludert deres forbindelse til en bestemt ressurs som f eks et manuskript, en samling av arkivalia eller spesifikke dokumenter. Hensikten med standarden er å gi kontekstuell informasjon om forholdene rundt dokumentdanning og bruk. Standarden kan benyttes opp mot EAD for en styrking av EADs muligheter i forhold til koding av kataloginformasjon. EAC-CPF er definert i en DTD ("Document Type Definition") såvel som i et XML schema. EAD EAD betyr Encoded Archival Description, og er den mest utbredte standarden for koding av arkivbeskrivelsen som benyttes i online nettverk hos bevaringsinstitusjoner. Kataloginformasjon er i denne forbindelse informasjon om bestemte samlinger. Denne type kataloger benyttes for å gi en detaljert beskrivelse av innhold og intellektuell organisering av samlinger med arkivmateriale. Ved hjelp av EAD kan kataloginformasjon standardiseres på tvers av bevaringsinstitusjoner og tilgjengeliggjøres til bestemte brukergrupper eller allmennheten som sådan. EAD er en datastruktur standard og ikke en standard for innholdsbeskrivelse. Den fungerer også som et kommunikasjonsformat basert på XML. Flat Files Flate filer er filer som er organisert enten med felter som starter i en gitt posisjon (tabellform) eller med felter atskilt av et spesifikt skilletegn (tegnseparert form). I tegnseparert form kan i tillegg tekstfelter være omgitt av et spesifikt angitt tegn (f.eks. ) for å kunne tillate spesialtegn i teksten. METS METS (Metadata Encoding and Transmission Standard) er en internasjonal standard i form av et XML schema som benyttes for koding og overføring av deskriptive, administrative og strukturelle metadata om objekter innenfor et digitalt depot, i Riksarkivets tilfelle innenfor en digital informasjonspakke METS er ikke i seg selv et vokabular, men den benyttes til å lenke til eksterne beskrivende metadata, eventuelt utføre en intern inkludering av dem. Et slikt vokabular identifiserer samtlige deler av den konstellasjonen en informasjonspakke utgjør. Den beskriver de ulike elementenes plassering, i tillegg til det strukturelle forholdet mellom dem. METS binder sammen deskriptive og administrative metadata med digitalt innhold. Det digitale innholdet kan bestå av for eksempel tekst, bilder og audiovisuelle filer. METS kan lenke det digitale innholdet til en kobling som igjen kan forsyne programvare som muliggjør tilgjengeliggjøring av det digitale innholdet. OAIS-standarden OAIS, Reference Model for an Open Archival Information System6 (ISO 14721: 2003) er en referansemodell for å innlemme, administrere og bruke bevart arkivmateriale i et depot. Den beskriver et depots funksjoner, prosesser og informasjonsflyt med fokus på integritetssikring, og definerer opplegg for vedlikehold innenfor et kontrollert miljø. OAISmodellen beskriver bevaringsobjekter med vekt både på deres konseptuelle og tekniske aspekter. Hvert bevaringsobjekt skal iht. OAIS lagres som en autonom og selvdokumenterende informasjonspakke, fast forbundet med alle tilhørende logiske og tekniske metadata. Slik skal bevaringsobjektet fortsatt kunne fremstilles, og slik skal det fortsatt være forståelig og autentisk som arkivmateriale. Et bevaringsobjektet i OAIS kan være et enkelt dokument eller et samlet datauttrekk fra en database. OAIS skiller mellom tre

5 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 5 av 18 typer av informasjonspakker, SIP (Submission Information Package innleveringspakke/overføringspakke) AIP (Archival Information Package arkivpakke) og DIP (Dissemination Information Package visningspakke) En OAIS-informasjonspakke har to grunnelementer: 1) informasjonsinnhold (Content Information) med datafiler og tekniske metadata (Representation Information), og 2) bevaringsbeskrivende metadata (Preservation Description Information) med underkategorier for logisk arkivbeskrivelse, kontekst, bevaringshistorikk i depot og integritetssikring. PREMIS PREMIS står for PREservation Metadata: Implementation Strategies. Det er et XML schema og en ordliste for bevaringsmetadata, med andre ord metadata som benyttes til å bevare digitalt skapt materiale i et digitalt depot eller et digitalt sikringsmagasin. PREMIS definerer en kjerne av semantiske enheter som et digitalt depot benytter for bevaringen av de digitale arkivpakkene, først og fremst innenfor områdene hendelser og rettigheter. Ved hjelp av PREMIS kan materialet bli både lest, avspilt og tilgjengeliggjort gjennom ulike typer programvare på standardisert vis. PREMIS forsyner det digitale depot med tilstrekkelig informasjon om innholdet, samtidig som den forsyner et system med tilstrekkelig informasjon om materialet for eksport til andre systemer. SIP Submission Information Package er objektet som depotet mottar som aksesjon. TAR/.tar Begrepet tar kommer fra Tape ARchive. Det arkivbaserte datasettet dannet av TAR inneholder diverse parametere som tidsstempel, eierskap, filaksess/tillatelser og directory organisering. Filstrukturen for lagring av denne informasjonen er senere blitt standardisert, og er etter hvert blitt et format som støttes av de fleste moderne filarkiveringssystemer. TAR pakker filer sekvensielt og uten komprimering. UUID Universally Unique IDentifier. En globalt unik identifikator som kan tildeles objekter. Identifikatoren er et 128-bits tall. Vanligvis vises det i lesbar form som 36 tegn (hvorav 32 er signifikante, 4 er bindestreker). UUID kan tildeles "tilfeldig", da det finnes mulige verdier, og dermed er sjansen forsvinnende liten for at samme kombinasjon skal opptre mer enn én gang. XML XML (Extensible Markup Language) er et universelt og utvidbart markeringsspråk. XML brukes til koding av dokumenter og som kommunikasjonsmiddel mellom ulike informasjonssystemer og dataformater. Filformatet.xml organiserer data i en hierarkisk struktur. Formatet er et vanlig tekstformat, leselig for mennesker, hvor merker, eller tagger, gir informasjon om hva innholdet er. XML fastsetter et metaspråk som andre språk kan defineres ut fra. De eksakte kravene til et konkret språk som bygger på XML fastsettes av en DTD, eller et XML-skjema (en "XSD-fil"). XSD XSD (XML Schema Definition) spesifiserer hvordan en kan gi en formalisert beskrivelse av elementene i et XML-dokument. En slik beskrivelse kan benyttes for å verifisere at ethvert informasjonselement i et dokument relateres til, eller er skapt i henhold til, elementbeskrivelsen der innholdet skal plasseres.

6 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 6 av Forskjellige typer arkivløsninger For ord og begreper henvises til avsnitt 1.4 og fotnoter.. En overordnet målsetting er å effektivisere testing av arkivmateriale samtidig som man beholder fleksibilitet i forhold til variasjoner i datainnhold. 2.1 Forskjellige typer arkiver Arkivdanning skjer i dag gjennom mange ulike løsninger. De kan kategoriseres slik: A. Generelle sakarkivsystem B. Fagsystem med arkivfunksjoner C. Fagsystem integrert med arkivsystem D. Fagsystem uten arkivfunksjoner Testverktøyet vil behandle de 4 kategorier noe forskjellig, ref. avsnitt 3. A. Generelle sakarkivsystem er arkivsystemer med varierende grad av dokumenthåndterings- og saksbehandlingsfunksjoner. De benyttes til journalføring av korrespondanse og andre journalføringspliktige dokumenter. Systemene er særlig knyttet til generell saksbehandling, gjerne med dokumentflyt, for høring og godkjenning. Dette er vanligvis Noark-4 12 eller Noark 5 3 komplett, løsninger som benyttes til sakarkiv av de fleste offentlige virksomheter, både i stat og kommune. De aller fleste slike systemer har Noarkgodkjenning (Noark-4 eller 5). Kun løsninger godkjent i henhold til Noark 5 vil ha innebygget funksjonalitet for produksjon av arkivuttrekk. Noark 4-godkjente løsninger har ikke innebygget funksjonalitet for overføring til depot. B. Fagsystem med journalførings- og arkivfunksjoner er fagsystemer, store og små, som har funksjonalitet for journalføring og arkivering samt produksjon av offentlig journal der det er påkrevet. Få av disse har funksjonalitet for avlevering av arkivmaterialet til depot. Det er et krav at nye fagsystemer skal tilfredsstille Noark 5-standarden, og noen har Noark 5-godkjenning. Det vil si at de forplikter seg til å oppfylle kravene til arkivdanning og overføring til depot, som definert i Noark 5. Fagsystem er ofte saksbehandlingssystem utviklet for spesifikke anvendelsesområder. Det kan være skreddersydde systemer for smale anvendelsesområder kommunene har ofte et stort antall slike, eller det kan være systemer som dekker store deler av virksomhetens, ofte etatens, anvendelsesområder. C. Fagsystem integrert med arkivsystem er fagsystem som får utført sine arkivfunksjoner ved program-til-program kommunikasjon med arkivsystem, enten komplette arkivsystem (Noark-4 og 5 komplett) eller arkivkjerner (Noark 5-kjerne). Et eksempel på slike er MATS i Mattilsynet. Ved å integrere fagsystemene med Noark 5-godkjente arkivkjerner, er tanken at all arkivfunksjonalitet, også for avlevering

7 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 7 av 18 til depot, ivaretas av arkivkjernene, slik at selve fagsystemapplikasjonen ikke trenger Noark 5-godkjenning. D. Fagsystem uten arkivfunksjonalitet er fagsystem som verken mottar eller produserer saksdokumenter (i arkivlovens forstand), men som f.eks. gjør en beregning eller holder oversikter. Folkeregisteret og enhetsregisteret er eksempler på slike systemer. Det vil normalt være knyttet saksbehandling til oppdatering og muligens oppslag i slike registre. Hvis dette er innebygget som del av registeret, vil det være et fagsystem med arkivfunksjoner. Generelt angående testing av disse kategorier: I den grad systemer av type B og C er Noark 5-godkjent forutsettes det at uttrekk testes i henhold til Noark 5 standard, jfr. punkt 3.2.A under. 2.2 Hva er ADDML? ADDML er det norske Arkivverkets egenutviklede standard for teknisk beskrivelse av strukturerte datafiler (tabelluttrekk). ADDML brukes også for slik teknisk strukturbeskrivelse i DIAS 4. Datafiler som skal testes vil falle i 2 hovedkategorier: XML-filer eller "Flat Files" (tegnseparerte filer, eller filer med fast postlengde). Standarden brukes i dag i versjonene 7.3 hos noen arkivskapere og andre arkiv, og 8.2 internt i Arkivverket. Verktøyet som her skal utvikles skal basere seg på versjon 8.2. For detaljer henvises til de to vedlegg: Bilag 2 - ADDML_8_2_Generelt.pdf Bilag 3 - ADDML_8_2_Utvidet_del.pdf 2.3 Om arkivdata, informasjonspakker og OAIS modellen En informasjonspakke skal inneholde en gitt struktur. Denne strukturen varierer noe mellom en SIP og en AIP, men i utgangspunktet er de egentlig identiske. Strukturen følger i hovedsak OAIS-modellen 5. Det er definert noen faste filer som skal være tilstede i strukturen. Disse filene følger noen gitte standarder, både i struktur og i innhold. Alle informasjonspakker skal dessuten være identifisert ved en UUID. Denne UUID'en vil være pakkens navn som fil. Pakken skal dessuten være pakket inn ved hjelp av TAR-formatet, slik at pakken i seg selv bare består av en enkelt fil. Ved overføring til et arkiv skal det likevel overføres to filer SIP'en som altså er en TAR-fil og en xml-fil som heter info.xml. Definisjonen av info.xml og de andre standardene som er benyttet vil også kunne finnes på arkivverkets nettsider slik som ADDML 6. Filen info.xml skal overføres elektronisk til arkivet, men adskilt fra SIP'en av sikkerhetsmessige grunner. Denne filen inneholder informasjoner om SIP'en knyttet til

8 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 8 av 18 overføringen, slik som SIP'ens sjekksum, eventuell krypteringsnøkkel, ansvarlig for overføringen, osv. Filen info.xml er definert i henhold til METS-standarden. Når det gjelder SIP'en skal denne følge en struktur som angitt i tegningen nedenfor, Figur 1: Strukturen i en AIP skal følge tegningen nedenfor, Figur 2:

9 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 9 av Overordnet funksjonalitet av verktøyet Figur 3, Testløpet i Arkade 5: 3.1 Sekvens av operasjoner i verktøyet Vi ønsker at verktøyet skal lede brukeren gjennom følgende hovedoppgaver: 1) Lese inn arkivdata 2) Lese inn beskrivelse av arkivdata 3) Registrere eventuell tilleggsinformasjon for arkivdelene 4) Teste arkivdata mot beskrivelsen 5) Logge alt som skjer i testprosessen 6) Oppsummere resultatet av testprosessen 7) Produsere en SIP eller AIP av arkivdata - for videre leveranse til Arkivverket 8) Kunne kjøre en statistikkmodul med utgangspunkt i loggen - og produsere testrapport Ad punkt 1: Man skal her kunne lese inn en "arkivpakke" (en "IP" i TAR format) eller et antall filer, vanligvis som "Flat Files" eller XML filer. Hvis det leses inn en IP så vil metadata om innholdet finnes i fila info.xml, se avsnitt 2.3. Ad punkt 2: Beskrivelsen av arkivdata leses i hovedsak inn fra en ADDML definisjonsfil, ref. vedlegg 2/3. Definisjonsfila vil vanligvis ha navnet addml.xml.

10 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 10 av 18 Hvis det som leses inn er en IP vil ADDML definisjonen ligge inne i IP-pakken. Ad punkt 6: Dersom det leses inn en IP (informasjonspakke), vil det normalt produseres en AIP (arkivpakke) ut. Dette vil typisk være dersom verktøyet skal teste et på forhånd produsert uttrekk. I andre tilfelle vil det leses data rett fra interne systemer for videre overføring til Riksarkivet (en SIP). For begreper se avsnitt Ordliste.På rot-nivået i pakken skal det ligge en METS-fil som følger dias-mets 7. Dias-mets inneholder en oversikt over alle filer som inngår i en IP, samt litt informasjon om disse filene, f.eks. sjekksum og type. I det store og hele kan man si at dias-mets.xml er pakkens pakkseddel. Under katalogen administrative_metadata skal det ligge to xml-filer. Den ene er en diaspremis.xml og den andre er addml.xml. (for Noark 5, heter den arkivuttrekk.xml, ref. punkt 3.2.A). Filen dias-premis.xml inneholder opplysninger om hendelser på materialet som inngår i pakken og hva slags rettigheter/restriksjoner som er knyttet til materialet. Filen addml.xml er altså addml-filen. Selve materialet som inngår i en pakke skal ligge i en katalog som heter content. I en SIP kan det også inngå to andre standardiserte filer, kalt ead.xml og eac-cpf.xml. Filen ead.xml inneholder informasjon om materialet slik som f.eks. hva det er benyttet til hos arkivskaper. Denne typen informasjon kalles arkivbeskrivelse, og er knyttet til systemet hos arkivskaper, og ikke spesielt til pakken som sådan. Filen eac-cpf.xml har en liknende type informasjon, men er spesielt knyttet til involverte aktører for systemet hos arkivskaper. Informasjonen kalles da også for aktørbeskrivelse. Begge disse to filene skal i pakken ligge i en katalog som heter descriptive_metadata. Når det er snakk om en AIP og ikke en SIP, er det påkrevd å ha med ead.xml og eac-cpf.xml. I tillegg skal alt testmateriale som produseres under testing vedlegges i pakken(e). Dette testmateriale skal ligge i en egen katalog under administrative_metadata som heter repository_operations. 3.2 Hvilke kategorier av tester skal verktøyet utføre. Det primære grunnlag for testing vil være ADDML-beskrivelsen av dataene, men for noen kategorier med visse tillegg.. Hvilken kategori uttrekket faller inn under fremgår av filtype(r) og metadata i ADDML-definisjonen. Test i henhold til ADDML-beskrivelsen vil falle i to hovedkategorier: "Flat Files" og "Data Objects", ref. de to vedlegg med ADDML spesifikasjon. "Flat Files" vil være tegnseparerte eller filer med fast feltlengde, eventuelt med tilhørende dokumentfiler. "Data Objects" forventes å være data i XML format, med tilhørende definisjonsfil (en ".XSD"). I ADDML er det mulig å definere en del prosesser som testverktøyet skal utføre. Disse prosessene må hver enkelt bruker av ADDML definere for sitt behov. Arkivverket har definert et sett av prosesser som skal kunne utføres etter ønske og avhengig av hva slags oppgaver som skal gjøres på materialet. Definisjonen av Arkivverkets prosesser finnes i del 2 av ADDML dokumentasjonen (vedlegg 3). 7 dias-mets.xsd og dias-premis.xsd er subset av mets.xsd resp. premis.xsd, som ble definert i DIAS-prosjektet.

11 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 11 av 18 Prosesser skal bare kjøres for "Flat Files". Verktøyet skal der støtte de grupper av prosesser som faller inn under analyse og kontroller. For "Data Objects" vil det være tilstrekkelig å teste gyldighet av XML filen(e) mot.xsd filene. Med referanse til kategoriene A-D i avsnitt 2 vil følgende gjelde: 3.2.A. Generelle sakarkivsystem Dette vil være Noark-systemer. Den tidligere Noark-3standard defineres nå som fagsystem, og faller inn under kategori D. For Noark-4 systemer må følgende tas hensyn til: NOARKIH.xml inneholder en beskrivelse av hvilke tabeller med hvilke felt som er med i akkurat dette uttrekket, samt hvor mange poster det er i hver tabell. ADDML standarden åpner ikke for å kunne registrere dette slik at en ADDML-fil kan utnytte alle de muligheter dette gir. Det er i ADDML dokumentasjonen beskrevet en mapping hvor antall poster blir ivaretatt, men kun dette. Dersom resten også skal ivaretas må det initieres spesialprogrammering. Noark 5-systemer vil i utgangspunktet testes ved å benytte ADDML-standarden. Man kan bemerke at ADDML-filen for Noark 5 har navnet "arkivuttrekk.xml", mens den generelle navnekonvensjon vil være "addml.xml". I tillegg vil det stilles krav om et antall tilleggstester for Noark 5. Disse er listet i vedlegg 4. Et Noark 5-system gjenkjennes fra "arkivuttrekk.xml" ved linjen <arkiv xmlns:xsd=" xmlns:xsi=" xmlns=" 3.2.B. Fagsystem med journalførings- og arkivfunksjoner Hvis disse er Noark 5-godkjent, forutsettes det testing i henhold til Noark5 standard som beskrevet over. 3.2.C. Fagsystem integrert med arkivsystem Hvis disse er Noark 5-godkjent, forutsettes det testing i henhold til Noark 5 standard som beskrevet over. 3.2.D. Fagsystem uten arkivfunksjonalitet Det forutsettes her at det testes kun ved hjelp av tilhørende ADDML-definisjon, av type "Flat Files" eller "Data Objects". Det vil kunne komme endringer i krav til formater og standarder, ref. avsnitt 2. Disse vil da kunne speiles i oppdaterte ADDML-definisjoner, slik at verktøyet ikke behøver endres av den grunn. Det vil også kunne komme endringer i krav til elementer i arkivbeskrivelsen (info.xml etc.) Verktøyet må lett kunne tilpasses ved krav til nye informasjonfelter (for testing og manuell registrering). Verktøyet skal være generisk ved å kunne teste data i forhold til enhver beskrivelse i en ADDML-definisjon.

12 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 12 av Overordnede mål og forventinger Verktøyets funksjonalitet og ytelsesnivå er hovedhensyn. Programvaren er nødvendig for å understøtte deler av en arbeidsprosess på tvers av forvaltningsorgan. Verktøyet skal understøtte strategisk, effektiv og kostnadseffektiv bruk av IT. Dette oppnådd ved å ta hensyn til hvilke tjenester (i forståelsen funksjonalitet) som leveres av komponenten, fremfor hvordan komponenten er sammensatt, slik at den derigjennom bidrar til gjenbruk. Komponenter vil være en nasjonal felleskomponent, og gjennom tjenesteorientering vil den bidra til raskere og mer kostnadseffektiv utvikling av elektroniske tjenester. Ved utvikling av løsningen vil det bli lagt til grunn en tilnærming som sikrer helhet og sammenheng med forvaltningens lovpålagte oppgaveløsing. Programmet bør være robust når det gjelder feilhåndtering, og enhver feilsituasjon skal resultere i tydelige feilmeldinger. Det forventes god dokumentasjon av alt som utvikles. Alle data, enten de leses inn manuelt eller automatisk, skal valideres. Alle nødvendige dataoperasjoner, herunder opprettelse av data, oppdatering av data, logisk sletting av data og lesing av data, skal logges. Riksarkivet ønsker en løsning som er tilstrekkelig modularisert, løst koblet og understøttet av veldefinerte grensesnitt. Dette betyr at løsningen både skal kunne kalle underliggende moduler og at deler av løsningen skal kunne kalles via et programgrensesnitt (API), gjerne basert på "REST" arkitektur 8. Dokumentasjon av API et må være god nok til at det er enkelt for programutviklere å benytte løsningen uten assistanse fra Riksarkivet. Spesielt bør brukergrensesnitt i størst mulig grad skilles fra underliggende programkode. Dette gjøres for at det eventuelt på et senere tidspunkt kan bli aktuelt å "dele" programmet ved hjelp av klient/tjener-arkitektur. 5. Strategiske føringer I den foreslåtte earkiv-arkitekturen 9 er det beskrevet flere grep for å forenkle, forbedre, automatisere og kvalitetssikre innlevering. Hovedhensyn er automatisering og standardisering, men også brukervennlighet og åpenhet. Et sentralt grep er å standardisere og automatisere funksjoner for uttrekk og testing, kvalitetssikring og bevaring av arkivmateriale. Det forventes at verktøyet vil bli integrert med earkiv-løsningene. Verktøyet må kunne samordnes med kommende standarder for kommunikasjon mellom offentlige etater, slik som BEST/EDU-grensesnittet, jfr. rapport fra Difi "Løsning for meldingsutveksling i offentlig sektor" "earkiv i offentlig forvaltningetablering av en datadrevet infrastruktur for løpende overføring av elektroniske arkiv til earkiv og digitalt depot", 20. januar

13 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 13 av 18 Det legges opp til en moderne, datadrevet arkitektur, hvor unødvendige manuelle funksjoner er gjort overflødig. Resultatet vil bli en kostnadseffektiv og tidsmessig løsning for validering av offentlige digitale arkiver. Utvikling av et nytt testverktøy åpner for store innsparinger i forhold til dagens metoder, gjennom betydelig effektivisering og automatisering. DIFIs arkitekturprinsipper 11 legges til grunn for løsningsvalgene. Spesielt kan nevnes av løsningen må støtte samtlige tegnsett som gitt ved standarden ISO/IEC , vanligvis kodet som UTF Kravspesifikasjonen legger vekt på brukerretting og kostnadseffektivitet. Dette beskriver også hovedutfordringene Riksarkivet og arkivskaperne opplever i dag; det går lang tid fra når data skal overføres til det gjøres en god validering av dem, og Riksarkivet opplever lav kvalitet på dataene som overleveres. Det som utvikles skal enkelt kunne installeres og kjøres på en standard Windows-installasjon uten krav til ekstra programvare. Det bør også være enkelt å flytte all programvare til andre aktuelle operativsystemer. Riksarkivets foretrukne plattformer er Windows og MAC på klientsiden, og Linux på server siden. Videre forvaltning av programmet etter akseptansetest vil være Riksarkivets ansvar. Riksarkivet vil delta aktivt i utviklingsfasen, både med prosjektledelse og tilrettelegging av programvare- utvikling. Riksarkivet benytter Confluence 14 og Jira 15 som interne verktøy. All programvare vil være fritt tilgjengelig som kildekode (GPL-lisensiering) 16. Koden skal ved ferdigstillelse være tilfredsstillende dokumentert og den skal tilgjengeliggjøres på GitHub 17. Ytelseskrav Ett og samme verktøy skal benyttes på alle typer uttrekk. Ref. avsnitt 3. Verktøyet skal distribueres til arkivskapere, arkivinstitusjoner og høyskolemiljøet. Dette forutsetter at det gis en robust utforming, slik at vedlikehold og oppfølging blir enklest mulig. Verktøyet skal kunne anvendes av personer med vanlig brukerkompetanse på itsystemer. Dette gjelder både uttrekksproduksjonen, selve kjøringen og analyse av testresultater som arkivskaper skal stå ansvarlig for overfor en depotinstitusjon. Testrapporten skal kunne analyseres og gjenbrukes maskinelt. Dette innebærer at de enkelte informasjonselementer skal gis en formalisert og entydig utforming, slik at de kan analyseres av systemet med henblikk på godkjenning eller ei. Dette gjør at de kan importeres til andre systemer for videre bruk. Verktøyet skal produsere en detaljert testrapport som grunnlag for godkjenning av uttrekket

14 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 14 av 18 Det er et mål at flest mulig av de samlede kontrollfunksjoner skal kunne formaliseres og implementeres i verktøyet. Dette skal sikre effektivitet, formalisert prosessdokumentasjon og etterprøvbarhet. Testverktøyet skal kontrollere den interne strukturen i uttrekket i forhold til standardiserte krav. Det betyr bl.a. at materialet i ettertid skal kunne vedlikeholdes og gjøre tilgjengelig med de verktøy Riksarkivet anvender.testverktøyet skal produsere statistikk over forekomster. Funksjonskrav Testverktøyet skal i utgangspunktet hente data fra fil, men det bør lett kunne modifiseres til å hente data fra andre datakilder, som for eksempel standard relasjonsdatabaser. Det skal innhentes to typer data for validering (modell): Dokumenter, i vanlig betydning av ordet. Dette vil typisk være saksdokumenter i PDF-format fra et Noark-system og lignende typer dokumenter fra fagsystemer. Verktøyet skal verifisere dokumenters eksistens. Verifisering av korrekt format i forhold til krav vil ligge i eksterne moduler, som må kunne kalles fra testverktøyet. Strukturerte data, som ofte vil være metadata til et sakarkiv (Noark), men som også kan være uttrekk fra en selvstendig database som ikke har tilhørende dokumenter. Hvis dette er metadata til digitale dokumenter som er med i uttrekket, må det testes på gyldige referanser mellom metadata og dokumentene. Ved hjelp av verktøyet skal man kunne registrere nødvendige metadata, ref. punkt 3.2. Uttrekket, sammen med tilhørende arkivbeskrivende og tekniske metadata, skal etter prosessering organiseres som en informasjonspakke, dvs. enten som en SIP eller som en AIP (Archival Information Package) i TAR format - i henhold til OAIS-standarden. En SIP skal være et selvdokumenterende objekt. Dette tilsier at all relevant informasjon som ikke må legges utenfor pakken, skal ligge inne i SIP-en. På en egen fil utenfor SIP-en legges en entydig identifikasjon av pakken som sådan, og en sjekksum for hele informasjonspakken. Sjekksummer for alle tilhørende dokumenter forutsettes generert av verktøyet og lagt inn i pakkens METS fil, ref. punkt 2.3. SIP-en består av selve uttrekket fra arkivskaperens digitale arkiv, dvs. strukturerte data og eventuelle dokumenter. En samlet betegnelse på dette kan være en IP ( Information Package). Dessuten skal den inneholde nødvendige metadata, både overordnede (tekniske og arkivbeskrivende), og en mer detaljert strukturbeskrivelse av data i IP-en. Strukturbeskrivelsen skal følge ADDML-standarden (se 2 vedlegg). Innhold og struktur på de øvrige metadata må spesifiseres som ledd i arbeidet med verktøyet. Verktøyet skal lese inn uttrekket, dvs. dokumenter og strukturerte data. Beskrivende metadata leses via xml-fil(er). Verktøyet skal tolke de spesifikasjonene som ligger i xml-filen(e) og bruke disse som kriterier for å teste uttrekket. Når testen gjennomføres, skal avvik fra det som er spesifisert i xml-filene angis i en testrapport, og det skal utvikles en analysemodul for en automatisert oppsummering av testrapporten. Både dokumenter og strukturerte data hentes av programmet.

15 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 15 av 18 Testverktøyet innhenter tre typer beskrivelse av uttrekket: A. Overordnet og annen beskrivende informasjon om uttrekket hentes fra filen info.xml dersom input til programmet er en "IP". Ref. punkt 3.2. B. Strukturbeskrivelsen for de strukturerte data i uttrekket hentes fra en ADDML-fil. Strukturbeskrivelsen for alle typer uttrekk, også fra Noark-systemer, vil ligge i en ADDML-fil, med eventuelle tillegg, ref avsnitt 3. Hvis input til programmet er en IP skal ADDML-filen ligge ved i pakken. C. Hvis input til programmet ikke allerede er en ferdig "IP" skal programmet ved hjelp av et brukergrensesnitt gi mulighet for å registrere de nødvendige data for å produsere en info.xml i den SIP som produseres. Verktøyet skal produsere 4 resultater: 1) En detaljert logg. 2) En testrapport som viser et samlet resultat for hver test. Testrapporten skal genereres av en egen modul i verktøyet. Modulen generer rapporten ut fra informasjon i den detaljerte loggen. 3) En analyse av testrapporten (sammendrag) hvor ulike typer avvik fra kravene oppsummeres. 4) En "ut-pakke" (en SIP eller AIP). Angående punkt 1 - logg. Det må spesifiseres et format for denne. Riksarkivet vil utarbeide et utkast her, eventuelt i samarbeid med de som utvikler verktøyet. Riksarkivet legger til rette for at verktøyet kan publiseres som åpen kildekode. Verktøyet skal kunne behandle verdier angitt på nynorsk i tillegg til bokmål.

16 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 16 av Detaljert kravmodell 6.1. Overordnede krav K 1.1 K 1.2 K 1.3 K 1.4 K 1.5 K 1.6 K 1.7 K 1.8 K 1.9 K 1.10 Verktøyet skal gis en generisk utforming slik at det kan benyttes på uttrekk fra alle vanlige typer databaser og dokumentfiler. Ulike varianter av strukturer, formater og innhold skal håndteres på basis av formaliserte beskrivelser. Det skal ikke være nødvendig å endre programkoden for å håndtere ulikheter i mottatte data som skal testes. Verktøyet må være modularisert, med mulighet for å koble på spesialiserte moduler. Verktøyets moduler skal være kallbare via et API. Verktøyet skal utformes med sikte på å kunne nedlastes for bruk av eksterne aktører arkivskapere og deres underleverandører samt andre arkivinstitusjoner. Nødvendige krav til ferdigstilling, systemdokumentasjon og robuste løsninger må være oppfylt. Verktøyet skal kunne installeres på en enkel måte som en samlet pakke. Installasjon skal kun kreve vanlig brukerkompetanse på it-systemer. Det generelle verktøyet skal kunne benyttes av personer med vanlig brukerkompetanse på it. Brukergrensesnittet må være tilpasset dette behovet. Spesielle moduler kan eventuelt kreve mer kompetanse. Verktøyet skal produsere en logg over gjennomførte operasjoner, resultater og oppsummering fra en testkjøring. Alle feil og unormale situasjoner skal logges i detalj. Loggen skal utformes etter nærmere spesifikasjoner. Verktøyet må være tilstrekkelig effektivt til å fungere som et hendig redskap både for arkivskapere og depotinstitusjoner. Det stilles ikke spesifiserte krav til effektivitet, men de prosessene som er etablert pr. i dag skal ytterligere optimaliseres ved utvikling av verktøyet. Verktøyet skal bygges på en moderne teknisk plattform, og baseres på åpen kildekode, slik at verktøyet fritt kan distribueres og gjenbrukes. Verktøyet skal i størst mulig grad utvikles ved hjelp av programvare som virker uavhengig av operativsystem og maskinvare. Som et minimum må det fungere på Windows, og helst også på de mest utbredte Linux-dialektene. Alle kontroller som lar seg formalisere skal utføres automatisert i testverktøyet. Verktøyet skal kunne kjøres på en arbeidsstasjon. Dersom tilbudet forutsetter spesielle krav til maskinvare eller programvare skal dette fremgå av tilbudet

17 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 17 av Lesing og skriving av data K 2.1 K 2.2 K 2.3 K 2.4 K 2.5 K 2.6 Verktøyet skal kunne lese en IP i TAR-format, pakke den ut og kontrollere innpakning og sjekksum. Verktøyet skal kunne kontrollere sjekksum for alle filer i en IP. Verktøyet skal kunne leses datafiler (metadata og dokumenter) som ikke er pakket i en IP - for videre testing. Alle xml-filer som leses skal sjekkes for at de er "velformet" XML og at de validerer mot den tilhørende xsd- eller dtd-filen. Alle xml-filer som produseres skal være velformet og validere i henhold til medfølgende.xsd-filer. Verktøyet skal støtte internasjonale tegnsett, antatt ved hjelp av UTF-8 standarden Testing og logging K 3.1 K 3.2 K 3.3 K 3.4 K 3.5 K 3.6 K 3.7 K 3.8 Metadata og data som leses inn - info.xml, metadata, strukturdefinisjoner fra ADDML - skal testes for samsvar. Verktøyet skal kunne sjekke eksistens av de dokumentfiler som angis. Verktøyet skal ha en egen modul for å kunne teste de filformater som angis i databeskrivelsen. Filformater skal primært testes ved hjelp av ekstern standard programvare; kallbare via et API, eller som en tjeneste. Modulen skal ha en åpen arkitektur, slik at det er enkelt å legge til nye testrutiner ved nye eller endrede filformater. Selve programvaren for test av formater inngår ikke i leveransen. Dersom input til programmet er en IP, skal verktøyet hente kriterier som f eks arkivperiode og arkivdel for utvelgelse av data fra info.xml og sette opp tester for å sjekke om alle relevante data i uttrekket oppfyller kriteriene. Verktøyet skal hente info om dataformater fra strukturbeskrivelsen og sette opp tester for alle felt i uttrekket mot formatfeil, ulovlige verdier etc.. jfr. vedlegg 2 og 3. Verktøyet skal hente info om primærnøkler, fremmednøkler og koblinger fra strukturbeskrivelsen og sette opp tester for å sjekke at primærnøkler er unike og at koblinger fungerer, jfr. vedlegg 2 og 3. Loggen som produseres av testverktøyet, skal vise alle operasjoner som foretas under en testkjøring og deres resultater. Loggen skal utformes slik at den kan være et hensiktsmessig redskap for å etterprøve testingen om slike behov skulle oppstå. Verktøyet skal hente info for aktuell statistikk fra loggen, og sette opp funksjoner for produksjon av den angitte statistikk samt eventuelle tester i forhold til grenseverdier (toleransegrenser) som angitt i ADDML definisjonen.

18 Kravspesifikasjon Arkade 5 Uttrekks- og testverktøy Side 18 av Brukergrensesnitt K 4.1 K 4.2 K 4.3 K 4.4 K 4.5 K 4.6 K 4.7 Brukergrensesnittet skal oppfylle følgende krav: Brukermiljøet skal være enklest mulig. Operasjoner som "dra og slipp" er foretrukket når det gjelder å hente inn filer og data Ord, fraser og konsepter som brukes i grensesnittet skal i størst mulig grad være på "godt norsk". Programmets moduler skal være tydelig adskilte Brukeren skal få tydelige tilbakemeldinger hvis det tastes inn ugyldige data Alle felt skal ha tooltip eller lignende hjelpfunksjon. Programmet skal ha kvalitetskontroll på all input "Lag pakke" (IP) - siste trinn i prosessen - skal ikke kunne aktiviseres før alle forutgående trinn er komplette. Verktøyet skal visualisere hvilke operasjoner som utføres og til enhver tid vise fremdrift i prosessene. Spesielt skal det fremgå hvilke tester som er kjørt. Ved fremvisning av hvilke tester som er kjørt skal det fremgå hvilke som er gått feilfritt igjennom, hvilke som har åpenbare feil, og eventuelt tvilstilfeller (for eksempel ved rød, gul eller grønn farge). Dette som et hjelpemiddel for arkivskaper og -tester, slik at man lett kan finne frem til hva som krever manuell vurdering eller endring. Som hovedregel skal testingen fullføres selv om det avdekkes alvorlige eller kritiske feil underveis. Hvis det avdekkes tekniske feil som er så alvorlige at det ikke lar seg gjøre eller ikke gir mening å kjøre videre, skal programmet foreta et kontrollert avbrudd med en forståelig feilmelding. Det skal også gis melding om hvor langt testingen var kommet ved avbruddet. Det er ønskelig at det for hver test åpnes for at det siden kan legges inn eksterne kall til hjelpemoduler. Disse moduler vil eventuelt i en fremtidig videreutvikling til å teste "toleransegrenser" o.a. for feilsituasjoner. Etter avsluttet testing skal verktøyet oppsummer testresultatene og dokumentere produksjon av en eventuell IP i en enkel testrapport. Verktøyet skal ha i tillegg til en enkel oppsummering ha en egen statistikkmodul som gjennomgår den fullstendige loggen, og oppsummerer ulike typer avvik fra kravene som definert i avsnitt 4.