Bilag 1 Kundens kravspesifikasjon

Transkript

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. Verktøyet skal brukes av medlemsinstitusjonene i Samarbeidstiltaket FS. Avtalen skal også regulere vilkår for å kunne ta verktøyet i bruk gjennom opsjoner. Som beskrevet i bilag 3, gjelder dette eksempelvis forskningsinformasjonssystemet CRIStin og økonomisystemene, herunder primært samarbeidsprosjektet mellom universitetene i Bergen, Oslo og Trondheim. 1.1 BRUKSOMRÅDER Verktøyet skal være en rapport- og presentasjonsløsning som: - På en effektiv og brukervennlig måte støtter institusjonenes behov for data på utdanningsområdet - Tilbyr standardrapporter og tilrettelegger for institusjonenes behov for egendefinerte rapporter - Gir støtte for kontrollrapporter for bedret datakvalitet Verktøyet skal forbedre og forenkle institusjonenes forhold til egne studiedata gjennom bedret fremvisning. Det skal dekke behovet for data til alle nivå i institusjonenes, både linjeledelse og superbrukere. Se pkt og 2.4. for spesifikasjon av overordnete krav og krav til rapportfunksjonalitet og visualisering. 1.2 BRUKERE For at leverandøren skal ha en forståelse av Kundens bruk av verktøyet gir vi her en beskrivelse av brukerbegreper som er etablert. Brukerne skal forstås hierarkisk slik at brukere med de mest avanserte rettighetene, også har samtlige rettigheter som er mindre avansert. 1

2 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. Sluttbruker: Sluttbrukeren er tilknyttet en institusjon. 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. Superbruker: Rollen 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 institusjon. Superbruker skal kun ha tilgang til data fra egen institusjon. Superbruker skal opprette brukere og administrere roller på sin institusjon. 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. Systemadministrator: Noen av systemadministratorne vil være utviklere for standardrapporter i systemet. Systemadministrator har brukerstøtte for institusjonenes superbrukere, og trenger derfor tilgang til data for de institusjonene de skal drive brukerstøtte for. Driftsansvarlig: Dette vil være de som er ansvarlig for drift av verktøyet, eksempelvis installasjon, oppgraderinger og overvåking. Organisering av opplæring: Systemadministrator og ekspertbrukere 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 slik at de selv kan foreta hensiktsmessig og sikker drift av systemet. 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. Sluttbruker vi få opplæring av institusjonens superbruker Kunden vil selv etablere brukerstøtte til sluttbrukere, superbrukere og ekspertbrukere. Hvordan dette skal organiseres vil avklares i forbindelse med utrullingen av systemet. 2

3 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. - : betyr et OBLIGATORISK krav som ansees som et MINIMUM for løsningen. Svar JA (kravet oppfylles) eller NEI (kravet oppfylles ikke). Alle -krav skal i tillegg besvares med en beskrivelse av hvordan kravet fylles. Funksjonalitet utover minimumskravet vil bli benyttet i rangeringen av løsningene. - 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. - BØR: betyr en ØNSKET EGENSKAP. Svar JA (kravet oppfylles), DELVIS (kravet oppfylles delvis) eller NEI (kravet oppfylles ikke). Det skal i tillegg gis en beskrivelse av hvordan kravet oppfylles, eller når kravet kan bli oppfylt i fremtiden. Funksjonaliteten ift bør-kravene benyttes i rangeringen av løsningene. 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 2.3 OVERORDNETE KRAV Her beskrives generelle krav og krav til støtte for hovedfunksjoner. Hovedfunksjoner er rapporter og visualisering i systemet. ID Krav 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 tillegg 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 Verktøyet skal ha funksjonalitet for å definere og visualisere rapporter. Rapportene skal enten bli tilgjengeliggjort som standardrapport for alle institusjoner, for en enkelt institusjon eller en enkelt sluttbruker/ gruppe av sluttbrukere. Beskriv løsning Beskriv eventuell analysefunksjonalitet i verktøyet. BØR 3

4 2.3.5 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 Verktøyet skal ha funksjonalitet for å vise rapporter på egne websider, portal, dashboard osv. Beskriv løsning. 2.4 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 Generell funksjonalitet: I tilfeller der rapportenes forekomster blir 5 eller lavere, er ikke lenger BØR dataene tilstrekkelig anonymisert og det blir behov for å ivareta dette. Beskriv verktøyets eventuelle mekanismer for anonymisering. Funksjonalitet for sluttbruker: Verktøyet skal ha funksjonalitet for å få flere grafiske og tabellariske fremstillinger i samme oversiktsbilde. Beskriv løsning Verktøyet skal ha funksjonalitet å fremvise enkeltelementer i hovedtabellen, f. eks topp fem eller lignende. Beskriv løsning Verktøyet skal ha funksjonalitet for å generere aggregerte rapporter med drill-down-effekt. Beskriv løsning Verktøyet skal ha funksjonalitet for å lage formatterte rapporter og eksportere disse til Office og HTML. Beskriv løsning Verktøyet skal ha en løsning for å kunne bevare rapportens funksjoner (for BØR eksempel filtrering, oppdatering av data med mer) etter eksport til andre standard programpakker som Office. Beskriv løsning Verktøyet skal ha et utvalg av diagramtyper. Beskriv utvalget Beskriv eventuell mulighet for å veksle mellom grafisk og tabell fremstilling. Funksjonalitet for superbruker/systemadministrator: Superbruker/systemadministrator skal kunne velge om valgte filter skal vises for sluttbruker i overskriften i rapporten. Beskriv løsning 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 Verktøyet skal ha funksjonalitet som gjør rapportenes SQL-kode tilgjengelig for superbruker/systemadministrator. Beskriv løsning Verktøyet skal ha funksjonalitet som gjør det mulig for superbruker/systemadministrator å endre rapportens SQL-kode. Beskriv løsning 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. BØR 4

5 ID Krav Tabellrelasjonene fra kilde som benyttes av verktøyet skal kunne vises og BØR manipuleres i verktøyet av systemadministrator og superbruker. Beskriv løsning Verktøyet skal ha støtte for style sheets /maler, slik at rapporter får et BØR standardisert utseende. Beskriv løsning Verktøyet skal vise hvilke rapporter/dashbord som er avhengig av et gitt BØR felt (impact-analyse) og hvilke kolonner som er kilder til et element i en rapport/dashbord (data lineage). Beskriv løsning Verktøyet skal kunne schedulere rapporter og dashbord slik at man kan BØR kjøre rapporter til fastsatte tider. Beskriv løsning Verktøyet skal kunne ta i bruk tabellrelasjonene fra kilde. Beskriv løsning. BØR 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

6 2.5 KRAV TIL BRUKERGRENSESNITT (SØK, RAPPORTERING OG LOGGFUNKSJONALITET) Krav til egenskaper ved brukergrensesnittet ID Krav Generell funksjonalitet: 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. Funksjonalitet for sluttbruker: Verktøyet skal ha et Web-basert brukergrensesnitt for sluttbrukere. Beskriv løsningen Det er ønskelig at webgrensesnittet følger retningslinjene fra Web BØR Accessibility Initiative (WAI). Tilbyder skal beskrive hvordan løsningen følger retningslinjene og dersom retningslinjene ikke følges 100% også beskrive planene for å bedre på dette Verktøyet skal ha en løsning for individuell konfigurering for sluttbruker BØR (f.eks. for å gjøre lokale tilpasninger i sin arbeidsflate som kan lagres) Spesifiser og beskriv muligheter Verktøyet skal ha mulighet for søk i metadata og selve dataene. Søk i BØR 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. Funksjonalitet for superbruker/systemadministrator: Design av rapportene for systemadministrator/superbruker må være skjermbasert, dra og slipp, fortrinnsvis syntaksfritt. Beskriv løsning Verktøyet skal kunne settes opp til å tilpasses ulike roller. Beskriv løsningen Verktøyet skal ha løsning for logg, spesielt med tanke for logg av BØR responstider. Beskriv løsning Verktøyet skal ha en løsning for å legge inn egne hjelpetekster i rapporter/dashboards av systemadministrator/superbruker som kan benyttes av sluttbruker ved bruk av rapporter/dashboards. 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 Generell funksjonalitet: 6

7 ID Krav Verktøyet skal ha funksjonalitet som ivaretar datasikkerhet og rutiner for å fange opp og korrigere eventuelle sikkerhetshull. Dokumenter verktøyets datasikkerhet Verktøyet skal ha en funksjonalitet for at all tilgang til verktøyets funksjoner reguleres gjennom en unik brukeridentitet og brukerprofil (inneholder for eksempel brukerrolle, org.tilhørighet). Beskriv løsning 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 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 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. Funksjonalitet for superbruker/systemadministrator: Verktøyet skal ha en løsning for håndtering av brukeradministrasjon og tilgang av systemadministrator/superbrukere i henhold til spesifikasjoner i bilag 3. Beskriv løsning Verktøyet skal ha funksjonalitet der roller og tilganger administreres med et GUI med for eksempel dra og slipp. Beskriv løsning Superbrukere skal kunne definere rapporter og gjøre disse tilgjengelig for andre brukere på sin institusjon. Beskriv løsning Rettigheter skal 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 Verktøyet skal ha funksjonalitet for å ta ut rapporter pr rolle og/eller institusjon, for å se hvilke rapporter som er knyttet til disse. Beskriv løsning Institusjonene skal selv kunne administrere tilgangskontroll på de forskjellige roller og nivåer på institusjonen. Systemadministrator skal ha tilgang til å gjøre dette for de institusjonene de skal ha brukerstøtte for. Beskriv løsning. BØR BØR 3.2 KRAV TIL SYSTEMKONFIGURASJON OG SYSTEMADMINISTRASJON Krav til systemkonfigurasjon og systemadministrasjon ID Krav Verktøyet må ha Unicode UTF8 støtte. Beskriv løsning 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. 7

8 ID Krav Det skal være mulig å definere faste tekster i rapportene, som for eks. overskrifter. Beskriv løsning Det skal være mulig å definere tilleggsfelter som f.eks. egne beregninger utover felter hentet fra kilde. Beskriv løsning Verktøyet skal ha funksjonalitet for automatisk avlogging av en bruker som har vært inaktiv i et definert antall minutter. Beskriv løsning Det er ønskelig å kunne parametersette hvor mange funn som kan vises pr. skjermbilde. Beskriv løsning. BØR 3.3 YTELSE OG ANTALL BRUKERE Krav til ytelse og skalering ID Krav 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 Verktøyet skal ha en high-availability-løsning som fungerer sammen med verktøyet. Beskriv løsning. BØR 4 Tekniske krav til verktøyet 4.1 TEKNISKE KRAV, KLIENTER Krav til tekniske krav for klienter ID Krav Verktøyet skal ha en flerlagsarkitektur med et metadatalag som danner et felles grunnlag for brukere av rapporter/dashbord. Beskriv løsning Verktøyet må ha 0-klientversjon for sluttbrukere som bare skal kjøre ferdige rapporter (dvs. en browser-versjon). Beskriv løsning Verktøyet må ha en 0-klientversjon for superbrukere som skal utvikle rapporter (dvs. en browser-versjon). Jf. Bilag 3 Beskriv løsning Verktøyet skal ha støtte for lesetavle (tablet) med mer for å kunne BØR lese/bruke ferdigutviklede rapporter/dashboards. Beskriv løsning All funksjonalitet i tjenesten skal minst støtte nettlesere gitt i bilag 3. Redegjør for rutiner for å sikre støtte til nyere versjoner når de kommer Websidene skal følge standarder for websider gitt i bilag Det skal være støtte for 64-bits arkitektur (gjelder applikasjonsserver). Beskriv løsning Beskriv løsning for cashing og in-memory-bruk (gjelder applikasjonsserver) Repository/metadata og kildedata må kunne legges i database gitt i bilag 3. Beskriv løsning 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 Applikasjonsserver må kunne bruke plattformer gitt i bilag 3. Beskriv løsning Beskriv hvilke verktøy applikasjonsserver benytter som f. eks Resin, Apache, Jboss. Beskriv løsning IT-verktøyet må tillate bruk av brannmur. Beskriv løsning. 8

9 ID Krav Verktøyet skal ha sikkerhetsmekanismer for kryptering av data. Beskriv løsning. Løsningen skal være i tråd med kravene beskrevet i Bilag GRENSESNITT Krav til grensesnitt mot andre systemer med de presiseringer som er gitt i bilag 3. ID Krav Beskriv muligheter for grensesnitt mot epostsystem Verktøyet må kunne lese fra Oracle-kilder Verktøyet skal 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 Verktøyet skal ha løsning for kommunikasjon med en database. Beskriv løsning (er det applikasjonsserver som kommuniserer med databasen, tykkklient osv.). 5 IKT-arkitektur 5.1 FELLES IKT-ARKITEKTUR Gjeldende faktaark med Prinsipp for planlegging av IKT-løysinger (se vedlegg) er en sjekkliste for generelle arkitekturkrav som bør oppfylles. Vi mener selv at vi har stilt de kravene som trengs for å fylle disse kravene. Disse kravene benyttes som kvalitetssikring slik at vi vet at vi har stilt de relevante kravene for å ivareta disse. 5.2 DRIFTSMESSIGE FORHOLD Krav til støtte for driftsmessige forhold ID Krav 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 Verktøyet skal ha funksjonalitet for oppgradering. Beskriv løsning Beskriv løsning for oppgraderinger som kan foretas når verktøyet er oppe. BØR Oppgraderinger må kunne gjøres av kundens systemadministrator og kundens driftsorganisasjon. Beskriv løsning. 9

10 ID Krav 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 alternativ 1 og 2. Beskriv også rutiner for produksjonssetting av rapporter i henhold til alternativ 1 og 2 i Bilag 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 Beskriv håndtering av passord i verktøyet Beskriv løsning for drift av brukeradministrasjon, samt hvordan testing og produksjonssetting kan være adskilt. 6 Krav i forbindelse med tjenesteleveransen Tjenesteleveransen ift denne kontrakten skal bestå av opplæring, bistand til test, konfigurering og dokumentasjon. Krav til tjenesteleveranse ID Krav 6.0 Omfanget av nødvendig tjenesteleveranse må beskrives. Leverandøren skal utarbeide en detaljert plan som viser deres bistand i forbindelse med implementering og testing, jfr bilag 5 slik at milepælene i bilag 4 nås innen avtalte tider. Planen skal vise hvilke ressurser leverandøren deltar med og omfanget. 6.1 Timeprisen for konsulenter skal være iht. kompetansenivå. Jf bilag 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. 6.5 Det skal foretas kompetanseoverføring til institusjonsrepresentanter/ekspertgruppe, driftspersonell og systemadministratorer. Beskriv løsning. Beskriv kostnader i bilag Hver institusjon skal kunne kjøpe ekstra lisenser. Pris for ekstra lisenser utenom definert brukeromfang må spesifiseres av leverandør. Se bilag Omfanget av tjenesteleveranser skal være godkjent av kunden før igangsetting 6.8 Det skal beskrives rutiner knyttet til henvendelser og oppfølging i forbindelse med eventuell benyttelse av opsjoner for å ta i bruk verktøyet til andre systemer enn FS 10

11 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. 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 Leverandøren skal vedlegge sin generelle vedlikeholdsavtale som supplement til bekreftelsene av det innhold i vedlikeholdsansvar som er gitt som bekreftelser og beskrivelser i punkt 8 under. 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 implementering Betaling inntrer når Fase 1 er ferdig og leveransen er godkjent, se betalingsplan i bilag 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. BØR 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. Beskriv tjenesten, inklusive rutiner for henvendelse og svartider, 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. Beskriv innhold og omfang i tilbudt support og vedlikeholdsavtale. Beskrivelsen må inneholde informasjon om rutiner for melding av feil og videre oppfølging fra leverandørens side, herunder responstider og forventede rettetider ved forskjellige feil. Det må også beskrives hvilke rutiner leverandøren har for å varsle kunden om 11

12 feil og mangler som oppdages i løsningen. Besvarelsen skal også inneholde en overordnet beskrivelse av supportorganisasjonen og hvor den er lokalisert. 8.3 Vedlikeholdsavtalen må omfatte og inkludere oppgraderinger og nye versjoner av verktøyet. Vedlikeholdsavtalen skal omfatte og inkludere feilrettinger, oppgraderinger og nye versjoner av verktøyet. Disse skal gjøres tilgjengelig for kunden uten unødig forsinkelse under forutsetning av at kunden har gyldig serviceavtale med priser som er angitt i bilag 7. Leverandøren må beskrive rutiner for varsling og metoder for tilgjengeliggjøring av feilrettinger, oppgraderinger og nye versjoner. 9 Opplæring, kursing og dokumentasjon (Avtalen punkt Opplæring og avtalen punkt 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. 9.3 Det skal 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 skal finnes en hjelpefunksjon tilrettelagt for søk etter et spesielt tema. Beskriv hvordan dette fungerer. 9.5 Det skal 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. 12

13 10 Krav til bistand etter godkjenning 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 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 - Andre institusjoner og andre felles tiltak i sektoren skal ha opsjon på å kunne ta i bruk verktøyet. Denne avtalen med avtalte rammer og enhetspriser vil ligge til grunn for slike leveranser. Konkret vil det måtte etableres nye versjoner av bilag 4, samt presisering av omfang, det vil si kostnader og betaling 13

14 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) 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) Verktøyet skal være en rapport- og presentasjonsløsning som: - På en effektiv og brukervennlig måte støtter institusjonenes behov for data på utdanningsområdet - Tilbyr standardrapporter og tilrettelegger for institusjonenes behov for egendefinerte rapporter - Gir støtte for kontrollrapporter for bedret datakvalitet Leverandøren skal på en overordnet måte beskrive hvorledes verktøyet bidrar til å nå disse målene. Kravtabell fra bilag 1 settes inn: 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: 14

15 (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) 15

16 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 (se alternativ 1 og 2 nedenfor) 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. Større institusjoner vil få tildelt lisenser for to til flere sluttbrukere etter behov. Ved full implementering antas det at det vil være i underkant av ti systemadministratorer, superbrukere og 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 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. o Økonomisystemene i UH-sektoren, herunder primært BOT-samarbeidet. BOT er et samarbeidsprosjekt mellom universitetene i Bergen, Oslo og Trondheim. Datamengde o Datavarehus: Antall rader:

17 o FS Antall tabeller: 255 Antall GB: 389 Antall tabeller: 2585 pr institusjon Antall rader: for stor institusjon (UIO), for mindre institusjon 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 (Red Hat 6 foretrukket), 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 17

18 Alternativer arkitekturskisser som verktøyet skal realiseres i: Det ønskes en sentral installasjon av Applikasjonstjener uavhengig av kilder, evt at det blir to sentrale installasjoner av applikasjonstjener, en mot datavarehus og en for produksjonsbaser for FS- kilder. Alternativ 1 er foretrukket løsning, men Leverandør bes om å få frem kostnad for Drift og installasjon 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 institusjon LDAP for institusjon LDAP for institusjon Datavarehus Felles Studentsystem (FS) UNINETT UiO UiT NTNU UiB KILDER 18

19 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 for institusjon LDAP for institusjon LDAP for institusjon 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 19

20 Bilag 4 Prosjekt- og fremdriftsplan for leveranse av verktøy Overordnet milepælsplan Hva Ferdig Ansvarlig Kommentar Når kontrakt er signert Kunde og leverandør Fase 1 Etablering av den Platform med grensesnitt som applikasjonen skal realiseres på. Oversendelse av dokumentasjon Gjennomføring av opplæring av driftsansvarlige DD.MM.ÅÅ Kunde Se SSA-k pkt 1.1, Bilag 3, samt pkt DD.MM.ÅÅ Leverandør Sa SSA-k samt bilag 1 pkt 9 jfr bilag 2. pkt 9 DD.MM.ÅÅ Leverandør med Sa SSA-k samt bilag 1 pkt deltakelse fra kunde 9 jfr bilag 2. pkt 9 Installasjon DD.MM.ÅÅ Kunde, med eventuelt bistand fra Leverandør SSA-k pkt 2.1.3, samt bilag 1 og 2 pkt 6 Teknisk test DD.MM.ÅÅ Kunde, med eventuelt SSA-k pkt og bilag 5 bistand fra Leverandør Teknisk godkjenning DDMÅ Kunden SSA-k pkt og bilag 5 Fase 2 Gjennomføring av opplæring i funksjonelle roller DD.MM.ÅÅ Kunde, med eventuelt bistand fra Leverandør SSA-k pkt 2.1.3, samt bilag 1 og 2 pkt 6 Konfigurering og etablering av et begrenset sett rapporter Gjennomføring av funksjonell testing Funksjonell Godkjenning ddmmåå Kunde, med eventuelt bistand fra Leverandør ddmmåå Kunden Se bilag 5 Leverandøren skal som en del av sitt tilbud, og ut i fra sin beste praksis og erfaringer, sette datoer på hoved milepælene angitt over. I tillegg skal leverandøren vedlegge detaljplaner som viser aktiviteter og omfang for kundens og leverandørens ressursbruk for å nå de ulike milepælene. 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: 20

21 Installasjon av verktøyet som tilgjengeligjør verktøyet for et gitt antall bruker på et gitt antall institusjoner. Verktøyet skal installeres 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 Dokumentasjon, opplysningsplikt mv. Frist for levering av dokumentasjon for utstyr og standardprogramvare: Leverandøren forplikter seg til en dato i tilbudet og skriver den inn i tabellen «Overordnet milepælsplan» Avtalen punkt Tidsfrist for forberedelse av installasjon, og leverandørens avsluttende inspeksjon Frist for forberedelse til installasjon: Kunden forplikter seg til en dato i tilbudet og leverandøren skriver den inn i tabellen «Overordnet milepælsplan» 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: Leverandøren forplikter seg til en dato i tilbudet og skriver den inn i tabellen «Overordnet milepælsplan» Avtalen punkt Plan for Kundens akseptansetest Frist for å utarbeide grunnlagsmateriale til akseptansetestplanen: Leverandøren forplikter seg til en dato i tilbudet og skriver den inn i tabellen «Overordnet milepælsplan» Andre frister for akseptansetestplanen: (Fylles ut dersom partene avtaler andre frister enn det som følger av avtalen) Avtalen punkt 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 Gjennomføring av Kundens akseptansetest Dato for påbegynnelse av Kundens akseptansetest: Leverandøren forplikter seg til en dato i tilbudet og skriver den inn i tabellen «Overordnet milepælsplan» 21

22 Dato for avslutning av Kundens akseptansetest: Leverandøren forplikter seg til en dato i tilbudet og skriver den inn i tabellen «Overordnet milepælsplan» Avtalen punkt Produksjon Frist for at leveransen settes i ordinær drift: Leverandøren forplikter seg til en dato i tilbudet og skriver den inn i tabellen «Overordnet milepælsplan» Partenes plikter i forbindelse med idriftsettelse: Avtalen punkt 6.1 Kundens ansvar og medvirkning Frister for Kundens medvirkning til leveransens gjennomføring: Avtalen punkt Dagbot ved forsinkelse Frist det er knyttet dagbot til: Når dokumentasjon er levert, opplæring er gjenomført, installasjon er foretatt og teknisk test starter. Leverandøren forplikter seg til en dato i tilbudet og skriver den inn i tabellen «Overordnet milepælsplan» Avtalen punkt 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) 22

23 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 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 Gjennomføring av Kundens akseptansetest Beskrivelse av gjennomføringen av Kundens akseptansetest: Avtalen punkt Varighet Godkjenningsperiodens varighet: (Fylles ut derom det er avtalt annen varighet enn det som følger av avtalen) Avtalen punkt 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. 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 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. Det forutsettes at Leverandøren leverer beskrivelser av de krav til omgivelser og grensesnitt som skal til for å drifte verktøyet. Videre forutsettes det at leverandøren leverer dokumentasjon for drift og sine standard tester. I fase 1 er det de tekniske kravene som testes ut, og i fase 2 vil det være de funksjonelle egenskapene som testes ut. I begge fasene vil testene tematisk omfatte: 23

24 Kundens akseptansetest skal omfatte programvare og/eller utstyr som inngår i leveransen, jf bilag 1 og 2. Er ikke annet avtalt i bilag 5, skal Kundens akseptansetest omfatte følgende tester: a) funksjonstest b) robusthetstest c) integrasjonstest d) volum-, kapasitets- og svartidstest e) gjennomgang av all dokumentasjon f) installasjonstest g) test av driftsprosedyrer, herunder sikkerhetskopiering Fase 1: Når driftspersonalet hos kunden har gjennomført opplæring vil kunden Foreta installasjon i tråd med overlevert dokumentasjon. Dette vil både fungere som test og godkjenning av Opplæring og dokumentasjon Det vil bli fortatt tekniske tester i tråd med mottatt testbeskrivelse Det vil bli foretatt tester som verifiserer at Grensenitt fungerer som forutsatt At løsningen kan populeres med data fra kilder som forutsatt At ulike brukere får de rettigheter som beskrevet Gjennomført sikkerhetstester Fase 2 Når funksjonelt personale har mottatt opplæring vil følgende tester gjennomføres Det vil bli laget noen av standard rapportene Dette verifiserer at dokumentasjonen virker og verktøyet fungerer som forutsatt Funksjonelle ressurser hos kunden vil gå inn i løsningen som brukere og anvende de genererte rapportene Dette verifiserer at måla med verktøyet er oppnådd. Hensikten med fase 2 er å bekrefte at verktøyet har de avtalte, påkrevde og lovede egenskaper og er i stand til å nå måla med verktøyet. Nås disse i tilstrekkelig grad godkjennes leveransen. Leverandøren har ikke forpliktelser på annet enn å yte avtalt bistand i Fase 2. Unntaket fra dette er dersom en i Fase 2 avdekker vesentlige feil eller mangler ved verktøyet. Avtalen punkt 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) 24

25 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: 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 25

26 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) 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.) Forpliktelser etter godkjenning Bilag 8 samt opsjoner Vedlikehold: Leverandøren skal varsle kunden om oppgradering, nye versjoner og eventuelt nye moduler. Beskriv de rutinene som leverandøren har for dette. Beskriv de rutinene og mekanismene leverandøren har for tilgjengeliggjøring av oppgraderinger, nye versjoner. Beskriv nærmere innholdet i vedlikeholdsavtalen, herunder varsling av feil, eskalering samt rutiner knyttet til support. 26

27 Opsjoner: Avtalen gir anledning til å ta i bruk verktøyet for andre virksomheter og kilde sett enn det som gjøres ved avtaleoppstart. Dette innebærer nye leveranser og ny bistand i form av opplæring, bistand til test mm. Rammer og enhetspriser knyttet til dette er det samme som ved levering til FS. Imidlertid skal det lages nye planer i samarbeid mellom kunden og leverandør, samt med oppdatert betalingsplan. Beskriv rutiner knyttet til å etablere rammer rundt fremtidige leveranser. 27

28 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. Totalkostnader: Element Enhetspris Antall Totalt Kjøp av lisenser (lisens administrator, lisens superbruker, lisens sluttbruker) (Lisens systemadministrator ca 10, superbruker 50-55, sluttbrukere 65-70) Vedlikeholdskostnader per år, i fem år Eventuelt utvikling eller annen programvare for å ivareta obligatoriske krav Etablering, i tråd med det som fremkommer i bilag 4 og 5 Opplæring Eventuelt annet Totalkostnader i 5 år etter installering (uten ekstra lisenser og vedlikeholdskostnader: For hver linje i tabellen over skal leverandøren utarbeide egne tabeller som viser detaljer slik at det kan verifiseres hvorledes linjene er fremkommet og at dette er korrekt. Under fremkommer det en del eksempler som kan benyttes. Tabellene skal utarbeides med utgangspunkt den prisstruktur som leverandøren har, eksempelvis for lisenser kan det benyttes kjøp og deretter årlig vedlikehold, eller alternativt årlig brukspris. Dersom det er ulik lisenskostnad for ulike typer brukere, kreve egne lisenser for ulike klieninstallasjoner med mer skal detaljtabellene vise at dette er tatt hensyn til. Det kan ikke kreves dekning av reise ved fremmøte i kundens lokaler i forbindelse med leveransen. Dersom det avtales reiser skal dette dekkes etter statens satser, og kun etter særskilt avtale. 28