Innhold Innhold... 1 Innledning... 2 Systemdiagram... 3 Use case definisjoner... 4 1. Funksjonelle krav til løsning... 5 2. Skisse til løsning... 11 3. Generelt... 13 4. Test... 15 5. Fremdriftsplan... 16
Innledning Med bakgrunn i vårt internasjonale FoU engasjement og vår erfaring fra arbeid innen tilgjengeliggjøring og gjenbruk av data fra de mest sentrale områdene for offentlige data vil vi først og fremst gi vår tilslutning til at etableringen av et nettsted som data.norge.no er et viktig og nødvendig skritt for å realisere det økonomiske, vitenskapelige og kunnskapsmessige potensialet som i dag er gjemt bort i separate informasjonsunivers. Vi håper naturligvis også at DIFI vil oppfatte AVINET og vårt løsningsforslag som interessant for implementering av portalen. Figur 1: Offentlige data med stort gjenbrukspotensiale i henhold til epsiplus prosjektet Arbeid som har vert utført innen offentlig informasjon i Europa har identifisert tre ulike dataområder som de viktigste kildene til data for gjenbruk: geografiske data; lovdata og meteorologiske data. Denne avgrensingen er gjort i samsvar med EU-direktivet for (gjenbruk av) offentlig informasjon hvor kulturinformasjon og statistikk er utelatt av hensyn til rettighetsproblematikk og sikkerhet. I data.norge.no vil vi gjerne også se disse to som en del av helheten. AVINET har gjennom snart 10 år arbeidet tett med å utvikle katalog og datautvekslingsløsninger for geodataproduserende etater i Norge (mellom annet Statens Kartverk), vi har også arbeidet tett med kultursektoren (en rekke prosjektet innen dataformidling for ABM-Utvikling 1, statens senter for utvikling innen arkiv-, biblioteks- og museumssektoren) og det siste året også med Statistisk Sentralbyrå som en svært viktig leverandør av offentlige data i Norge. Innen det juridiske området har AVINET vert med på å utvikle og drive en rekke av de sentrale systemene for eiendom, persondata og kriminalrett. AVINET er også en sentral gjenbruker av åpne data innen meteorologiområdet i Norge og er et ledende kompetansemiljø for de løsninger som ligger til grunn for tjenesten yr.no 2. Vår erfaring fra dette arbeidet tilsier at det har etablert seg skillelinjer ikke bare mellom organisasjoner men også mellom sektorer. Det geografiske området har sin egen datakatalog, Norge Digitalt som kun fokuserer på data som har en direkte geografisk referanse men som er en viktig kilde til metadata også for data.norge.no. Å bryte ned dette skillet ved hjelp av maskin-maskin interoperabilitet mellom kataloger vil være en svært viktig suksessfaktor for dette prosjektet. Avinet mener å ha den nødvendige erfaring og kontakt med relevante fagmiljøer for å oppnå denne gevinsten. Til dette prosjektet har vi i tillegg til våre egne erfaringer og kunnskap hentet inn støtte fra flere hold som vil bistå i detaljspesifikasjonsfasen for å sikre at alle relevante hensyn blir tatt og for å sikre optimal læringsverdi og overføringsverdi fra tilsvarende initiativ andre steder. 1 ABM-U er for tiden under omorganisering og vil bli overført til Nasjonalbiblioteket og Norsk Kulturråd. 2 Yr.no blir utviklet av Nrk og DNMI. Avinet er ikkje involvert i dette arbeidet. 2
Disse inkluderer: ekspertise fra data.gov.uk-prosjektet og; ekspertise innen gjenbruk av offentlig informasjon fra epsiplus-prosjektet Vi har også tillatt oss å fremheve ytterligere momenter som vil være viktige for å lykkes med data.norge.no, herunder markedsføring av tjenesten mot både datatilbydere og sluttbrukere hvorav offentlig sektor selv kanskje vil være den største volumbrukeren men hvor privat sektor og særlig ideelle organisasjoner/ngoer vil kunne utgjøre et stort potensial i løpet av kort tid. Systemdiagram AVINETs løsningsforslag er beskrevet i henhold til tabellene i DIFIs kravspesifikasjon under overskriftsnumrene 1-5 nedenfor og er vist forenklet i dette systemdiagrammet: Figur 2: Systemdiagram for AVINETs løsningsforslag for data.norge.no I tillegg til de komponenter som er eksplisitt etterspurte i DIFIs kravspesifikasjon har vi valgt å inkludere MapServer som en del av teknologiplattformen da søk og gjenfinning av datasett etter geografisk dekningsområde kan være av stor interesse for eventuelle gjenbruk. 3
Use case definisjoner For at løsningen skal svare til de aktuelle problemstillingene for de ulike aktørene innen åpne data i Noreg har vi valgt å definere noen enkle generelle use-case scenerier som illustrerer de viktigste funksjonene løsningen må støtte. Mer detaljerte diagrammer vil bli utformet som en del av detaljspesifikasjonsaktiviteten i fase 1-3. Figur 3: UML use-case diagrammet over viser hvilke brukerscenarier som er vektlagt for løsningsforslaget 4
1. Funksjonelle krav til løsning Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 1.1 Generelle krav 1.1.1 Løsningen skal bestå av et rammeverk som Løsningen bygger på ivaretar design og navigasjon mellom de rammeverket Drupal som sikrer at løsningen fremstår forskjellige modulene i løsningen slik at løsningen som enhetlig. fremstår som enhetlig og sammenhengende. Rammeverket skal omfatte følgende innholdskategorier: Nettstedets logo, navn, etc., som skal vises på alle sider Språkvalg Faner e.l. som hjelper brukeren å navigere mellom datakatalogen, blogg, andre dokumenter og ressurser Innlogging for brukere 1.1.2 Løsningen skal kunne fremstå på flere språk, med mulighet for å gjøre innhold tilgjengelig på flere språk. 1.1.3 Løsningen skal ha minst ett unikt navn, det vil si et navn som ikke er direkte knyttet til løsningen eller leverandøren av løsningen. For eksempel data.norge.no 1.1.4 Løsningen skal aktivt hjelpe brukeren til å følge referansekatalogens krav til IT-standarder der det er relevant. (http://standard.difi.no/). Et konkret eksempel på dette er at løsningen skal sørge for at dokumenter blir publisert i rett format. 1.1.5 Løsningen skal utformes i tråd med statens IKTarkitekturprinsipper: http://prosjektveiviseren.no/dokumenter/arkite kturprinsipper 1.1.6 Løsningen skal tilfredsstille kravene i W3C WAI WCAG 2.0 AA (alle kriterier merket A og AA i standarden - http://www.w3.org/wai/wcag20/quickref/over view.php). Ved leveranse skal dette dokumenteres. 1.1.7 Løsningen skal benytte RDF/Linked Open Dataattributter til å annotere innhold på nettstedet. Vil benytte Drupal s språkmoduler. Løsningen vil i hjelpefunksjoner og ledetekster for skjemaer for publiserering (og bruk) av data peke til relevante standarder både fra DIFI og andre relevante nasjonale og internasjonale standarder. Løsningen vil også implementere aktiv validering av felter for opplasting for å sikre kompatible filtyper etc. Grafisk visning av søkeresultater i kart vil være en ikke-essensiell tilleggsmodul hvor noe av det grafiske innholdet vanskelig kan stille kravene til WACG standarden, Dette vil imidlertid bare dreie seg om en alternativ måte å vise innhold på således vil løsningen som helhet være kompatibel med tilgjengelighetsstandardene. Deskriptive metadata som vil være tilgjengelige som RDF vil være basert på velkjente 5
attributt-vokabular hvor Dublin Core er det viktigste men hvor det også vil lånes elementer fra DCAT, Friend-of-a-Friend, SKOS, Creative Commons og DOAP for å utvikle en DC applikasjonsprofil for data.norge.no. Dataene vil siden bli eksponerte over Internett gjennom spørreprotokollen SPARQL og kataloggrensesnittet i CKAN/ Drupal. 1.1.8 Datakatalog-delen av løsningen bør bygge på Comprehensive Knowledge Archive Network (CKAN) eller bedre. Beskriv hvordan dere ønsker å bruke CKAN. Dersom løsningen ikke bygger på CKAN, begrunn hvorfor og hva dere vil bruke istedet. Alt.1) Det installeres en instans av CKAN for å lagre metadata om datasettene. CKAN benytter et format med noen standardelementer og i tillegg kan det defineres andre, som til dømes Dublin Core. Datakatalogen vil bli brukt fra Drupal vha CKANs APIer, både for spørring, registrering og vedlikehold. Metadataene registreres og vedlikeholdes i utgangspunktet manuelt der brukertilgangen i Drupal og CKAN er samordnet. Alt.2) Metadata om datasett defineres som en innholdstype i Drupal. Content Construction Kit (CCK) brukes for å definere felter. Det finnes CCK-modul for DC samt extensible Catalog Drupal toolkit som blant annet inneholder OAI-PMH harvester modul for høsting av metadata. Ellers finnes mange moduler for import og sync i Drupal. 1.2 Administrasjon av nettstedet 1.2.1 Løsningen skal kunne håndtere et større antall brukere med ulike roller og rettigheter. Det skal registreres kontaktinformasjon relatert til hver bruker. 1.2.2 Innholdet på nettstedet skal kunne administreres gjennom et webbasert grensesnitt kryptert med SSL. 1.2.3 Løsningen må legge til rette for en enkel autentisering av brukere. Det må være mulig å verifisere enkelte brukere som representanter Se også 1.2.12 og 1.6.1 CKAN (alt.1) velges fordi den er tiltenkt å behandle datasett og andre kunnskapsressurser og at den alt er brukt i søster-prosjekt som data.gov.uk. CKAN mangler en del funksjonalitet som lagring av kommentarer og visning av statistikk over bruk. data.gov.uk har derfor laget en åpen CKAN-Drupal integrasjonsmodul, for å benytte funksjonalitet i Drupal i stedet. Kort sagt lagres node i Drupal for hver metadatapakke som datasett i CKAN. Vi forutsetter at denne integrasjonen også tas i bruk aktuell løsning. User Management moduler i Drupal benyttes. Disse kan integreres mot OpenID moduler for Drupal. OpenID modulene har bl.a. mulighet til å automatisk generere Drupal brukere for personer som har OpenID og å hente ned relevante data Drupal støtter https og kryptering. Det er flere måter å løse dette på, og de ulike metodene har sine positive og negative sider. Grad av sikkerhet må sees opp mot ressursbruk. Moduler i Drupal benyttes. Pålogging vha OpenID eller ved å angi brukernavn og passord. 6
for departement, etater og kommuner. 1.2.4 Det skal være støtte for å tildele rettigheter til brukere på en enkel måte. 1.2.5 Alt innhold skal eies av én eller flere brukere i systemet. 1.2.6 Administrator skal kunne administrere alt innhold. 1.2.7 Løsningen skal kunne håndtere flere versjoner av metadata, der hver av versjonene korresponderer med ulike versjoner av datasettet metadataene beskriver. Det skal komme klart frem hvilke versjoner av det beskrevne datasettet som er tilgjengelige til enhver tid, og hvilke versjoner som er historiske. 1.2.8 Løsningen skal ha en rutine for håndtering av metadata for relaterte datasett. Det skal være mulig å se metadata for relaterte datasett i sammenheng. 1.2.9 Løsningen skal ha en rutine for utfasing av beskrivelser av spesifikke datasett. Brukere kan ha roller (for eksempel gruppe) med ulike rettigheter. Via rollebegrepet i Drupal. Alt innhold i løsningen vil være knyttet til en bruker eller rolle i systemet og vil kunne administreres av denne. CKAN versjonerer automatisk all metadata dvs. at alle endringer lagres. Innholdet i metadatafeltene som peker til det stedet hvor datasettet er publisert som LOD vil kunne være forskjellig fra versjon til versjon av metadataene. Det er imidlertid opp til datatilbyder å endre denne informasjonen og passe på at metadataene peker til korrekt versjon av datasettet, eventuelt historiske versjoner av dataene. CKAN supporterer relasjoner mellom pakker (metadata) gjennom Package Relationships Register og har Model API som kan benyttes fra til dømes Drupal. Metadata vil gis i form av nøkkelord hentet fra et felles kontrollert vokabular uttrykt i som SKOS (Simple Knowledge Organisation System). Nøkkelordene vil være i metadatafeltet DC:Subject og disse vil også kunne brukes til å avlede relasjoner mellom datasett, det samme gjelder felter som for eksempel DCMI:terms ispartof. Med dette punktet forstår vi at det vil være behov for å fjerne metadata for et gitt datasett da det blir avdekket eventuelle feil i dataene eller andre forhold krever dette. Løsningen støtter både permanent fjerning av metadata for datasett (sletting) og midlertidig blokkering av tilgang, det siste kan være relevant i situasjoner der et datasett må tas offline i en 7
1.2.10 Løsningen skal kunne håndtere import av metadata fra andre kilder. Slik import skal kunne automatiseres. 1.2.11 Datakatalogen skal inneholde metadata som kreves for å kunne gjøre en tjeneste tilgjengelig, eksempelvis informasjon, relevante adresser, formater, dokumenter, standarder, lisenser og kontaktinformasjon for feilmeldinger meldt på nettstedet. Beskriv hvordan disse metadatadefinisjonene kan vedlikeholdes. 1.2.12 Alle innholdselement skal ha en unik permanent URI. URI-en må være lesbar ( human readable ), være hierarkisk oppbygget, og være utformet slik at man skal kunne tolke hva den representerer. Beskriv hvordan disse URI-ene kan vedlikeholdes. 1.2.13 Det skal være mulig å navigere i metadataene på flere måter, f.eks. etter eier, forvaltningsnivå, eiers geografiske plassering, type data og lisenstype. 1.2.14 Det skal være mulig å gi tilbakemelding på alle datasett som er beskrevet i datakatalogen. Beskriv hvordan dette løses og administreres. 1.2.15 Det skal være mulig å følge en RSS/Atom-feed med nyheter om hvert datasett som er beskrevet periode for å utføre rettinger av systematiske feil el. l. Midlertidig blokkering gjøres fra Drupal mens permanent sletting også kan gjøres fra CKAN. CKAN har Excel Importer for metadata (og datasett). CKAN har kommandolinjeklient (datapkg) som kan lette automatisering (jfr. cron). Det må trolig lages/tilpasses importrutiner for andre formater som XML/JSON, om de ikke alt finnes. Definisjonene kan vedlikeholdes i en CKAN Form, fra Drupal via API eller som en CKAN klient. Unike permanente Id-er vil bli bygget opp ved hjelp av datasettenes eierskap, navn og versjonsnummer. Eksempel: http://data.norge.no/[normalise rt kortform av tilbyderorganisasjonsnavn]/[no rmalisert kortform av datasettnavn]/[versjonsnumm er] Metadataene vil inneholde provenansinformasjon for å peke videre til original URIer for data som blir vedlikeholdt i andre kataloger og høstet automatisk av data.norge.no. For hver id vil det være tilgjengelig et (auto-generert) RDF dokument som gir informasjon om datasettet, dets relasjoner med mer. Se også punkt 1.6.1 Dette kan gjøres gjennom CKAN s søke-api fra Drupal ved å angi de elementer som skal søkes på. Dette kan gjøres ved at kommentarer lagres i Drupal knyttet til node for datatasettets metadata. API-et CKAN Feeds gir en liste over endringer i alle eller en pakke (metadata om 8
i datakatalogen. Disse nyhetene skal kunne lages direkte på nettstedet. Løsningen skal også kunne videreformidle nyheter fra dataeier. 1.2.16 Alt innhold skal være synlig datert. 1.2.17 Hvert datasett som er beskrevet i datakatalogen skal presenteres med nøkkeltall relatert til visningen av datasettet. Et eksempel på nøkkeltall er antall visninger i en gitt periode. Det skal være mulig å navigere etter slike nøkkeltall. 1.2.18 Det skal være mulig å registrere informasjon om applikasjoner. Det skal være mulig å registrere metadata om applikasjonen, i tillegg til at det skal være mulig å knytte metadata om applikasjonen til metadata om de datasettene applikasjonen benytter. 1.3 Krav til nettstedet 1.3.1 Nettstedet skal ha en innbydende utforming hvor alt innhold redigeres i samme grensesnitt som visningen. 1.3.2 Løsningen skal ha en søkemekanisme som lar bruker søke i fritekst på alt innhold i løsningen. 1.3.3 Det skal være mulig å karakterisere noen av de beskrevne datasettene som populære eller hotte. Disse skal kunne profileres på fremsiden og/eller i sidekolonner. 1.4 Krav til bloggen 1.4.1 Det skal være mulig å importere alt innhold fra den nåværende bloggen på data.norge.no inn i den nye bloggen. 1.5 Presentasjon av datasett 1.5.1 Eier av datasett skal kunne laste opp ett eller flere eksempel på datasettet. Disse skal både kunne lastes ned og kunne visualiseres i nettleseren av besøkende. Minimum støtte er JSON og XML. datasett). Det kan også være naturlig å knytte nyheter om datasettet til noden i Drupal og bruke RSS Feed derfra.. Det finnes en core-modul og en avansert modul i Drupal for statistikk over bruk av noder som for eksempel metadata om datasett. Vi antar at dette skulle reflektere bruken av datasett i CKAN. En kan navigere etter nøkkeltall til dømes via en skymodul. Metadata om applikasjoner lagres i CKAN som andre metadata, men definert med andre felt. Ved å definere relasjonsfelt i metadataene kan metadata om applikasjon og datasett knyttes sammen. Drupal s fritekst-søk er trolig godt nok også for metadata da de er lagret som noder, ellers kan CKAN Search API utføres fra Drupal. Administrator av nettstedet registrerer dette i Drupal eller en kan profilere etter bruken av noden. Eksisterende blogg er tilgjengelig som RSS og alt innhold kan hentes via denne kanalen. CKAN Excel Importer finnes og bør kunne brukes til å laste opp datasett og metadata til gruppe Eksempler til dømes. JSON og XML bør også kunne lastes opp som et filvedleggsfelt i skjema for datasett. 9
1.6 Tilgjengelighet av rådata 1.6.1 Katalogen over offentlige datasett skal beskrives som et eget datasett i løsningen, og gjøres tilgjengelig i standardiserte, strukturerte, maskinlesbare formater. Katalogen skal som et minimum gjøres tilgjengelig på veldokumentert JSON- og XML-format (Dette er det eneste datasettet som skal gjøres tilgjengelig på data.norge.no). Beskriv forslag til format og programmeringsgrensesnitt for dette datasettet. Data.norge.no-katalogen og dens innhold vil bli publisert som Linked Open Data hvor hvert datasett blir gitt en unik IRI 3 basert identifikator. Data vil være tilgjengelige både som fildump i RDF/XML / JSON formater - og som et dynamisk endepunkt for SPARQL spørringer mot en integrert triple-store. SPARQL serveren vil også støtte både RDF/XML og JSON men i tillegg også flere formater om ønskelig. Se også punkt 1.2.12 3 International Resource Identifier, se også RFC3987 10
2. Skisse til løsning Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 2.1 Leverandøren må gi en skisse til løsningsforslag. Programvarekomponenter Løsningsforslaget skal minst omfatte: som inngår i løsningen: Se En modell for løsningen som synliggjør skisse neste side. hvilke funksjoner som inngår i løsningen Vi legger opp til i å bruke mest En spesifikasjon av hvilke mulig åpen kildekode programvarekomponenter nettsted og database hyllevare i vår løsning. baseres på Oppgi hvilke deler av løsningen som baserer seg på hyllevare, egenutviklete standardløsninger og skreddersøm, og hvilke lisenser som gjelder for hver komponent. Drupal: Et innholdsstyringssystem basert på fri og åpen kildekode. Drupal er lisensiert under GNU General Public License versjon 2 eller senere. Alle moduler som nyttes i Drupal er og underlagt samme lisens. Er utviklet i PHP. CKAN: Et åpent og fritt verktøy for deling og gjenbruk av åpent innhold og åpne data. CKAN er utviklet i Pyton. Er lisensiert under GNU Affero GPL. MySql: Er en mye brukt relasjonsdatabase både innen kommersiell bruk og for bruk i FOSS (Free Open Source Software) løsninger. Er underlagt GNU General Public License (version 2, with linking exception) or proprietary EULA Apache http server: Er en fri og åpen kildekode basert webtjener. Er lisensiert under sin egen Apache License, v2.0. OpenID: Drupal med moduler, har støtte for bruk av OpenID. Dette er en tjeneste som tilbys av flere, men en kan også sette opp egen OpenID server om ønskelig. Mapserver: Er en åpen kildekode basert plattform for å publisere romlige data og interaktive kartløsninger på web. Er lisensiert under en MIT-Style license. 11
2.2 Dersom løsningen bygger på programvare som leverandøren ikke selv står ansvarlig for, bes det om opplysninger om forhold mellom leverandør og rettighetshaver, og om planer for videreutvikling av programvaren og løsningen. 2.3 Leverandøren bes beskrive ansvarsforhold, ressurser og rutiner for utvikling, feilretting, kvalitetskontroll og support for tilbudt tredjeparts programvare. Alle komponentene som inngår i vår løsning er under åpen kildekode paraplyen. Det er ikke noe annet ansvarsforhold mellom oss og rettighetshaver, enn det som er styrt gjennom de ulike lisensmodellene. De ulike programmene har sine egne dedikerte miljøer som driver med videreutvikling og oppdatering. Se 2.2 12
3. Generelt Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 3.1 Dokumentasjon 3.1.1 Følgende dokumentasjon skal tilpasses oppdragsgiver og utarbeides: Brukerdokumentasjon for innholdsleverandørene Bruker/system-dokumentasjon for administrator Driftsdokumentasjon for leverandør av tjenesten Brukerveiledning for sluttbruker, tilgjengelig på nettstedet Teknisk dokumentasjon (programvare, versjoner, plattform, osv.) 3.1.2 Løsningen i seg selv skal være mest mulig selvforklarende, og alle moduler og funksjoner skal beskrives i dokumentasjonen. 3.1.3 Alle skjema skal følge ELMER standarden. http://standard.difi.no/forvaltningsstandarder/a nvendelsesomraade/naeringslivskjema-paaoffentlige-nettsider Løsningen skal være mest mulig selvforklarende. Det tilrettelegges online hjelpesystem (for eksempel WinCHM,lisenskostnad ca. $1300) for innlegging av informasjon. Oppdragsgiver er ansvarlig for innholdet. Tilstrekkelig brukerdokumentasjon for administrator leveres elektronisk. Det leveres oversiktsskisse for drift av løsningen. Det forutsettes at driftspersonell har basiskunnskap om standardsoftware som må installeres. Løsningen skal være mest mulig selvforklarende for sluttbruker. Det tilrettelegges online hjelpesystem (for eksempel WinCHM) for innlegging av informasjon. Oppdragsgiver er ansvarlig for innholdet. Det lages oversiktskart over teknisk løsning og kort beskrivelse av programvare og på hvilke plattformer en kan sette opp løsningen. Dokumentasjonen skal være tilstrekkelig til å kunne sette opp løsningen på egen server. Ved hjelp av standard hjelpesystem skal det være mulig å legge inn beskrivelse av moduler og funksjoner så langt oppdragsgiver finner det formålstjenlig. Oppdragsgiver er ansvarlig for innholdet. Drupal i kombinasjon med CKAN API vil være vårt verktøy for utvikling av skjema. Så langt ikke verktøyet setter begrensninger, vil vi definere 13
http://standard.difi.no/forvaltningsstandarder/s tandard/elmer/elmer-v2 3.1.4 All dokumentasjon som utarbeides for løsningen skal leveres i elektronisk form. 3.1.5 Driftsdokumentasjon skal være så presis og detaljert at personer som ikke har deltatt i utviklingen har mulighet til å drifte systemet. 3.2 Kildekode og rettigheter 3.2.1 Kildekoden skal leveres med historikk i form av versjonskontroll, og det skal være mulig for tredjepart å bidra med nye funksjoner til kildekoden. Oppgi hvilket versjonskontrollsystem dere vil levere kildekoden i. 3.2.2 Spesialutviklet kildekode skal dokumenteres grundig. Det skal være mulig for andre å bruke kildekoden til å sette opp tilsvarende nettsteder. Dokumentasjonsspråket er engelsk. skjema etter ELMER standard. Skjema for internt bruk, slik som administrasjon av løsningen vil kunne avvike. Det forutsettes at driftspersonell har basiskunnskap om standardsoftware som må installeres. Versjonshåndtering vil bli ivaretatt ved hjelp av trac/svn. Dokumentasjon av spesialutviklet kode gjøres i hovedsak som kommentarer i koden. Det lages en oversikt over spesialutviklet moduler. 14
4. Test Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 4.1 Leverandøren skal lage en testplan for følgende Det settes opp testplan i nært tester: samarbeid og aktiv deltakelse 1) funksjonstest av kunden. Planen inneholder tidspunkt for når testene skal 2) robusthetstest utføres og hvilke tester som er 3) integrasjonstest hensiktsmessige. Foruten 4) volum-, kapasitets- og svartidstest funksjonstest(enhetstest) og 5) gjennomgang av all dokumentasjon nettlesertest, er det kundens 6) installasjonstest ansvar å sette opp testkriteria 7) test av driftsprosedyrer, herunder og gjennomføre testen i sitt driftsmiljø. sikkerhetskopiering Se også Asplan Viak Internet 8) nettlesertest sin standard for test av internettløsninger beskrevet i Bilag 6. 4.2 Leverandør må ha egnede prosedyrer for endringshåndtering. Hvem og hvordan besluttes endringer? Beskriv eventuelle prosesser og prosedyrer rundt dette. Se utdrag fra Asplan Viak Internet sin standard for utviklingsprosedyrer beskrevet i Bilag 6 15
5. Fremdriftsplan Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 5.1 Leverandøren bes fremlegge en detaljert fremdriftsplan for utvikling, testing, installasjon, pilot og produksjonsstart. Vi forutsetter i vår fremdriftsplan at kontraktstildeling skjer innen uke 40. Dersom prosjektet igangsettes senere vil vi måtte forskyve tidsplanen tilsvarende. Figur 4: Gantt diagram 16
Figur 5: Arbeidsflytdiagram for prosjektgjennomføring Tabell 1: Fremdriftsplan med aktivitetsbeskrivelse for hovedaktiviteter Aktiviteter data.norge.no Varighet Nr Hovedaktivitet Inneholder Timer Sum Frå Til Fase 1 Initiering 01.11.2010 01.11.2010 Kontrakt 8 Oppstartmøte 8 Installasjon 02.11.2010 03.11.2010 17
Installasjon av tilbudt systemløsning i Asplan Viak Internet as sitt utviklingsmiljø. 16 Detaljspesifikasjon 03.11.2010 12.11.2010 Datamodell 16 Design 32 Definisjon og spesifikasjon av funksjonalitet for fase1 40 Utvikling fase1 Implementering av fase1 funksjonalitet. 120 15.11.2010 03.12.2010 Funksjonstest fase1 Funksjonstest 32 06.12.2010 08.12.2010 Dokumentasjon Begrenset bruker/systemdokumentasjon for administrator 4 09.12.2010 10.12.2010 Betatest fase1 Feilhåndtering 16 13.12.2010 14.01.2011 292 Fase 2 Revisjon fase1/ tilbakemeldinger 17.01.2011 18.01.2011 Vurdering av tilbakemeldinger 4 Revisjonsmøte 4 Beslutninger 4 Detaljspesifikasjon 18.01.2011 28.01.2011 Endringer i funksjonalitet 24 Endringer design 16 Resterende funksjonalitet som inngår i tilbudet. 24 Utvikling fase2 31.01.2011 11.02.2011 Implementering av endringer og ny fase2 funksjonalitet. 56 Funksjonstest fase2 14.02.2011 15.02.2011 Funksjonstest fase2 16 Nettlesertest 8 Dokumentasjon 14.02.2011 16.02.2011 18
Betatest fase2 Bruker/systemdokumentasjon for administrator Installasjon av og maler for online hjelpesystem for innlegging av brukerveiledning for administrator, innholdsleverandører og sluttbrukere. 8 Feilhåndtering 16 16.02.2011 04.03.2011 8 Fase 3 Revisjon fase2/ tilbakemeldinger 07.03.2011 08.03.2011 Vurdering av tilbakemeldinger 4 Revisjonsmøte 4 Beslutninger 4 Detaljspesifikasjon 10.03.2011 11.03.2011 Endringer i funksjonalitet 4 Endringer design 4 188 Utvikling fase3 11.03.2011 11.03.2011 Implementering av endringer. 8 Funksjonstest fase3 14.03.2011 14.03.2011 Funksjonstest fase3 4 Dokumentasjon 14.03.2011 18.03.2011 Teknisk dokumentasjon (programvare, versjoner, plattform, osv.) 8 Revisjon av øvrig dokumentasjon. 16 Betatest fase3 Feilhåndtering 8 15.03.2011 25.03.2011 Installasjon i kundens driftsmiljø 30.03.2011 30.03.2011 Forutsetter server med basissoftware tilgjengelig. Installasjon av applikasjon. 8 Akseptansetest 04.04.2011 06.04.2011 Installasjonstest 4 Integrasjonstest 4 Robusthetstest 4 19
Volum-, kapasitets- og svartidstest 4 Gjennomgang av all dokumentasjon 8 Test av driftsprosedyrer, herunder sikkerhetskopiering 4 Godkjenning 4 08.04.2011 08.04.2011 104 SUM TIMER 584 20