Innhold Innhold... 1 Innledning... 2 Systemdiagram... 3 Use case definisjoner... 5 1. Funksjonelle krav til løsning... 6 2. Skisse til løsning... 14 3. Generelt... 16 4. Test... 19 5. Fremdriftsplan... 21
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 3
å 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. Som relasjonsdatabase i løsningen er valgt PostgreSQL i stedet for MySql, da vi fra utviklingsgruppen for CKAN er anbefalt dette. Avinet har valgt å inkludere Mapserver i tilbudet for å muliggjøre søk og visualisering i kart for geografiske eller geo-relaterte data. Det er satt av 20 timer til dette arbeidet i prosjektet og integrasjonen er basert på bruk av javascript biblioteket OpenLayers som leser bakgrunnskart fra Statens Kartverk s tile-cache tjeneste basert på den åpne standardenwms-c og overlagrer disse med dekningsrektangler, polygoner, linjer eller punkt for åpne data som er tilgjengelige som WMS, WFS, WCS, GeoRSS eller andre kjente standardformater for geografisk informasjon. Lucene søkeindex kan benyttes, men ikke nødvendig da det ikke er snakk om de store datamengdene. Default er at også søkeindex baseres på PostgreSql. 4
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 5
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. Det er ikke mulig å utføre en sikker validering av en fil bare ved å teste endingen på filnavnet da en fil naturligvis kan gis et vilkårlig navn uavhengig av innholdet. Dette er imidlertid den vanligste måten å utføre validering på ved opplasting av filer. I data.norge.no er det tre typer filer som kan vere aktuelle å laste opp: dokumenter til filarkiv/publisering i portal, filvedlegg til kommentarer og eksempeldata på XML/JSON format for de enkelte datasett. Om det fastsettes hvilke filtyper som skal tillates er det mulig å gjøre en sekundær test ved å lese en bytesekvens fra begynnelsen av hver opplastet fil og sjekke om denne inneholder signaturen til de ulike filformatene. På denne måten kan for eksempel ODT, PDF og XML dokumenter lett identifiseres. 1.1.5 Løsningen skal utformes i tråd med statens IKT- 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. 6
arkitekturprinsipper: 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. 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 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 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. 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. 7
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 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. I utgangspunktet foreslår vi å etablere et enkelt temahierarki som siden kan bygges ut som en folksonomi i portalen. På denne måten kan brukerne av tjenesten bidra til å etablere underinndelinger og relasjoner mellom konseptene i vokabularet. 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. 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 8
1.2.9 Løsningen skal ha en rutine for utfasing av beskrivelser av spesifikke datasett. 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. 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 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 9
automatisk av data.norge.no. 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 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. 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 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. Løsningen bygger på Drupal sitt rammeverk der det finnes et utall av muligheter for visuell utforming av nettstedet. Utformingen vil måtte skje i nært samarbeide med kunde og ved aktiv bruk av prototype verktøy. Leverandør og kunde må i fellesskap finne fram til beste og mest hensiktsmessige løsning, gitt de forutsetninger en legger til grunn, der bruk av Drupal og de krav ELMER II standarden setter er sentrale. I 10
utgangspunktet ønsker vi å benytte standard Drupal - maler der disse ikke kommer i konflikt med uttalte ønsker i kravspesifikasjonen. Elementer som benyttes ved design av web-siden, som logo,bilder, knapper og lignende er kundens ansvar å framskaffe. AVINET har lang erfaring i utforming av grensesnitt i samsvar med standarder for brukervennlighet og universell utforming. Vårt fokus er på oversiktlig og funksjonell design for sluttbrukere og innholdsprodusenter. I tilfeller hvor våre kunder ønsker mer særpregede eller eksperimentelle design, har vi ett nært samarbeid med designbyrået Gasta. Byrået produserer innovative designforslag som kunden kan velge mellom før vi implementerer dem i henhold til ovenfor nevnte standarder. Dette tilbudet inkluderer ca. 20 t bistand fra Gasta for utforming av konseptuelle design for data.norge.no, og som kan brukes som et utgangspunkt for tilpassing av den endelige løsningen. 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. Drupal har alle de vanlige mulighetene for en blog men tillater i tillegg avansert arbeidsflyt for publisering av redaksjonelt innhold og integrasjon med tredjepartsløsninger. Vi har derfor valgt å benytte denne platformen for å oppnå en mest mulig enhetlig systemløsning. Funksjoner som støttes er mellom annet: Bruker- og rollehåndtering som tillater redaktører og forfattere Oppretting av gjesteblogger Skriving av artikler for dynamisk informasjon 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. 11
Skriving av sider for statisk informasjon (kunn redaktører) Valgfri godkjenning av artikler fra vanlige forfattere Valgfritt (pr artikkel/side) brukerkommentarer Moderasjon av kommentarer Syndikering og konsumering av RSS-feeds, Atom-feeds etc Sosiale bokmerker del.icio.us etc Integrasjon med sosiale medier: Twitter, Facebook, LinkedIn All funksjonalitet som er tilgjengelig i den eksisterende blog-løsningen på nettstedet data.norge.no vil vere tilgjengelig i den nye. Det er fleksibelt å tilpasse design. 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. For opplastede eksempelfiler i kjente filformater som XML/JSON/CSV vil brukeren valgfritt kunne se en eksempelvisning av dataene på skjermen som kildekode med syntax-highlighting ved hjelp av GeSHi, som en trestruktur ved hjelp av en PHP Tree Menu eller som en tabell ved hjelp av jquery. For eventuelle eksempelfiler som ikke lar seg visualisere uten plug-in verktøy vil disse la seg laste ned for brukere som ønsker dette. 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. 12
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 13
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. PostgreSQL: PostgreSQL er en mye brukt, åpen kildekodebasert relasjonsdatabase. Databasen er lisensiert under sin egen PostgreSql License. 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. 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 Mapserver: Er en åpen kildekode basert plattform for å publisere romlige data og interaktive kartløsninger på web. Er lisensiert under en MIT-Style license. Alle komponentene som inngår i vår løsning er under åpen kildekode paraplyen. Det er ikke noe annet 14
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. 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 15
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 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. Vi ser det som naturlig at innholdet i hjelpesystemet d.v.s. all tekst angående utfylling eller forståelse av skjema og datainnhold,beskrives av kunden. Dette for å sikre riktig informasjon til rett brukergruppe. Tekst/informasjon kan registreres direkte i hjelpesystemet. 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. 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å 16
3.1.3 Alle skjema skal følge ELMER standarden. http://standard.difi.no/forvaltningsstandarder/a nvendelsesomraade/naeringslivskjema-paaoffentlige-nettsider 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. Versioneringssystemet Subversion (SVN) er lisensiert som CollabNet/Tigris.org Apache.style. 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. 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. Alle skjema vil bli inndelt etter ELMER II standard med navigasjonsområde, informasjonsområde og utfyllingsområde. Øvrig automatikk og validering tas inn i detaljspesifiseringsfasen dersom det er hensiktsmessig. Bruk av hjelpetekst er beskrevet i kapittel 3.1.1. Skjema for internt bruk, slik som administrasjon av løsningen vil kunne avvike ELMER II standarden, da disse vil være en del av CKAN. 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. Asplan Viak Internet as vil gjerne gjennomføre prosjektet som et open source prosjekt om kunde også synes dette er interessant. Dette vil heve kvaliteten på koden og spesielt på dokumentasjonen. Dette vil stille FAD fritt til å la hvem som helst foreta videreutvikling mot løsningen. 17
Vi vil også foreslå at kunden deltar på en studietur av inntil tre dagers varighet sammen med prosjektmedlemmer fra Avinet for å se på tilsvarende løsninger som utvikles parallelt andre steder i Europa. Prosjekt som kan være av spesiell interesse er data.gov.uk i London og/eller Piemonte s løsning dati.regione.piemonte.it/. Deltagelse på denne studieturen vil være gratis, men reise- og oppholdsutgifter dekkes av den enkelte deltager. 18
4. Test Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 4.1 Leverandøren skal lage en testplan for følgende tester: 1) funksjonstest 2) robusthetstest 3) integrasjonstest 4) volum-, kapasitets- og svartidstest 5) gjennomgang av all dokumentasjon 6) installasjonstest 7) test av driftsprosedyrer, herunder sikkerhetskopiering 8) nettlesertest Følgende testplan foreslås: Testplan fase1: 1. Løsningen utvikles basert på detaljspesifikasjoner og prototyper fase1, og modultester foretas fortløpende. 2. Ved utført fase1-utvikling, overføres fase 1 til egen testserver hos leverandør. 3. Det foretas funksjonstest fase1 før den legges ut i pilot. 4. Kunde/brukere får tilgang til betaversjonen av fase1 applikasjonen for utprøving og test. 5. Kunden melder tilbake eventuelle feil/mangler i forhold til detaljspesifikasjon fase 1 Det settes opp testplan i nært samarbeid og aktiv deltakelse av kunden. Planen inneholder tidspunkt for når testene skal utføres og hvilke tester som er hensiktsmessige. Foruten funksjonstest(enhetstest),integ rasjonstest og nettlesertest, er det hensiktsmessig at kunden har ansvar for å sette opp testkriteria for akseptansetest og gjennomføre testen i sitt driftsmiljø. Se også Asplan Viak Internet sin standard for test av internettløsninger beskrevet i Bilag 6. Løsningen er foreslått utviklet i tre faser, der løsningen installeres og testes i leverandørens utviklingsmiljø i samarbeid med kunden. Først etter funksjonstest i fase3 overføres systemet til kundens driftsmiljø. Testplan fase2: 1. Løsningen utvikles basert på endringsønsker, detaljspesifikasjoner og prototyper, og modultester foretas fortløpende. 2. Ved utført fase2-utvikling, overføres endringer i forhold til fase 1 til testserver hos leverandør. 3. Det foretas funksjonstest fase2 før den legges ut i pilot. 4. Kunde/brukere får tilgang til betaversjonen av fase2 applikasjonen for utprøving og test. 5. Kunden melder tilbake eventuelle feil/mangler i forhold til detaljspesifikasjon fase 2 Testplan fase3: 1. Løsningen endres basert på resterende godkjente endringsønsker i.h.t. kravspesifikasjon og tilbud, og modultester foretas fortløpende. 2. Ved utført fase3-utvikling, overføres endringer i forhold til fase 2 til testserver hos leverandør. 3. Det foretas funksjonstest fase3 før den 19
legges ut i pilot. 4. Kunde/brukere får tilgang til betaversjonen av fase3 applikasjonen for utprøving og test. 5. Kunden melder tilbake eventuelle feil/mangler og godkjenner fase3 pilot. 6. Løsningen overføres til kundens driftsmiljø for gjennomføring av akseptansetest. Kunden er ansvarlig for testplan og gjennomføring av testene,leverandøren bistår teknisk. a. Det gjennomføres funksjonstest i kundens driftsmiljø. b. Det gjennomføres robusthetstest i kundens driftsmiljø. c. Kunden gjennomfører integrasjonstest i kundens driftsmiljø. d. Det gjennomføres volum, kapasitets og svartidstest i kundens driftsmiljø. e. Dokumentasjon gjennomgås og godkjennes. f. Det gjennomføres test av driftsprosedyrer i kundens driftsmiljø. 4.2 Leverandør må ha egnede prosedyrer for endringshåndtering. Hvem og hvordan besluttes endringer? Beskriv eventuelle prosesser og prosedyrer rundt dette. Vi vil benytte Trac sitt Ticket system til håndtering av feil, oppgaver og endringsønsker. Trac kan også brukes til videre prosjektstyring med roadmap, milestones og timeline samt til dokumentasjon (Wiki-funksjonlitet). Trac kan vere web-klient til Subversion, er utviklet i Phyton og lisensiert under modified BSD. Se utdrag fra Asplan Viak Internet sin standard for utviklingsprosedyrer beskrevet i Bilag 6 20
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 21
Figur 5: Arbeidsflytdiagram for prosjektgjennomføring 22
Tabell 1: Fremdriftsplan med aktivitetsbeskrivelse for hovedaktiviteter. Planen er forskyvd 2 uker. Aktiviteter data.norge.no Varighet Nr Hovedaktivitet Inneholder Timer Sum Frå Til Fase 1 Initiering 18.10.2010 18.10.2010 Kontrakt 8 Oppstartmøte 8 Installasjon 19.10.2010 20.10.2010 Installasjon av tilbudt systemløsning i Asplan Viak Internet as sitt utviklingsmiljø. 16 Detaljspesifikasjon 20.10.2010 29.10.2010 Datamodell 16 Design 32 Definisjon og spesifikasjon av funksjonalitet for fase1 40 Utvikling fase1 Implementering av fase1 funksjonalitet. 120 01.11.2010 19.11.2010 Funksjonstest fase1 Funksjonstest 32 22.11.2010 24.11.2010 Dokumentasjon Begrenset bruker/systemdokumentasjon for administrator 4 25.11.2010 26.11.2010 Betatest fase1 Feilhåndtering 16 29.11.2010 31.12.2010 Fase 2 Revisjon fase1/ tilbakemeldinger 03.01.2011 04.01.2011 Vurdering av tilbakemeldinger 4 Revisjonsmøte 4 Beslutninger 4 Detaljspesifikasjon 04.01.2011 14.01.2011 Endringer i funksjonalitet 24 Endringer design 16 Resterende funksjonalitet som inngår i tilbudet. 24 292 Utvikling fase2 17.01.2011 28.01.2011 Implementering av endringer og ny fase2 funksjonalitet. 56 Funksjonstest fase2 31.01.2011 01.02.2011 Funksjonstest fase2 16 Nettlesertest 8 23
Fase 3 Dokumentasjon 31.01.2011 02.02.2011 Bruker/system-dokumentasjon for administrator 8 Installasjon av og maler for online hjelpesystem for innlegging av brukerveiledning for administrator, innholdsleverandører og sluttbrukere. Betatest fase2 Feilhåndtering 16 02.02.2011 18.02.2011 Revisjon fase2/ tilbakemeldinger 21.02.2011 22.02.2011 Vurdering av tilbakemeldinger 4 Revisjonsmøte 4 Beslutninger 4 Detaljspesifikasjon 24.02.2011 25.02.2011 Endringer i funksjonalitet 4 Endringer design 4 8 188 Utvikling fase3 25.02.2011 25.02.2011 Implementering av endringer. 8 Funksjonstest fase3 28.02.2011 28.02.2011 Funksjonstest fase3 4 Dokumentasjon 28.02.2011 04.03.2011 Teknisk dokumentasjon (programvare, versjoner, plattform, osv.) 8 Revisjon av øvrig dokumentasjon. 16 Betatest fase3 Feilhåndtering 8 01.03.2011 11.03.2011 Installasjon i kundens driftsmiljø 16.03.2011 16.03.2011 Forutsetter server med basissoftware tilgjengelig. Installasjon av applikasjon. 8 Akseptansetest 21.03.2011 23.03.2011 Installasjonstest 4 Integrasjonstest 4 Robusthetstest 4 Volum-, kapasitets- og svartidstest 4 Gjennomgang av all dokumentasjon 8 Test av driftsprosedyrer, herunder sikkerhetskopiering 4 Godkjenning 4 25.03.2011 25.03.2011 104 SUM TIMER 584 24
25