Innhold INNHOLD... 1 BILAG 1 KUNDENS KRAVSPESIFIKASJON... 2 1.1 BRUKERE OG BRUKSOMRÅDER... 2 Innledning... 2 Brukerebegreper og organisering av opplæring... 2 2 KRAV... 3 2.1 TYPE KRAV... 3 2.2 FUNKSJONELLE KRAV... 3 2.3 GENERELLE KRAV... 43 2.4 HOVEDFUNKSJONER... 4 2.5 KRAV TIL RAPPORTFUNKSJONALITET OG VISUALISERING... 4 2.6 KRAV TIL BRUKERGRENSESNITT (SØK, RAPPORTERING OG LOGGFUNKSJONALITET)... 6 3 KRAV TIL SYSTEM- OG BRUKERADMINISTRASJON... 6 3.1 KRAV TIL TILGANGSRETTIGHETER, ROLLER OG BRUKERE... 6 3.2 KRAV TIL SYSTEMKONFIGURASJON OG SYSTEMADMINISTRASJON... 7 3.3 YTELSE OG ANTALL BRUKERE... 78 4 TEKNISKE KRAV TIL TJENESTEKVALITET... 8 4.1 TEKNISKE KRAV, KLIENTER... 8 4.2 GRENSESNITT... 8 5 IKT-ARKITEKTUR... 9 5.1 FELLES IKT-ARKITEKTUR... 9 5.2 DRIFTSMESSIGE FORHOLD... 9 6 KRAV I FORBINDELSE MED TJENESTELEVERANSEN... 10 7 MERKANTILE KRAV... 10 8 KRAV TIL VEDLIKEHOLDSAVTALE/SUPPORT... 11 9 DRIFTSSPESIFIKASJON, OPPLÆRING, KURSING OG DOKUMENTASJON... 11 10 KRAV TIL BISTAND... 12 10.1 KONSULENTBISTAND OG OPPDRAG... 12 BILAG 2 LEVERANDØRENS LØSNINGSSPESIFIKASJON... 13 BILAG 3 KUNDENS TEKNISKE PLATTFORM... 14 BILAG 4 PROSJEKT- OG FREMDRIFTSPLAN FOR LEVERANSE AV VERKTØY... 1819 BILAG 5 TESTING OG GODKJENNING... 2122 BILAG 6 ADMINISTRATIVE BESTEMMELSER... 2223 BILAG 7 SAMLET PRIS OG PRISBESTEMMELSER... 2526 BILAG 8 ENDRINGER I DEN GENERELLE AVTALETEKSTEN... 2829 BILAG 9 ENDRINGER AV LEVERANSEN ETTER AVTALEINNGÅELSEN... 2930 VEDLEGG... 3031 1
Bilag 1 Kundens kravspesifikasjon Målet med avtalen: Avtalen omhandler et verktøy som fremstår som en rapport- og presentasjonsløsning. Overordnet funksjonalitet kan karakteriseres ved: - Rapportene vil inneholde styringsdata på utdanningsområdet på en visualisert måte. - Vise standardrapporter og tilrettelegger for kundens behov for egendefinerte rapporter og ad hoc-rapporter. - er tilrettelagt for kobling og bruk mot flere typer datakilder (kildesystem og datavarehus) Kravene i det følgende er fullstendig med hensyn til funksjonelle og tekniske krav som verktøyet skal tilfredsstille og som leverandøren slik leverandøren har beskrevet i bilag 2 og øvrige bilag har forpliktet seg til. Avtalen skal legge grunnlag for en effektiv og trygg leveranse og gi en ramme for samarbeid mellom kunde og leverandør i etableringsfasen frem til godkjenning og samarbeid knyttet til vedlikehold og mulig utvidet bruk av verktøyet. Innledning 1.1 BRUKERE OG BRUKSOMRÅDER For at leverandøren skal ha en forståelse av Kundens bruk av verktøyer innleder vi her med en beskrivelse av brukerbegreper som Kunden har etablert. Disse brukerne skal forstås hierarkisk slik at brukere med de mest avanserte rettighetene, også har samtlige rettigheter som er mindre avansert. Brukerebegreper og organisering av opplæring Aktører: Personer, enheter eller eksterne systemer som kan defineres med oppgaver/roller i forhold til verktøyet. Konkrete personer eller enheter kan opptre samtidig i roller knyttet til ulike aktører. Roller: I et verktøy kan begrepet roller spesielt knyttes til verktøyets autentiseringssystem, som identifiserer brukere og deres rettigheter. Verktøyet kan ha egne autentiseringssystemer, men må kunne knyttes til institusjonenes ordinære autentiseringssystemer, og brukernes roller bør kunne defineres der. Systemadministrator: Systemadministrator er UTVIKLER for standardrapportene systemet skal inneholde. Systemadministrator har brukerstøtte for institusjonenes superbrukere, og trenger derfor tilgang til data for de institusjonene de skal drive brukerstøtte for. Ekspertbrukere: Det vil være en ekspertgruppe for bruken av verktøyet. Denne vil bestå av et utvalg superbrukere fra 4-6 av institusjonene som bruker verktøyet. Ved behov kan andre institusjonsbrukere inkluderes i gruppen. Deres rolle vil være å definere hvilke rapporter som skal være standardrapporter. Superbruker: Roller skal innehas av en eller et fåtall personer ved den enkelte institusjon. Superbruker er UTVIKLER for internrapporter for institusjonen. og kan utvikle rapporter på vegne av institusjonen. Superbruker har førstelinje-brukerstøtte for brukere på den enkelte 2
institusjon. Superbruker skal kun ha tilgang til data fra egen institusjon. Superbruker skal opprette brukere og administrere roller på sin institusjon. Sluttbruker: Verktøyets sluttbrukere. Disse skal kun ha tilgang til ferdigutviklede rapporter. Sluttbrukeren skal ha tilgang til drillfunksjoner i rapportene og skal ha mulighet for å lagre rapportene med ulike utplukk. Det vil være mange ulike kategorier sluttbrukere. Noen vil kun forholde seg til et fåtall rapporter som viser situasjonen på et gitt tidspunkt. Andre brukere vil ha større behov for gode drillfunksjoner og utvalgsparametre. Sluttbruker skal kun ha tilgang til data for egen institusjon. Sluttbruker kan inngå i flere brukergrupper. Organisering av opplæring av personale: Systemadministrator og ekspertgruppe(se bilag 3 for beskrivelse av brukere) hos kunden skal gis nødvendig og tilstrekkelig opplæring i verktøyet til å kunne benytte verktøyet til å utvikle og gjøre tilgjengelig standardrapporter i verktøyet. Likeledes skal opplæringen være slik at de kan ivareta videre opplæring og hensiktsmessig forvaltning av verktøyets funksjonelle innhold. Driftsansvarlig hos kunden for verktøyet gis nødvendig og tilstrekkelig opplæring i de grensesnitt som verktøyet benytter for import og eksport av data slik at de selv kan foreta hensiktsmessig og sikker drift av systemet og aktiv forvaltning av systemets grensesnitt. Superbruker hos kunden vil bli opplært av systemadministratorer og ekspertgruppe hos kunden basert på dokumentasjon av de konfigureringene og rapporter som genereres ved etablering av løsningen. Brukerstøtte: Kunden vil selv etablere brukerstøtte til sluttbrukere, superbrukere og ekspertbrukere. Hvordan dette skal organiseres vil avklares i forbindelse med utrullingen av systemet. 2 Krav 2.1 TYPE KRAV Kravene er enten kategorisert som -krav eller BØR-krav. - : betyr et OBLIGATORISK krav. Svar JA(kravet oppfylles) eller NEI (kravet oppfylles ikke). Krav hvor det eksplisitt etterspørres spesifikasjon/beskrivelse er angitt i kravspesifikasjonen. - BØR: betyr en ØNSKET EGENSKAP. Svar JA (kravet oppfylles) eller NEI (kravet oppfylles ikke). Det er mulig å gi en beskrivelse av hvordan kravet oppfylles og om og evt. når kravet kan bli oppfylt. Krav hvor det eksplisitt etterspørres spesifikasjon/beskrivelse er angitt i kravspesifikasjonen. 2.2 FUNKSJONELLE KRAV Verktøyet skal ha flere bruksnivåer, med ulike behov: - Enkel bruk: Innebærer bruk av ferdige rapporter/dashbord med kun muligheter for å gjøre foreta utvalg (for eksempel å velge år/semester, fakultet/avdeling). - Rapportutvikling: Utvikling av nye rapporter/dashbord/portaler - Administrasjon og installasjon: Installasjon av verktøyet, administrasjon av brukere/roller, oppsett av sluttbrukerlag 3
2.3 GENERELLE KRAV Generelle krav ID Krav 2.3.1 Verktøyet skal være et standardsystem, Med standardsystem mener vi ferdigutviklede systemer. Standardsystemer kan bestå av ulike moduler som kan berike funksjonalitet, utvide grensesnitt og annet. Det skal gis en tydelig beskrivelse av hvilke elementer som inngår i tilbudet og hvilke elementer eller moduler som kan anskaffes i tilegg. 2.3.2 Verktøyet må kunne håndtere flere ulike juridiske enheter (institusjoner) Verktøyet må kunne brukes av flere institusjoner som kun har tilgang til institusjonens data og som hver har rettigheter til å opprette brukere, tildele roller og utvikle og distribuere rapporter for egen institusjon. Beskriv løsning. 2.4 HOVEDFUNKSJONER Hovedfunksjoner er rapporter og analyse i systemet. Krav til støtte for hovedfunksjoner ID Krav 2.4.1 Det må være mulig å definere og visualisere rapporter for superbruker/systemadministrator som grunnlag for videre analyse. Rapportene skal enten bli tilgjengeliggjort som standardrapport for alle institusjoner, for en enkelt institusjon eller en enkelt sluttbruker/ gruppe av sluttbrukere. Beskriv løsning 2.4.2 Beskriv eventuell analysefunksjonalitet i verktøyet BØR 2.4.3 Verktøyet skal være rollebasert slik at det kan benyttes av ulike brukerkategorier, f.eks. sluttbrukere og superbrukere. Spesifiser løsning for brukeradministrasjon, opprettelse og administrering av roller, grupper m.m. 2.4.4 Det skal være funksjonalitet for å vise rapporter på egne websider, portal, dashboard osv. Beskriv løsning. 2.5 KRAV TIL RAPPORTFUNKSJONALITET OG VISUALISERING I verktøyet skal det utvikles standardrapporter i tillegg til at den enkelte superbruker/utvikler skal kunne lage egne rapporter. Her beskrives krav til viktige egenskaper i forhold til rapportene. Krav til funksjoner for rapportgenerering og oppfølging ID Krav 2.5.1 Det skal være mulighet for flere grafiske og tabellariske fremstillinger i samme oversiktsbilde. Beskriv løsning. 2.5.2 Det skal være mulig å fremvise enkeltelementer i hovedtabellen, f. eks topp fem eller lignende. Beskriv løsning. 2.5.3 Det skal være mulighet for å generere aggregerte rapporter med drill-downeffekt. Beskriv løsning. 2.5.4 I tilfeller der rapportenes forekomster blir 5 eller lavere, er ikke lenger dataene tilstrekkelig anonymisert og det blir behov for å ivareta dette. Hvilke muligheter finnes i verktøyet for å løse dette? Beskriv løsning. BØR 4
ID Krav 2.5.5 Beskriv verktøyets sikkerhetsmekanismer for kryptering, anonymisering osv. 2.5.6 Superbruker/systemadministrator skal kunne velge om valgte filter skal vises for sluttbruker i overskriften i rapporten. Beskriv løsning. 2.5.7 Rapportgeneratoren må ha funksjon til å velge filter ved hjelp av enkle pek/ klikk eller rullegardinvalg for systemadministrator/superbruker. Dette må også være tilgjengelig for sluttbruker. Beskriv løsning. 2.5.8 Det må være mulig å lage formatterte rapporter og eksportere disse til Office og HTML. Beskriv løsning. 2.5.9 Ved eksport til andre standard programpakker som Office, bør man BØR fremdeles kunne benytte rapportens funksjoner. 2.5.10 Rapportenes SQL-kode må være tilgjengelig for superbruker/systemadministrator. Beskriv løsning. 2.5.11 Rapportens SQL-kode bør kunne endres av BØR superbruker/systemadministrator. Beskriv løsning 2.5.12 Det skal finnes et egnet felt hvor superbruker/systemadministrator kan legge inn beskrivelse av rapporter/dashbord som er tilgjengelig/leselig for sluttbruker. Beskriv løsning. 2.5.13 Verktøyet skal ha støtte for style sheets /maler, slik at rapporter får et BØR standardisert utseende. Beskriv løsning. 2.5.14 Verktøyet skal ha et utvalg av diagramtyper. Beskriv utvalget. 2.5.15 Under forutsetning av at det i løsningen er etablert standarder for presentasjon av rapporter som tabell og grafisk, skal brukere selv kunne veksle mellom grafisk og tabell fremstilling. Beskriv hvorledes dette gjøres. 2.5.16 Verktøyet bør vise hvilke rapporter/dashbord som er avhengig av et gitt felt BØR (impact-analyse) og hvilke kolonner som er kilder til et element i en rapport/dashbord (data lineage). Beskriv løsning. 2.5.17 Verktøyet bør kunne schedulere rapporter og dashbord slik at man kan BØR kjøre rapporter til fastsatte tider. Beskriv løsning. 2.5.18 Verktøyet bør kunne ta i bruk tabellrelasjonene fra kilde. Beskriv løsning. BØR 2.5.19 Tabellrelasjonene fra kilde som benyttes av verktøyet bør kunne vises og BØR manipuleres i verktøyet av systemadministrator og superbruker. Beskriv løsning. 2.5.20 Det må være mulig å dele lokalt utviklede rapportspørringer til andre institusjoner, slik at de kan benytte disse for sine institusjonsdata. Beskriv løsning for distribusjon. 5
2.6 KRAV TIL BRUKERGRENSESNITT (SØK, RAPPORTERING OG LOGGFUNKSJONALITET) Krav til egenskaper ved brukergrensesnittet ID Krav 2.6.1 Verktøyet skal ha et Web-basert brukergrensesnitt for sluttbrukere. Beskriv løsningen. 2.6.2 Design av rapportene for systemadministrator/superbruker må være skjermbasert, dra og slipp, fortrinnsvis syntaksfritt. Beskriv løsning. 2.6.3 Det skal finnes hjelpetekster i brukergrensesnittet ved utvikling av rapporter, administrasjon av verktøyet, brukergrensesnittet for sluttbruker m.m. på minimum engelsk, men det er ønskelig med norsk. 2.6.4 Det bør være mulig å legge inn egne hjelpetekster i rapporter/dashboards av BØR systemadministrator/superbruker som kan benyttes av sluttbruker ved bruk av rapporter/dashboards. Beskriv løsning. 2.6.5 Verktøyet skal kunne settes opp til å tilpasses ulike roller. Beskriv løsningen. 2.6.6 Hvilke muligheter finnes for individuell konfigurering for sluttbruker f.eks. BØR for å gjøre lokale tilpasninger i sin arbeidsflate som kan lagres. Spesifiser muligheter. 2.6.7 Beskriv eventuelle muligheter for logg, spesielt med tanke for logg av BØR responstider. 2.6.8 Verktøyet bør ha mulighet for søk i metadata og selve dataene. Søk i metadata er søk før man har kjørt rapporter, som hvilke rapporter finnes innenfor et gitt tema. Søk i selve dataene er søk etter at rapport er kjørt. Beskriv løsning. BØR 3 Krav til system- og brukeradministrasjon 3.1 KRAV TIL TILGANGSRETTIGHETER, ROLLER OG BRUKERE Rettigheter omfatter både funksjonsrettigheter (for eksempel retten til å kunne lage rapporter og hente ut datasett) og adgangsrettigheter (for eksempel retten til å lese data fra flere institusjoner). Funksjonsrettigheter styres på rollenivå. Adgangsrettigheter styres på brukernivå. Krav til tilgangskontroll og sikkerhet ID Krav 3.1.1 Dokumenter verktøyets datasikkerhet og dokumenter rutiner for å fange opp og korrigere eventuelle sikkerhetshull. 3.1.2 Beskriv hvordan brukeradministrasjon og tilgang håndteres i verktøyet av systemadministrator/superbrukere i henhold til spesifikasjoner i bilag 3. 3.1.3 Roller og tilganger må kunne administreres med et GUI med dra og slipp. Beskriv løsning. 3.1.4 IT-verktøyet må tillate bruk av brannmur. Beskriv løsning. 3.1.5 All tilgang til verktøyets funksjoner skal reguleres gjennom en unik brukeridentitet og brukerprofil (inneholder for eksempel brukerrolle, org.tilhørighet). Beskriv løsning. 6
ID Krav 3.1.6 Verktøyet skal kunne støtte ekstern autentisering basert på protokoller for autentisering gitt i bilag 3, slik som FEIDE og MinID, evt. skal det kunne utvikle slik støtte. Beskriv løsning eller beskriv muligheter for å utvikle slik støtte hvor det sies noe om tid og kostnad for en slik utvikling. 3.1.7 Verktøyet må støtte ekstern autorisasjon basert på protokoller for autorisasjon gitt i bilag 3. Alternativt skal verktøyet støtte provisjonering av autorisasjonsdata basert på standardisert import av tilgangsdata gjerne via en WebService basert på SOAP. Beskriv løsning. 3.1.8 Institusjonene skal selv kunne administrere tilgangskontroll på de forskjellige roller og nivåer på institusjonen. Systemadministrator skal ha tilgang til å gjøre dette for alle institusjoner. Beskriv løsning. 3.1.9 Superbrukere skal kunne definere rapporter og gjøre disse tilgjengelig for andre brukere på sin institusjon. Beskriv løsning. 3.1.10 Rettigheter bør kunne kopieres eller arves mellom brukergrupper på ulikt nivå i hierarkiet. Beskriv hvordan dette løses, samt hvordan en rettighet kan overstyre en annen. Beskriv løsning. 3.1.11 Det bør være mulig å ta ut rapporter pr rolle og/eller institusjon for å se hvilke rapporter som er knyttet til disse. Beskriv løsning. 3.1.12 Sluttbruker skal kun ha tilgang til data for egen institusjon. Superbrukere skal kun ha tilganger innenfor egen institusjon og institusjoner det er avtalt å samarbeide om forvaltning med. Systemadministrator skal ha tilgang til data for de institusjonene de skal drive brukerstøtte for. Beskriv løsning. BØR BØR 3.2 KRAV TIL SYSTEMKONFIGURASJON OG SYSTEMADMINISTRASJON Krav til systemkonfigurasjon og systemadministrasjon ID Krav 3.2.1 Verktøyet må ha unicode UTF8 støtte. Beskriv løsning. 3.2.2 Det skal være mulig endre navn på felter som kommer fra kilde. Det må også være mulig for den enkelte institusjon å endre navn på slike felter i ettertid på rapporter slik at de kan tilpasses bedre den enkelte institusjon hvis dette er nødvendig. Beskriv løsning. 3.2.3 Det skal være mulig å definere faste tekster i rapportene, som for eks. overskrifter. Beskriv løsning. 3.2.4 Det skal være mulig å definere tilleggsfelter som f.eks. egne beregninger utover felter hentet fra kilde. Beskriv løsning. 3.2.5 Verktøyet skal ha funksjonalitet for automatisk avlogging av en bruker som har vært inaktiv i et definert antall minutter. Beskriv løsning. 3.2.6 Det er ønskelig å kunne parametersette hvor mange funn som kan vises pr. BØR skjermbilde. Beskriv løsning. 3.2.7 Beskriv løsning for drift av brukeradministrasjon, samt hvordan testing og produksjonssetting kan være adskilt 3.3 YTELSE OG ANTALL BRUKERE 7
Krav til ytelse og skalering ID Krav 3.3.1 Verktøyet må ha en arkitektur som er i stand til å håndtere institusjonenes behov for bearbeiding av store datamengder og stort antall brukere i henhold til beskrivelser i bilag 3. Beskriv skaleringsmuligheter. 3.3.2 Hva slags high-availability-løsning fungerer sammen med verktøyet? Beskriv løsning. 4 Tekniske krav til tjenestekvalitet 4.1 TEKNISKE KRAV, KLIENTER Krav til tekniske krav for klienter ID Krav 4.1.1 Verktøyet skal ha en flerlagsarkitektur med et metadatalag som danner et felles grunnlag for brukere av rapporter/dashbord. Beskriv løsning. 4.1.2 Verktøyet må ha 0-klientversjon for sluttbrukere som bare skal kjøre ferdige rapporter (dvs. en browser-versjon). Beskriv løsning. 4.1.3 Verktøyet må ha en 0-klientversjon for superbrukere som skal utvikle rapporter (dvs. en browser-versjon). Beskriv løsning. 4.1.4 Det bør være støtte for lesetavle (tablet) med mer for å kunne lese/bruke BØR ferdigutviklede rapporter/dashboards. Beskriv løsning. 4.1.5 All funksjonalitet i tjenesten skal være minst støtte nettlesere gitt i bilag 3. Redegjør for rutiner for å sikre støtte til nyere versjoner når de kommer. 4.1.6 Websidene skal følge standarder for websider gitt i bilag 3. 4.1.7 Det skal være støtte for 64-bits arkitektur (gjelder applikasjonsserver). Beskriv løsning. 4.1.8 Beskriv løsning for cashing og in-memory-bruk (gjelder applikasjonsserver) 4.1.9 Repository/metadata og kildedata må kunne legges i database gitt i bilag 3. Beskriv løsning. 4.1.10 Verktøyet må kunne benytte VPD i database, se bilag 3, eller evt ha egen løsning for denne type håndtering. Beskriv løsning. 4.1.11 Applikasjonsserver må kunne bruke plattformer gitt i bilag 3. Beskriv løsning 4.1.12 Beskriv hvilke verktøy applikasjonsserver benytter som f. eks Resin, Apache, Jboss. Beskriv løsning. 4.2 GRENSESNITT Krav til grensesnitt mot andre systemer ID Krav 4.2.1 Beskriv muligheter for grensesnitt mot epostsystem. 4.2.2 Verktøyet må kunne lese fra Oracle-kilder 4.2.3 Verktøyet bør kunne lese de vanligste og mest utbredte kilder slik som BØR PostGreSQL, SQLserver, MySql og tekstfiler. Beskriv hvilke kilder man kan lese data fra. 4.2.4 Beskriv hvordan verktøyet kommuniserer med en database, er det applikasjonsserver som kommuniserer med databasen, tykk-klient osv.? Beskriv løsning. 8
5 IKT-arkitektur 5.1 FELLES IKT-ARKITEKTUR Forbruker- og administrasjonsdepartementet (FAD) har i rundskriv nr P 4/2009 (datert 11.09.2009) kunngjort at det vil bli stilt nye krav til planlegging av IKT-investeringer i staten. FAD har besluttet at ved utvikling av nye IKT-systemer eller ved vesentlig ombygging av eksisterende systemer skal disse utvikles i tråd med noen felles arkitekturprinsipper. Prinsippene er obligatoriske for statlige IKTinvesteringer (jf. Rundskriv P 3/2009 Fellesføringer i tildelingsbrevet for 2010). Direktoratet for forvaltning og IKT (Difi) er gitt i oppdrag å forvalte og videreutvikle prinsippene. Se mer: http://kvalitet.difi.no/ og http://www.w3.org/wai/ Gjeldende faktaark med Prinsipp for planlegging av IKT-løysinger (se vedlegg XX) er en sjekkliste for generelle arkitekturkrav som bør oppfylles og som vi ber leverandøren kommentere. Krav om felles IKT-arkitektur ID Krav 5.1.1 Tjenesteorientering: IKT-systemer skal bygges opp som en samling avgrensede delsystemer som legger til rette for mest mulig gjenbruk. 5.1.2 Interoperabilitet: IKT-systemer må kunne utveksle og dele data og informasjon med andre systemer gjennom standardiserte grensesnitt. 5.1.3 Tilgjengelighet: Elektroniske brukertjenester skal være universelt utformet, og brukerne skal kunne benytte disse uten hensyn til tid, sted og kanal. 5.1.4 Sikkerhet: Informasjon og tjenester skal tilfredsstille krav til konfidensialitet, kvalitet og tilgjengelighet. 5.1.5 Åpenhet: Offentlige IKT-systemer skal være basert på åpne eller godkjente standarder. Systemene skal ikke sette spesielle krav til teknologi hos brukerne. 5.1.6 Fleksibilitet: Forvaltningen skal etablere og utvikle IKT-systemer på en slik måte at de er forberedt på endringer i bruk, innhold, organisering, eierskap og infrastruktur. 5.1.7 Skalerbarhet: IKT-systemer skal være forberedt på endringer i antall brukere, datamengde og levetiden til tjenesten. 5.2 DRIFTSMESSIGE FORHOLD Krav til støtte for driftsmessige forhold ID Krav 5.2.1 Alle endringer i IT-verktøyet må skje kontrollert og gjøres til gjenstand for sikkerhetsmessig godkjenning og testing. Leverandøren må kunne vise til rutiner for systemvedlikehold og oppgraderinger. Oppgraderinger som Leverandøren leverer vil Kunden selv installere i testversjon, foreta verifisering før det settes i produksjon. Beskriv rutiner knyttet til levering av oppgradering og programvarevedlikehold. 5.2.2 Hvordan oppgraderes verktøyet? Kan en oppgradering foretas når verktøyet er oppe? Beskriv løsning. 5.2.3 Oppgraderinger må kunne gjøres av kundens systemadministrator og kundens driftsorganisasjon.. Beskriv løsning. 9
ID Krav 5.2.4 Beskriv teknisk spesifikasjon og krav til miljøene som kunden skal benytte til å drifte, utvikle/vedlikeholde/teste verktøyet og rapporter i henhold beskrivelser i bilag 3 og alternativ 1,2 og 3 i bilag 3 Videre forklar rutiner for produksjonssetting av rapporter i henhold til alternativ 1,2 og 3 i bilag 3. 5.2.5 For alle passord mellom applikasjonsserver og andre grensesnitt som f. eks databaser hvor passord er tatt i bruk, må passord kunne endres. Beskriv løsning. 5.2.6 Beskriv håndtering av passord i verktøyet. 6 Krav i forbindelse med tjenesteleveransen Krav til tjenesteleveranse ID Krav 6.0 Omfanget av nødvendig tjenesteleveranse må beskrives 6.1 Timeprisen for konsulenter skal være iht. kompetansenivå 6.2 CV eller andre opplysninger vedr kvalifikasjoner til det personell som skal BØR benyttes i leveransen skal være tilgjengelig for oppdragsgiver. Oppdragsgiver forbeholder seg retten til å godkjenne bruken av konsulenter. 6.3 Leverandør plikter å opprettholde tilbudt kompetansenivå og det antallet ressurser som er nødvendig for å gjennomføre leveransen uavhengig av bytte av konsulenter, ferieavvikling, permisjoner, sykdom m.m. 6.4 Det skal leveres terminvise timelister per konsulent, som i detalj viser hva som er gjort og til hvilken pris. 6.5 Det skal foretas kompetanseoverføring til institusjonsrepresentanter/ekspertgruppe, driftspersonell og systemadministratorer. Beskriv løsning. Beskriv kostnader i bilag 7. 6.6 Hver institusjon skal kunne kjøpe ekstra lisenser. Pris for ekstra lisenser utenom definert brukeromfang må spesifiseres av leverandør. Se bilag 3. 6.7 Omfanget av tjenesteleveranser skal være godkjent av kunden før igangsetting 7 Merkantile krav Merkantile krav ID Krav 7.1 Prismodellen for tilbudte verktøy må inkludere alle produkter, tjenester, lisenser, utvikling/tilpasning, installasjon osv som er nødvendig for at verktøyet kan implementeres iht. leverandørens løsningsbeskrivelse. 7.2 Lisensbestemmelser skal være faste i avtaleperioden, og være vedlagt til Avtalen. 7.3 Leverandørens målemetodikker for oppdragsgivers bruk av tilbudte lisenser må foreligge. 10
ID Krav 7.4 Leverandørens lisensbestemmelser i forbindelse med test, utvikling, recovery, standby osv må foreligge. 7.5 Detaljert beskrivelse av Leverandørens support & vedlikeholdsbetingelser, inkl tilgjengelig supportapparat og supportnivå inkl priser for de forskjellige supportnivåene pr lisenstype må foreligge 7.6 Kontrakter som skal benyttes for denne anskaffelsen er Difi s standardkontrakter for kjøp av Programvare, samt Difi s standard avtale for Support & vedlikehold 7.7 Spesifikasjon av opplæring inkl priser skal fremkomme. 7.8 Alle priser skal oppgis i NOK 7. 9 Betaling og forvaltningsansvar for lisenser inntrer først for Pilot og Full BØR implementering 7.10 Tilleggstjenester faktureres kun på bakgrunn av bestilling fra kunde, og skal alltid medføre en endringsordre fra kunde. En hver endring skal være skriftlig kontraktsfestet. 8 Krav til vedlikeholdsavtale/support Id Krav 8.1 Teknisk, funksjonell og Best-Practice support for driftspersonell og systemadministratorer. Beskriv tjeneste og gi pris på denne type support. 8.2 Beskriv innhold og omfang i tilbudt support og vedlikeholdsavtale. Denne skal også inneholde en overordnet beskrivelse av support organisasjonen og hvor den er lokalisert. 8.3 Vedlikeholdsavtalen må omfatte og inkludere oppgraderinger og nye versjoner av verktøyet. 9 Driftsspesifikasjon, opplæring, kursing og dokumentasjon (Avtalen punkt 2.1.2 Opplæring og avtalen punkt 2.1.1 Dokumentasjons og opplysningsplikt) Krav til brukerdokumentasjon og veiledningsmateriell Id Krav 9.1 All dokumentasjon ment for sluttbrukere skal være skrevet på norsk/engelsk. Dokumentasjon som kun er ment for superbrukere og teknisk personell kan være skrevet på engelsk. Beskriv tilgjengelige utførelser og formater for dokumentasjonen. 9.2 Det skal finnes komplett, detaljert, oppdatert brukerdokumentasjon i tillegg til oversiktlig og lettfattet brukerveiledning til verktøyet. Det er tilstrekkelig at dokumentasjonen gjøres tilgjengelig for kunden elektronisk. Oppdatering av dokumentasjonen skal helst foreligge før installasjon i kundens test, og helst 3 uker før endringer i tjenesten settes i produksjon. 11
9.3 Det bør være enkelt å skrive ut brukerdokumentasjon for både enkeltfunksjonalitet, og hele moduler / funksjonalitetsgrupper samlet. Utskrift av dokumentasjonen må danne et brukervennlig og pedagogisk alternativ for alle brukergrupper. 9.4 Det bør finnes en hjelpefunksjon tilrettelagt for søk etter et spesielt tema. Beskriv hvordan dette fungerer. 9.5 Det bør finnes rutiner for dokumentasjon av funksjonalitetsendringer av verktøyet. Beskriv rutinene. BØR BØR BØR Krav til opplæring Id Krav 9.6 Det skal være mulig å benytte seg av leverandørens opplæringstilbud i hele avtaleperioden. Opplæring kan ytes til personer med drifts-, opplærings- og forvaltningsoppgaver hos kunden. Beskriv hvorledes opplæringsaktiviteter kan koordineres, gjennomføres og prises. 9.7 Det er ønskelig med mulighet for nettbasert opplæring som e-læring. Beskriv BØR opplæringstyper med eventuelle påbyggingsmoduler. 9.8 Det må være en supportorganisasjon. Beskriv denne. 10 Krav til bistand Det er viktig å sikre at kunden får den støtte til implementering av verktøyet som behøves i forhold til tidsplan, verktøyets hensikt og evt. behov for prosessendringer. 10.1 KONSULENTBISTAND OG OPPDRAG Leverandøren skal på forespørsel og etter egen avtale yte kunden bistand til: - Bistand til optimalisering av kundens drift - Bistand Videreutvikling av kundenes felles driftsløsning av verktøyet - Kundespesifikke resultat av bistand og oppdrag med unntak av eventuell testing og implementering, skal gjøres tilgjengelig for Samarbeidstiltaket FS. 12
Bilag 2 Leverandørens løsningsspesifikasjon Leverandøren skal beskrive sin løsning i forhold til Kundens kravspesifikasjon i bilaget. Dette gjøres normalt ved at Leverandøren besvarer Kundens kravspesifikasjon punkt for punkt. Behov for oppgradering av Kundens tekniske plattform: (Dersom slik oppgradering er nødvendig for å utnytte leveransen skal Leverandøren påpeke dette her) Åpenbare feil, mangler eller uklarheter i Kundens kravspesifikasjon: (Dersom det er slike åpenbare feil, mangler eller uklarheter i Kundens kravspesifikasjon skal Leverandøren påpeke disse) Krav til Kundens medvirkning: Avtalen punkt 10.5 Fri programvare Fri programvare som benyttes i leveransen: Navn på fri programvare Fri programvarelisens Kopi av aktuelle fri programvarelisenser skal vedlegges Leverandøren redegjørelse for sin vurdering av hvorvidt den frie programvare kan krenke tredjeparts rettigheter: Virkning av videredistribusjon: (Leverandøren må oppgi hvis videredistribusjon innebærer at også andre deler av leveransen enn det som opprinnelig var fri programvare vil bli omfattet av vilkårene i en fri programvarelisens) 13
Bilag 3 Kundens tekniske plattform Driftsmiljø I relasjon til avtalens begrepsbruk skal ulike subjekter i bilag 3 forstås avtalemessig som kunden. Uninett drifter i dag alle FS-institusjonene i samarbeidstiltaket, med unntak av UiO, UiB, UiT, NHH, UNIS og NTNU. Disse har egne databaser. Dette innebærer at de som driftes av Uninett har en felles AD-katalog, de som er utenfor har egne. De som driftes av Uninett vil i løpet av 2013 tar i bruk VPD (Virtual Privat Database). Datavarehuset vil være kilde for et nytt rapport- og presentasjonsverktøy, i tillegg til rapportering direkte mot kildesystemet FS. Datavarehuset er delt opp i utvikling, test og produksjonsmiljø, og et verktøy må kunne ha tilsvarende miljøer. I datavarehuset finnes data fra FS, i tillegg til data for økonomi for UIO/UIB og forskning (CRISTIN). Brukeromfang og teknisk rammeverk Antall brukere: Antall brukere FS: Antall brukere hos institusjonene vil variere avhengig av den enkelte institusjons størrelse. Antallet brukere vil også være avhengig av hvor enkelt verktøyet oppfattes og hvor mange rapporter man vil få tilgang til via nettsider. Hver institusjon (54 stk) får tildelt lisens for en superbruker og en sluttbruker. Institusjoner med studenter over 5000 vil få tildelt lisenser for to sluttbrukere. Ved full implementering antas det at det vil være i underkant av ti systemadministratorer, 50-55 superbrukere og 65-70 sluttbrukere. Hver institusjon skal i tillegg kunne kjøpe ekstra lisenser. Pris for ekstra lisenser utenom definert brukeromfang må spesifiseres av leverandør. Antall andre brukere: Det kan i tillegg komme flere brukere gjennom opsjoner. Dette gjelder: o o Forskningsinformasjonssystemet CRIStin som er et verktøy for forskere og forskningsmiljøer i Norge for å registrere og profilere publikasjonsdata, prosjekter, enheter og kompetanseprofiler. Systemet brukes også til innrapportering av publikasjonspoeng. CRIStin har i dag ca 160 institusjoner. Økonomisystemene i UH-sektoren, herunder primært BOT-samarbeidet. BOT er et samarbeidsprosjekt mellom universitetene i Bergen, Oslo og Tromdheim. Datamengde o Datavarehus: Antall rader: 593.119.797 Antall tabeller: 255 14
o FS Antall GB: 389 Antall tabeller: 2585 pr institusjon Antall rader: 1 631 40 309 for stor institusjon (UIO), for mindre institusjon 5 757 698 rader (FSHIM?) Antall GB: ca 812 GB for 58 institusjoner (inkl minus 30% overhead ) Protokoller for autentisering: SAML2.0 Protokoller for autorisasjon: SAML2.0 eller LDAP Nettlesere: Firefox versjon 3.5, Internet explorer versjon 8, Safari versjon 4 eller nyere. Standard for websider: HTML 4.01/XHTML 1.0 standard eller nyere Applikasjonsserver: 64-bits arkitektur Plattform for applikasjonsserver: Red Hat 5 eller nyere alternativt Windows server 2008 R2 eller nyere Databaser: Oracle 11.2.x eller nyere versjoner. VPD- opsjon er tatt i bruk blant annet for å realisere institusjonsspesifikk tilgang til egne data, både for datavarehus og FS. Beskrivelse av kilder Datavarehus Kilde: Oracle Modellering: Stjernemodell Miljø: Utvikling, Test, Produksjon FS Kilde: Oracle Modellering: relasjonsdatabase Miljø: Utvikling, Test, Produksjon 15
LDAP for institusjo Veiledende bilag til SSA-K Alternativer arkitekturskisser som verktøyet skal realiseres i: Det ønskes en sentral innstallasjon av Applikasjonstjener uavhengig av kilder, evt at det blir to sentrale innstallasjoner av applikasjonstjener, en mot datavarehus og en for produksjonsbaser for FSkilder. Alternativ 1 er foretrukket løsning, men Levererandør bes om å få frem kostnad for Drift og innstallasjon m.m. for begge alternativene under. Alternativ 1 1. Pålogging: 3. Applikasjonstjener: Organisasjon velges av bruker Brukernavn og passord oppgis til Feide som etablerer en autentisert sesjon til verktøyet Det finnes 60 FS-institusjoner som potensielt vil benytte verktøyet. Samtlige støtter SAML2.0 enten ved at de er med i Feide eller via IDporten/MinID. Applikasjonstjener Mobil Browser Nettbrett Autentisering/autorisasjon Autentisering skal foregå ved hjelp av SAML2.0. Når støtte for SAML 2.0 er tilgjengelig for verktøyet kan protokollen også benyttes for autorisasjon. Kundene må tilgjengeliggjøre rolledata for relevant personell i avtalt attributt og på avtalt format i sin Feide-katalog (LDAP med Feide-skjema). Støtter ikke verktøyet autorisasjon via SAML2.0 må det foreligge støtte for oppkobling til eller innhenting av data fra multiple autoritative kildesystemer. 2. Feide har implementert en såkalt WAYF-tjeneste ( where-are-you-from ) som tillatter brukeren å velge hvilken vertsinstitusjon skal avgi autentiserings- og autorisasjonsdata. Feide sørger for at korrekt back-end (LDAP-katalog) velges på bakgrunn av angitt vertsinstitusjon. Verktøyet skal hente relevante data fra multiple, veldefinerte datasettsamlinger via spesifiserte grensesnitt SAML 2.0 FEIDE LDAP for institusjo LDAP for institusjo Datavarehus Felles Studentsystem (FS) UNINETT UiO UiT NTNU UiB KILDER 16
1. Pålogging: 3. Gitt at det pga av krav til sikkerhet og driftsløsning ikke er ønskelig at verktøyet skal kunne lese både fra datavarehus og direkte mot FS produksjonsbaser, kan det være en løsning å ha en applikasjonstjener for tilgang til data fra datavarehus og en for tilgang til data fra FS produksjonsbaser. Applikasjonstjener 1: Verktøyet skal hente relevante data fra et definert datasettsamling via spesifisert grensesnitt. Alternativ 2 Organisasjon velges av bruker Brukernavn og passord oppgis til Feide som etablerer en autentisert sesjon til verktøyet Det finnes 60 FS-institusjoner som potensielt vil benytte verktøyet. Samtlige støtter SAML2.0 enten ved at de er med i Feide eller via IDporten/MinID. Applikasjonstjener 1 Mobil Browser Nettbrett Applikasjonstjener 2 Autentisering/autorisasjon Autentisering skal foregå ved hjelp av SAML2.0. Når støtte for SAML 2.0 er tilgjengelig for verktøyet kan protokollen også benyttes for autorisasjon. Kundene må tilgjengeliggjøre rolledata for relevant personell i avtalt attributt og på avtalt format i sin Feide-katalog (LDAP med Feide-skjema). Støtter ikke verktøyet autorisasjon via SAML2.0 må det foreligge støtte for oppkobling til eller innhenting av data fra multiple autoritative kildesystemer. 2. Feide har implementert en såkalt WAYF-tjeneste ( where-are-you-from ) som tillatter brukeren å velge hvilken vertsinstitusjon skal avgi autentiserings- og autorisasjonsdata. Feide sørger for at korrekt back-end (LDAP-katalog) velges på bakgrunn av angitt vertsinstitusjon. SAML 2.0 FEIDE LDAP instit LDAP instit LDAP instit Applikasjonstjener 2: Verktøyet skal hente relevante data fra multiple, veldefinerte datasettsamlinger via spesifiserte grensesnitt Datavarehus UNINETT Felles Studentsystem (FS) UiO UiT NTNU UiB KILDER 17
Bilag 4 Prosjekt- og fremdriftsplan for leveranse av verktøy Oppgave Ansvar Tidsfrist Merknad Opplæring Leverandør 01.10.2013 Installasjon, brukeradm, bruk av verktøy, systemadm. tilgang Installasjon av verktøy Leverandør 01.10.2013 I samarbeid med Kunde for kompetanseoverføring av installasjon. Kompetanseoverføring skal sikre at kunden er i stand til å tilgjengeliggjøre verktøy for institusjonene som ikke er inkludert i akseptansetest. Akesptansetest Kunde 01.02.2014 Opplæring: Opplæring gis til et gitt antall brukere for et gitt antall institusjoner. Antall systemadministratorer: ca 10 Antall fra ekspertgruppe/institusjonsrepresentant: 6-10 Antall superbrukere:6 Antall sluttbrukere: 11 Antall institusjoner: 6 Installasjon av verktøy: Installasjon av verktøyet som tilgjengligjør verktøyet for et gitt antall bruker på et gitt antall institusjoner.verktøyet skal innstalleres med miljø for utvikling, test og produksjon. Akseptansetest: Skal teste at vertøy er levert i henhold til kravspesifikasjon. Antall systemadministratorer: 5 Antall fra ekspertgruppe: 6-10 Antall superbrukere:6 Antall sluttbrukere: 11 Antall institusjoner: 6 Avtalen punkt 2.1.1 Dokumentasjon, opplysningsplikt mv. Frist for levering av dokumentasjon for utstyr og standardprogramvare: 02.04.20122 Avtalen punkt 2.1.5 Tidsfrist for forberedelse av installasjon, og leverandørens avsluttende inspeksjon Frist for forberedelse til installasjon: 18
15.04.2013 Leverandøren skal ikke foreta en avsluttende inspeksjon av om fysiske og/eller tekniske forhold er slik at Leverandøren godkjenner at installasjon kan finne sted: (Angis dersom partene har avtalt at slik inspeksjon ikke er relevant for leveransen) Starttidspunkt for installasjon: 15.04.2013 Avtalen punkt 2.2.1 Plan for Kundens akseptansetest Frist for å utarbeide grunnlagsmateriale til akseptansetestplanen: 30.04.2013 Andre frister for akseptansetestplanen: (Fylles ut dersom partene avtaler andre frister enn det som følger av avtalen) Avtalen punkt 2.2.2 Definisjon av feilnivåer Følgende definisjoner av feil skal legges til grunn: (Fylles ut dersom partene avtaler andre definisjoner enn det som følger av avtalen) Avtalen punkt 2.2.4 Gjennomføring av Kundens akseptansetest Dato for påbegynnelse av Kundens akseptansetest: 02.05.2013 Dato for avslutning av Kundens akseptansetest: 31.05.2013 Avtalen punkt 2.2.6 Idriftsettelse Frist for at leveransen settes i ordinær drift: 30.08.2013 Partenes plikter i forbindelse med idriftsettelse: Avtalen punkt 6.1 Kundens ansvar og medvirkning Frister for Kundens medvirkning til leveransens gjennomføring:?? Avtalen punkt 11.5.2 Dagbot ved forsinkelse Frist det er knyttet dagbot til: (Fylles ut dersom partene har avtalt andre frister enn det som følger av avtalen) 19
Dagbotsatser: (Fylles ut dersom partene avtaler annet enn det som følger av avtalen) Løpetid for dagbot: (Fylles ut dersom partene avtaler annet enn det som følger av avtalen) Avtalen punkt 2.1.5 Tidsfrist for forberedelse av installasjon, og leverandørens avsluttende inspeksjon Frist for forberedelse til installasjon: (Dato) Leverandøren skal ikke foreta en avsluttende inspeksjon av om fysiske og/eller tekniske forhold er slik at Leverandøren godkjenner at installasjon kan finne sted: (Angis dersom partene har avtalt at slik inspeksjon ikke er relevant for leveransen) Starttidspunkt for installasjon: (Dato) Avtalen punkt 2.2.1 Plan for Kundens akseptansetest Frist for å utarbeide grunnlagsmateriale til akseptansetestplanen: (Dato) Andre frister for akseptansetestplanen: (Fylles ut dersom partene avtaler andre frister enn det som følger av avtalen) Avtalen punkt 2.2.2 Definisjon av feilnivåer Følgende definisjoner av feil skal legges til grunn: (Fylles ut dersom partene avtaler andre definisjoner enn det som følger av avtalen) Avtalen punkt 2.2.4 Gjennomføring av Kundens akseptansetest Dato for påbegynnelse av Kundens akseptansetest: Dato for avslutning av Kundens akseptansetest: Avtalen punkt 2.2.6 Idriftsettelse Frist for at leveransen settes i ordinær drift: (Dato) Partenes plikter i forbindelse med idriftsettelse: Avtalen punkt 6.1 Kundens ansvar og medvirkning 20
Frister for Kundens medvirkning til leveransens gjennomføring: Avtalen punkt 11.5.2 Dagbot ved forsinkelse Frist det er knyttet dagbot til: (Fylles ut dersom partene har avtalt andre frister enn det som følger av avtalen) Dagbotsatser: (Fylles ut dersom partene avtaler annet enn det som følger av avtalen) Løpetid for dagbot: (Fylles ut dersom partene avtaler annet enn det som følger av avtalen) Bilag 5 Testing og godkjenning Her beskrives prosedyrer for testing og godkjenning med testkriterier, rutiner osv. Nedenfor følger punkter som avtalen henviser til dette bilaget. Avtalen punkt 2.2.3 Akseptansetestens omfang Kundens akseptansetest skal omfatte følgende tester: (Fylles ut dersom partene avtaler andre tester enn det som følger av avtalen) Akseptansetest etter erfaring fra pilot Avtalen punkt 2.2.4 Gjennomføring av Kundens akseptansetest Beskrivelse av gjennomføringen av Kundens akseptansetest: Avtalen punkt 2.3.1 Varighet Godkjenningsperiodens varighet: (Fylles ut derom det er avtalt annen varighet enn det som følger av avtalen) Avtalen punkt 2.3.2 Kundens undersøkelsesplikt Spesifisering av innholdet i godkjenningsperioden med konkret angivelse av de undersøkelsene som Kunden skal gjennomføre: Oppgave Ansvar Merknad Installasjon Kunde Bistand fra leverandør Leverandør tester Leverandør Leverandør spesifiserer Kunde tester Kunde Test iht. Kravspesifikasjon. Test periode 1 måned etter leverandørens test er gjennomført Godkjenning Kunde Etter test fra oppdragsgiver. 21
Kunden vil så langt det er mulig gjennomføre tester som verifiserer at alle krav i Bilag 2 er oppfylt. Særlig -kravene vil bli testet. Alle feil/avvik vil bli loggført og meldt til leverandøren fortløpende. Feil vil bli kategorisert i henhold til definisjonen i del 2, kontrakten kapittel 2.2.2 Undersøkelsesplikt. Når testing er gjennomført og leverandøren har rettet meldte feil, vil kunden lage en sluttrapport for testingen. Denne danner grunnlaget for evt. godkjenning. Verktøyet vil bli godkjent hvis det ikke inneholder kjente A- eller B-feil. I motsatt fall kan kunden oppheve kontrakten. Avtalen punkt 2.3.3 Håndtering av feil Prosedyrer om melding av feil fra Kunden til Leverandøren: Frist for utbedring av feil: (Fylles ut dersom partene har avtalt annen frist enn innen utgangen av godkjenningsperioden) Bilag 6 Administrative bestemmelser Bilaget brukes til å samle administrative rutiner for avtaleforholdet og samarbeidet mellom partene. Avtalen punkt 1.6 Partenes representanter Bemyndiget representant for partene: For Kunden Navn: Stilling: Telefon: E-post: For Leverandøren Navn: Stilling: Telefon: E-post: Prosedyrer og varslingsfrister for utskifting av bemyndiget representant: Avtalen punkt 5.2 Krav til Leverandørens ressurser og kompetansen Leverandørens prosjektleder: Navn: Stilling: Telefon: E-post: 22
Leverandørens nøkkelpersonell: Navn Stilling Kompetanseområde Avtalen punkt 5.3 Bruk av underleverandør Leverandørens godkjente underleverandører: Navn Org.nr Leveranseområde Avtalen punkt 5.4 Samarbeid med tredjepart Omfang av Leverandørens samarbeid med tredjepart valgt av Kunden: Avtalt vederlag: (Fylles ut dersom det er avtalt særlig vederlag for samarbeid med tredjepart) Avtalen punkt 5.5 Lønns- og arbeidsvilkår Aktuell tariffavtale samt samsvarserklæring: (Her identifiseres allmenngjort tariffavtale eller aktuell landsomfattende tariffavtale, samt inntas egenerklæring evt. tredjepartserklæring om samsvar mellom aktuell tariffavtale og faktiske lønns- og arbeidsvilkår for oppfyllelse av Leverandørens og eventuelle underleverandørers forpliktelser) Avtalen punkt 6.2 Bruk av tredjepart Kundens valgte tredjeparter: Navn Org.nr Arbeidsområde Avtalen punkt 16.3 Uavhengig ekspert Uavhengig ekspert valgt av partene: Navn Kompetanseområde Avtalen punkt 7.1. Møter Frist for innkallelse til møter: (Fylles ut dersom partene avtaler annen frist enn det som følger av avtalen) 23
Rutiner for gjennomføring av møter: (Her kan det f. eks spesifiseres hvem som skal møte, hvor møtene holdes, krav til referat, hyppighet osv) 24
Bilag 7 Samlet pris og prisbestemmelser Alle priser og nærmere betingelser for det vederlaget Kunden skal betale for Leverandørens ytelser skal fremgå av bilag 7. De samlede prisene og samlet sluttvederlag skal fremkomme her. Som en del av grunnlaget for totalprisen skal eventuelle spesielle betalingsordninger, rabatter, forskudd, delbetaling og avvikende betalingstidspunkt også fremgå Dersom partene avtaler annet enn det som følger av avtalen vedrørende vederlag, skal det spesifiseres i dette bilaget. Avtalen punkt 8.1 Vederlag Utgangspunktet er at prisene oppgis i norske kroner og eksklusiv merverdiavgift. Annet må spesifiseres særskilt. Det må oppgis hvorvidt prisen er per enhet eller f. eks per måned/år/avtaleperioden. Tabellene bør tilpasses prisstrukturen for leveransen. Totalkostnader: Element Referanse Totalkostnad Kjøp av lisenser Tabell 1 Etablering Vedlikehold TOTALT Tabell 1 Pris lisenser: Beskrivelse/navn Pris i NOK Antall Total (eksl. mva) Vedlikeholds kostnad Sum: Pris opplæring: Beskrivelse/navn Pris i NOK Antall Total (eksl. mva) Sum: Pris vedlikehold/support: Beskrivelse/navn: Tilbudspris i NOK Antall Total(eksl. Mva) Pris dokumentasjon: Beskrivelse/navn Pris i NOK Antall Total (eksl. mva) Sum: 25
Pris disposisjonsrett: Beskrivelse/navn Pris i NOK Antall Total (eksl. mva) Sum: Pris per time tjenester: Beskrivelse/navn Pris i NOK Antall Total (eksl. mva) Sum: Totalpris: Pris i NOK Antall Total (eksl. mva) Følgende utlegg dekkes: (Fylles ut dersom partene avtaler at utlegg skal dekkes, og her spesifiseres det hvilke utlegg som er omfattet) Reise- og diettkostnader skal dekkes etter følgende satser: (Fylles ut dersom partene avtaler at Statens satser ikke skal legges til grunn) Følgende reisetid kan faktureres: (Hovedregelen er at reisetid ikke faktureres. Reisetid kan derfor bare faktureres hvis det er avtalt. Det bør i tilfelle spesifiseres i hvilke tilfeller eller hvilke reiser som kan faktureres) Avtalen punkt 3.2. Endringsoverslag Priser og betingelse for tilleggsarbeid: Standardpriser for utarbeidelse av endringsoverslag: Avtalen punkt 8.2 Fakturering Betalingsplan: Øvrige betalingsvilkår: Vilkår for implementering av EHF (elektronisk handelsformat): Leveranse av elektroniske fakturaer skal skje på den av Direktorat for økonomistyring (DFØ) sin til enhver tid valgte kommunikasjonsmetode. Ved endring av kommunikasjonsmetode vil Leverandøren bli varslet seks måneder før nødvendig endring finner sted. Faktureringstidspunkt: (Fylles ut dersom partene avtaler annet enn det som følger av avtalen) 26
Fakturaadresse: Faktura skal merkes med referansenummer navn Avtalen punkt 8.5 Prisendring Avtalt prisendring: Timepris kan endres i henhold til følgende indeks: (Fylles ut dersom partene avtaler regulering etter annen indeks enn konsumprisindeksen, f. eks lønnsindeks for bransjen) Avtalen punkt 2.4 Avbestilling Avtalt avbestillingsgebyr: (Fylles ut dersom partene har avtalt annet avbestillingsgebyr enn det som følger av avtalen) Avtalen punkt 10.1 Eiendomsrett til utstyr Avtalt salgspant: (Fylles ut dersom partene har avtalt salgspant) Avtalen punkt 10.4.2 Disposisjonsrettens varighet (Disposisjonsretten løper uten tidsbegrensning etter avtalen. Dersom partene avtaler disposisjonsretten med løpende vederlag fylles det ut her.) 27
Bilag 8 Endringer i den generelle avtaleteksten Endringer til den generelle avtaleteksten skal samles i bilag 8, med mindre den generelle avtaleteksten henviser slike endringer til et annet bilag. Det er mulig å gjøre endringer til alle punkter i avtalen, også der hvor det ikke klart henvises til at endringer kan avtales. Endringene til avtaleteksten skal fremkomme her, slik at teksten i den generelle avtaleteksten forblir uendret. Det må fremkomme klart og utvetydig hvilke bestemmelser i avtalen det er gjort endringer til. Leverandøren bør imidlertid være oppmerksom på at forbehold og endringer i avtalen ved tilbudsinnlevering kan medføre at tilbudet blir avvist av Kunden. Punkt Erstattes med 28
Bilag 9 Endringer av leveransen etter avtaleinngåelsen Endringer av leveransen etter avtaleinngåelsen skal følge prosedyrene i kapittel 3 og gjøres skriftlig. Leverandøren skal føre en fortløpende katalog over endringene som utgjør dette bilaget. Nr Dato Endringen gjelder 29
Vedlegg Vedlegg: Statens Prinsipp for planlegging av IKT-løysinger 30
Faktaa Prinsipp for planlegging av IKT-løysingar Vedlegg 4: Statens Prinsipp for planlegging av IKT-løysinger Staten må sikre god utnytting av dei store IKT-investeringane. IKT-systema må leggje grunnlaget for enklare samhandling og utveksling av informasjon. Gode verkemiddel er gjenbruk og fleirbruk av IKTløysingane i forvaltninga og standardisering av mellom anna format og protokollar. I tillegg er det viktig å ha nokre felles prinsipp å halde seg til i utviklinga av nye IKT-løysingar i staten eller når eksisterande system skal byggjast om. Felles prinsipp sikrar at dei IKTløysingane som kvar etat eller sektor kjøper, utviklar og nyttar, vert underlagde sentrale krav om betre brukarorientering og meir samordning på tvers av offentlege einingar. Einsarta prinsipp for forvaltninga kan over tid gjere forvaltninga meir endringsdyktig ved at datasystem i verksemdene i større grad vert sette i samanheng med systema i andre verksemder. Det gjer integrering av systema enklare. Prinsippa vil vere eit rammeverk for ein felles IKTarkitektur i offentleg sektor. Denne arkitekturen må ha ein fornuftig balanse mellom universelle og lokale løysingar og ha respekt for at delar av forvaltninga treng spesialisert teknologi og eigne program for å få utført oppgåvene sine slik lovverket krev og dei politiske styresmaktene forventar. Regjeringa legg til grunn at statlege verksemder skal nytte følgjande prinsipp i planlegginga av nye IKTløysingar eller ved vesentleg ombygging av eksisterande løysingar: Tenesteorientering: IKT-system skal byggjast opp som ei samling avgrensa delsystem som legg til rette for mest mogleg gjenbruk. Interoperabilitet: IKT-system må kunne utveksle og dele data og informasjon med andre system gjennom standardiserte grensesnitt. Tilgjenge: Elektroniske brukartenester skal vere universelt utforma, og brukarane skal kunne nytte dei utan omsyn til tid, stad og kanal. Tryggleik: Informasjon og tenester skal tilfredsstille krav til konfidensialitet, kvalitet og tilgjenge. Openheit: Offentlege IKT-system skal vere baserte på opne eller godkjende standardar. Systema skal ikkje setje spesielle krav til teknologi hos brukarane. Fleksibilitet: Forvaltninga skal etablere og utvikle IKTsystem på ein slik måte at dei er føre-budde på endringar i bruk, innhald, organisering, eigarskap og infrastruktur. Skalerbarheit: IKT-system skal vere føre-budde på endringar i talet på brukarar, datamengd og livs-lengda til tenesta. 31