Bilag for SS-K lille Bilag 1-9 Programvare for visualisering av vegprosjekter Status: Publisert Versjon: 1.0 Sist oppdatert: 17.02.2014 Kontraktstandard Dette er et sett med bilag for Statens standardavtaler om IT-anskaffelser Den lille Kjøpsavtalen SS-K lille. Kontrakten benyttes ved anskaffelser av mindre omfang Side: 1 av 24
1.1 Overordnede beskrivelser... 4 1.1.1 Bakgrunn for kravspesifikasjonen... 4 1.1.2 Oversikt over kravspesifikasjonen... 4 1.1.3 Overordnet om spesifiseringen av krav... 4 1.2 Oversikt over krav... 5 1.2.1 Kundens formål med anskaffelsen... 5 1.2.2 Krav til brukskvalitet... 6 1.2.3 Eksterne rettslige krav, personvern og sikkerhet... 7 1.2.4 Krav til teknologi, miljø og tjenester... 7 1.2.5 Krav til leveranse og framdrift... 7 1.2.6 Krav til testing og godkjenning... 7 1.2.7 Krav til pris og prisbestemmelser... 7 1.3 Kravtabell... 8 1.4 Definisjoner og forkortelser... 10 2 Bilag 2: Leverandørens løsningsspesifikasjon... 11 2.1 Løsningsbeskrivelse... 11 2.2 Kravtabell... 11 2.3 Behov for oppgradering av Kundens tekniske plattform:... 11 2.4 Åpenbare feil, mangler eller uklarheter i Kundens kravspesifikasjon... 11 2.5 Krav til Kundens medvirkning... 11 2.6 Dokumentasjon, opplæring mv... 11 2.7 Fri programvare... 11 2.7.1 Fri programvare som benyttes i leveransen... 11 2.7.2 Leverandøren redegjørelse for sin vurdering av hvorvidt den frie programvare kan krenke tredjeparts rettigheter... 12 2.7.3 Virkning av videredistribusjon... 12 3 Bilag 3: Kundens tekniske plattform... 13 3.1 Standarder... 13 3.2 Miljøer... 13 3.3 Plattformer... 14 3.3.1 Operativsystem... 14 3.3.2 Database... 14 3.3.3 pplikasjonstjener... 14 Side: 2 av 24
3.3.4 Cluster-rammeverk... 14 3.3.5 Katalogtjeneste... 14 3.3.6 Brannmur... 14 3.3.7 Lastbalansering... 14 3.3.8 utentisering og autorisasjon... 14 3.3.9 Eksponering... 15 3.4 Virtualisering... 15 3.5 Nettverk... 15 3.6 Lagring... 15 3.7 Høytilgjengelighet... 16 3.8 Konsolidering... 16 4 Bilag 4: Prosjekt- og fremdriftsplan... 17 4.1 Dokumentasjon, opplysningsplikt mv.... 17 4.2 Tid og sted for leverandørens ytelse... 17 4.3 Gjennomføring av Kundens godkjenningsprøve... 17 4.4 Dagbot ved forsinkelse... 17 5 Bilag 5: Testing og godkjenning... 18 5.1 kseptansetestens omfang... 18 5.2 Krav til leverandør... 18 6 Bilag 6: dministrative bestemmelser... 19 6.1 Partenes representanter... 19 6.2 Bruk av underleverandør... 19 7 Bilag 7: Samlet pris og prisbestemmelser... 20 7.1 Vederlag... 20 7.2 Fakturering... 21 7.2.1 Betalingsplan:... 21 7.2.2 Øvrige betalingsvilkår... 21 7.2.3 Fakturaadresse... 21 7.2.4 Merking av fakturaen... 21 7.3 Prisendring... 22 7.4 Eiendomsrett til utstyr... 22 8 Bilag 8: Endringer i den generelle avtaleteksten... 22 9 Bilag 9: Endringer av leveransen etter avtaleinngåelsen... 24 Side: 3 av 24
Bilag 1: Kundens kravspesifikasjon 1.1 Overordnede beskrivelser Statens Vegvesen, Vegdirektoratet, (heretter Kunden) ønsker å anskaffe en programvare for visualisering av vegprosjekter. 1.1.1 Bakgrunn for kravspesifikasjonen Programvaren skal benyttes til å fremstille stillbilder og video med utgangspunkt i eksisterende og prosjektert situasjon i 3d. Produktet skal brukes til å gi publikum og beslutningstakere et mer virkelighetsnært bilde av tiltak i regi av. 1.1.2 Oversikt over kravspesifikasjonen Dokumentet er delt inn i følgende hoveddeler: 1. Overordnede beskrivelser 2. Oversikt over krav 3. Kravtabell 4. Definisjoner og forkortelser 5. Referanser Den første hoveddelen inneholder ingen direkte krav, men beskriver viktige rammer og mål for anskaffelsen. Denne første delen av dokumentet fungerer som en selvstendig oversikt samtidig som den fungerer som en innledning og viktig bakgrunn for resten av kravspesifikasjonen. Den andre hoveddelen inneholder oversikt over krav, og tredje del er en kravtabell. I tillegg til kravnummer og kortnavn vil kravtabellen inneholde flere andre egenskaper for kravet slik som en beskrivelse av selve kravet. Kravtabellen kan evt. foreligge som et vedlegg til dette bilaget. Fjerde hoveddel inneholder definisjoner og forkortelser. Den femte og siste hoveddelen inneholder fullstendige referanser for det som er referert til i denne kravspesifikasjonen. 1.1.3 Overordnet om spesifiseringen av krav Hensikten med denne kravspesifikasjonen er å gi et tilstrekkelig grunnlag til å få oversikt over omfanget av anskaffelsen slik at den kan prises og det kan utarbeides planer for å få etablert en slik løsning. Kravspesifikasjonen skal også gi et grunnlag for å kunne utarbeide og sammenligne løsningsforslag. Nummerering lle krav skal være nummerert med «K» som prefiks. Det vil si K-01, K-02 og så videre. Kravkortnavn lle krav skal ha et kravkortnavn som gjør det lett å gjenkjenne det. Side: 4 av 24
Kravbeskrivelse lle ferdig definerte krav skal ha en kravbeskrivelse som inneholder selve kravteksten. Kravprioritet: bsolutte krav () Kravet MÅ tilfredsstilles. Tilbud som ikke tilfredsstiller alle MÅ-krav vil bli avvist. Tilbudt merverdi utover minimumsforlangende vil bli evaluert og gitt høyere score enn tilfredsstillende. Viktige krav (B) Kravet BØR tilfredsstilles, men det er ikke et absolutt krav. Svar vil ha stor betydning for evaluering av tilbudet. Kravet tillegges høyere vekt enn C-krav. 1.2 Oversikt over krav 1.2.1 Kundens formål med anskaffelsen Programvaren skal benyttes til å fremstille realistiske 3D animasjoner med utgangspunkt i eksisterende og prosjektert situasjon i 3D. Programvaren skal i utgangspunkt ikke være et prosjekteringsverktøy, men et rendyrket visualiseringsverktøy, som genererer en animasjon eller stillbilder i høy oppløsning. Programvaren er ikke tenkt brukt eksklusivt av en dedikert gruppe spesialister innenfor visualisering, men snarere av prosjekterende og tekniske tegnere for ulike fagdisipliner i etaten. Programvaren skal derfor ha et brukergrensesnitt som muliggjør nær fotorealistisk produksjon med minimale forkunnskaper for brukeren. Produktet skal brukes til å gi publikum og beslutningstakere et mer virkelighetsnært bilde av tiltak i regi av. Programmet skal muliggjøre enkelt import fra eksisterende prosjekteringsverktøy i Statens Vegvesen, men kan ellers være basert på annet teknologi (f.eks. på teknologien fra spillindustrien). Side: 5 av 24
1.2.2 Krav til brukskvalitet og funksjonalitet Brukergrensesnitt skal være så enkel i bruk at man kan produsere realistiske animasjoner av en komplett vegmodell med tilhørende terreng og objekter allerede første dagen i bruk; det skal ikke være nødvendig med andre forkunnskaper enn de man kan forvente hos prosjekterende og tekniske tegnere i etaten (ved tvil om programmets egnethet vil de bli testet av en testgruppe) skal muliggjøre produksjon av et kvalitativ høyverdig produkt med minimale krav til tidsbruk og brukerens forkunnskaper Intuitivt selvlæringsmateriale og steg for steg-videoer skal være tilgjengelig. Programmets innebygde brukerinstruksjon vektlegges. Kompatibilitet: Programvaren må være godt integrert i sine eksisterende produksjonsløyper og må derfor kunne lese standardformater: *.dae, *.skp, *.fbx, *.dwg, *.dxf, *.3ds, *.obj, *.tga, *.bmp, *.jpg, *.dds, *.png, *.psd, *.wav. Noen av disse formatene er -krav og noen er B-krav (se kravtabell for nærmere informasjon). Funksjonalitet: Programvaren skal kunne produsere høykvalitets-renderinger av prosjekterte 3D-modeller basert på geometri (punkt-, linje-, flate- og volum-objekter) fra etatens prosjekteringsverktøy. Programvaren skal være i stand til å fremstille eksisterende og prosjektert terreng på en realistisk måte. Det skal være mulig å modellere og manipulere terreng og overflater direkte i programvaren. Programvaren skal inneholde et omfattende material- og objektbibliotek og det skal være mulig å legge materialer på flere flater samtidig Programvaren skal være i stand til å fremstille realistiske animasjoner av tiltak som samsvarer med norske forhold. Objektbiblioteket må inneholde blant annet animerte objekter. Det må være mulig å redigere på enkelte materialtyper. Dynamisk oppdatering fra importfiler vektlegges. Endringer i prosjekteringsfiler skal på en enkel måte kunne legges inn i visualiseringsprosjektet, for eksempel via en oppdateringsfunksjon. Programvaren skal kunne visualisere ulike årstider på en enkel og troverdig måte Side: 6 av 24
Programvaren skal inneholde filmeffekter og spesialeffekter for å kunne generere realistiske animasjoner. Eksport av stillbilder og videoer skal være enkelt, intuitivt og hurtig. Programvaren skal inneholde funksjonalitet for videoredigering. «Intelligent» komprimering vektlegges - programvaren må kunne produsere resultatfiler i høy oppløsning av liten filstørrelse. 1.2.3 Eksterne rettslige krav, personvern og sikkerhet vtalen punkt 2.6 Krav til leveransen etter generelt eller sektorspesifikt regelverk: 1.2.4 Krav til teknologi, miljø og tjenester 1) Programmet må løse oppgavene beskrevet i pkt.1.2.2. 2) Programmet skal være brukervennlig og funksjonelt 3) Programmet skal være stabilt og uten feil 4) Programvaren skal lisensieres med flytende nettverkslisens og ha en mulighet for offline bruk (lån av lisens e.l.) 5) Det skal være mulig å importere og eksportere i data nevnt i punkt 1.2.2 1.2.5 Krav til leveranse og framdrift Jfr. Bilag 4. Installering, opplæring, kompetanse, samarbeid mellom Kunde og Leverandør, garantiperiode 1.2.5.1 Tid og sted for Leverandørens ytelse Utstyr og programmer i samsvar med denne avtalen skal være levert og installert på den adresse og til de tidspunkter som fremgår av bilag 4 1.2.5.2 Dokumentasjon, opplæring mv. Opplæringsmateriale (manualer, opplæringsvideoer) skal være tilgjengelig på Internett på norsk eller engelsk. 1.2.6 Krav til testing og godkjenning Jfr bilag 5. godkjenningsprøve, feilhåndtering 1.2.7 Krav til pris og prisbestemmelser Jfr. Bilag 7. fakturering, prisendring, avbestilling Side: 7 av 24
1.3 Kravtabell Kravnr Kravkortnavn Kravbeskrivelse prioritet Leverandørens svar (J/N/forbehold) K-01 brukervennlighet Programvaren skal være brukervennlig og funksjonell (nærmere beskrevet i punkt 1.2.2) K-02 stabilitet Programvaren skal være stabil og uten feil K-03 effektivitet Programvaren skal være effektiv sammenlignet med konkurrerende programvare (målt i antall museklikk eller tid for å gjennomføre samme oppgaver). K-04 3D import Må støtte import av modellfiler i følgende formater: *.dwg, *.dae, *.skp og *.fbx K-05 Bilde import Må støtte import av modellfiler i følgende formater: *.jpg, *.bmp og *.png K-06 Lyd import Må kunne importere lydfiler K-07 Brukergrensesnitt, oppstart Det skal ta ca. 8 klikk fra oppstart av programmet til 3D-modell er importert. K-08 Brukergrensesnitt, navigasjon Navigasjon bør være enkelt og intuitivt og være logisk i forhold til andre prosjekteringsverktøy som Vegvesen bruker K-09 Opplæring Selvlæringsmateriale og steg for steg videoer bør være tilgjengelig. K-10 Oppdatering Det skal være en dynamisk oppdateringsfunksjon for prosjektdata K-11 Modellering Man bør ha muligheten til enkel modellering og redigering av terreng og overflater direkte i programmet. K-12 Materialer Det skal være enkelt å legge materialer på flere flater samtidig (ønskelig med ca. 8 klikk) K-13 Teksturer Programmet skal inneholde et rikt bibliotek av ferdige teksturer. Det skal være mulig å legge til egne teksturer. B B B Side: 8 av 24
Kravnr Kravkortnavn Kravbeskrivelse prioritet Leverandørens svar (J/N/forbehold) K-14 Objekter Programmet skal inneholde ett rikt bibliotek av naturtro (animerte) objekter. Det må være objekter som er fornuftige å bruke i etatens modeller, som for eksempel planter, biler, gatemøbler, mennesker osv. K-15 Filmeffekter Programmet skal inneholde et bibliotek av filmeffekter, for å lage mer naturlige modeller, f.eks. vær, vind, ulike kameralinser K-16 Væreffekter Bør kunne visualisere ulike årstider på en realistisk måte. B K-17 Eksport Stillbilder, fremgangsmåte K-18 Eksport stillbilder, format K-19 Eksport stillbilder, oppløsning K-20 Eksport Video, fremgangsmåte K-21 Eksport video, format K-22 Eksport video, komprimering K-23 Eksport video, oppløsning K-24 Eksport video, bildesekvens K-25 Eksport Visningspakke Eksport av stillbilder skal være enkel og intuitiv og det skal ta ca. 5 klikk til bildet er lagret Eksport formater: JPG og PNG til en oppløsning på 7680x4320 piksel Eksport av video skal være enkel og intuitiv og det skal ta ca. 5 klikk til video er lagret Eksport format: MP4 Video må ha «intelligent» komprimering, dvs. høy oppløsning med lav filstørrelse (f.eks. VC kodek) Må være minst på 2560x1440 (1440p) Det er ønskelig med en eksport av en bildesekvens i et format uten kvalitetstap, f.eks. png. Bør kunne eksportere til en «standalone» visningspakke med mulighet for gjennomkjøring av modellen. Bør ikke trenge lisens for å se denne visningspakken. B B K-26 Spesialeffekter Bør inneholde et bibliotek av spesialeffekter, som for eksempel brann, tåke, røyk osv. B Side: 9 av 24
1.4 Definisjoner og forkortelser Begrep eller forkortelse Oppdragsgiver Kunden Tilbyder Leverandør vtale Forklaring/ tolkning Vegdirektoratet Det firma som tilbyr tjenester på basis av tilbudsforespørselen Det firma som man inngår avtale med Benevnelse på avtalen for anskaffelsen Side: 10 av 24
2 Bilag 2: Leverandørens løsningsspesifikasjon Leverandøren skal beskrive hvordan Leverandøren vil oppfylle de kravene som er stilt i bilag 1 og spesifisere varer og andre ytelser som tilbys. 2.1 Løsningsbeskrivelse Leverandørens beskrivelse av tilbudte varer og/eller tjenester 2.2 Kravtabell Kundens kravtabell med svar/tilbud fra Leverandøren. Kravtabellen kan foreligge som vedlegg til dette bilaget. 2.3 Behov for oppgradering av Kundens tekniske plattform: vtale punkt 2.1.1 (Dersom slik oppgradering er nødvendig for å utnytte leveransen skal Leverandøren påpeke dette her) 2.4 Å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) 2.5 Krav til Kundens medvirkning Dersom Leverandørens tilbud forutsetter medvirkning fra Kunden, skal det spesifiseres her 2.6 Dokumentasjon, opplæring mv vtalen punkt 2.1.2 Dokumentasjon: Medium og format for dokumentasjon: Opplæring: Hvilke grupper av ansatte som skal motta opplæring og antall: Sted der opplæring skal skje hvis det er et annet sted enn i Kundens lokaler: 2.7 Fri programvare vtalen punkt 4.3 2.7.1 Fri programvare som benyttes i leveransen Navn på fri programvare Fri programvarelisens Side: 11 av 24
Kopi av aktuelle fri programvarelisenser skal vedlegges 2.7.2 Leverandøren redegjørelse for sin vurdering av hvorvidt den frie programvare kan krenke tredjeparts rettigheter 2.7.3 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) Side: 12 av 24
3 Bilag 3: Kundens tekniske plattform 3.1 Standarder har utarbeidet mange håndbøker, noen beskriver etat standarder. Håndbok 162 (HB162) er det viktig at leverandør gjør seg kjent med og forstår innholdet. Vi gir utdrag fra denne i dette kapittelet. Det er også etablert krav og retningslinjer for utvikling av tjenester og da med hensyn til tjenesteorientert arkitektur(so). Dette og flere dokumenter blir gitt som vedlegg. Blant annet Sikkerhet og Single Sign On, Testing, Naming and Design Rules, SO ref.ark, IKT rkitekturprinsipper for å nevne noen. lle er viktige på sine områder, men det er det totale bildet som er viktigst å se. Da vil det medføre en enkelhet i overføringen fra miljø til miljø. Uklarheter og ting som ikke passer rett inn i infrastrukturen må avklares på forhånd før avhengigheter blir for store til å kunne endres. 3.2 Miljøer Eksterne miljøer: I spesielle tilfeller er det behov for drift av miljøer eksternt. Disse miljøer er underlagt de samme reglene som for interne miljøer med visse unntak. lle unntak uansett skal det søken om og dokumenteres i unntaksregister og lagres i arkivløsning hos Statens Vegvesen. Interne miljøer: s datasenter tilbyr i utgangspunktet tre miljøer: Utvikling, Testprod og Produksjon. Utrulling og oppgradering av systemer starter i utvikling, kommer deretter til Testprod og til slutt i Produksjon. Produksjon Testprod Utvikling Beskrivelse/formål I dette miljøet kjørers produksjon. Sluttbruker bruker dette miljøet. Miljø for akseptansetester og ytelsestester. Skal som hovedregel være likt produksjon Tilgjengelig for utrulling av kode fra utviklere og systemforvaltere. Servicetid 24/7 eller 08:00 til 16:00 Normal arbeidstid Normal arbeidstid Vaktordning Ja, for 24/7 systemer Nei Nei Tilgang til innlogging på server(e) Kun IKT Drift Kun IKT Drift IKT Drift Utviklere Systemeier/forvalter (dministrator/root kun for drift) ndre behov må forekomme som krav fra leverandør, hvis våre miljøer ikke er tilstrekkelige. Side: 13 av 24
3.3 Plattformer har valgt å standardisere på noen plattformer for å oppnå god kompetanse og mulighet til å gi god assistanse for IKT-løsningene. 3.3.1 Operativsystem Server o RedHat Enterprise Linux (gjeldende versjon se HB162) (Intel, 64-bit) o Windows Server 2008 R2 (Intel, 64-bit) Klient o Windows 7 Enterprise 3.3.2 Database Oracle 11g R2 på Exadata (utvikling kjører samme versjon utenom Exadata) 3.3.3 pplikasjonstjener standardiserer på IKT-løsninger bygget på J2EE Oracle Weblogic (gjeldende versjon se HB162) på Exalogic (utvikling kjører samme versjon utenom Exalogic) 3.3.4 Cluster-rammeverk Veritas Cluster Server fra Symantec 3.3.5 Katalogtjeneste LDPv3 sentral katalog Meta Directory Service som bygger opp den sentrale katalogen fra andre kilder, f.eks. ctive Directory som brukes i klient-miljøet 3.3.6 Brannmur Tilstandsfull brannmur for IPv4 og IPv6. Nettverket er delt inn i soner fra internett og inn til klient-nett. Det er laget en policy når det gjelder mulighet for åpning av porter mellom soner. 3.3.7 Lastbalansering IP-basert hardware lastbalansering på TCP-port nivå. Mulighet for helsjekk basert på f.eks. HTTP header, svar på porten etc. utomatisk utmelding av servere som feiler helsesjekk 3.3.8 utentisering og autorisasjon Det er etablert sentral tilgangsstyring basert på OpenSSO Fingranulering av tilganger gjøres av applikasjonen selv Det brukes kryptering (for eksempel SSL) for å unngå at passord sendes i klartekst Tilgangskontroll og hvilket nivå dette blir satt til er avhengig av sikkerhetsnivået dataene/informasjonen løsningen behandler er klassifisert for. (Risiko og Sikkerhetsvurdering og verdivurdering må gjennomføres) Side: 14 av 24
3.3.9 Eksponering Behov for eksponering (eksternt og internt) må beskrives fra funksjonelle behov og må følge retningslinjene og etats standard. 3.4 Virtualisering har et stort antall servere virtualisert på VmWare plattform (ESXi). Det er etablert 5 Produksjon-, 1 Test- og 1 Utviklings-farmer. Virtualisering benyttes så langt det er mulig i datasenteret (kort tid for provisjonering og skalering, samt redundans). Underliggende maskinvare er basert på HP og Dell, og plassert adskilt for redundans i datahallene. Både RedHat Enterprise Linux og Windows 2008 server kan kjøres virtualisert i vårt VmWare miljø. 3.5 Nettverk s nettverk baserer seg på TCP/IP protokollen i versjon 4 og 6. Nettverket er bygd opp i et WN med varierende linjehastigheter fra 2 Mb/s og opp til 10 Gb/s på LN. Innen datasenteret i Brynsengfaret 6, tilbys lag 2 (data link) og lag 3 (network). For kommunikasjon til og fra datasenteret tilbys kun lag 3. 3.6 Lagring s lagringsløsning bygger på hardware fra Hitachi Data Systems. Den består av tre ulike nivåer med ulik ytelse: Nivå 1: Nivå 2: Nivå 3: USP-V med 300 GB og 600 GB FC disker på 15000 rpm. MS2500 med 600 GB SS disker på 15000 rpm. MS2500 med 2 TB ST disker på 7200 rpm. SS og ST er virtualisert bak USP-V slik at ingen klienter har kontakt med MS2500 skapene. Det finnes to identiske slike miljøer i to ulike datarom for redundans. Redundans oppnås som hovedregel med speiling på serveren. Diskene i lagringsløsningen settes opp med RID 6+2 og det er satt opp dynamisk provisjonering slik at det er mulig å overallokere disk. Side: 15 av 24
3.7 Høytilgjengelighet For applikasjoner som krever høy tilgjengelighet (driftstid 24/7), øker det og kompleksiteten, og dermed kostnadene, betraktelig. Det bør derfor vurderes nøye så tidlig som mulig, om dette er et reelt behov. bygger systemer for høytilgjengelighet rundt prinsippet med ingen single point of failure (SPOF). Slike løsninger skal med andre ord kunne kjøre videre med full funksjonalitet, eventuelt med redusert kapasitet, uansett om det oppstår feil i en hvilken som helst enkelt komponent. Ulike mekanismer brukes for å sikre dette. Det kan være for eksempel clustring eller lastbalansering. Et annet prinsipp er at et system med høy tilgjengelighet, ikke må være avhengig av et annet system med lavere tilgjengelighetsgrad. I forbindelse med sekundært datarom er plass og strøm begrenset og virtualisering er enda mer nødvendig for kunne etablere Legacy systemer. jobber for tiden med å få etablert et eget datasenter separat fra våre hoved-lokaler i Brynsengfaret 6. Det er foreløpig ikke avklart om det vil bli støtte for lag 2 mellom Brynsengfaret 6 og den nye lokasjonen. Datasenteret i består i dag av fire datahaller, de ligger i separate bygg. Systemer som krever høy tilgjengelighet, plasseres i begge bygg, slik at det kan kjøres videre om vi mister en datahall. 3.8 Konsolidering har bygd opp datasenteret rundt et hovedprinsipp om konsolidering. Dette stiller større krav til applikasjoner når det gjelder å følge standarder og best practice slik at flere applikasjoner kan leve side om side på samme server. Side: 16 av 24
4 Bilag 4: Prosjekt- og fremdriftsplan Her inntas prosjekt- og fremdriftsplanen for leveransen. Nedenfor følger bestemmelser som henviser frister eller endringer til dette bilaget. 4.1 Dokumentasjon, opplysningsplikt mv. vtalen punkt 2.1.2 Frist for levering av dokumentasjon for utstyr og standardprogramvare: Ved produksjonssetting av løsningen. 4.2 Tid og sted for leverandørens ytelse vtalen punkt 2.1.3 Utstyr og programmer i samsvar med denne avtalen skal være levert til Kundens adresse (installasjonsstedet) senest (dato) Installasjonsstedets adresse: Programmene skal installeres av: Leverandøren Kunden 4.3 Gjennomføring av Kundens godkjenningsprøve Dato for påbegynnelse av Kundens godkjenningsprøve: Dato for avslutning av Kundens godkjenningsprøve: 4.4 Dagbot ved forsinkelse vtalen punkt 6.2 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: Side: 17 av 24
5 Bilag 5: Testing og godkjenning Testing av løsningen anses som godkjent når alle definerte kravene i kravtabell er oppfylt. Funksjonaliteten blir testet før testing kan anses som godkjent. Testing skal gjennomføres med utgangspunkt i Teststrategi for. Teststrategien beskriver hvilke krav til test som gjelder for henholdsvis Kunde og Leverandør. Dersom partene avtaler andre tester og setter andre krav til testgjennomføring enn beskrevet i Teststrategi og avtalen skal det beskrives i dette bilag. Nedenfor følger punkter som avtalen henviser til dette bilaget. 5.1 kseptansetestens omfang vtalen punkt 2.2.2 Beskrivelse av Kundens godkjenningsprøve: programmet skal testes av en gruppe av prosjekterende og tekniske tegnere fra ulike fagdisipliner i Statens Vegvesen. Denne gruppen er ikke spesialister, men har god kunnskap innenfor DK. Programmet godkjennes hvis gruppen klarer å lage en enkel visualisering av grunnlagsmateriale, som Vegvesen stiller. 5.2 Krav til leverandør Leverandøren skal dersom ikke annet er avtalt fremlegge resultater fra testgjennomføring herunder logg over feil og endringsanmodninger til standardproduktet, fremsatt av Leverandøren selv og/eller andre kunder som benytter disse produktene. Side: 18 av 24
6 Bilag 6: dministrative bestemmelser Bilaget brukes til å samle administrative rutiner for avtaleforholdet og samarbeidet mellom partene. Leverandøren bes å fylle inn bilaget. 6.1 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 utskiftning av bemyndiget representant: 6.2 Krav til leverandørens ressurser og kompetanse vtalen punkt 5.2 Leverandørens prosjektleder: Leverandørens nøkkelpersonell: Navn: Stilling: Telefon: E-post: 6.3 Bruk av underleverandør Leverandørens godkjente underleverandører: Navn: Org.nr.: Leveranseområde Side: 19 av 24
7 Bilag 7: Samlet pris og prisbestemmelser lle 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. 7.1 Vederlag vtalen punkt 8.1 Prisene oppgis i norske kroner og eksklusiv merverdiavgift. nnet må spesifiseres særskilt. Det må oppgis hvorvidt prisen er per enhet eller f. eks per måned/år/avtaleperioden. Pris lisenser: Beskrivelse/navn Pris i NOK ntall Total (eksl. mva) Programvare for visualiseringer av vegprosjekter ink. Subscription Opsjon for ytterligere lisenser: Programvare for visualiseringer av vegprosjekter ink. Subscription 6 lisenser 4 lisenser Sum: Pris dokumentasjon: Beskrivelse/navn Pris i NOK ntall Total (eksl. mva) Opplæringsmateriale (manualer, video, ) Sum: Totalpris: Pris i NOK ntall Total (eksl. mva) Side: 20 av 24
7.2 Fakturering vtalen punkt 3.2 7.2.1 Betalingsplan: Det avtales betalingsplan iht. leveranser. Månedlig betaling ved kjøp av varer og tjenester knyttet til løpende drift og vedlikehold. 7.2.2 Øvrige betalingsvilkår s generelle betalingsbetingelse er 30 dager etter mottak av korrekt faktura og varer/tjenester. 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) 7.2.3 Fakturaadresse Regnskap Båtsfjordveien 18 9815 Vadsø 7.2.4 Merking av fakturaen Elektronisk faktura skal merkes med: Bestillers navn: Norma Enes ttestant: Sukhmeet Singh nsvarskode: 67141 Faktura sendt oss uten disse opplysningene må vi returnere. Ny betalingsfrist beregnes deretter ut fra mottak av korrekt merket faktura. lle fakturaer til skal sendes til ovennevnte adresse. Husk å skille mellom fakturaadresse og leveringsadresse når dere handler med oss. Betaling skjer etter kontraktsmessig levering. Det vil ikke bli betalt ut forskudd. Det skal ikke betales ekspedisjons- eller fakturagebyrer. Dersom det faktureres månedlig, skal fakturaen vedlegges en oversikt over utførte leveranser. Leverandøren skal levere fakturaer og kreditnotaer i henhold til det fastsatte formatet EHF. Leverandørens EHF-fakturaer skal sendes til Oppdragsgivers organisasjons nummer: 97 10 32 081 Side: 21 av 24
Leveranse av EHF skal skje på den av Direktorat for forvaltning og IKT (Difi) 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. Leverandøren må selv bære eventuelle kostnader leveranse av EHF måtte medføre. Leverandøren skal sette seg inn i Oppdragsgivers og Difi s krav til EHF-faktura. Informasjon om hvordan Leverandøren skal levere EHF til Oppdragsgiver, samt særskilte krav til datainnhold finnes her: http://www.vegvesen.no/om+statens+vegvesen/kontakt/kontakt+oss/for+leverandorer/elektronisk faktura EHF som ikke oppfyller Oppdragsgivers og Difi s minstekrav til fakturering, har Oppdragsgiver rett til å returnere. Dersom Oppdragsgiver rettmessig har returnert en faktura, skal betalingsfristen i denne forlenges til et tidspunkt som er rimelig. 7.3 Prisendring vtalen punkt 3.5 Hovedregelen er at prisene ikke endres i avtaleperioden. Fylles ut dersom partene avtaler regulering etter annen indeks enn konsumprisindeksen, f. eks lønnsindeks for bransjen. Timepris kan endres i henhold til SSBs prisindeks for datakonsulenttjenester. (http://www.ssb.no/tpiikt/) vtalt prisendring: iht. avtaler 7.4 Eiendomsrett til utstyr vtalen punkt 4.1 vtalt salgspant: (Fylles ut dersom partene har avtalt salgspant) 8 Bilag 8: Endringer i den generelle avtaleteksten Endringer til den generelle avtaleteksten skal samles i dette bilag, 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. Side: 22 av 24
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 Side: 23 av 24
9 Bilag 9: Endringer av leveransen etter avtaleinngåelsen Endringer av ytelsen etter avtaleinngåelsen skal avtales skriftlig. Leverandøren skal føre en fortløpende katalog over endringene som utgjør dette bilaget. Nr Dato Endringen gjelder Side: 24 av 24