Nettstedet data.norge.no

Transkript

1 Konkurransegrunnlag Konkurranse med forhandling etter forskriftens del I og II (Konkurransen gjennomføres i ett trinn, uten pre-kvalifisering) for anskaffelse av Nettstedet data.norge.no For levering til Fornyings-, administrasjons- og kirkedepartementet Saksnummer i DocuLive Tilbudsfrist: 23. august 2010 kl. 12:00

2 Innhold 1 GENERELL BESKRIVELSE Oppdragsgiver Anskaffelsens formål Omfang og kontraktsverdi Oppbygging av konkurransegrunnlaget Kunngjøring REGLER FOR KONKURRANSEN Gjennomføring av konkurransen Tilbudets utforming og levering Innleveringsfrist Vedståelsesfrist Behandling av tilbud Tilleggsopplysninger KVALIFIKASJONSKRAV Obligatoriske og ufravikelige krav Leverandørens tekniske, faglige og økonomiske kvalifikasjoner TILDELINGSKRITERIER ANNEN INFORMASJON UNDERSKRIFT LEVERANDØRENS SJEKKLISTE BILAG 1 HMS-EGENERKLÆRING BILAG 2 TILPASNINGSAVTALEN (SSA-T) BILAG 3 KRAVSPESIFIKASJON GENERELL BESKRIVELSE 1.1 Oppdragsgiver Fornyings-, administrasjons- og kirkedepartementet er ansvarlig for statens IKT-politikk, offentlighetsloven og for statens arbeid med viderebruk av offentlige data. Oppdragsgivers kontaktperson er: Navn: Sverre Andreas Lunde-Danbolt Postadresse: Postboks 8004 Dep Besøksadresse: Akersgata 59 E-post: sld@fad.dep.no Telefon: / Eventuelle spørsmål skal rettes til kontaktpersonen pr. e-post. 2

3 1.2 Anskaffelsens formål Konkurransegrunnlag for anskaffelse av nettstedet data.norge.no Nettstedet data.norge.no skal være forvaltningens knutepunkt for alle tema knyttet til viderebruk av offentlige data. Nettstedet skal være (1) en publiseringsløsning for å vedlikeholde sider med innhold knyttet til temaet, (2) en blogg for deling av informasjon og offentlig debatt om temaet, (3) en katalog med metadata om tilgjengelige, offentlige datasett, (4) en katalog med metadata om applikasjoner som utnytter offentlige datasett, og (5) en applikasjon for visualisering av eksempeldata. Det skal ikke lagres offentlige data på selve nettstedet (ikke kartdata, eiendomsinformasjon, trafikkopplysninger, etc.), kun beskrivelser av slike datasett (metadata) og annen informasjon. For nærmere beskrivelse av leveransen se bilag 3 Kravspesifikasjon. 1.3 Omfang og kontraktsverdi Oppdraget er å utvikle nettstedet. Utviklingen skal skje i etapper, og flere betaversjoner skal lanseres underveis i utviklingsarbeidet. Leveransen skal derfor stykkes opp i minimum tre faser, der det skal leveres en betautgave av nettstedet på slutten av hver fase. Målsetningen er å lansere nettstedet med begrenset funksjonalitet så snart det lar seg gjøre, og bruke kommentarer og innspill fra de første brukerne av nettstedet i det videre arbeidet med å ferdigstille nettstedet. Det nøyaktige antallet utgaver/betaversjoner av nettstedet vil bli gjenstand for nærmere forhandlinger, og vil bli tilpasset ønsket progresjon i utviklingsarbeidet. Leverandør har driftsansvar for løsningen i denne utviklingsfasen. Videre drift er derimot ikke en del av denne anskaffelsen. Oppdraget har en økonomisk ramme på inntil kr ,- eks. mva. 1.4 Oppbygging av konkurransegrunnlaget Konkurransegrunnlaget består av dette dokument med tilhørende bilag 1 (HMS-egenerklæring), bilag 2 (SSA Tilpasningsavtalen ( og bilag 3 (Kravspesifikasjon). 1.5 Kunngjøring Konkurransen er kunngjort med FADs i bloggen på og i DOFFINdatabasen (se 2 REGLER FOR KONKURRANSEN 2.1 Gjennomføring av konkurransen Anskaffelsen gjennomføres i henhold til lov om offentlige anskaffelser av 16. juli 1999 (LOA) og forskrift om offentlige anskaffelser (FOA) av 7. april 2006 nr Del II 5-1. Kontraktstildeling vil bli foretatt etter prosedyren Konkurranse med forhandling. Alle interesserte leverandører gis adgang til å levere tilbud. Forhandlingene vil kunne bli gjennomført i flere faser for å redusere det antall tilbud det forhandles om. En første reduksjon av tilbud vil kunne skje før forhandlingene starter. Reduksjonen av antall tilbud det forhandles om skjer på bakgrunn av de fastsatte tildelingskriteriene, jfr. forskriftens 11-8(1). 3

4 Bare de tilbyderne som oppfyller kvalifikasjonskravene vil få sine tilbud evaluert. 2.2 Tilbudets utforming og levering 1. Tilbudet skal være merket: «Anbud på utvikling av data.norge.no (DL )» 2. Dette konkurransegrunnlaget skal benyttes for å avgi tilbud/svar. Leverandørens svar skrives med blå skrift rett under det angjeldende spørsmål eller i tabeller avsatt for svar. 3. Vedlegg skal nummereres i den rekkefølge som vedlegg nevnes i konkurransegrunnlaget. 4. Tilbudet skal inneholde komplett utfylt priser/prisskjema. 5. Tilbudet skal leveres til postmottak@fad.dep.no med kopi til sld@fad.dep.no 6. Leverandørene skal også levere en utgave av tilbudet hvor det som anses å være forretningshemmeligheter er sladdet. Ved begjæring om innsyn, skal oppdragsgiver uavhengig av dette vurdere hvorvidt opplysningene er av en slik art at oppdragsgiver plikter å unnta dem fra offentlighet. 7. Underskrift Dette konkurransegrunnlaget er utformet slik at leverandøren kan fylle inn teksten direkte i konkurransegrunnlaget slik at det samlet sett fremstår som leverandørens tilbud. 2.3 Innleveringsfrist Innleveringsfrist er satt til 23. august kl For sent innlevert tilbud vil bli avvist. 2.4 Vedståelsesfrist Leverandøren må vedstå seg sitt tilbud 120 kalenderdager regnet fra innleveringsfristen. 2.5 Behandling av tilbud Alle leverandører vil få tilbakemelding om hvilket tilbud som er valgt. 2.6 Tilleggsopplysninger Dersom leverandøren finner at konkurransegrunnlaget ikke gir tilstrekkelig veiledning, kan han skriftlig be om tilleggsopplysninger hos oppdragsgiver ved oppdragsgivers kontaktperson. Dersom det oppdages feil i konkurransegrunnlaget, bes det om at dette formidles skriftlig til oppdragsgivers kontaktperson. Skriftlig henvendelse om tilleggsopplysninger merkes: «Forespørsel om tilleggsopplysninger for anbud til data.norge.no (DL )» og sendes til oppdragsgivers kontaktperson per e-post. 3 KVALIFIKASJONSKRAV Krav til leverandøren for deltakelse i konkurransen. Informasjon til leverandør: Fra kapittel 3, 4 og 5 skal det fylles inn direkte i dette dokumentet. Samlet innfylling og vedlegg vil da utgjøre leverandørens tilbud. Husk å fylle inn med blå skrift. 4

5 3.1 Obligatoriske og ufravikelige krav Krav Dokumentasjonskrav Vedlegg nr: Det kreves at Skatteattest (Skatteattest for skatt utstedes av leverandøren har ordnede forhold mht. skatteinnbetaling og momsinnbetaling. kemner/kommunekasserer (skjema RF-1244)) som ikke er mer enn 6 måneder gammel. Merverdiavgiftsattest (Attest for betalt merverdiavgift utstedes av skattefogden (skjema RF-1244)) som ikke er mer enn 6 måneder gammel. Det kreves at leverandøren har et fungerende HMSsystem. HMS -egenerklæring (Se bilag 1 til konkurransegrunnlaget) Leverandørens tekniske, faglige og økonomiske kvalifikasjoner Krav Dokumentasjonskrav Leverandørens svar Vedlegg nr: Leverandøren skal ha økonomisk kapasitet til å gjennomføre oppdraget/kontrakten Velg en av disse to: Kredittvurdering/rating, ikke eldre enn 1 år, og som baserer seg på siste kjente regnskapstall. En rating skal være utført av offentlig godkjent kredittvurderingsinstitusj on Årsregnskap inkl. styrets årsberetning og revisorerklæring Dersom leverandøren av gyldige grunner ikke kan fremlegge den dokumentasjon oppdragsgiver har anmodet om, kan han godtgjøre sin økonomiske og finansielle stiling med ethvert annet dokument som oppdragsgiver kan akseptere. Leverandøren skal ha Beskrivelse av

6 Krav Dokumentasjonskrav Leverandørens svar Vedlegg nr: erfaring fra minimum 3 leverandørens 3 mest tilsvarende oppdrag i relevante oppdrag i løpet av løpet av de 3 siste årene. de siste 3 årene. (Man bør utdype hva man Beskrivelsen må inkludere legger i "tilsvarende angivelse av oppdragets oppdrag".) verdi, tidspunkt og mottaker (navn, telefon og e-post.) Referanser blir kontaktet ved behov for klargjøring av oppdragets relevans. Det er likevel slik at det er leverandørens ansvar å dokumentere relevans gjennom beskrivelsen. Leverandøren skal ha Redegjørelse for de verktøy, tilstrekkelig materiell eller teknisk utstyr gjennomføringsevne og som leverandøren kapasitet. disponerer over til gjennomføring av kontrakten/oppdraget. Det kreves et godt og velfungerende kvalitetssikrings-system for ytelsene som skal leveres. Beskrivelse av gjennomføringen (Nevn eksempler fra tidligere prosjekt) CV til nøkkelpersonene Redegjørelse vedrørende leverandørens kvalitetssikringssystem/- styringssystem eller Kopi av systemsertifikat utstedt av akkrediterte sertifiseringsorganer eller tilsvarende dokumentasjon. 6

7 4 TILDELINGSKRITERIER Kriterier Vekt Dokumentasjonskrav Leverandørens svar Vedlegg Samlet pris 20 % Tilbudet bør gi en oversikt over prissettingen for de enkelte delelementer, samt en samlet pris for hele leveransen. Løsningsforståelse 50 % Løsningsforståelse vil bli vurdert ut ifra tilbudet i sin helhet. Fordi løsningen ligner mye på nettsteder satt opp i andre land (data.gov, data.gov.uk, etc.) og i andre byer (datasf.org, data.octo.dc.gov, etc.), vil det være et viktig poeng i hvilken grad løsningen gjenbruker åpen kildekode fra andre, lignende nettsteder. Leveringsdyktighet 30 % I tillegg til tilbudet i sin helhet og planlagt gjenbruk av åpen kildekode, vil leveringsdyktighet bli vurdert ut ifra leverandørens referanser. Tilbudet skal derfor inneholde kontaktpersoner hos minst tre tidligere kunder. Det pekes her ikke minst på annonseringen fra data.gov.uk som den 20. august i år annonserte at de har tilgjengeliggjort CKAN integrasjon fra Drupal som open source nr:

8 5 ANNEN INFORMASJON Informasjon fra oppdragsgiver Svar/informasjon fra leverandøren Evt. vedlegg nr: Det forventes at leverandør drifter løsningen i 5.1 utviklingsfasen og verifikasjonsfasen. Løsningen vil være offentlig tilgjengelig som en betatjeneste i utviklingsfasen, gjennom domenet data.norge.no. Ansvaret for dette nettstedet vil etter hvert overføres fra FAD til Direktoratet for forvaltning og IKT (Difi). FAD/Difi vil i utgangspunktet drifte denne løsningen selv. Dersom det blir aktuelt å sette ut videre drift av løsningen vil det bli lagt opp til en separat anbudskonkurranse om drift av nettstedet UNDERSKRIFT Firmaopplysninger Fyll inn Leverandør: Computas AS Adresse: Lysaker Torg 45, 1327 Lysaker Kontaktperson: David Norheim Telefonnummer: Telefaks: E-postadresse: david.norheim@computas.com Foretaksnummer: , den......se under... Leverandørs underskrift ved innlevering av tilbudet 8

9 7 LEVERANDØRENS SJEKKLISTE Følgende dokumenter skal leverandøren legge ved tilbudet: 1. Skatteattest (Se punkt 3.1) 2. Merverdiavgiftsattest (Se punkt 3.1) Følgende dokumenter kan oppdragsgiver be deg legge ved tilbudet: 3. HMS-egenerklæring (se punkt 3.1) 4. Leverandørens tekniske, faglige og økonomiske kvalifikasjoner (Se punkt 3.2) 5. Kravspesifikasjoner (se punkt 4) Leverandøren besvarer kravene til dokumentasjonen på tildelingskriterier så godt det er mulig: 6. Se oppdragsgivers liste tatt inn i punkt 5 Husk at skal vedleggene som skal med nummereres og at vedleggsnummerene tas inn i dette dokumentet. Leverandørens svar fylles inn med blå skrift. 9

10 BILAG 1 HMS-EGENERKLÆRING Se Vedlegg

11 BILAG 2 TILPASNINGSAVTALEN (SSA-T) Tilpasningsavtalen (SSA-T) finnes her: 1

12 BILAG 3 KRAVSPESIFIKASJON data.norge.no skal være et nettsted som informerer, promoterer og stimulerer initiativ som publiserer eller tar i bruk datasett som er gjort offentlig tilgjengelig i maskinlesbare formater. Nettsiden skal være sosialt rettet og legge til rette for at sluttbruker skal kunne bidra med informasjon og meninger relatert til emnet. Den tekniske løsning skal være modulær og åpen, på en slik måte at framtidige endringer kan skje på en smidig måte med lavest mulige kostnader. Løsningen skal i første omgang bestå av følgende moduler: Publiseringsløsning for å vedlikeholde sider med informasjon relatert til emnet Blogg for deling og diskusjon av informasjon og meninger relatert til emnet Katalog med metadata om offentlig tilgjengelige datasett Katalog med metadata om applikasjoner som utnytter offentlig tilgjengelige datasett Applikasjon for å visualisere eksempeldata fra datasett på utvalgte kjente format Tabellen under inneholder minstekrav til løsningen. Det er obligatorisk å svare på alle punktene. Indikér om kravet er oppfylt i løsningen ved å sette Ja eller Nei i tredje kolonne. Dersom svaret inneholder referanser til annen dokumentasjon så skal dette fremkomme i siste kolonne og dokumentasjonen skal leggest ved (og gjerne med kryssreferanse tilbake til kravet). Løsningens kildekode blir tilgjengeliggjort gjennom en åpen lisens som bestemmes av oppdragsgiver i etterkant av leveransen. Begreper Følgende begreper er benyttet i kravspesifikasjonen: Applikasjon: Applikasjon eller komponent som benytter ett eller flere datasett Datasett: Sett med data gjort tilgjengelig i filer eller på standardisert maskinlesbart format via ett eller flere kjente grensesnitt (API). Datasettene skal lagres hos dataeierne, ikke på data.norge.no. På data.norge.no skal det kun være metadata om datasett. Data: Innholdet i et datasett Metadata: Informasjon som beskriver datasett, grensesnitt mot datasettet, vilkår for bruk av datasettet og data i datasettet Informasjon: Innhold på nettstedet data.norge.no Innhold: Informasjon på nettstedet data.norge.no 1

13 1. Funksjonelle krav til løsning Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 1.1 Generelle krav Løsningen skal bestå av et rammeverk som ivaretar design og navigasjon mellom de forskjellige modulene i løsningen slik at løsningen 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 Løsningen skal kunne fremstå på flere språk, med mulighet for å gjøre innhold tilgjengelig på flere språk 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 Løsningen skal aktivt hjelpe brukeren til å følge referansekatalogens krav til IT-standarder der det er relevant. ( Et konkret eksempel på dette er at løsningen skal sørge for at dokumenter blir publisert i rett format Løsningen skal utformes i tråd med statens IKTarkitekturprinsipper: tekturprinsipper Løsningen skal tilfredsstille kravene i W3C WAI WCAG 2.0 AA (alle kriterier merket A og AA i standarden - erview.php). Ved leveranse skal dette dokumenteres. Leverandøren tilbyr her Drupal som portalrammeverk. Rammeverket støtter tilpasning til behovet nevnt her. Drupal og moduler støtter internasjonalisering. Innholdet i metadatakatalogen vil være tilgjengelig i det språk det er publisert. Dette settes opp i proxy og DNS. De angitte standardene vil følges der relevant. I en grad det her skal publiseres vedlegg til blogposter osv., kan disse begrenses av standardene nevnt. Når det gjelder eksport av data og metadata er p.t. ingen referansekatalogstandarder. Visualiseringer vil benytte Javascript. Løsningen er sterkt påvirket av RESTfulle tjenesteorienterte APIer, og samsvarer godt med statens IKT tjenesteorientee arkitekturprinsipper. Drupal støtter i utgangspunktet WAI krav, men dette kan variere noe avhengig av malverk og plugins. Det er satt av tid til testing og forbedring av dette. 1

14 1.1.7 Løsningen skal benytte RDF/Linked Open Dataattributter til å annotere innhold på nettstedet. Drupal støtter annotering med RDFa, spesifikt FOAF, SKOS og SIOC vokabularene 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. 1.2 Administrasjon av nettstedet Løsningen skal kunne håndtere et større antall brukere med ulike roller og rettigheter. Det skal registreres kontaktinformasjon relatert til hver bruker Innholdet på nettstedet skal kunne administreres gjennom et webbasert grensesnitt kryptert med SSL 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 Det skal være støtte for å tildele rettigheter til brukere på en enkel måte Alt innhold skal eies av én eller flere brukere i systemet Administrator skal kunne administrere alt innhold 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. Delvis CKAN benyttes. Det finnes også en plugin for Drupal for CKAN som blir benyttet. Drupal er rolle- og rettighetsstyrt. Admin området til Drupal kan settes opp med SSL i proxy. Det må bygges funksjonalitet for å skille mellom brukergrupper på denne måten. MinID anses som uaktuell på det nåværende tidspunkt. Drupal er rolle- og rettighetsstyrt. I utgangspunktet eies innhold av én bruker. En brukergruppe definert med en rolle kan også ha full tilgang til aktuelt innhold. Det finnes moduler for å gi eierskap til en rolle med full tilgang. CKAN har et revisjonssystem hvor man kan se endringer i beskrivelsen. Versioner av datasettet (som ikke skal leveres i denne løsningen) kan ha ulike URLer for nedlastning. Alternativt må det bygges et 1 1

15 system for å duplisere versioner av beskrivelser som ulike pakker med ulik status. Usikker på behovet her 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 Løsningen skal ha en rutine for utfasing av beskrivelser av spesifikke datasett Løsningen skal kunne håndtere import av metadata fra andre kilder. Slik import skal kunne automatiseres 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 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 Det skal være mulig å navigere i metadataene på flere måter, f.eks. etter eier, forvaltningsnivå, eiers geografiske plassering, type data og lisenstype Det skal være mulig å gi tilbakemelding på alle datasett som er beskrevet i datakatalogen. Beskriv hvordan dette løses og administreres 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. Ja Ja, dette kan gjøres med kategorisering. Ja, det er mulig å markere som slettet. CKAN har et standard set av kjerne-metadata, men kan utvides med et ubegrenset sett av andre metadata. Metadata-definisjonene (metamodellen) holdes i CKAN. En egen migreringsbeskrivelse kan benyttes når det er ønske om utvidelser av metamodellen. Drupal støtter friendly URLs. Hvordan Drupal støtter Clean URLs er beskrevet i 5 CKAN API drupal komponent støtter dette. Støttet ved katalogen/ckan + Drupal forum eller blogg/kommentarer Katalog RSS feed er støttet av CKAN. Nyheter RSS feed er støttet av Drupal Alt innhold skal være synlig datert. Delvis Malavhengig, det må i såfall 1

16 tilpasses i maler der det ikke er 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. Nei Ifølge konkurransegrunnlagets punkt 1.2, anskaffelsens formål skal datasettet IKKE vises. Det er i såfall beskrivelsene som blir vist, og hvilken verdi dette har for bruker ønskes diskutert. Eventuelt kan HTTP akesslogger benyttes for statistikkformål 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 Nettstedet skal ha en innbydende utforming hvor alt innhold redigeres i samme grensesnitt som visningen Løsningen skal ha en søkemekanisme som lar bruker søke i fritekst på alt innhold i løsningen 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 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 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. 1.6 Tilgjengelighet av rådata Det kan bygges som en egen datatype. Søk i innhold (ikke katalog) er støttet av Drupal. Katalogsøk er støttet av CKAN API. Mulige metadata til datasettbeskrivelsene. Igjen, dette er kun beskrivelsene. Det er satt av noen timer til dette. Antakelsen er at dagens løsning er Wordpress. JSON, RDF og XML vil kunne lastes opp som filer og lastes ned. Visualisering gjennom google chart tools Katalogen over offentlige datasett skal Katalogdatane er 1

17 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 XMLformat (Dette er det eneste datasettet som skal gjøres tilgjengelig på data.norge.no). Beskriv forslag til format og programmeringsgrensesnitt for dette datasettet. tilgjengelig iallefall som RSS, RDF og JSON. Det tilbys kun en nedlasting av datasettet, ikke ytterligere programmeringsgrensesnitt. 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. Løsningsforslaget skal minst omfatte: En modell for løsningen som synliggjør hvilke funksjoner som inngår i løsningen En spesifikasjon av hvilke programvarekomponenter nettsted og database 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. Se vedlegg kapittel 4.2. Alle komponenter er open source med tilpassninger. Lisenser er som følger: Drupal: GPL v2 PHP: PHP license 3.01 Apache Web server: Apache License, v2.0 CKAN: GNU Affero GPL MySQL: GPL License for open source prosjekter Google Chart Tools: Se Googles betingelser om/apis/chart/terms. html Ubuntu: open source, programmenes lisens varierer og CKAN Drupal API: GPL v2 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. Se i vedleggsdokumentet 2.3 Leverandøren bes beskrive ansvarsforhold, Se i 1

18 ressurser og rutiner for utvikling, feilretting, kvalitetskontroll og support for tilbudt tredjeparts programvare. vedleggsdokumentet 3. Generelt Krav nr. Beskrivelse av krav Status Leverandøren sitt svar 3.1 Dokumentasjon 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.) Løsningen i seg selv skal være mest mulig selvforklarende, og alle moduler og funksjoner skal beskrives i dokumentasjonen Alle skjema skal følge ELMER standarden. /anvendelsesomraade/naeringslivskjema-paaoffentlige-nettsider /standard/elmer/elmer-v All dokumentasjon som utarbeides for løsningen skal leveres i elektronisk form 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 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. Det forutsettes at Kunden er delaktig i brukerdokumentasjon og brukerveilending. Det settes av noe tid til dette. Det forutsettes at metadatasettet er begrenset. Ref. krav og kjernen av CKAN. Subversion Spesialutviklet kildekode skal dokumenteres 1

19 grundig. Det skal være mulig for andre å bruke kildekoden til å sette opp tilsvarende nettsteder. Dokumentasjonsspråket er engelsk. 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 4.2 Leverandør må ha egnede prosedyrer for endringshåndtering. Hvem og hvordan besluttes endringer? Beskriv eventuelle prosesser og prosedyrer rundt dette. Det forutsettes at Kunden tar ansvar for akseptansetest. Ved oppstart vil prosjektet ettablere et feil og endringshåndteringsregime i JIRA. Leverandør vil kunne melde inn endringsønsker i dette systemet. Endringer vil konsekvensutredes av leverandør før avklaring om iverksettelse. For å redusere administrasjon med en styringsgruppe knyttet til avklaring om iverksettelse, foreslås det at endringsanmodninger håndteres av kontraktsansvarlig hos kunden og leverandør sammen med prosjektleder(e) hvor det besluttes om endringene utføres. Endringsanmodninger vil under utvikling kunne håndteres i forkant av hver sprint gjennom et kort møte, per telefon eller e-post. Etter utviklingsfasen tas slike møter ad-hoc. Om det er ønskelig har Computas mer formelle prosedyrer for endringshåndtering som kan dokumenteres (The 1

20 Computas Way). 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. Se 6.5 i vedleggsdokumentasjonen. 2