TIL STIFTELSEN LILLEHAMMER MUSEUM
Avtale for kjøp av nye websider
TIL STIFTELSEN LILLEHAMMER MUSEUM
Kundens kravspesifikasjon Bilag 1 til SSA-k-lille
Saksnr: 1/2014
1 OM ANSKAFFELSEN, BEHOV OG KRAVTABELL
3
1.3 Kravspesifikasjon – Del 1 (Front-end) - Hovedleveranse 6
1.4 Kravspesifikasjon – Del 2 (Back-end) – Opsjon 14
1.5 Kompetanseprofil til leverandørens tilbudte team 23
1.6 Leverandørens referansetabell 24
1 Om anskaffelsen, behov og kravtabell
1.1 Overordnet behov
Det er essensielt for anskaffelsens effektmål at de overordnede behovene imøtekommes.
Vi fokuserer på den kommersielle virksomheten i denne anskaffelsen. Overordnet og absolutt viktigste målsetning for nettsidene er å friste til besøk. De nye websidene må fremstå som kommersielle og de skal friste brukeren til å besøke museene.
Områder som vektlegges:
• Museene har fått ny visuell profil. Disse skal framkomme på nettstedene. De skal bidra til å formidle hvert enkelt museum sin særegenhet.
• Det skal være meget enkelt og intuitivt å finne praktisk informasjon som åpningstider, priser, veibeskrivelse etc.
• Den nye weben skal bidra til at museene har bred tilstedeværelse på digitale flater og i sosiale medier.
1.2 Kravtabell
Hvordan kravene skal forstås og besvares av Leverandør
Tabellen nedenfor lister opp spesifikke, nummererte krav. Listen kan ikke sees som uttømmende i forhold til ovenstående beskrivelser, men som en utdyping av nødvendige, utvalgte områder. Hvert krav er identifisert med en unik ident (ID), er av en bestemt type fra tabellen nedenfor (Type) og har en tekst som beskriver kravet (Beskrivelse)
Kravene er delt inn i følgende typer:
Obligatoriske krav (M) | Kravet MÅ tilfredsstilles og skal være innkalkulert i prisen på leveransen |
Betingende krav (B) | Kravet BØR tilfredsstilles, men det er ikke et absolutt krav. Svar vil likevel ha betydning for evaluering av tilbudet. Hvis punktet ikke inngår som en del av Leverandørens standard leveranse, skal punktet prises. |
Opsjon (O) | Kravet MÅ eller BØR tilfredsstilles, men det er opp til Oppdragsgiver å velge om kravet skal inkluderes i leveransen eller ikke. Oppdragsgiver skal også ha anledning til å bestille opsjonen i etterkant av inngåelse av kontrakt. Opsjonskrav skal prises som tillegg og ikke inngå i den totale prisen. |
Info (I) | Skal ikke besvares i trinn I av konkurransen. Dersom tilbyder går videre til trinn II, der tilbyder inviteres til å presentere tilbudet, skal kravet besvares. |
Alle kravene i kravtabellen skal besvares (bortsett fra Info (I)). For hvert krav skal Leverandøren angi i
hvilken grad løsningsforslaget sitt kan tilfredsstille kravet (Ja, Nei eller Delvis). For krav som besvares med delvis, må det særskilt utdypes hva som ikke kan tilfredsstilles. For krav som tilfredsstilles eller delvis tilfredsstilles må Leverandøren gi utfyllende informasjon om hvordan kravet tilfredsstilles.
Leverandøren bes i innledningen til svarbeskrivelsen om å gi en overordnet beskrivelse av løsningen totalt, slik den tilbys og i samsvar med kravene i denne kravspesifikasjonen. Leverandørens beskrivelse kan omfatte tekst, figurer og referanser til de enkelte kravelementer, der dette er naturlig.
Leverandøren bes i innledningen til de enkelte underkapitler til svarbeskrivelsen om å gi en utfyllende beskrivelse av det aktuelle løsningsområdet. Leverandørens beskrivelse kan omfatte tekst, figurer og referanser til de enkelte kravelementer, der dette er naturlig.
Der leverandøren f.eks. av plasshensyn ikke finner det hensiktsmessig å legge løsningsbeskrivelsen inn i selve kravtabellen, kan beskrivelsen merkes med ID og tas inn rett under kravtabellen.
Skissen gir en beskrivelse av kravtabellenes innhold (tidsplanen er tentativ):
Høsten 2014/Vinter 2015
sept
okt
nov
des
jan
Front-end (Del 1, hovedleveranse)
•Design/utforming av hovedsider og undersider (som HTML5, CSS og JavaScript)
•Strukturell navigasjon
•Responsivt design
•Tilfredstille krav til Universell Utforming
Back-end (Del 2, opsjon)
•Teknisk plattform for nettstedene, utvikling av CMS
•Digitalt kart over Maihaugenområdet
•Bookingløsning, kjøp av adgangsbilletter og påmelding til aktiviteter
•Migrering av innhold fra gammel til ny webløsning
1.3 Kravspesifikasjon – Del 1 (Front-end) - Hovedleveranse | |||
ID | Funksjonelle krav | Tekniske krav | Kravtype (M/B/O/I) |
N01 | Overordnet behov Gi en utfyllende beskrivelse på hvordan overordnet behov (beskrevet i kap 1.1) er tenkt løst. | Front-end skal utvikles og leveres kodet i HTML5, CSS og JavaScript. Kode skal valideres mot X0X.xxx | M |
N02 | Egne nettsteder Xxxxxxxxx.xx skal deles opp i egne nettsted som skal fremstå som egne unike websider. • Maihaugen (xxxxxxxxx.xx) • Xxxxxxxxxxxx Xxxxxxxxx hjem Aulestad (xxxxxxxx.xx) • Xxxxxx Xxxxxxx hjem Bjerkebæk (xxxxxxxxx.xx) • Norges Olympiske Museum (xx.xxxxxx.xx) • Postmuseet (xxxxxxxxxx.xx) • Maihaugsalen (xxxxxxxxxxxx.xx) • Lillehammer Museum (xxxxxxxxxxxxxxxxx.xx) | M | |
N03 | Egne nettsteder De skal ha egen unik design ut fra deres designprofil og en oppbygning og visuell profil som retter seg mot museets målgruppe. (Leverandør må ha kontakt med SLM’s designbyrå for | Det er ønskelig at fargeprofiler styres av stilsett (CSS) og at løsningen har begrenset innslag av grafiske elementer i rammeverket. Når grafiske elementer benyttes skal disse være optimalisert | M |
avklaringer ang designprofilen) | for web og implementeres som .jpg, .png og/eller .gif. Hvert nettsted skal også ha et favicon utfra grafisk profil. | ||
N04 | Egne nettsteder Samtidig som nettstedene skal ha sitt unike design og uttrykk må det vises at de har en samhørighet med de andre museene. | M | |
N05 | Egne nettsteder - Maihaugsalen • Etablere eget nettsted for Maihaugsalen • Dele opp i to hovedområder: o Konsertsal (konserter og forestillinger) o Konferanser og events • Fremheves som kulturhus. Ønsker å skille Maihaugens program og Maihaugsalens program. | M | |
N06 | Fleksibilitet på første sidene Nettstedenes startsider må kunne ha fleksibilitet for webredaktør (For eksempel flytte/bytte på moduler. Uavhengig om det er tekst eller bilde). Designet må derfor ta høyde for et dynamisk uttrykk. | Det skal ikke foreligge noen tekniske begrensninger i layout/design som forhindrer tilgjengelighet, i forhold til responsiv visning eller Universell Utforming. | M |
N07 | Modul på siden for visning av eksternt innhold Det må være mulig å hente og vise fra eksterne | Elementer som viser innhold fra eksterne informasjonskilder |
informasjonskilder (bilder og tekster). Det er ønskelig med forslag på hvordan eksternt innhold kan integreres på nettstedene. For eksempel en modul/et vindu til museumsrelatert innhold på eksterne nettsider. Eksterne nettsteder med relevant innhold er blant annet Wikipedia og xxxxxxxxxxxxxx.xx | må tydeliggjøres i forhold til opphavsrettigheter, hvis dette er påkrevd. | M | |
K01 | Kalender Nettstedene skal ha en egen «hva skjer» - Kalender. Skal vises på nettstedene for Maihaugen, Bjerkebæk, Aulestad, Norges Olympiske Museum og Maihaugsalen. Kalenderne skal fremstå som fristende og spennende. Skoletilbudet skal også ha egen kalender. Den skal være på en av undersidene til xxxxxxxxx.xx (Webredaktør må kunne, ved behov, ha muligheten til å fremheve enkelte kalenderaktiviteter på forsiden). Kalenderne, innhold: Gjelder for alle aktiviteter, konserter og tilstelninger på museene (inkl Maihaugsalen og kalender for skoler): • Aktiviteter med billettkjøp • Aktiviteter man kan melde seg på • Aktiviteter som hverken har billettkjøp eller påmelding knyttet til seg. | Det er ønskelig at kalenderen ved visning på norsk språk settes med følgende format: DD-MM-ÅÅÅÅ Kalender skal følge gjeldende formater i henhold til ISO 8601 på alle fremmedspråk i løsningen: YYYY-MM-DD | M |
K02 | Kalender - funksjonalitet |
Dagens program skal være sentralt på første side. Museumsprogrammet skal være en del av kalenderen. Det skal være mulig å fremheve nærstående arrangement med bilde og video. Det må være mulig å søke i kalenderen. Aktiviteter og arrangement skal kunne deles inn i kategorier. For eksempel: • Type event: konsert, guidet tur. • Passer for: barn 3-7 år, barn 8-12 år, tenåringer, hele familien. | M | ||
K03 | Kalender – visuelt Det er ønskelig med forslag på løsning for kalender i form av skisser. Vise hvordan kalender-elementene fremstår visuelt samt en beskrivelse av funksjonalitet som viser mulighetene. Det må legges vekt på at kalenderen skal friste til besøk på museet. Ta i bruk juni-programmet for Maihaugen i forslaget. | I (kun en del av trinn II av konkurransen) | |
B01 | Booking. Det skal være mulig å kjøpe/booke adgangsbilletter via weben. SLM er i testfasen for å vurdere om de skal ta i bruk xxxx://xXxxxxxx.xx. | Booking av adgangsbilletter skal også være tilrettelagt for visning på håndholdte enheter og fungere på standardiserte nettlesere for mobiler og nettbrett. Dette gjelder for både iOS og Android plattformer. | O |
Dette må komme tydelig frem i designet. | |||
B02 | Booking Det skal være mulig for bruker å kunne printe ut billetten eller få en kode på mobilen og «scanne seg inn» på museet. Det er ønskelig med et design som visualiserer hvordan dette er tenkt løst. | Koder for mobil hentes direkte fra eBillett. Dersom eBillett har støtte for whitelabeling er det ønskelig at Leverandør utvikler et forslag til visuelt uttrykk. | M |
B04 | Booking Det skal være mulighet til å melde seg på aktiviteter som for eksempel omvisninger eller guidet tur (aktiviteten er inkludert i inngangsbilletten). Funksjonen må være knyttet opp mot nettstedenes aktivitetskalender. | Booking av aktiviteter skal også være tilrettelagt på håndholdte enheter og fungere på standardiserte nettlesere for mobiler og nettbrett. Dette gjelder for både iOS og Android plattformer. | M |
P01 | Tilbud for bedrifter Visning av de unike bedriftstilbudene på en god måte • Konferanser • Events Tilbudene kan fremstå som «pakker». Ferdige produkter som konferanseansvarlig kan bestille. Fremheve tilbudet som en ny og spennende setting for konferansen samtidig som man kan være trygg på at konferansefasilitetene og rammen rundt er profesjonelt | M |
håndtert. Påmelding skjer pr telefon/e-post | |||
R01 | Responsivt design og krav om brukervennlighet Det er ønskelig at tilbudet inneholder skisser med forslag for nettstedene med responsivt design for: PC, nettbrett og smartphones. Nettsiden skal utformes på en slik måte at man får optimal utnyttelse av skjermstørrelsen, uten at dette går ut over brukervennlighet og tilgjengelighet. | • Nettsiden må overholde tilgjengelighetskriteriene beskrevet i WCAG 2.0 og basere seg på etablerte webstandarder for å sikre tilgang for flest mulig, uavhengig av fysiske eller psykiske begrensninger. Leverandør skal forholde seg til retningslinjene som er definert av Difi (Direktoratet for forvaltning og IKT). • Løsningen skal uten større avvik kunne vises på de mest utbredte smarttelefoner, nettbrett og datamaskiner. Operativsystemer som må støttes er iOS (Apple iPad og iPhone), Android , Windows Mobile, OS X og Windows OS. Nettlesere som må støttes er Internet Explorer (IE 9 eller høyere), Firefox (4 eller høyere), Safari (4 eller høyere), Opera (9 eller høyere) og Chrome (22 eller høyere for PC/Mac, 18 eller høyere for Android og 21 eller høyere for iOS). • Malverket og løsningen skal generes som HTML5 og valideres mot X0X.xxx Oppdragsgiver stiller krav til bruk av validert HTML- kode som sikrer universell tilgjengelighet på tvers av tekniske plattformer og nettleserversjoner. • Malverket skal ikke inneholde fremmedelementer som for eksempel Adobe Flash, QuickTime eller Silverlight. | M |
• All funksjonalitet i løsningen skal vises/kunne benyttes selv om script, applets eller andre programmerte objekter er avslått eller ikke støttes. • Løsningen skal kodes med UTF-8 tegnsett. • Nettstedet skal utvikles med semantisk kode for blant annet definere overskrifter, avsnitt og lenker. | |||
D01 | Digitalt kart over Maihaugen-området Det må lages et digitalt kart over Maihaugen-området. Kartet skal være klikkbart der man kan se bilder, video og tekst om hus og severdigheter på området. Kartet skal kunne zoomes. Dagsprogrammet for Maihaugen skal linkes inn i kartet slik at hendelser for dagen vises på kartet, der det skjer, med tid og beskrivelse av aktiviteten. | Oppdragsgiver krever at digitale karttjenester som skal benyttes i løsningen baseres på Google Maps API. | O |
S01 | Søk Nettstedene skal ha en søkefunksjon. Søk skal være mulig fra forsidene. | Søkeboks skal tilpasses med auto-complete forslag | M |
M01 | TripAdvisor og Facebook Modul på nettstedene mot TripAdvisor og Facebook. | Løsningen skal ha mulighet for å legge til deling av innhold mot Facebook. Det skal være enkelt å legge til deling mot andre sosiale kanaler om det er ønskelig. Ved bruk av widgets skal disse beskrives i løsningsforslaget. | M |
M02 | Nyhetsbrev Mulighet for påmelding til nyhetsbrev på nettstedene. | Det må legges på en Captcha-kode for å forhindre |
Nyhetsbrevet skal være kun på norsk og likt for alle målgrupper. | registreringer av spambots. | M | |
M03 | Videomodul Hvor det er enkelt å sette inn eget innhold eller video som er plassert på andre videotjenester (Vimeo og Youtube) | Løsningen skal ha mulighet til å spille av video i HD-kvalitet, og mulighet for visning i fullskjerm-modus i alle enheter. | M |
M04 | Instagramfeed Det skal være mulig å legge til Instagramfeed på nettstedene. | Ved bruk av widgets skal disse beskrives i løsningsforslaget. | M |
F01 | Forslag, tilrettelegging for anbefalinger Forslag til løsning fra tilbyder: Hvordan museene kan få publikum, etter at de har besøkt museene, til å anbefale til familie og venner. For eksempel incentiv for å anbefale på sosiale medier? – Aktiv handling ved exit fra museene? Gjelder også konferansegjester. | M |
1.4 Kravspesifikasjon – Del 2 (Back-end) – Opsjon | |||
ID | Funksjonelle krav | Tekniske krav | Kravtype (M/B/O/I) |
N01 | Overordnet behov Gi en utfyllende beskrivelse på hvordan overordnet behov er tenkt løst | Standarder Det skal benyttes åpne standarder, metoder og mekanismer for integrasjon av deltjenester. All integrasjon skal dokumenteres i systemdokumentasjon. Fleksibilitet for fremtidige endringer For å sikre en fortsatt attraktiv opplevelse for brukerne bør løsningen være fleksibel og kostnadseffektiv med hensyn til fremtidige endringer i brukerkrav og endringer knyttet til ny teknologi. Leverandørens krav til Oppdragsgiver Leverandøren må beskrive hva som er forventet og påkrevd av Oppdragsgiver for henholdsvis opplæring, installasjon, oppsett og akseptansetest. Installasjon Leverandøren skal beskrive hvilke installasjoner som må gjennomføres og hvordan de planlegges gjennomført. Leverandøren skal bistå ved oppstart av løsningen og bistå i | O |
konfigurering og oppsett av løsningen i henhold til Xxxxxxxxxxxxxx mål, krav og behov. Akseptansetest Leverandøren skal spesifisere hvilke akseptansetester som må gjennomføres og hvordan de planlegges gjennomført. | |||
N07 | Modul på siden for visning av eksternt innhold Det må være mulig å hente og vise fra eksterne informasjonskilder (bilder og tekster). Det er ønskelig med forslag på hvordan eksternt innhold kan integreres på nettstedene. For eksempel en modul/et vindu til museumsrelatert innhold på eksterne nettsider. Eksterne nettsteder med relevant innhold er blant annet Wikipedia og xxxxxxxxxxxxxx.xx | Leverandør skal beskrive hvordan dette er tenkt implementert i moduler og opplyse om hvilke APIer som ligger til grunn. | O |
K04 | Kalender – publisering Informasjon om aktiviteter hos museene legges i dag inn i flere publiseringssystemer: • Xxxxxxxxx.xx (EPIServer) • GDPuls (Origo) • Xxxxxxxxxxx.xxx (Tellus) Det er ønskelig at publiseringen gjøres på et sted og at det er i Tellus. Informasjonen skal vises i museenes kalendere. Hvis SLM velger å ikke ta i bruk Tellus skal løsningen for kalender etableres i det nye publiseringssystemet for | Tellus har et API for å tilgjengeliggjøre registrert data på andre nettsteder. Leverandør må forholde seg til gjeldende API og ta kontakt med Xxxxxx for tilgang til dette. | O |
nettstedene. | |||
B01 | Booking Det skal være mulig å kjøpe/booke adgangsbilletter via weben. SLM er i testfasen for å vurdere om de skal ta i bruk eBillett. Hvis SLM velger å ikke ta i bruk eBillett må det etableres en ny kjøpsløsning på nettstedene. | Ved installasjon av betalingstjenester skal Leverandør informere MuseumsIT om nødvendige sikkerhetsmessige tiltak på serverside i forhold til benyttet programvare. | O |
B02 | Booking Det skal være mulig for bruker å kunne printe ut billetten eller få en kode på mobilen og «scanne seg inn» på museet. | Løsningen må konfigureres mot eBillett i forhold til håndtering av QR-koder. | O |
B03 | Booking Booking-modulen skal ha en kobling mot museets økonomisystem slik at kjøp via web-bookingen automatisk registreres på rett sted (må registreres som billettinntekt i museets økonomisystem, Visma Business). | Løsningen skal sørge for en sikker utveksling av data mot Visma Business. Oppdragsgiver ønsker en detaljert utredelse for hvordan dette teknisk skal løses. | O |
B04 | Booking Det skal være mulighet til å melde seg på aktiviteter som for eksempel omvisninger eller guidet tur (aktiviteten er inkludert i inngangsbilletten). Funksjonen må være knyttet opp mot nettstedenes aktivitetskalender. | Oppdragsgiver skal ha tilgang til å hente ut rapporter over påmeldte fra CMS og med mulighet for eksport til PDF. Rapporten må kunne sorteres ut fra kategoritype (For eksempel navn på aktiviteten og dato). Det er ønskelig at det legges opp til en arkivering av rapporter for å ivareta | O |
Det må være mulig for museumsadministrasjonen å enkelt kunne kjøre ut en rapport over påmeldte. | historikk. | ||
S01 | Søk Nettstedene skal ha en søkefunksjon. Søk skal være mulig fra forsidene. | Det skal være mulig å knytte et sett med metadata til artikler, dokumenter og filer. Metadata skal danne grunnlag for avansert søk. Metadata skal også danne grunnlag for å knytte informasjonselementene opp i informasjons¬strukturer. | O |
P01 | Publiseringsløsning (CMS) Et publiseringsprogram for alle nettstedene | Løsningen skal, uavhengig av opsjonen, driftes av MuseumsIT. Leverandøren må forholde seg til selskapets krav til plattform, sikkerhet og rutiner i forhold til utvikling og implementasjon av løsningen. | O |
P02 | Publiseringsløsning (CMS) Programmet skal være fleksibelt og enkelt i bruk | Plattform Oppdragsgiver krever at løsningen utvikles i CMS som baseres på fri programvare komponenter. Dersom Leverandøren har egen spesialtilpasset lisens for åpen kildekode skal dette opplyses. CMS må kunne kjøre på en eller flere av følgende teknologier: • OS: CentOS 6.5 x86_64 • DB: Postgresql 9.3 eller Mysql 5.1 • Apache/NginX • Php 5.3.x / 5.4.x • Python 2.7.x / 3.x • Openjdk >= 1.7 • Javascript | O |
MuseumsIT stiller med staging- og produksjonsserver. Applikasjonen distribueres av drift på en staging server, når applikasjonen godkjennes distribueres den videre til produksjon . Applikasjonen kan overgis drift enten i form av zip-filer / tar- filer / gz-filer eller via utsjekking fra versjons kontrollsystemer, som for eksempel git eller subversion. I tilfeller der det blir brukt versjonskontroll skal det dokumenteres, av utviklere, hvilken branch som er produksjon / release og hvilken branch som holder utvikling. Det skal tagges med release nummer for hver versjon som ender opp i produksjon. Installasjon Installasjonsbeskrivelse for applikasjonen, avhengigheter av moduler og hvilke versjoner som er brukt i utvikling må spesifiseres nøyaktig. Dersom det skal benyttes Python så gjør vi oppmerksom på at dette krever spesiell kontroll på moduler, og det foretrekkes bruk av pip- og requirementsfiler. Vedlikehold og rettelse av feil |
Applikasjonen må kunne følge oppdateringer av det underliggende rammeverket for å tette sikkerhetshull samt for portabilitet / kompatibilitet med fremtidig oppdatering av programvare på serveren. Applikasjonen skal aldri ligge mer enn 2 versjoner etter siste versjon av underliggende rammeverk / CMS. For kritiske sikkerhetshull som oppdages må applikasjonen kunne oppdateres raskt. Det må være en vedlikeholds avtale for applikasjonen som spesifiserer forventet tid for endringer, endringer ved feil og endringer ved kritiske feil. For kritiske feil som fører til nedetid for applikasjonen må det være tilgang på rask utbedring. Drift må ha et kontaktpunkt, f.eks. en epost adresse, der de kan melde om feil som oppdages i applikasjonen. For kritiske feil kan det være nødvendig med telefon nummer i tillegg. Adgangskontroll for maskin- og programvare Leverandørens maskin- og programvare knyttet til produksjon og distribusjon må ha tilfredsstillende adgangskontroll som hindrer uønsket tilgang for eksterne. Tilsvarende må produksjons- og distribusjonsdata, være tilfredsstillende sikret mot uønsket tilgang i tilfelle utstyret |
kommer på avveie eller lignende. Sikring av maskin- og programvare Leverandørens maskin- og programvare knyttet til produksjon og distribusjon må være sikret tilfredsstillende mot skadelig programvare og virus. Sikring av betalingsløsninger Ved eventuell installasjon av betalingstjenester skal Leverandør informere MuseumsIT om nødvendige sikkerhetsmessige tiltak på serverside i forhold til benyttet programvare. Sikring av integritet Innhold, som tilgjengeliggjøres av henholdsvis Leverandør og Oppdragsgiver skal ikke kunne endres av utenforstående. Adgangskontroll for administrator Administratorfunksjonalitet som redigering og publisering av innhold skal begrenses til dem som har fått tildelt tilgang. Det må gjennomføres tilfredsstillende autentisering av administratorer førvedkommende får tilgang. Tildeling av administratorfunksjonalitet skal tilsvarende være regulert. |
P03 | Publiseringsløsning (CMS) Webredaktør skal ha stor frihet i hvordan hun ønsker å vise innhold på sidene | Valgt CMS må ha mulighet for å benytte ulike oppsett i artikler både gjennom definerte maler og plassering av mediaelementer. MuseumsIT sin interne filserver skal benyttes for lagring og fremvisning av alle typer bilder, videofiler og andre filtyper. Filserver konverterer video og lyd til ulike formater som muliggjør avspilling på ulike enheter. Filserveren tilbyr et api der man bestiller en upload-key, som sendes med når man laster opp filen (på grunn av autentisering mot serveren). Ved fremvisning av bilder spesifiseres ID på bildet og hvilken størrelse som ønskes. For avspilling av lyd eller video, bestilles det avspillings-url for aktuell fil, som gir tilbake url for avspilling i ulike formater. Mer detaljert dokumentasjon på løsningen gis ved behov. | O |
P04 | Publiseringsløsning (CMS) Nettstedene skal fremkomme på flere språk hva som er for xxxxxxxxx.xx i dag, som kun er på norsk og engelsk. Det er ønskelig at tilbyder har forslag til generell støtte for språk i publiseringsløsningen. | Oppdragsgiver skal selv ha mulighet til å administrere språk på en enkel måte fra back-end. Alle tekstbaserte elementer i løsningen skal ha støtte for ulike språk. Løsningen må være fleksibel slik at det er enkelt å legge til nye språk for artikler, menyer, metadata og moduler. Leverandøren skal gi en utfyllende beskrivelse av hvordan dette tilrettelegges i sitt forslag. | O |
P06 | Flytting av innhold fra dagens web Alt innhold på dagens web må videreføres til de nye nettstedene uten at webredaksjonen manuelt må publisere innhold. Alt overført innhold må fremstå med et greit oppsett og med eventuelt tilhørende bilder og fungerende web-linker. Det er ønskelig med et tilbud på denne jobben. SLM kan deretter ta stilling til om de gjør dette selv eller kravet blir en del av leveransen. | MuseumsIT kan bistå med dump av database fra dagens løsning dersom dette forenkler arbeidet til Leverandør. | O |
1.5 Kompetanseprofil til leverandørens tilbudte team
Leverandøren bes komplettere skjema med leverandørens team/organisasjonen som kreves for gjennomføring av prosjektet med kompetanseprofil. Nøkkelpersoners erfaring og kompetanse, herunder relevant erfaring fra liknende leveranser, skal dokumenteres ved å vedlegge CV. Referansene som angis skal beskrives ytterligere i punkt 1.6.
Den enkelte konsulents kompetanseprofil, CV og referanseprosjekter vil bli evaluert. Leverandør må fylle inn et nivå (1, 2 eller 3).
Nivå 1: Vedkommende har høy kompetanse innen området og har relevant erfaring. Har gjennomført oppdrag med høy kvalitet. 5-10 års erfaring på området.
Nivå 2: Vedkommende har kompetanse innen området og har relevant erfaring. 2 til 5 års erfaring på området.
Nivå 3: Vedkommende har kompetanse innen området og har relevant erfaring. 1 til 2 års erfaring på området.
Kompetanseområde: | Grafisk design | Prosjektleder- kompetanse | Interaksjons- design | System- utvikling | Annet | CV* | Referanseprosjekt ** |
Leveranse av Front-end: | |||||||
Navn på tilbudte konsulenter: | Nivå 1-3 | ||||||
Leveranse av Back-end: | |||||||
Navn på tilbudte konsulenter: | Nivå 1-3 | ||||||
* Sett en x i feltet for å indikere at konsulentens CV er vedlagt tilbudet. Konsulentens standard CV er tilstrekkelig under den forutsetning at opplysninger om vedkommendes arbeidserfaring, formell utdanning og prosjekter de siste 2 år er godt spesifisert.
** Vennligst oppgi minimum 2 og maksimum 5 referanseprosjekter per konsulent. For konsulenter med kompetansenivå 3 er det tilstrekkelig med 1-2 referanser
1.6 Leverandørens referansetabell
Leverandør bes komplettere skjema med tre tilsvarende leveranser de siste 5 år samt referanser og kontaktinformasjon.
Referanse firma | Referanse navn | Telefon og e-post | Verdi ekskl.mva | Tid/ periode | Nettsted | Prosjektbeskrivelse |
Referansearbeid legges ved tilbudet som egne vedlegg. Merk vedleggene med firmanavnet til referansen.