Løsningen skal ha høy sikkerhet og lav sårbarhet både i sin tekniske og organisatoriske struktur.

Transkript

1 edlegg 1 data.norge.no spesifikasjon for en ny allmenn tjeneste for publisering av informasjon om offentlige datasett som er gjort tilgjengelige i maskinlesbare formater. Dette er en foreløpig skisse til kravspesifikasjonen. Anbudet skal omfatte organisatoriske, tekniske, økonomiske forslag for utvikling og drift av løsning. Kunde og leverandør skal samarbeide om organiseringen av løsningen på kunde (eier)-siden, slik at data.norge.no er sikret kvalitet tilbake til data-produsentene, som ligger til grunn for tjenesten. Leverandørens tekniske løsning skal harmoniseres med overordnet organisering. Foruten teknisk løsning, skal leverandør beskrive sin organisering og krav/ønsker til organisering hos kunde. Pris skal reflekteres på komponenter, med opsjoner for kvalitetsalternativer, samt for organisering og fremdrift. Driftsforslag skal harmonisere med den organisering som data.norge.no har valgt, og leverandør skal beskrive de støttesystemer som skal sikre datafangst og eventuelle konverteringsløsninger frem til bukerportalen. Den tekniske løsning skal være modulær og åpen, på en slik måte at fremtidige endringer kan skje på en smidig måte med lavest mulige kostnader. Proprietære løsninger, med spesiell leverandør avhengighet eller avhengighet til personer, vil bli forsøkt unngått. Løsningen skal ha høy sikkerhet og lav sårbarhet både i sin tekniske og organisatoriske struktur. Koder og begreper bligatorisk - algfritt 1. Funksjonelle krav til løsning (/) 1.1 Generelle krav Løsningen skal bestå av en nettbasert publiseringsløsning (CMS) som skal ha støtte for: Blogg (Kommentar: Det bør vurderes om dette kan leveres/ integreres ved hjelp av et spesialisert blogg verktøy som f.eks. WordPress) ppretting og vedlikehold av egne datar, spesifikt en data for lagring og presentasjon av metadata relatert til et offentlig tilgjengelig datasett Støtte for synkronisering mot ekstern datakilde for datar

2 1.1.2 Det skal være mulig å publisere dokumenter og andre filer på nettstedet. (Kommentar: Bør støtte opplasting av multiple filer.) Løsningen skal støtte publisering av informasjon på flere språk, herunder rammer for levende bilder for tegnspråk på alle sider De implementerte språkene skal kunne knyttes direkte til nettadressene data.norge.no, data.noreg.no, data.norga.no og data.norway.no Løsningen skal følge referansekatalogens krav til IT-standarder der det er relevant. ( [Meningsløst krav hvis man ikke er konkret ift. hvor det er relevant. Er bedre å være konkret under hvert spesifikke punkt i kravspek en og vise til konkrete standarder som må oppfylles] erktøyet skal utformes i tråd med statens IKT- arkitekturprinsipper: Løsningen skal tilfredsstille kravene i W3C WAI WCAG 2.0 AA (alle kriterier merket A og AA i standarden - WAI/WCAG20/quickref/verview.php). ed leveranse skal dette dokumenteres. 1.2 Administrasjon av nettstedet Innholdet på nettstedet skal kunne administreres gjennom et webbasert grensesnitt. Det må være mulig å registrere minimum n antall unike brukere i dette grensesnittet, der n er lik summen av antall kommunale, fylkeskommunale, statlige og andre virksomheter. [Bedre å angi et konkret tall i stedet for å la leverandør sitte og regne ut dette selv] (Kommentar: Det bør også her skrives hvordan brukerregistrering skal foregå. F.eks. skal det være mulig å registrere bruker i bulk?) Publiseringsløsningen må kunne håndtere ulike roller. En rolle skal kunne styre tilgang til et utvalgt sett av innhold i løsningen. En bruker skal kunne knyttes til en eller flere roller. (Kommentar: spesifikasjonen her burde vært skrevet ved hjelp av bruker historier / user stories) Det webbaserte grensesnittet for administrasjon av nettstedet skal være en integrert del av det offentlige nettstedet Administrasjon av nettstedet skal krypteres med SSL Innlogging på nettstedet skal kunne skje med allerede etablerte autorisasjonsløsninger. ppgi hvilke autorisasjonsløsninger som kan tilbys. (Kommentar: Auth, penid? I så fall burde det være muligheter for integrasjon mot ganske mange tjenester som f.eks. Google Mail og Facebook) Tilbudet må omfatte eventuelle andre sikkerhetsmekanismer som anbefales. Hvis noen tilbys, angi disse Det må være mulig å administrere de registrerte brukerne på en effektiv og hensiktsmessig måte. Det må også være mulig å sende ut meldinger til deler av eller alle brukerne. (Kommentar: Hvordan man skal sende ut meldinger må spesifiseres nærmere. Det er alt for generelt hvordan det er beskrevet her. Man bør se på standard løsninger for utsendelse av meldinger og ikke finne opp hjulet på nytt) Innhold på nettstedet skal kunne tildeles spesifikke brukere, som så har rett til å endre disse dataene. Brukere må kunne hindres fra å redigere annet innhold. (Kommentar: Burde ikke størst mulig del av nettsidene være åpent tilgejngelig for editering. Data.norge.no bør være et nettsamfunn og arbeidet med vedlikehold burde gjøres av

3 samfunnet) Det må være enkelt å skille mellom innhold som er eid av en bruker, og poster som ikke er eid og altså forvaltes av administrator Det skal være mulig å slette innhold permanent Databasen skal tilfredsstille kravene til metadata beskrevet i [hva er gode krav til metadata her?] Dette innebærer blant annet at hver post skal inneholde feltene navn, beskrivelse, eier, url, forvaltningsnivå, format, pris, vilkår. ppgi hvilket merarbeid nye felter, eller endring av eksisterende felter, vil medføre Alle postene skal ha en unik permanent URI. Denne nøkkelen bør være enkel nok til å kunne bruke i en URL. URIen må være lesbar, og være utformet slik at man skal kunne tolke hva den representerer. Spesifiser hvordan dere ser for dere at en slik nøkkel kan være. [Kommentar fra Kjetil Kjernsmo: det er ikke klart hva man mener med URI vs. URL her] Det skal være mulig å kategorisere dataene på flere måter, f.eks. etter eier, forvaltningsnivå, eiers geografiske plassering, data og vilkår for bruk Det skal være mulig å koble kontaktinformasjon for registrerte brukere med deres tildelte datasett Det skal være mulig å velge å ha en knapp for tilbakemelding på hvert datasett. Denne knappen skal bruke kontaktinformasjonen til dataeier/ registrerte brukere som alt er registrert, og gjøre det enkelt å melde fra om feil og mangler. (Kommentar: Kan ikke tilbakemeldinger være offentlige?) Det skal være mulig å følge en RSS-feed med nyheter om datasett for ett eller flere datasett. Dette skal kunne hentes hos dataeier Det må være mulig å lenke hver post sammen med andre eksterne og interne ressurser, så som lenker til applikasjoner som bygger på dataene, lenker til kildekodebibliotek man kan bruke til å analysere dataene, og dokumenter Databasen skal være versjonert. Det skal være mulig å ha flere aktive versjoner samtidig. Det skal også være mulig å hente frem gamle, deaktiverte versjoner av beskrivelsene. Spesifiser hvilken versjonering dere mener vil være mest hensiktsmessig for denne n data. [ersjonering av database er feil å si. Her dreier det seg om versjonering og historikkhåndtering av innholdselementer i løsningen] Det må være mulig å datostemple innhold etter når det sist ble oppdatert. Dataeier må også ha mulighet til å registrere når og/eller hvor ofte man skal forvente at datasettet oppdateres Administrator skal ha enkel tilgang til detaljert statistikk over bruken av nettstedet, og kunne ta ut rapporter om f.eks. mest benyttede søkeord, mest populære datasett, etc. (Kommentar: Bør ikke også dette være offentlig?) Brukere skal ha tilgang til statistikk over hvor mange ganger innholdet de eier har blitt vist. 1.3 til nettstedet Nettstedet 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 datakilder, blogg og andre dokumenter og ressurser Aktuell driftsinformasjon Innlogging for informasjonsleverandører og administratorer

4 1.3.2 Det grafiske designet av nettstedet skal være åpent og innbydende. Det skal tilfredsstille regjeringens krav til universell utforming[hvordan forholder dette seg til 1.1.7?], og være moderne i en slik grad at det kan sies å bli omfattet av et diffust begrep som Web 2.0-design. [Er dette en så vissen formulering[] at den bør tas ut?][det kan stå, man forstår i hvilke baner de tenker][umulig krav å måle endelig løsning mot, bør tas ut av en kravspesifikasjon][helt enig, denne uttalelsen hører ikke hjemme i et formelt dokument] Det skal være mulig å søke etter alle dataene som ligger i databasen.(kommentar: gså i offentlige søketjenester som f.eks. Google og Bing) Sluttbruker skal kunne foreta fritekstsøk på alle tekstfelt, inkludert avanserte søk med logiske operatorer. ed stavefeil bør søket gi treff på tilnærmet likt innhold. Det skal også være mulig å maskere enkelttegn ved søk.[hva menes med å maskere enkelttegn?] Systemet har funksjoner som forhindrer at man setter i gang tidkr evende søk.[dette må spesifiseres nærmere] Det skal være mulig å avbryte et søk.(kommentar: Hva menes med dette? Et søk vil jo alltids kunne avbryes ved å trykke Back?) Løsningen skal støtte eksport av søkeresultat til lesbare format (pdf) og maskinlesbare formater (se kapittel 1.5) Det skal være mulig å få opp statistikk over hvor mange datasett som er registrert, hvor!!!!!!!!!!! mange som er registrert på ulike eier, hvor mange datasett som er oppdatert, etc Det skal være mulig å karakterisere noen datasett som populære eller hotte. Disse skal kunne profileres gjennom egne bokser på fremsiden og/eller i sidekolonner. 1.4 til bloggen Det skal være mulig å importere alt innhold fra den nåværende bloggen på data.norge.no inn i den nye bloggen Bloggen skal i all hovedsak ha den samme funksjonaliteten som den nåværende bloggen Bloggen skal være basert på en utbredt bloggteknologi med et solid utviklermiljø og mange ferdigtestede utvidelsesmoduler Bloggen skal støtte publisering vha. AtomAPI eller liknende. 1.5 knyttet til tilgjengelighet av rådata Dataene på nettstedet skal kunne lastes ned i maskinlesbare formater. Dette skal kunne gjøres både samlet og i deler gjenom et programmeringsgrensesnitt (API) Informasjonen på nettstedet skal være tilgjengelig i formatene xml, json og csv. Spesifiser hvilke formater dere foreslår, og begrunn forslaget. Kommentar: Det er viktig at tjensten kan syndikeres. Det bør derfor være mulig å hente innholdet fra bloggen i et maskinlesbart persistent format v.h.a. REST kall) Der det er praktisk mulig, skal dataene publiseres ved hjelp av linkede data-prinsippene. Alle ting i databasen skal ha en HTTP URI som representerer tingen, og når denne derefereres, skal man vises ved en HTTP 303 Redirect til rådata om URIen. Rådataene skal da finnes på minst formatene RDF/XML og Turtle og det skal kunne brukes HTTP Content Negotiation for å velge format. (Kommentar: Bra prinsipp. Bør også være mulig å overstyre Content Negotitation v.h.a. query

5 parametre?) Det skal være mulig å kjøre spørringer mot linkede data ved hjelp av spørrespråket SPARQL gjennom et HTTP SPARQL Endpoint. Det skal også være mulig å redigere data, ved bruk av SPARQL 1.1 HTTP Bindings og relevante sikkerhetsmekanismer, se punkt Dataene skal linkes til sentrale, eksisterende noder blant Linked pen Data Det skal legges til rette for å la brukere legge til linker til andre datasett i Linked pen Data. 2. Skisse til løsning Beskriv else av krav 2.1 Leverandøren må gi en skisse til løsningsforslag. Løsningsforslaget skal minst omfatte: En modell for løsningen (blogg og nettsted) som synliggjør hvilke funksjoner som inngår i løsningen og hvordan disse samvirker En spesifikasjon av hvilke programvarekomponenter blogg, nettsted og database baseres på 2.2 Leverandøren bes angi hva som inngår av programvarelisenser for f.eks. databaser, og server-programvare for at blogg, nettsted og database skal fungere. 2.3 ppgi hvilke deler av løsningen som baserer seg på hyllevare, egenutviklete standardløsninger, og skreddersøm. 2.4 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.5 Leverandøren bes beskrive ansvarsforhold, ressurser og rutiner for utvikling, feilretting, kvalitetskontroll og support for tilbudt tredjeparts programvare. 2.6 ppgi i hvilken grad og på hvilke betingelser løsningen kan tas i bruk av andre offentlige virksomheter som ønsker å etablere tilsvarende tjenester. (/) 3. Generelt 3.1 Dokumentasjon Følgende dokumentasjon skal tilpasses oppdragsgiver og utarbeides: Brukerdokumentasjon for innholdsleverand ørene Bruker/system-dokumentasjon for administrator (/)

6 Driftsdokumentasjon for leverandør av tjenesten Brukerveiledning for sluttbruker, tilgjengelig på nettstedet Teknisk dokumentasjon (programvare, versjoner, plattform, osv.) Systemet i seg selv skal være mest mulig selvforklarende, men alle moduler og funksjoner skal beskrives i dokumentasjonen Det må være elektronisk hjelpefunksjon i programmet, og forklarende tekst når du peker på et felt. [Bør det presiseres her at alle skjema skal følge Elmer-standarden?] naeringslivskjema-paa-offentlige-nettsider All dokumentasjon som utarbeides for løsningen skal leveres i elektronisk form Leverandøren er ansvarlig for at dokumentasjonen til enhver tid samsvarer med aktuell versjon av systemet Leverandøren må angi hva slags brukerdokumentasjon som inngår, hvilke format den foreligger i og hvordan dokumentasjonen som er spesifikk for løsningen skal utvikles Driftsdokumentasjon skal være så konsis at personer som ikke har deltatt i utviklingen har mulighet til å drifte systemet For applikasjonen skal det utarbeides driftsdokumentasjon med oversikt over meldinger for alle feilutganger i systemet, og med anbefaling om aksjon. Hver feilutgang skal ha sin unike melding Leverandøren må angi hva slags systemdokumentasjon som inngår, format den foreligger i, og hvordan dokumentasjon som er spesifikk for løsningen skal utvikles. 3.2 Kildekode og rettigheter Spesialutviklet kildekode til bloggen, databasen og nettstedet tilhører oppdragsgiver. ppdragsgiver står fritt til å utvikle eller forandre på programvaren, enten med hjelp av leverandør eller med hjelp fra andre Spesialutviklet kildekode til bloggen, databasen og nettstedet skal publiseres som åpen kildekode. Angi hvilken lisens som skal brukes. Kommentar: Det burde være obligatorisk at løsningen er basert på åpen kildekode da dette ville gi en god signal effekt på et nettsted som dette Spesialutviklet kildekode til bloggen, databasen og nettstedet skal dokumenteres grundig. Det skal være mulig for andre å bruke kildekoden til å sette opp tilsvarende nettsteder. Dokumentasjonsspr åket er engelsk. 3.3 Utvidelsesmuligheter Leverandøren må beskrive hvordan løsningen på et senere tidspunkt kan utvides til å være en tjeneste der det for små dataeiere som ikke nødvendigvis har råd til å sette opp egne servere vil være mulig å lagre selve dataene på en server som tilhører nettstedet data.norge.no. 4. Test (/)

7 4.1 Leverandøren forventes å samarbeide med oppdragsgiver om en plan om testing. Det forventes at personell fra leverandøren er tilgjengelig under testfasen. I testplanen skal det fremgå hvordan henholdsvis leverandør og oppdragsgiver skal delta. Beskriv hvordan leverandøren forholder seg til dette. 4.2 Leverandøren må oppgi hvordan systemet kan testes (simulert) for ulike antall brukere. 4.3 Leverandør må ha egnede prosedyrer for endringshåndtering. Hvem og hvordan besluttes endringer? Beskriv eventuelle prosesser og prosedyrer rundt dette. 5. Teknisk infrastruktur og tekniske løsninger 5.1 ppgi om leverandøren tilbyr driften selv eller via tredjepart. 5.2 Leverandøren bes med utgangspunkt i den foreligg ende informasjon, samt krav til belastning og oppetid (se videre i spesifikasjonen), om å beskrive sitt løsningsforslag på et overordnet nivå. Løsningsforslaget skal omfatte: (/) En arkitekturskisse av driftsløsningen som viser hvilke arkitekturkomponenter som inngår i løsningen, og hvordan disse samvirker. Skissen skal vise brannmurer, nettverkstopologi, DMZ, og reserveløsning for å garantere ønsket driftskvalitet og driftskapasitet. 5.3 Leverandøren bes beskrive løsningens åpenhet og fleksibilitet med henhold til bytte av driftsleverandør. 5.4 Leverandøren bes beskrive løsningens utbredelse i markedet og tilgang på kompetanse rundt løsningen i markedet. Dersom det er noen deler av løsningen som avviker i forhold til utbredelse og kompetanse for løsningen som helhet, må dette spesifiseres. hva er ønsket? 6. Drift og vedlikehold 6.1 edlikeholdskontrakt Leverandøren bes utarbeide et forslag til vedlikeholdskontrakt for løsningen med definert servicenivå (se videre i spesifikasjonen) og kostnadsestimat. Kontrakten skal gjelde for to år etter garantitidens utløp og gi mulighet til forlengelse. 6.2 Kompetanse i driftsfasen Leverandøren skal vedlikeholde sin kompetanse på drift av løsningen under hele driftsperioden. 6.3 Servicenivå, oppetid og kostnader Leverandøren må tilby brukerstøtte på forespørsel fra oppdragsgiver. Servicepersonell må ha den riktige kompetansen basert på de (/)

8 driftssituasjoner som erfares Servicepersonell skal være tilg jengelig via telefon og epost. Leverandøren bes utarbeide oversikt over tjenester med pristabell Leverandøren må ha reserveløsninger på programvare, maskinvare og nettverk Nettstedet og applikasjonen forventes å være tilgjengelig syv dager i uken (24/7) Leverandøren må garantere 99.5 % oppetid, og vise pristabell for ulike avvik fra garantien. Hvis garantien differensieres på dagtid og nattid, helger og helligdager må dette også beskrives. Prosentberegninger for oppetid beregnes inkludert planlagt tid for vedlikehold Tilbudet må omfatte en pristabell som viser pris for henholdsvis drift og brukerstøtte i ulike perioder i døgnet Leverandøren må angi trinnvis refusjon i månedlig avtalebeløp dersom krav til oppetid ikke ivaretas. Skalaen skal være slik at månedlig avtalebeløp bortfaller i sin helhet dersom månedlig oppetid er lavere enn 96 % innen avtalt oppetid Leverandøren må garantere backup som er maksimalt 24 timer gammel og dokumentere at det finnes rutiner for å teste at alle backuper er valide og mulige å legge tilbake. Backup skal lagres i en annen bygning enn der produksjonsanlegget er plassert Leverandøren må dokumentere at rutiner og driftsmiljøet er tilrettelagt for døgnkontinuerlig og sikkert drift. Leverandøren må dokumentere hva slags beredskapsplan man har og definere garantert recovery-tid etter ulike r driftsbrudd/hendelser. Restore av data skal starte seneste 2 timer etter at oppdragsgiver har meldt behovet Leverandøren må påta seg å levere feilrapporter etter driftsavbrudd Leverandøren må ta ansvaret for å avholde månedlig driftsmøte eller ved 2 behov med oppdragsgiver Systemet skal føre logg over alle hendelser Kapasitet, ytelse og utvidbarhet Leverandøren bes sannsynliggjøre at løsningen kan håndtere den aktuelle dokument- og trafikkmengde samt beskrive kapasitet og ytels e for foreslått løsning Leverandøren må garantere stor nok og fleksibel nok serverpark samt tilstrekkelig båndbredde for å kunne håndtere eventuelle belastningstopper Leverandøren bes beskrive i hvilken grad driftsløsningen kan skaleres etter behov Leverandøren bes angi priser for forskjellige antall samtidige brukere Leverandøren bes beskrive løsningens praktiske og/eller teoretiske begrensninger i forhold til antall brukere, antall informasjonselementer, informasjonselementenes maksimale størrelse, løsningens maksimale lagringskapasitet, spissbelastningskapasitet, mm Leverandøren må angi trinnvis refusjon i månedlig avtalebeløp dersom krav til ytelse innenfor avtalt antall samtidige brukere ikke ivaretas. Skalaen skal være slik at månedlig avtalebeløp bortfaller i sin helhet dersom månedlig gjennomsnittlig ytelse er slik at svartider øker med mer enn 100 %. 6.5 Utvidelser og integrasjoner

9 6.5.1 Leverandøren bes beskrive driftmiljøets rammebetingelser for utvidelser og integrasjoner Leverandøren bes beskrive hvordan installasjon og drift av utvidelser og integrasjonsløsninger bør skje Leverandøren bes beskrive hvordan oppgradering av programvare, patching og nye versjoner håndteres Leverandøren bes beskrive informasjonshåndtering ved oppgraderinger eller endringer av nettstedet eller databasen. 6.7 Sikkerhetsløsninger knyttet til drift Leverandøren bes beskrive sikkerhetsmekanismer i forbindelse med driftsmiljø ppgi om alle krav til sikker kommunikasjon og som antas å berøre applikasjonen og infrastrukturen, er ivaretatt. organisering av support funksjonen. ansvarskart driftsansvars hos systemeier organisering av datavedlikehold 7. Fremdriftsplan 7.1 Leverandøren bes fremlegge en detaljert fremdriftsplan for utvikling, testing, installasjon, pilot og produksjonsstart. (/) organisering av prosjektet med ansvarforhold på kunde og leverandørsiden. Ansvarskart, løp, milepeler. 8. Leverandørens forbehold 8.1 Angi hvilke forbehold, forutsetninger og betingelser som tas. (/)