Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 1 av 32 Kravspesifikasjon Arkade 5 Testverktøy for digitale arkivpakker Innhold 1 Innledning... 3 1.1 Anskaffelsens innhold... 3 1.2 Vurderingskriterier ved anskaffelse... 3 1.3 Anskaffelsens formål... 4 1.4 Bakgrunn for behov... 4 1.5 Struktur av dette dokumentet... 4 1.6 Ordliste... 5 2 Strategiske føringer ved programutvikling... 9 2.1 Om et fremtidig earkiv... 9 3 Overordnede mål og forventinger... 10 3.1 Verktøyets arkitektur... 10 3.2 Validering og logging... 10 3.3 Konklusjoner angående aksept av uttrekket... 10 3.4 Anskaffelsens begrensning... 11 4 Forskjellige typer arkivløsninger... 11 4.1 Forskjellige typer arkiver... 11 4.2 Hva er ADDML?... 12 4.3 Om arkivdata, informasjonspakker og OAIS modellen... 12 5 Verktøyets arkitektur... 14 5.1 Sekvens av operasjoner i Verktøyet... 14 5.2 Hvilke kategorier av tester skal Verktøyet utføre.... 15 5.2.1 Generelle sakarkivsystem... 16 5.2.2 Fagsystem... 17 5.2.3 Betraktninger rundt størrelse... 17 6 Funksjonelle krav... 17 6.1 Overordnede krav... 17 6.2 Detaljerte krav... 18 7 Sikkerhet... 19 8 Prosjekt - gjennomføring... 20 9 Avtale, dokumentasjon, akseptanse, vedlikehold og drift... 20 9.1 Avtaleinngåelse... 20 9.2 Dokumentasjon... 20 9.3 Akseptansetest... 21 9.4 Vedlikehold og drift... 21 10 Appendiks 1 - Sekvensiell gjennomgang av testløpet... 22 10.1 Sekvens av operasjoner hos arkivskaper... 22 10.1.1 Opprette ny struktur... 23 10.1.2 Lese inn arkivdata fra en samling filer... 23 10.1.3 Lese inn en informasjonspakke generert tidligere... 23 10.1.4 Registrere eventuell tilleggsinformasjon for arkivdataene... 24 10.1.5 Teste arkivdata mot beskrivelse... 24 10.1.6 Logge alt som skjer i testprosessen... 24
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 2 av 32 10.1.7 Lage en testrapport... 24 10.1.8 Oppsummere resultatet av testprosessen... 24 10.1.9 Produsere en (S)IP for overføring til depotet... 24 10.1.10 Produsere en info.xml for samme IP... 24 10.2 Sekvens av operasjoner hos depot... 25 10.2.1 Lese inn en informasjonspakke mottatt fra arkivskaper... 25 10.2.2 Lese inn info.xml mottatt fra arkivskaper... 25 10.2.3 Legge på eventuelle testpunkter... 25 10.2.4 Registrere eventuell tilleggsinformasjon for arkivdataene... 25 10.2.5 Teste arkivdata mot beskrivelse... 25 10.2.6 Logge alt som skjer i testprosessen... 25 10.2.7 Lage en testrapport... 26 10.2.8 Oppsummere resultatet av testprosessen... 26 10.2.9 Produsere en (A)IP for overføring til magasinet... 26 10.3 Standardisering... 26 11 Appendiks 2 - Detaljert kravmodell... 27 11.1 Arkitektur... 27 11.2 Brukergrensesnitt og oppstart... 27 11.3 Testing... 27 11.4 Dokumenter... 28 11.5 Logging og rapportering... 28 11.6 OAIS prinsipper og output... 28 11.7 Dokumentasjon og distribusjon... 29 11.8 Ytelse, operativsystem og maskinvare... 29 12 Appendiks 3 - Liste over manuelle hendelser som skal logges... 30 13 Appendiks 4. Endringer i ADDML spesifikasjon 8.2 til 8.3... 31 14 Appendiks 5 - Liste over øvrige vedlegg til spesifikasjonen... 32
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 3 av 32 Versjon 2.0 Versjon Beskrivelse Dato Ansvarlig 2.0 Spesifikasjon - offentlig anbud - DOFFIN/TED 17.03.2016 Arkivverket 1 Innledning 1.1 Anskaffelsens innhold Arkivverket vil utvikle et verktøy som skal teste arkivuttrekk både før og etter leveranse til arkivinstitusjon. Testverktøyet skal kunne distribueres til alle forvaltningsorgan i Norge. Målgruppen er primært arkivskapere i statlige og kommunal sektor, foruten Arkivverket selv, men private aktører skal også kunne ta verktøyet i bruk. 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. 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 Arkivverket. Rammeverket for anskaffelsen finnes i "Forskrift om utfyllende tekniske og arkivfaglige bestemmelser om behandling av offentlige arkiver", kapittel VIII, "Bestemmelser om elektronisk arkivmateriale som avleveres eller overføres som depositum til Arkivverket" 1. I det følgende vil det som skal utvikles kalles Verktøyet. 1.2 Vurderingskriterier ved anskaffelse Arkivverket vektlegger gjennomføringsevne med 70% og det mest økonomisk fordelaktige med 30%. Gjennomføringsevne innbefatter både administrative og tekniske ressurser. 1 https://lovdata.no/dokument/sf/forskrift/1999-12-01-1566#kapittel_8
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 4 av 32 1.3 Anskaffelsens formål Målet med verktøyutviklingen er å forenkle testprosessene, for dermed raskt å kunne gjøre forbedringer, slik at kvaliteten øker 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 så tidlig som mulig i testprosessen, helst hos arkivskaper. Dermed kan rettinger gjøres før uttrekket overføres fra forvaltningen til Arkivverket for endelig verifikasjon, og kostnadene kan reduseres. Forvaltningsorganene kan rette opp teknisk genererte feil umiddelbart, fremfor at man ender opp med mer ressurskrevende opprydding i etterkant. Verktøyet vil også bli brukt av Arkivverket internt. Sentralt i anskaffelsen er funksjoner og brukervennlighet. 1.4 Bakgrunn for behov Beregninger som er gjort gir grunnlag for å estimere at det for perioden 2015-2034 vil være cirka 1.380 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, Eksempler fra statlig sektor viser at forvaltningsorganenes egne kostnader per uttrekk kan være i størrelsesordenen100.000 eller mer, ofte fordi det kreves flere "runder" før arkivuttrekk kan bli godkjent. For Arkivverket ligger kostnaden per uttrekk mellom 50.000 og 100.00 for å ta imot, teste, dokumentere og lagre hvert uttrekk i digitalt sikringsmagasin. Totalt koster altså hvert arkivuttrekk anslagsvis 200.000 kroner. I statlig sektor er det for perioden 1995-2014 anslått at det i de 355 enhetene er opparbeidet et etterslep på 6.690 uttrekk som ikke er avlevert til depot. Verktøyet vil senke terskelen for å kjøre tester av arkivuttrekk, noe som vil spare tid og kostnader både for arkivkapere og arkivinstitusjoner. 1.5 Struktur av dette dokumentet Dokumentet gjennomgår strategiske og overordnede krav, deretter krav til Verktøyet mer i detalj. En del detaljer er plassert i appendikser, slik som aggregert sjekklister for funksjonalitet, og detaljer angående syntaks og funksjonalitet i underliggende moduler. Spesielt kan nevnes avsnitt 5.1, "Sekvens av operasjoner i Verktøyet". Avsnittet er et sammendrag av Appendiks 1 som gjennomgår oppgaveflyt mer i detalj. Samtlige fotnoter (lenker) i dette dokumentet er gyldige pr. 15. mars 2016. Dette dokument er Vedlegg 01 i utlysning for anbudskonkurranse. Andre vedlegg refereres mange steder. En liste over resterende vedlegg finnes her som Appendiks 5.
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 5 av 32 1.6 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 Arkivverket. En slik innlevering defineres som en innleveringspakker eller overføringspakke. Standarden er XML basert. I ADDML kan man legge inn prosesser som fungerer som instruksjoner for et verktøy som tester pakkenes "velformethet" og innhold. ADDML standarden er et samarbeid mellom arkiver i Norge, Sverige og Finland. Det finnes lokale variasjoner. Verktøyet skal bruke den norske definisjonen, som er vedlagt i Vedlegg 08 ("addml.xsd") AIP Archival Information Package (AIP). En informasjonspakke brukt for å overføre arkivmateriale til bevaring i et depot. Pakken inneholder både metadata (informasjon om dataene) og selve dataene. Pakken vil som oftest være i "TAR" format (se i ordlisten nedenfor). 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 deler felter i en tabellrad. dataobjects Dataobjekter er en betegnelse som her 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
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 6 av 32 arkivloven med forskrifter er det i Norge kun tillatt å deponere eller avlevere et begrenset antall dokumentformater (Riksarkivarens forskrift kap VIII, paragrafene 17-20). DTD DTD (Document Type Definition) spesifiserer hvordan en kan gi en formalisert beskrivelse av elementene i blant annet XML-filer. I senere år han man i stor grad gått over til "XSD" (se nedenfor) for dette formål. EAC-CPF EAC-CPF står for Encoded Archival Context - Corporate bodies, Persons and Families 2. 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 (se nedenfor) for en styrking av EADs muligheter i forhold til koding av kataloginformasjon. EAC-CPF er definert via et XML schema ("XSD"). 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. I dette Verktøyet skal man forholde seg til EAD versjon 3 og den definerte ead3.xsd 3 fra august 2015. flatfiles "Flate filer" er i denne sammenheng 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) 4 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 Arkivverkets 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 2 http://eac.staatsbibliothek-berlin.de/ 3 https://github.com/saa-sdt/ead3/releases/tag/v1.0.0 4 http://www.loc.gov/standards/mets/
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 7 av 32 tilgjengeliggjøring av det digitale innholdet. I Norge brukes en lokal tilpasning av METS, som kan ses i detalj i Vedlegg 08. OAIS-standarden OAIS, Reference Model for an Open Archival Information System6 (ISO 14721: 2003) 5 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 bevaringsobjekt i OAIS kan være et enkelt dokument eller et samlet datauttrekk fra en database. OAIS skiller mellom tre 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 6. 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 fra arkivskaper. Denne vil som oftest bestå av et antall filer pakket i TAR format, og vil danne grunnlaget for en senere "AIP" for innlemming i depot. Sjekksum En kode som genereres for en fil. Ved endring av en fil vil sjekksummen endres. Sjekksummen sikrer dermed integritet av en fil. TAR/.tar Begrepet TAR kommer fra Tape ARchive. Det arkivbaserte datasettet dannet av TAR inneholder diverse parametere som tidsstempel, eierskap, filaksess/tillatelser og mappeorganisering. Filstrukturen for denne informasjonen er senere blitt standardisert, og støttes av de fleste moderne filarkiveringssystemer. TAR pakker filer sekvensielt uten komprimering. 5 http://www.iso.org/iso/catalogue_detail.htm?csnumber=24683 6 http://www.loc.gov/standards/premis/
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 8 av 32 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 3.4 10 38 mulige verdier, og dermed er sjansen forsvinnende liten for at samme kombinasjon vil 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.
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 9 av 32 2 Strategiske føringer ved programutvikling Det legges opp til en moderne 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. DIFIs arkitekturprinsipper 7 legges til grunn for løsningsvalgene. Kravspesifikasjonen legger vekt på brukerretting og kostnadseffektivitet. Dette beskriver også hovedutfordringene Arkivverket og arkivskapere 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 Arkivverket 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. Noen prinsipper vil kunne gjenbrukes fra forrige versjon av Arkade ("Arkade 4"). Kildekoden fra Arkade 4 vil derfor distribueres til eventuelle interesserte. Arkade 4 er utviklet i Java, men dette gir ingen føringer for valg av metodikk i Arkade 5. Arkivverket forutsetter at Verktøyet publiseres som åpen kildekode. 2.1 Om et fremtidig earkiv 8 Sentralt ved fremtidig utvikling av arkivsektoren i offentlig forvaltning er innføring av "earkiv" som en felleskomponent. I den foreslåtte arkitekturen 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 i nye versjoner vil bli integrert med de kommende earkivløsningene. Verktøyet skal da kunne levere data til earkiv som et alternativ til å levere til arkivinstitusjon. Verktøyet må derfor senere 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" 9. Dette bør det tas hensyn til i Verktøyets arkitektur. 7 http://www.difi.no/sites/difino/files/arkitekturprinsipper-2.1.pdf 8 "earkiv i offentlig forvaltningetablering av en datadrevet infrastruktur for løpende overføring av elektroniske arkiv til earkiv og digitalt depot", 20. januar 2015 9 https://www.difi.no/sites/difino/files/losningsbeskrivelse_meldingsutveksling_i_offentlig_sektor_difirapport_2015_3.pdf
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 10 av 32 3 Overordnede mål og forventinger 3.1 Verktøyets arkitektur Arkivverket ønsker en løsning som er tilstrekkelig modularisert, løst koblet og understøttet av veldefinerte grensesnitt. Dette betyr at Verktøyet både skal kunne kalle underliggende moduler og at Verktøyets funksjoner skal kunne kalles via et programgrensesnitt (API). Dokumentasjon av API et må være god nok til at det er enkelt for programutviklere å benytte Verktøyet uten assistanse fra Arkivverket. 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. Verktøyet bør være solid når det gjelder feilhåndtering, og enhver feilsituasjon skal resultere i tydelige feilmeldinger. Det forventes god dokumentasjon av alt som utvikles. Verktøyet har "malbasert" brukergrensesnitt, slik at det vil være enkelt å endre språk. 3.2 Validering og logging Alle data, enten de leses inn manuelt eller automatisk, skal valideres. Alle sjekksummer skal kontrolleres. Alle XML filer skal sjekkes for "velformethet"; uttrekk skal avvises, og programmet skal terminere med en feilmelding dersom dette ikke er tilfelle. Det er imidlertid ikke et absolutt krav at XML filene skal validere mot korresponderende XSD eller DTD fil. Eksempelvis kan konvertering av Noark uttrekk fra tidligere til senere versjoner medføre mangel av obligatoriske felter. Slike feil skal logges og rapporteres, men ikke medføre avslutning av testprosessen. Dersom feil som avdekkes skyldes avvik eller mangler i grunnlagsdata ("ekte feilregistreringer") har det ikke innvirkning på vurdering om uttrekket kan godkjennes. Dataoperasjoner skal logges. Operasjoner faller i 2 kategorier: I. Manuelle operasjoner, herunder opprettelse av datastrukturer, oppdatering av data, og testing av data. Se Appendiks 3 for en liste over disse. II. Automatiserte operasjoner, slik de er innebygget i Verktøyets testprosesser 3.3 Konklusjoner angående aksept av uttrekket Verktøyet kan vanligvis ikke konkluderer entydig om et uttrekk vil bli godkjent av arkivinstitusjonen. Resultatene vil vanligvis gi en klar indikasjon, men manuell vurdering vil ofte være nødvendig. Det vil likevel være noen feil som er såpass alvorlige at Verktøyet kan avvise uttrekket - og det skal dermed ikke ferdigstilles en SIP. Eksempler på dette kan være feil i sjekksummer eller feil i antall journalposter. Riksarkivet vil distribuere en liste over uakseptable feil i forbindelse med utvikling av Verktøyet.
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 11 av 32 3.4 Anskaffelsens begrensning Verktøyet skal ikke generere uttrekk, kun teste og pakke Verktøyet forholder seg heller ikke til hvilke systemer eller databaser (programvare) som genererer de uttrekk som skal testes Verktøyet forholder seg ikke til hvilke data som skal bevares, eller hvilke data i systemene som er bevaringsverdige. Verktøyet tar ikke stilling til hvilke arkivuttrekk som er avleveringspliktige 4 Forskjellige typer arkivløsninger For ord og begreper henvises til avsnitt 1.6 og fotnoter. En overordnet målsetting er å effektivisere testing av alle kategorier av arkivmateriale, samtidig som man beholder fleksibilitet i forhold til variasjoner i datainnhold. 4.1 Forskjellige typer arkiver Arkivdanning skjer i dag gjennom mange ulike løsninger. De kan kategoriseres slik: A. Generelle sakarkivsystem B. Fagsystem Testverktøyet vil behandle de 2 kategorier noe forskjellig, ref. avsnitt 5.2. A. 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 1011 eller Noark 5 12 komplett, løsninger som benyttes til sakarkiv av de fleste offentlige virksomheter, både i stat og kommune. De aller fleste slike systemer har Noark-godkjenning (Noark-4 eller 5). Noark 5 løsninger kan ha innebygget funksjonalitet for produksjon av arkivuttrekk. Noark 4-godkjente løsninger har ikke innebygget funksjonalitet for overføring til depot. B. Fagsystem Fagsystemer med NOARK-godkjent arkivfunksjonalitet vil kunne beskrives ved hjelp av ADDML standarden - og dermed automatisk kunne testes av Verktøyet. Se neste avsnitt angående ADDML. Dette vil vanligvis være systemer 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. I så tilfelle vil det noen ganger kunne leveres i Noark 5 standard, og testes i henhold til det (ref. avsnitt 5.2.1). 10 http://www.arkivverket.no/arkivverket/offentleg-forvalting/noark/noark-4 11 https://lovdata.no/dokument/sf/forskrift/1999-12-01-1566/kapittel_4#kapittel_4 12 http://www.arkivverket.no/arkivverket/offentleg-forvalting/noark/noark-5
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 12 av 32 Generelt angående testing av disse kategorier: Begge kategorier skal kunne testes ved hjelp av tilhørende ADDML beskrivelse. For Noark 4 og Noark-5 gjelder noen tilleggskrav. 4.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 13. Datafiler som skal testes vil falle i 2 hovedkategorier: "dataobjects" (XML filer) eller "flatfiles" (tegnseparerte filer, eller filer med fast postlengde). Standarden brukes i dag i versjonene 7.3 hos noen arkivskapere og andre arkiv, og 8.2 eller 8.3 internt i Arkivverket. Verktøyet som her skal utvikles skal i første versjon basere seg på versjon 8.3. For detaljer henvises til de to vedlegg: Vedlegg 02 - ADDML_8_2_Generelt.pdf Vedlegg 03 - ADDML_8_2_Utvidet_del.pdf Det er versjon 8.2 som er dokumentert, da dokumentasjon for versjon 8.3 ikke er ferdigstilt. Det er imidlertid små forskjeller, og endringer fra versjon 8.2 til 8.3 er spesifisert i Appendiks 4. For de som fortsatt bruker versjon 7.3 av ADDML vil det senere bli levert en XSLT transformasjon som konverterer til versjon 8.3. 4.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 relativt identiske. Strukturen følger i hovedsak OAIS-modellen 14. Det er definert noen faste filer som skal være til stede 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 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 en arkivinstitusjon skal Verktøyet likevel overføre 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 15. 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 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. 13 http://www.arkivverket.no/arkivverket/arkivbevaring/elektronisk-arkivmateriale/dias-prosjektet 14 http://public.ccsds.org/publications/archive/650x0m2.pdf 15 http://www.arkivverket.no/arkivverket/arkivbevaring/elektronisk-arkivmateriale/standarder/
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 13 av 32 I tillegg til OAIS er pakkestrukturene også basert på definisjonene gjort i DIAS-prosjektet. Dette medfører at begge typer pakker skal inneholde filene dias-mets.xml og diaspremis.xml. I en AIP skal i tillegg filene ead.xml og eac-cpf.xml følge med i pakken. Hvilke elementer som skal benyttes i disse filene fremgår av XSD filer i Vedlegg 08. Informasjonen finnes også på Arkivverkets nettside om DIAS. Når det gjelder SIP'en skal denne følge en struktur som angitt i tegningen nedenfor, Figur 1: Vi viser også strukturen i en AIP i tegningen nedenfor, Figur 2: Verktøyet skal imidlertid når det brukes av arkivskapere kun generere "SIP"-er.
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 14 av 32 5 Verktøyets arkitektur Figur 3, Viser testløpet i Arkade 5: 5.1 Sekvens av operasjoner i Verktøyet Vi ønsker at Verktøyet skal lede brukeren gjennom følgende hovedoppgaver: 1) Lese inn arkivdata (uttrekk) - fra en "SIP" - eller via vanlig(e) fil(er) inn i struktur 2) Lese inn beskrivelse av arkivdata 3) Manuelt å registrere eventuell tilleggsinformasjon for arkivdelene 4) Teste arkivdata mot beskrivelsen 5) Logge alt som skjer i testprosessen til fil. Denne behøver ikke være lesbar manuelt. 6) Kjøre en statistikkmodul med utgangspunkt i loggen, produsere detaljert testrapport og en oppsummering av funnene 7) Produsere en SIP og en info.xml fil for videre leveranse til arkivinstitusjon. Ved bruk hos arkivinstitusjon vil det normalt sett i stedet produseres en AIP. Ad punkt 1: Man skal her kunne lese inn en "arkivpakke" (en "IP" i TAR format) eller et antall filer, vanligvis som "flatfiles" eller XML filer. Hvis det leses inn en IP, så vil metadata om innholdet finnes i filen info.xml, se avsnitt 4.3. En XML mal (.xsd) og en tekstlig beskrivelse av info.xml finnes pakket sammen i Vedlegg 06 - info.xsd.zip. Ad punkt 2: Beskrivelsen av arkivdata leses i hovedsak inn fra en ADDML definisjonsfil, ref. Vedlegg 02/03. Definisjonsfilen vil vanligvis ha navnet addml.xml. Hvis det som leses inn er en IP vil ADDML definisjonen ligge inne i IP-pakken.
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 15 av 32 Ad punkt 6: Oppsummering må vurderes manuelt for å avgjøre om arkivuttrekket anses godt nok for godkjenning Ad punkt 7: Det vil normalt produseres en arkivpakke ut enten for videre overføring til Arkivverket (en SIP), eller for lagring i depot hos arkivinstitusjon (en AIP). For begreper se avsnitt 1.6 - Ordliste. På rot-nivået i pakken skal det ligge en METS-fil som følger DIAS- METS 16. 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 diasmets.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 5.2.1). 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åkrevet å ha med ead.xml og eaccpf.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. 5.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: "flatfiles" og "dataobjects", ref. de to vedlegg med ADDML spesifikasjon. "flatfiles" vil være tegnseparerte eller filer med fast feltlengde, eventuelt med tilhørende dokumentfiler. "dataobjects" forventes å være data i XML format, med tilhørende definisjonsfiler ("XSD"- er). Første fase av en test i henhold til ADDML definisjonen vil være å sjekke feltbeskrivelser mot innhold (for eksempel datoformater). I ADDML er det i tillegg mulig å definere en del prosesser som testverktøyet skal utføre, utover det som fremgår av feltdefinisjoner. 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 03). 16 DIAS-METS.xsd og DIAS-PREMIS.xsd er subset av METS.xsd resp. PREMIS.xsd, som ble definert i DIASprosjektet.
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 16 av 32 Prosesser skal med unntak av Noark-4 uttrekk bare kjøres for "flatfiles". Prosesser faller i 3 kategorier: 1. Analyser. Disse ønskes kjørt dersom definert. Resultatet bør gå frem av statistikken. Disse kan kjøres på fil-, post- eller felt-nivå. Eksempelvis kan det være å telle antall av en viss type forekomster. 2. Kontroller: Disse ønskes kjørt dersom definert. Disse kan også kjøres på fil-, posteller felt-nivå og resultater skal komme frem av statistikken. Eksempelvis kan dette være kontroll av "fremmednøkler" 17. 3. Konvertering: Disse skal ikke kjøres av Verktøyet selv om de er definert. I første versjon skal alle definerte prosesser i kategori 1 og 2 kjøres. Det er likevel ønskelig at koden senere lett kan modifiseres til å selektere blant de definerte prosesser. For "dataobjects" vil det være tilstrekkelig å teste gyldighet av XML filen(e) mot XSD filene. ADDML definisjonen åpner for også å definere prosesser i "dataobjects", men de skal i så fall ignoreres i denne versjon av Verktøyet. Se likevel angående spesialbehandling for Noark 5 i avsnitt 5.2.1 under. Med referanse til kategoriene A og B i avsnitt 4.1 kan vi dele kategoriene for test i følgende: 5.2.1 Generelle sakarkivsystem Noark-3. Den tidligere Noark-3 standard er nå redefinert via en ADDML definisjon. Den kan testes via standard ADDML "flatfiles". Et eksempel på en Noark-3 ADDML fil finnes i Vedlegg 08. Noark-4. Noark-4 uttrekk er i utgangspunktet bestående av et sett av xml-filer med en NOARKIH.xml som den beskrivende filen. ADDML standarden åpner ikke for å kunne registrere dette direkte, slik at en ADDML fil kan utnytte alle de muligheter dette gir. For Noark-4 systemer vil derfor prosessen kreve et ekstra trinn. Det er utarbeidet en transformasjon ved hjelp av en XSLT 18 fil. Trinn 1 i en Noark-4 test vil være å kjøre XSLT-transformasjonen på NOARKIH.xml. Leverandøren står her fritt ved valg av programvare/bibliotek. XSLT transformasjonen vil generere en ADDML fil - som da på vanlig måte kan brukes av Verktøyet for påfølgende testing. Denne filen vil også inneholde prosesser som skal kjøres på Noark-4 uttrekket, men siden det kun er NOARKIH.xml som blir transformert vil altså uttrekket inneholde en addmlfil samt et sett av xml-filer. Transformasjonen er lagd slik at datafilene (dvs. xmlfilene) tolkes som om de var flate filer og følgelig kan ha prosesser (ref. unntak over angående kjøring av prosesser på uttrekk av typen "dataobjects"). XSLT definisjonen, så vel som eksempler på NOARKIH og ADDDML filer er vedlagte denne spesifikasjonen (Vedlegg 08). "Vedlegg C" i ADDML spesifikasjonen "Utvidet del" (vårt Vedlegg 03) kan dermed ignoreres. ADDML filen vil også her være av typen "flatfiles", og testes i henhold til dette, inklusive eventuelt definerte "prosesser". 17 https://en.wikipedia.org/wiki/foreign_key 18 https://en.wikipedia.org/wiki/xslt
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 17 av 32 Noark 5 Disse vil i utgangspunktet testes ved å benytte ADDML standarden "dataobjects". Man kan bemerke at ADDML filen for Noark 5 har navnet "arkivuttrekk.xml", mens den generelle navnekonvensjon vil være "addml.xml". Et eksempel på en Noark 5 ADDML fil finnes i Vedlegg 08. Siden ADDML definisjonen for Noark 5 er av type "dataobjects" vil det ikke være krav om testing av "prosesser". Men for Noark 5 vil det i stedet stilles krav om et antall tilleggstester. Disse er listet i Vedlegg 05, og vil i stor grad innebære tester på samme måte som prosess testing for "flatfiles". 5.2.2 Fagsystem Det forutsettes her at det testes kun ved hjelp av tilhørende ADDML definisjoner. Det vil kunne komme endringer i struktur av data i uttrekk. Disse vil da kunne speiles i oppdaterte ADDML filer. Det vil ikke være nødvendig å endre Verktøyet av den grunn - så lenge ikke selve ADDML standarden (versjon 8.3) endres. 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 informasjonsfelter (for testing og manuell registrering). Verktøyet skal være generisk ved å kunne teste data i forhold til enhver beskrivelse i en ADDML definisjon slik den er beskrevet i Vedlegg 02 og 03, med tillegg av endringer som listet i Appendiks 4. 5.2.3 Betraktninger rundt størrelse Det må tas hensyn til at det kan bli ganske store XML strukturer som skal leses inn i Verktøyet. En løsning der alle data holdes i maskinens minne slik som det vanligvis gjøres i en "Document Object Model" 19 vil derfor antagelig ikke være hensiktsmessig, ref. krav 8.3 i appendiks 2. 6 Funksjonelle krav 6.1 Overordnede krav Ett og samme verktøy skal benyttes på alle typer uttrekk. Verktøyet skal distribueres til arkivskapere, arkivinstitusjoner og høyskolemiljøet. Verktøyet skal kunne anvendes av personer med vanlig brukerkompetanse på itsystemer. Dette gjelder kjøringen og testprosessen. Analyse av testresultater som arkivskaper skal stå ansvarlig for overfor en depotinstitusjon vil kunne kreve mer arkivfaglig kompetanse. Det er viktig at Verktøyet visualiserer hvilke oppgaver som til enhver tid kjører, og viser fremdrift underveis. 19 https://en.wikipedia.org/wiki/document_object_model
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 18 av 32 Alle felter for manuell inntasting skal ha hjelpefunksjoner i form av Tooltip 20 eller lignende Testloggen skal kunne analyseres og gjenbrukes maskinelt, både av Verktøyet (for å produsere testrapport) og av eventuell utenforliggende programvare. Det stilles dermed strengere krav til struktur og dokumentasjon av testloggen. De enkelte informasjonselementer må gis en formalisert og entydig utforming. Format for testloggen må derfor defineres ved en XML mal (.xsd). Dette gjør at de kan importeres til andre systemer for videre bruk. Verktøyet skal produsere en detaljert testrapport - et grunnlag for manuell vurdering av hvorvidt uttrekket kan godkjennes. 6.2 Detaljerte krav Testverktøyet skal i utgangspunktet hente data fra fil(er), 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, men ikke verifisere at dokumentene er i samsvar med gjeldende format standarder. Det bør likevel være åpning for at fremtidige versjoner av Verktøyet kan kalle på eksterne moduler eller tjenester som kan verifisere dokumentformater. 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 (eksistens) mellom metadata og dokumentene. Ved hjelp av Verktøyet skal man kunne registrere nødvendige metadata, ref. punkt 5.1. 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 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. Som algoritme for sjekksum ønskes i denne versjon SHA-256 21. Sjekksummer for alle tilhørende dokumenter forutsettes generert av Verktøyet og lagt inn i pakkens METS fil, ref. punkt 4.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 Vedlegg 02 og 03). Innhold og struktur på de øvrige metadata må spesifiseres som ledd i arbeidet med Verktøyet. 20 https://no.wikipedia.org/wiki/tooltip 21 https://en.wikipedia.org/wiki/sha-2
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 19 av 32 Testverktøyet innhenter tre typer beskrivelse av uttrekket: A. Overordnet og annen beskrivende informasjon om uttrekket hentes fra filen info.xml dersom input til Verktøyet er en "IP". Ref. punkt 4.3. 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 4.2. Hvis input til Verktøyet er en IP skal ADDML filen ligge ved i pakken. C. Hvis input til Verktøyet ikke allerede er en ferdig "IP" skal Verktøyet ved hjelp av et brukergrensesnitt gi mulighet for å registrere de nødvendige data for å produsere en info.xml i den SIP eller AIP som produseres. Obligatoriske metadata i info.xml fremgår av innholdet i filen info.xsd, ref. Vedlegg 06. Verktøyet skal produsere 4 resultater: 1) En detaljert logg i XML format. XML/XSD definisjonen skal være engelskspråklig. Tekstlig innhold kan være norsk- eller engelskspråklig. 2) En testrapport som viser et samlet resultat for hver test. Rapporten skal være på norsk. 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. Denne skal genereres på norsk. 4) En "ut-pakke" (en SIP eller AIP). Angående punkt 1 - logg. Det må defineres et format for denne. Riksarkivet vil kunne bidra i spesifikasjonen. Når det gjelder tegnsett skal Verktøyet støtte både ISO 10646 22 (vanligvis betegnet som UTF- 8 23 ), ISO 8859-1 ("Latin-1") og ISO 8859-4 ("Latin-4"), ref. gjeldende versjon av Riksarkivarens forskrift 24. Støtte for disse tegnsett gjelder både inn- og utdata ("arkivpakker"). Interne data (hjelpetekster og lignende) forutsettes kodet i UTF-8. Det samme gjelder logger og metadata som produseres av Verktøyet. 7 Sikkerhet Koden til programvaren vil være fritt tilgjengelig. Det gjelder imidlertid ikke de data som vil flyte gjennom systemet. Det må derfor sikres mot lekkasjer av data. Dette gjelder spesielt ved en tenkt fremtidig arkitektur der deler av Verktøyet vil kunne kalles som en nettbasert tjeneste. 22 https://en.wikipedia.org/wiki/universal_coded_character_set 23 https://en.wikipedia.org/wiki/utf-8 24 https://lovdata.no/dokument/sf/forskrift/1999-12-01-1566/kapittel_8#%c2%a78-17
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 20 av 32 8 Prosjekt - gjennomføring Riksarkivet vil inngå i prosjektgruppen for å kunne bidra med arkivfaglig kompetanse, og eventuelt tilrettelegging av programvare. Prosjektet vil rapportere til en Styringsgruppe, med medlemmer fra Arkivverket og andre sentrale interessenter. Riksarkivet benytter Confluence 25 og Jira 26 for intern administrasjon. All programvare som utvikles skal være fritt tilgjengelig som kildekode (GPL-lisensiering) 27. Koden skal ved ferdigstillelse være tilfredsstillende dokumentert og den skal tilgjengeliggjøres på GitHub 28. 9 Avtale, dokumentasjon, akseptanse, vedlikehold og drift 9.1 Avtaleinngåelse Difi's standard "Avtale om utrednings- og utviklingsoppdrag fra Konsulent" 29 vil legges til grunn ved inngåelse av kontrakt. 9.2 Dokumentasjon Sammen med Verktøyet skal det leveres 1) Beskrivelse av installasjon og eventuelle rammeverk 2) Systemdokumentasjon - overordnet beskrivelse av moduler og deres sammenheng 3) Annen utvalgt teknisk dokumentasjon, som for eksempel XSD definisjoner for XML 4) Dokumentasjon for vanlige brukere 1) Kan skrives på engelsk eller norsk 2) og 3) Skal skrives på engelsk 4) Må skrives på norsk For øvrig forventes det tilfredsstillende kommentarer og dokumentasjon inne i all kode. Dette skal være engelskspråklig. 25 https://en.wikipedia.org/wiki/confluence_%28software%29 26 https://en.wikipedia.org/wiki/jira 27 http://no.wikipedia.org/wiki/gnu_general_public_license 28 https://github.com/ 29 http://www.anskaffelser.no/verktoy/oppdragsavtalen-ssa-o
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 21 av 32 9.3 Akseptansetest Før godkjenning skal leveransen bestå en akseptansetest. Denne skal baseres på de tekniske punkter i Appendiks 2. Riksarkivet er ansvarlig for å sette opp maskin- og programvare som muliggjør en slik test i detalj. Avvik mellom beskrevet funksjonalitet inndeles i 2 kategorier: A. Kritisk eller alvorlig feil: Feil som medfører stopp eller at sentral funksjonalitet ikke finnes eller ikke virker B. Mindre alvorlig feil: Feil i mindre sentral funksjonalitet, mindre mangler i brukergrensesnitt og mangler i dokumentasjon. Verktøyet anses ikke som levert før feil av type A) er rettet. Påviste feil av type B) må rettes eller endres innen 3 måneder fra akseptanse. Først på dette tidspunkt regnes leveransen som komplett. 9.4 Vedlikehold og drift Det vil bli tegnet en oppsigelig avtale om vedlikehold og feilretting for et antall måneder etter komplett og akseptert leveranse. Ansvar deretter for videre forvaltning av Verktøyets programvare er foreløpig ikke definert. Verktøyet vil bli driftet i separate instanser hos Arkivverket og hos arkivskapere.
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 22 av 32 10 Appendiks 1 - Sekvensiell gjennomgang av testløpet Figur 4. En overordnett modell over prosesser både hos arkivskaper og i depot hvor Arkade 5 er tenkt benyttet. I det følgende vil de forskjellige delene av prosessen både hos arkivskaper og hos depot bli nærmere beskrevet. Det er mange likhetspunkter mellom de to hoveddelene av prosessen, men også distinkte forskjeller. Derfor beskrives begge to. 10.1 Sekvens av operasjoner hos arkivskaper Oppgaver 1. Opprette en ny struktur 2. Lese inn arkivdata fra en samling filer 3. Lese inn en informasjonspakke generert tidligere. (Vil erstatte punkt 1 og 2.) 4. Registrere eventuell tilleggsinformasjon for arkivdataene 5. Teste arkivdata mot beskrivelse 6. Logge alt som skjer i testprosessen
Kravspesifikasjon versjon 2 Arkade 5 - Testverktøy Side 23 av 32 7. Lage en testrapport 8. Oppsummere resultatet av testprosessen 9. Produsere en (S)IP for overføring til depotet 10. Produsere en info.xml for samme IP Se også skisse i Vedlegg 04 - "Arkade 5 - Oppgaveflyt.pdf" 10.1.1 Opprette ny struktur Verktøyet må kunne opprette en tom struktur for å begynne å lage en beskrivelse og en informasjonspakke fra grunnen av. Dette må ikke nødvendigvis skje i starten av prosessen. Men på ett eller annet tidspunkt er det naturlig at applikasjonen skal kunne utføre en slik funksjon. 10.1.2 Lese inn arkivdata fra en samling filer Hos arkivskaper vil det normalt ikke være noen informasjonspakke til å starte med. Noen vil i stedet ha gjort et uttrekk fra et system, dvs. fra systemets database. Et slikt uttrekk vil normalt være en samling av filer organisert i en katalogstruktur. Filene i denne strukturen kan være av mange forskjellige typer, fast format, tegnseparert format, XML filer og andre. Dessuten vil dette bare være datafilene, og i liten grad metadata om informasjonen. Selve strukturen vil så bli beskrevet ved hjelp av arkivverkets hjelpemiddel "Arkadukt" 30 eller en tilsvarende applikasjon. Resultatet her vil altså bli en beskrivelse i form av en ADDML fil. Produksjon og beskrivelse av ADDML filen er ikke en del av Verktøyet som skal utvikles. Arkadukt vil parallelt bli utviklet av Arkivverket internt, blant annet for å ta høyde for endringer i siste versjon av ADDML (8.3). Denne funksjonen vil dermed bestå av to deler: Først å lese inn selve strukturbeskrivelsen, dvs ADDML filen. Deretter å lese inn selve arkivdataene fra katalogstrukturen. Igjen: Dette er ikke nødvendigvis den gitte rekkefølgen av funksjonene. 10.1.3 Lese inn en informasjonspakke generert tidligere I noen tilfeller kan det være aktuelt at det allerede er laget en informasjonspakke tidligere og så lese den inn på ny. Nå vil altså arkivdata og strukturbeskrivelse ligge inne i pakken, men i tillegg kan det også finnes ytterligere metadata her. 30 http://www.arkivverket.no/arkivverket/arkivbevaring/elektronisk-arkivmateriale/testverktoey/arkadukt