Nytt CMS for Meteorologisk institutt (MET) Kravspesifikasjon

Transkript

1 Nytt CMS for Meteorologisk institutt (MET) Kravspesifikasjon Side 1 av 15

2 Innhold 1. Sammendrag Mål og rammer for prosjektet Bakgrunn Omfang Mål Priser Behov Tid Forprosjekt høst/ vinter Datanettet Dagens publiseringssystemer Desktop Krav til løsningen Type løsning Leverandøruavhengighet Rollefordeling og tilgangsstyring Design, interaksjon og navigasjon Søk Funksjonalitet Enkel programmering WYSIWYG-redigering av artikler Multimedia-kapabilitet Sosiale medier Versjonshåndtering Seleksjonsalgoritmer Bildehåndtering Personalisering Brukerstatistikk Systemkrav og teknisk plattform Kompatibilitet Nettleserversjoner og plattformer Leverandøren skal også beskrive funksjonalitet for følgende plattformer Leverandørens tjenesteplattform Side 2 av 15

3 4.2 Autentisering Roller og tilgang Oversikt over våre systemer Systemdokumentasjon og lisenser API Integrasjon mot andre systemer Fremtidig funksjonalitet Åpne standarder Tilgjengelighet og universell utforming Generelle tekniske krav Hosting og drift Båndbredde og datamengde Sikkerhet Utvikling og implementering Sammendrag Meteorologisk institutt har i dag flere nettsteder - både eksternt og internt. Løsningene vi har i dag er bygget på ulike typer publiseringsløsninger. Nå ønsker vi et CMS som kan fungere som et rammeverk for alle eksisterende og kommende nettsteder. I første omgang skal vi løse behovet for et intranett og to nettsider. I neste omgang ønsker vi å utvide løsningen til også og omfatte flere nettsider. Vi ønsker å jobbe med implementeringen av løsningen høsten 2013 og våren Mål og rammer for prosjektet 2.1 Bakgrunn Meteorologisk institutt har i dag flere ulike CMS løsninger for våre nettsider. Noe er egenlaget og annet er innkjøpte CMS systemer. Vi arbeider med produksjon av data. Flater hvor dette skal presenteres vil alltid være aktuelt for oss. Meteorologisk institutt har lenge fokusert på data-produksjon, men ikke like mye på presentasjon eller enhetlig produksjon av innhold. I dag finnes det ingen felles CMS for web-tjenestene våre. Det finnes heller ingen helhetlig måte å samarbeide på om innholdsproduksjonen i organisasjonen. Side 3 av 15

4 I siste halvdel av 2012 ble det gjennomført et forprosjekt for innholdsstrategi (se eget pkt. 2.7 og bilag 3). Prosjektet konkluderte med at et felles CMS for instituttets nettsider (eksterne og interne) er hensiktsmessig. Det vil gjøre det enklere å jobbe med sidene redaksjonelt og det vil bli en bedre kommunikasjon med brukerne av nettsidene. 2.2 Omfang Leverandøren skal levere et CMS i henhold til denne kravspesifikasjonen og bistå oss i prosessen frem til et ferdig produkt. 2.3 Mål For intranett Forenkle arbeidsprosessen for ansatte og åpne for mer samhandling og deling. Styrke opplevelsen av at vi er én organisasjon. Bygge opp under instituttets verdier; at vi er robuste, aktive, personlige og nytenkende. For eksterne nettsider: Kommunisere mer helhetlig og mer effektivt. Fremstå som mer situasjonstilpasset for brukeren, og å kommunisere mer enhetlig med publikum. Møte fremtidige brukerkrav. Vi skal gjøre det lettere for eksterne brukere å finne nødvendig informasjon og sikre at det oppleves som informasjonen kommer fra et sted Meteorologisk institutt. Noe som igjen skal sikre at vi er til å stole på og at vi er robuste (to av instituttets verdier). 2.4 Priser Se konkurransegrunnlagets pkt. 1.3 for nærmere beskrivelse og bilag 2 prisskjema. 2.5 Behov Vi skal ha et CMS som gir oss et rammeverk som dekker behovene for intranett og to nettsider på kort sikt, og som vi enkelt selv kan utvide til å omfatte flere nettsider på lengre sikt og ved behov. 2.6 Tid Kravspesifikasjonen legges ut på Doffin 03. juli Tilbud skal inn innen 22. august 2013 kl. 09:00. I løpet av høsten 2013 og våren 2014 ønsker vi å jobbe med implementering av løsningen. 2.7 Forprosjekt høst/ vinter 2012 Representanter fra fire ulike nettsidesatsninger deltok i forprosjektet. Gruppene jobbet frem behovsanalyser og tjenestekart. Vi vurderte brukeropplevelse, Side 4 av 15

5 målgrupper, innholdsproduksjon med mer. Forprosjektet ble gjennomført i samarbeid med Steria. 2.8 Datanettet Datanettet ved Meteorologisk institutt er delt opp i flere sikkerhetssoner med ulik beskyttelse. Serverne som skal være tilgjengelige fra internett står i et DMZ og de interne serverne er plassert i et produksjonsnett. Brukernettet er adskilt fra servernettene. Alle sikkerhetssoner er beskyttet av egne brannmurer hvor det bare åpnes for nødvendig tilgang. Internt er kapasiteten ut til hver arbeidsstasjon 1Gb, mens kapasiteten ut fra instituttet mot internett er 10Gb. 2.9 Dagens publiseringssystemer Intranettet er utviklet på en virtuell linux-server. Det er et perl-skript som kjøres automatisk flere ganger i timen, som henter html-filer fra et staging-område, og legger til rammeverk og design. Html-filene publiseres på en apache-webserver. met.no er nå hostet hos Idium hvor vi bruker deres Idium Web Portal for publisering Desktop 50% ansatte sitter på Linux desktop, Ubuntu LTS, og 50% sitter på Windows Krav til løsningen 3.1 Type løsning Løsningen skal være et CMS. Systemet skal brukes til intranett og ekstranett. Vi ønsker tilbud på drift og hosting av systemet, med opsjon på at vi hoster det selv. Se eget pkt. om hosting og drift. 1. Løsningen skal være et CMS system for bruk på intranett og ekstranett. 2. Leverandøren skal gi tilbud på drift og hosting av systemet, med opsjon på at vi hoster det selv. 3.2 Leverandøruavhengighet Løsning og plattform skal være leverandøruavhengig slik at vi kan beholde løsningen selv om vi endrer leverandør. 3. Løsning og plattform skal være leverandøruavhengig. 3.3 Rollefordeling og tilgangsstyring Løsningen skal være brukervennlig på flere nivåer. Side 5 av 15

6 Systemet skal ha et hierarkisk oppbygd tilgangssystem hvor roller kan fordeles på brukernivå. Det skal være mulig å skille mellom brukerens rolle som ansatt, og som redaktør. Ansatte skal selv kunne legge inn informasjon om seg selv og prosjekter de jobber med. Denne informasjonen skal lagres i CMS. Se også pkt. om funksjonalitet. Systemet bør ha et brukergrensesnitt som er mulig å tilpasse til tilgangsnivå. For eksempel bør det kunne gi enklest mulig publisering for innholdsleverandører og mer avansert for administratorer. 4. Systemet skal ha et hierarkisk oppbygd tilgangssystem. 5. Brukerne skal kunne ha flere roller i systemet. 6. Alle ansatte skal selv kunne legge inn informasjon om seg selv, prosjekter etc. 7. Informasjon om ansatte skal kunne lagres i CMS. 8. Systemet bør ha et brukergrensesnitt som er mulig å tilpasse til tilgangsnivå (enkel publisering for alle, avansert for administratorer). 3.4 Design, interaksjon og navigasjon Det skal utvikles en design i tråd med vårt grafiske uttrykk (designguide er tilgjengelig ved etterspørsel), samt interaksjonsdesign for de ulike sidene. Vi skal bygge nettsider i Responsive Design og CMS må støtte dette. Vi skal stå fritt til å lage, tilpasse, bygge ut og endre layout, grafisk design og oppdatere maler etter behov. Endringer skal vi selv ha mulighet til å implementere og lansere. Systemet bør ha en oversiktlig informasjonsarkitektur for alt innholdet (fra tilknyttede nettsider). Det bør være mulig med sømløs interaksjon mellom intranett og eksterne nettsider for MET sine ansatte. 9. Det skal utvikles design i tråd med vårt grafiske uttrykk (designguide tilgjengelig ved etterspørsel). 10. Vi skal bygge nettsider i Responsive Design og CMS må støtte dette. 11. Vi skal stå fritt til å tilpasse og endre layout og grafisk design, samt å oppdatere maler etter behov. Endringer skal vi selv ha mulighet til å implementere og lansere. 12. Systemet bør ha en oversiktlig informasjonsarkitektur for alt innhold. 13. Det bør være mulig med sømløshet mellom intranett og eksterne nettsider for MET sine ansatte. Side 6 av 15

7 3.5 Søk Det skal være enkelt å legge et søkefelt på sidene, slik at brukeren kan søke i fritekst på hele nettstedet. Søk er en av de viktigste funksjonene i det nye intranettet. Vi trenger et CMS med god søkefunksjonalitet og som enkelt kan indeksere innholdet. Dette innebærer: Fritekstsøk i egne og tilleggende tjenester ved hjelp av en hierarkisk oppbygd søkealgoritme som søker i både interne og eksterne nettsider og gir treff i prioritert rekkefølge. Eksempler på tjenester vi bør kunne søke i er personalhåndboka, ansattdatabase (OpenLDAP), stedsøkedatabasen til yr.no, Meteorologisk leksikon (Metlex) og Wiki. Leverandøren skal angi hvilke formater man kan søke opp innhold i. Vi ønsker f.eks å kunne få treff i innhold i rapporter (pdf etc.) og ikke bare i filnavn. Tema skal kunne merkes/ tagges enkelt i CMS (med tanke på søkemotoroptimalisering). URL er skal ikke inneholde lange strenger med bokstaver og tall. Leverandøren skal beskrive hvordan et avansert søk kan se ut. 14. Leverandøren skal beskrive hvordan et avansert søk skal bygges opp og se ut. 15. Det skal være enkelt å indeksere innhold. 16. Søkealgoritmen skal kunne søke i både interne og eksterne nettsider og gi treff i prioritert rekkefølge (avtales). 17. Leverandøren skal angi hvilke formater man kan søke opp innhold i. 18. Tema skal kunne merkes/ tagges (blant annet med tanke på SEO). 19. URL er skal ikke inneholde lange strenger med bokstaver og tall. 3.6 Funksjonalitet Vi skal ha redigerings- og stylingfunksjonalitet for å redigere tekst, bilder, video og animasjon. Vi skal også ha muligheten til å endre koden, slik at vi kan gjøre lettere programmering for undersider ved behov. Intranettet skal ha en arbeidsflate der alle daglige verktøy er tilgjengelige. Det skal være mulig å skreddersy innhold for ulike brukergrupper. Vi skal produsere nyheter, dele nyheter mellom egne nettsider og dele til sosiale medier. Det skal være mulig å lenke meldinger og artikler til hverandre (relasjoner/ relaterte artikler). Systemet skal ha en skjemabasert «mail to»-funksjon for spørsmål. Side 7 av 15

8 Våre ansatte har behov for prosjektsider som gjør samhandling og deling enklere. Systemet skal derfor ha en form for samhandlingsverktøy og diskusjonsforum ala Yammer.com hvor ansatte skal kunne lage egne profiler. Leverandøren skal beskrive hvilken standard de benytter for chat og diskusjonsforum, og hvordan dette kan løses. Det bør være mulig med automatisk innholdsmoderering for chat og diskusjonsforum på norsk og engelsk. 20. Vi skal ha redigerings- og stylingfunksjonalitet for å redigere tekst, bilder, video og animasjon. 21. Vi skal ha mulighet til å endre koden, slik at vi kan gjøre lettere programmering for undersider ved behov. 22. Intranettet skal ha en arbeidsflate der alle daglige verktøy er tilgjengelige. 23. Vi skal produsere nyheter, dele nyheter mellom egne nettsider og dele til sosiale medier. 24. Det skal være mulig å lenke meldinger og artikler til hverandre. 25. Systemet skal ha en skjemabasert «mail to»-funksjon for spørsmål. 26. Systemet skal ha en form for samhandlingsverktøy og diskusjonsforum ala Yammer.com hvor ansatte skal kunne lage egne profiler, samt diskutere i grupper etc. 27. Leverandøren skal beskrive hvilken standard de benytter for chat og diskusjonsforum, og hvordan dette kan løses. 28. Det bør være mulig med automatisk innholdsmoderering for chat. 3.7 Enkel programmering Det skal være mulig å skrive HTML rett inn i artikkelteksten og foreta enkle layoutendringer av bilder og figurer, tabeller og annet. Det skal være mulig å bruke Iframe, CSS, Javascript, html (html5), xml og de vanligste enkle programmeringsstandarder. 29. Det skal være mulig å skrive HTML rett inn i artikkelteksten og foreta enkle layout-endringer av bilder og figurer, tabeller og annet. 30. Det skal være mulig å bruke Iframe, CSS, Javascript, html (html5), xml og de vanligste enkle programmeringsstandarder. 3.8 WYSIWYG-redigering av artikler Det skal være mulig å merke av og endre tekstformatering etc. på samme måte som du gjør i tradisjonelle tekstbehandlingsverktøy i CMS. Eventuelt også direkte fra nettsiden. 31. Det skal være mulig med WYSIWYG-redigering av artikler. Side 8 av 15

9 3.9 Multimedia-kapabilitet Det skal være mulig å laste opp multimediafiler (lydfiler, videofiler etc.) i systemet for nedlasting/ visning uten at dette lages som plug-ins. 32. Det skal være mulig å laste opp multimediafiler (i systemet for nedlasting/visning) uten at dette lages som plug-ins Sosiale medier Systemet skal ha integrerte løsninger for sosiale medier som innebærer at man kan publisere direkte til sosiale medier og dele nyhetssaker fra nettsidene. Det skal også være feeds fra Twitter på nettsidene. Intranett skal ha sosiale funksjoner for deling, dialog og kommentarfunksjoner. 33. Systemet skal kunne publisere direkte til sosiale medier. 34. Systemet skal kunne dele nyhetssaker til sosiale medier. 35. Vi skal kunne legge inn twitterfeeds. 36. Intranett skal ha sosiale funksjoner for deling, dialog og kommentarfunksjoner Versjonshåndtering Vi vil få flere innholdsleverandører enn i dag og det skal være en løsning med versjonshåndtering slik at vi vet hvem som har redigert hva og når, og at redaktøren kan gå tilbake til siste versjon dersom uopprettelige feil oppstår i publiseringsfasen. Alle ansatte skal kunne redigere i løsningen samtidig. 37. Vi skal ha en løsning med versjonshåndtering. 38. Alle ansatte skal kunne redigere i løsningen samtidig Seleksjonsalgoritmer Vi skal kunne styre innhold i forhold til tema og viktighet i både tid og rom. Noe innhold skal publiseres kun på undersider, avdelingssider og temasider, annet til forsiden. Større nyhetssaker vil kanskje ligge på topp på forsiden i noen dager (tidsspesifisert). Vi skal også ha muligheten for å planlegge saker (for helg osv.) som autopubliseres. 39. Vi skal kunne styre innhold i forhold til tema og viktighet i både tid og rom (herunder også autopublisering). Side 9 av 15

10 3.13 Bildehåndtering Hvordan man laster opp, henter inn og linker til bilder i publiseringsløsningen er avgjørende for hvor enkelt det vil være å bruke bilder/ figurer, animasjoner og video på nettsidene. Løsningen skal ha et billedarkiv med synlige thumbnails slik at man kan se hvilke bilder man kan velge i. Man skal enkelt kunne publisere bilder (for eksempel med drag-and-drop). 40. Løsningen skal ha et billedarkiv med synlige thumbnails slik at man kan se hvilke bilder man kan velge i. 41. Man skal enkelt kunne publisere bilder (for eksempel med dragand-drop) Personalisering Det skal være mulig å tilpasse innhold til hver enkelt bruker (el. avdelinger etc.). Dette kan løses med for eksempel pålogging med tilgangsnivåer. Leverandøren skal gi et forslag på hvordan dette kan løses. 42. Det skal være mulig å tilpasse innhold til hver enkelt bruker. Leverandøren skal gi et forslag på hvordan dette kan løses Brukerstatistikk 43. Systemet bør ha et verktøy for enkelt å hente ut brukerstatistikk for analyse. 4. Systemkrav og teknisk plattform 4.1 Kompatibilitet Det skal være mulig både å redigere i CMS og ha kompatibel visning på Microsoft og Linux (se påfølgende krav) Nettleserversjoner og plattformer Løsningen skal støttes av seneste versjoner av Chrome og Firefox både på Windows 7 Enterprise og nyere, samt Linux 64 bit. Løsningen skal støtte av seneste versjoner av IE, 8 og 9 eller nyere. Løsningen skal utvikles i HTML5 og Javascript. Løsningen skal ikke bruke propritære plugins som silverlight, java og flash. Løsningen skal se lik ut og ha like funksjoner på de ulike plattformer, OS og nettleserversjoner. Side 10 av 15

11 4.1.2 Leverandøren skal også beskrive funksjonalitet for følgende plattformer ipad2 eller nyere, iphone4 eller nyere (ios 6 og nyere). Android telefon eller nettbrett og nyere (Android 4 og nyere). Windows Phone og Windows Surface (Windows 8, Windows RT og nyere). Dersom funksjonalitet foreslås, som ikke fungerer på alle plattformer, så skal leverandøren beskrive hva dette gjelder og på hvilke plattformer det gjelder Leverandørens tjenesteplattform Leverandørens tekniske tjenesteplattform (hardware og software) skal ha levetid, med supportavtale, som dekker hele avtaleperioden. Leverandøren skal beskrive den tekniske tjenesteplattformen. 44. Løsningen skal støttes av seneste versjoner av Chrome og Firefox både på Windows 7 Enterprise og nyere, samt Linux 64 bit. 45. Løsningen skal støtte av seneste versjoner av IE, 8 og 9 eller nyere. 46. Løsningen skal utvikles i HTML5 og Javascript. Løsningen skal ikke bruke propritære plugins som silverlight, java og flash. 47. Løsningen skal se lik ut og ha like funksjoner på de ulike plattformer, OS og nettleserversjoner. 48. Leverandøren skal også beskrive funksjonalitet for følgende plattformer: ipad2 eller nyere, iphone4 eller nyere (ios 6 og nyere). Android telefon eller nettbrett og nyere (Android 4 og nyere). Windows Phone og Windows Surface (Windows 8 og nyere). 49. Leverandøren skal levere en beskrivelse av sin infrastruktur. 50. Leverandøren skal beskrive den tekniske tjenesteplattformen. 51. Leverandørens tekniske tjenesteplattform (hardware og software) skal ha levetid, med supportavtale, som dekker hele avtaleperioden. 4.2 Autentisering Autentisering skal foregå mot instituttets OpenLDAP over SSL. Leverandør skal oppgi hvilke protokoller for autentisering av brukere (innloggingsfunksjon) som støttes. Vi påberoper oss rett til å vurdere leverandørenes foreslåtte løsninger omkring autentisering etter vår kostnadsvurdering for implementering. 52. Autentisering skal foregå mot instituttets OpenLDAP og SSL. 53. Leverandør skal oppgi hvilke protokoller for autentisering av brukere (innloggingsfunksjon) som støttes. 4.3 Roller og tilgang Den brukeren du er pålogget med skal bestemme hva du får tilgang til av informasjon og hvilken mulighet du har for redigering. Innholdsprodusenter skal ha mulighet for å produsere, vedlikeholde og slette sider som de har ansvar for. En bruker skal kunne ha flere roller (f.eks. en rolle som ansatt Side 11 av 15

12 og en annen som redaktør på en nettside) selv om det samme CMS benyttes til redigering. Leverandøren skal beskrive hvilke løsninger for single sign-on de støtter og/eller kan levere. 54. Den brukeren du er pålogget med skal bestemme hva du får tilgang til av informasjon og hvilken mulighet du har for redigering. 55. En bruker skal kunne ha flere roller. 56. Leverandøren skal beskrive hvilke løsninger for single sign-on de støtter og/eller kan levere. 4.4 Oversikt over våre systemer System wikier, interne og eksterne Metlex Ansattdatabase Personalhåndboken Om DokuWiki brukes som wikiløsning både internt og eksternt hos Meteorologisk institutt. Det er i dag 2 DokuWiki instanser som hostes på egne servere. Autentisering via OpenLDAP. Har innebygget søk. Krever autentisering for redigering. Kjører på Linux. Meteorologisk leksikon er en instans av MediaWiki. Adganskontroll via OpenLDAP. Krever autentisering for skriving. Har innebygget søk. Kjører på Linux. I dag et CGI-script som kombinerer søk i OpenLDAP med en katalog med passbilder for å vise informasjon om de ansatte. Krever ikke autentisering. Kjører på Linux. Statens personalhåndbok med lokale endringer for met.no. Hostes eksternt hos Met.no bruker en egen innloggingstoken lesing. Krever autentisering for redigering. Billedarkiv Arkivsystem Stemplingssystem, ansatt tilstedeinformasjon Rekruteringssystem Opoint OpenLDAP Eget fotoarkiv levert av interfoto, Autentiserer mot AD. Krever autentisering. Kjører på Windows. Ephorte. Har egen autentisering. Krever autentisering. Kjører på Windows. Tidbank. Autentiserer mot AD. Krever autentisering. Kjører på windows. Lumesse EasyCruit, Har egen autentisering. Krever autentisering. Medieovervåkning, Har egen autentisering. Krever autentisering for redigering. Redundant OpenLDAP oppsett med mulighet for autentisering over SSL. Løsningen er read only. 4.5 Systemdokumentasjon og lisenser Som en del av den endelige leveransen skal leverandøren utarbeide systemdokumentasjon og brukerveiledning. Eventuelle lisenskostnader omtales i punkt 1.3 og spesifiseres i punkt 4.2 (bilag 2) i konkurransegrunnlaget. 57. Leverandøren skal utarbeide systemdokumentasjon og brukerveiledning. Side 12 av 15

13 4.6 API Systemet skal ha et WEBAPI som man enkelt kan hente ut meldinger fra (etter tema/ tags) for å kunne lage feeds og meldingstjenester i eksisterende systemer og rammeverk. Systemet skal ha et WEBAPI som man enkelt publisere meldinger fra andre systemer i. Leverandøren skal beskrive hvordan dette kan løses. 58. Systemet skal ha et WEBAPI som man enkelt kan hente ut meldinger fra (etter tema/ tags) for å kunne lage feeds og meldingstjenester i eksisterende systemer og rammeverk. 59. Systemet skal ha et WEBAPI som man enkelt publisere meldinger fra andre systemer i. 60. Leverandøren skal beskrive hvordan dette kan løses. 4.7 Integrasjon mot andre systemer Vi ønsker søk i- og integrasjon mot en rekke systemer. Leverandøren skal beskrive hvordan denne integrasjonen skal foregå (nivåer av integrasjon). Med integrering mener vi alt fra sømløs integrasjon, til søk. Systemer som det skal eller bør integreres mot: 61. Bildearkiv. Vi har et godt grensesnitt front end, men skal integrere for bruk back end til publisering på alle nettsider. System leveres av FotoWare Skal kunne dele og presentere kalenderere mot vårt kommunikasjonssystem (basert på formatet ical som definert i RFC 5545). 63. Tidbank: Tilstedeværelse skal kunne knyttes opp mot CMS. 64. Arkiv: ephorte saksbehandlingssystem. Bør kunne integreres. 65. Ansattedatabasen (OpenLDAP) via søk og presentasjon. Bør kunne integreres. 66. Personalhåndboka: all HR relatert informasjon ligger i et system som heter Infotjenester. Systemet kan integreres ved at det gis treff i denne ved søk og viser resultat i samme grensesnitt. Bør kunne integreres. 67. Stedsdatabase yr.no bør kunne integreres. 68. Metlex bør kunne integreres. 69. Systemet bør kunne integrere ledige stillinger fra rekrutteringssystemer (i første rekke webcruiter og easycruit). I dag listes stillinger ut via iframe (fra easycruit). 70. Opoint bør kunne integreres. 71. Wiki bør kunne integreres. 4.8 Fremtidig funksjonalitet Systemet skal være skalerbart og mulig å oppdatere i henhold til gjeldende designstandarder, tekniske krav og andre behov. Leverandøren skal beskrive hvordan ny funksjonalitet tilgjengeliggjøres for kunden. 72. Systemet skal være skalerbart og mulig å oppdatere i henhold til Side 13 av 15

14 gjeldende designstandarder, tekniske krav og andre behov. 73. Leverandøren skal beskrive hvordan ny funksjonalitet tilgjengeliggjøres for kunden. 4.9 Åpne standarder All data skal være tilgjengelig i åpne standardarder slik at CMS enkelt kan overtas. Leverandøren skal dokumentere hvilke standarder som brukes. Krav Leverer Beskriv hvordan tilbudt 74. All data skal være tilgjengelig i åpne standardarder slik at CMS enkelt kan overtas. 75. Leverandøren skal dokumentere hvilke standarder som brukes Tilgjengelighet og universell utforming Våre nye nettsider skal følge retningslinjer for universell utforming og tilgjengelig webinnhold etter den internasjonale standarden WCAG 2.0 AA. CMS skal understøtte dette. 76. CMS skal understøtte at våre nettsider skal følge retningslinjer for universell utforming og tilgjengelig webinnhold etter den internasjonale standarden WCAG 2.0 AA Generelle tekniske krav 77. Leverandøren skal garantere en oppetid på 99,9 % pr. 30- dagers syklus. Statistikk skal leveres etter nærmere avtale Hosting og drift Løsningen skal driftes på dedikerte virtuelle eller fysiske maskiner. MET ønsker tilbud på en eller flere av disse kombinasjoner (minst et tilbud på hosting og et på drift av løsningen) Hosting A) Løsningen er plassert hos leverandør (med 24/7 support). B) Løsningen er plassert hos MET og eies av MET, etter dimensjoneringskrav fra leverandør. Drift A) Fult drifts- & forvaltningsansvar av løsningen pålegges leverandør, med 24/7 support. Side 14 av 15

15 B) MET tar ansvar for 1.linje support (basert på dokumentasjon fra leverandør). Leverandøren har ansvar for 2. og 3. linje support, samt tjenesteforvaltning (inkludert oppgradering og patching), og 24/7 support. 78. Løsningen skal driftes på dedikerte virtuelle eller fysiske maskiner. 79. Leverandøren skal levere forslag til hosting og drift av løsningen (se bilag 2 prisskjema) Båndbredde og datamengde Leverandøren skal beskrive hvilken båndbredde som leveres. Det skal skilles mellom inn- og utgående båndbredde. Eventuelle forbehold til levering av beskrevet båndbredde skal begrunnes. Om det er mulig å utvide båndbreddekapasiteten skal dette beskrives med reelle priseksempler. Hvis leverandøren priser mengden data inn eller ut fra løsningen skal det leveres med en prismatrise eller en god beskrivelse av prising som lett kan brukes til å kalkulere ut flere alternativer. 80. Leverandøren skal beskrive hvilken båndbredde som leveres Hvis leverandøren priser mengden data inn eller ut fra løsningen skal det leveres med en prismatrise eller en god beskrivelse av prising Sikkerhet Leverandøren skal beskrive disaster recovery. Leverandøren skal beskrive fysiske og logiske sikringstiltak relatert til IT-sikkerhet samt løsninger for løpende overvåking. 81. Leverandøren skal beskrive disaster recovery. 82. Leverandøren skal beskrive fysiske og logiske sikringstiltak relatert til IT-sikkerhet samt løsninger for løpende overvåking. 5. Utvikling og implementering Vi ønsker å jobbe iterativt med tilbyder, slik at vi i utviklingsfasen kan prioritere (dele opp) hva som utvikles først, for så å teste og godkjenne underveis. Dette gjør det enklere for oss å se hvilken funksjonalitet vi ønsker på de ulike nettsidene, det passer bedre med hvordan vi organiserer vårt arbeid og prioriterer ressurser. Det endelige antallet maler og deres utforming bestemmes i samarbeid med tilbyderen tidlig i prosessen. Side 15 av 15