PS2000 Kontraktsstandard for leveranse av programvare m. m.

Del III - Kontraktsbilag

DEN NORSKE DATAFORENING

Kommentar fra PROMIS april 2008: Dette er et eksempel på utfylte bilag som både viser forklarende tekst <i klammer og kursiv> og spesifikk kontraktstekst, her vist med revisjonsmerking, slik at det tydelig fremgår hva som er lagt til. Den forklarende teksten i kursiv vil bli strøket i endelig kontraktstekst, men er her altså beholdt for å vise hvilken informasjon PS 2000-kontrakten etterspør, og hvordan leverandøren har besvart dette.

I bilag A er kun et utvalg av besvarelsen av kravene tatt med. Følgende eksempel kan illustrere et typisk omfang; Kontrakt på 10 MNOK, 200 krav, beskrevet på 150 sider, inklusiv behovsbeskrivelse, kravbesvarelse, beskrivelse av overordnet løsningsforslag, forutsetninger, usikkerhetsvurderinger, og eventuelt referanseprosjekter.

Innholdsfortegnelsen i hvert bilag er ikke nødvendigvis oppdatert.

Versjon : 3.0

Dato oppdatert : 09.04.08

Bilag A: Behovsanalyse

INNHOLDSFORTEGNELSE

A 1 INNLEDNING 4

A 2 BEHOVSANALYSE 5

A 2.1 Overordnede behov og anvendelsesområder 5

A 2.2 Generelle krav 5

A 2.3 Funksjonell beskrivelse 5

A 2.4 Funksjonskrav og tekniske krav 5

A 3 GROVT LØSNINGSFORSLAG 7

A 4 FORUTSETNINGER OG FORBEHOLD 8

A 5 USIKKERHETSMATRISE 9

A 1 Innledning

Dette Kontraktsbilag inneholder en behovsanalyse som skal være grunnlaget for gjennomføring av Leveransen. Behovsanalysen er dokumentert i form av en kravtabell som gir en grov spesifikasjon av Kundens behov, krav og egne leveranser.

Videre inkluderes Leverandørens utdypning av forutsetninger og forbehold i et grovt løsningsforslag.

I tillegg inkluderes en usikkerhetsmatrise som er et underlag for ansvarsdeling og vederlag slik det blir dokumentert i øvrige bilag.

A 2 Behovsanalyse

A 2.1 Overordnede behov og anvendelsesområder

A 2.1.1 Overordnede mål

KUNDE X skal fremstå som en profilert, sterk og verdidrevet organisasjon. KUNDE Xs grunnleggende roller er å påvirke beslutningstakere, understøtte tillitsvalgte og yte medlemsservice. Utviklingen av KUNDE X-portalen er et virkemiddel for å nå organisasjonens overordnede mål og for å støtte ansatte i utøvelsen av våre grunnleggende roller.

KUNDE X-portalen skal forenkle arbeidshverdagen for våre medlemmer, tillitsvalgte, organisasjonsvalgte og ansatte.

Xxxxxxxx skal rette seg mot både interne og eksterne målgrupper og skal sikre de enkelte målgrupper tilgang til personifiserte arbeidsflater. For nærmere beskrivelse, se pkt A2.6.

A 2.1.2 Beskrivelse av dagens situasjon

KUNDE X har i dag kun en internettløsning for distribusjon av informasjon. Nåværende løsning er frittstående i den forstand at den i liten grad er integrert mot andre systemer. Den har begrensninger hva gjelder mulighet til å effektivisere interne og eksterne arbeidsprosesser gjennom bruk av blant annet selvbetjeningsløsninger mot våre medlemmer. Dagens arkitektur støtter i liten grad fleksibel bruk av kompetanse og samarbeid på tvers i en geografisk spredt organisasjon.

For elektronisk distribusjon av informasjon til ulike målgrupper er kanalene pr i dag nettsidene som er åpne for alle, eller e-post. KUNDE X mangler således elektroniske arenaer som gir ulike målgrupper, avhengig av rolle og funksjon, ulik tilgang på informasjon og kunnskap.

KUNDE X har i 2007 innført et felles dokumenthåndteringssystem (Livelink ECM - eDOCS DM). Dette er første skritt i retning av å tilrettelegge for større grad av informasjonsutveksling, kompetansedeling og kompetanseflyt i KUNDE X. Arkivfunksjonen gir flere grupper i KUNDE X tilgang til en felles kunnskapsbase.

Vi har per i dag ingen felles løsning/funksjonalitet for fremskaffelse av rapporter og statistisk materiale i organisasjonen, men er henvist til å bruke funksjonalitet som er knyttet til enkeltstående applikasjoner/systemer. Dette gjør at vi i dag bruker unødvendig mye tid på å fremskaffe beslutningsunderlag og statusrapporter i forhold til de ulike deler av organisasjonens måloppnåelse.

KUNDE X har i dag en meget begrenset ekstranettløsning, som gir medlemmene et begrenset innsyn i informasjon vi har lagret om dem og muligheter til å fylle ut ulike bestillings- og/ eller meldingsskjemaer. Skjemaløsningen er basert på enkeltstående programmer som er

utviklet ved bruk av Domino/Notes og disse løsningen er i liten grad basert på toveis integrasjon med databasen. For øvrig brukes løsningen som en mer eller mindre statisk informasjonskanal.

KUNDE Xs produksjonsmiljø består per i dag en kombinasjon av Microsoft, Lotus Notes/Domino, Oracle og Linux.

KUNDE X har en IT-plattform bestående av sentraliserte tjenester som Windows 2003 domene, databaser, applikasjoner og lagring.

Servere	KUNDE X har investert i en VMware løsning basert på VI3. Kapasiteten er stor og hver av de 6 serverne har 2xIntel Quad Core 2,66ghz, 32gb ram, 4x1gbit nettverkskort, 2x4gbit Qlogic HBA Alle serverne er koblet mot et Dell EMC CX3-20 SAN basert på 4gbit fiberchannel SCSI via redundante Brocade switcher. For de serverne som IKKE passer inn i et VMware miljø har vi Dell bladeservere med samme spesifikasjoner som VMware serverne som også er tilkoblet SAN.
Lagring	KUNDE X har to SAN, et Dell/EMC CX300 og et Dell/EMC CX3-20 som begge er koblet til Brocade switcher. Vi har totalt over 5TB lagringskapasitet fordelt på forskjellige typer RAID volums. CX3-20 kan utvides med flere hyller.
Backup	KUNDE X bruker TSM som backupsoftware og kjører backup til disk (SAN) og kopi til tape (LTO3).
Nettverk	KUNDE X's kjernestack er basert på 10gbit+ backbone og 1gbit kantswitcher. VMware serverne er direkte tilkoblet kjernestacket. Firewallene er redundante og kjører full 10gbit hastighet.
Load balancing	Vi har også 2stk F5 BIG-IP bokser for loadbalancing av trafikk
Internettlinjer	KUNDE X har idag 50mbit fiber via TDC Song, med en backup via kommer på 4mbit. Vi har idag et helt C-nett med offisielle ip-adresser som vi "eier" (ikke ISP avhengige ip-adresser).
Arbeidsstasjoner	I KUNDE Xs nettverk benyttes både bærbare pc-er, stasjonære pc-er og terminaler. Det er i hovedsak på fylkeskontorene det brukes terminaler, men det finnes også terminalbrukere i Forhandlingsavdelingen. Operativsystemet som kjøres er Microsoft Windows XP. Terminalene benytter Citrix Metaframe for aksessering av KUNDE Xs systemer.

KUNDE X har i dag ca. 200 interne brukere og ca. 100 Hovedtillitsvalgte med utstyr fra KUNDE X. Av disse befinner en ca. 130 seg ved hovedkontoret i Oslo, mens de resterende er spredt geografisk.

I Tabellen nedenfor er noen interne systemer nærmere beskrevet:

Telefoni (Alcatelløsning)	KUNDE X benytter per i dag en IP-basert telefoniløsning fra Alcatel som inkluderer en avansert kontaktsenterfunksjonalitet(Alcatel Premium edition), og som for øvrig også er ment å skulle håndtere henvendelser via e-post. Telefoniløsningen er driftet sentralt og bruker WAN-forbindelsene for å styre inngående og utgående trafikk til våre fylkeskontor. Telefoniløsningen er tilpasset integrasjon også mot IMS systemer.
Livelink ECM-Edocs DM(dokumenthåndteringsystem)	KUNDE X har i løpet av høsten 2007 innført nytt dokumenthåndteringssystem i hele KUNDE X og dette skal for fremtiden være det stedet vi lagrer alt arkivverdige materiale og all virksomhetsrelatert dokumentproduksjon. Dokumenthåndteringssystemet baserer seg på bruk av Oracle database og et filbibliotek som er etablert på KUNDE Xs filserver. Løsningen har per i dag en viss integrasjon mot vårt nåværende medlemssystem. Som et tillegg til dokumenthåndteringssystemet, medfølger en modul for å tilgjengeliggjøre funksjonalitet fra dokumenthåndteringssystemet via Web (Livelink ECM- Edocs Collaboration). Ved innføringen av vår nye Virksomhetsportal, vil det være ønskelig at portalløsningen blir etablert på en slik måte at den kan hente og presentere informasjon direkte fra dokumenthåndteringssystemets fillager.
Nytt medlemssystem	KUNDE X benytter per i dag et spesialutviklet medlemssystem som i sin tid ble basert på Winorg, men som benytter en helt egen datamodell. Vi vil i løpet av 2007 ha gjennomført en anbudskonkurranse med sikte på å ha anskaffet et nytt medlemssystem. Vi ønsker at valgt leverandør av portalrammeverk utvikler brukergrensesnittene til medlemssystemet, som skal brukes i portalen. Vi tror at vi trenger å utvikle egne brukerdialoger for å oppnå et optimalt samspill med medlemssystemet, i kontekst av portalrammeverket. Videreutviklingen bør skje i samarbeid med kommende leverandør av nytt medlemssystem.
Visma Business økonomisystem	Som økonomisystem benytter vi Visma Business og dette kjører på en Oracle database.
Eksisterende internettsider	Dagens Internettsider bruker CoreTrek sin PHP-baserte

	publiseringsløsning CorePublish og denne kjøres på en My SQL-database. Det må vurderes hvilke konsekvenser valg av portalrammeverk har i forhold til denne publiseringsløsningen.
Domino/Notes (ekstranett + skjemaer på internett)	Eksisterende Domino/Notes miljø inneholder en del applikasjoner som sikrer at vi kan tilby elektroniske skjemaer på nett, samt noe prosesstøtte knyttet til å gjennomføre elektronisk valg av kandidater(studentvalg) via bruk av nett og SMS. I tillegg gir løsningen oss mulighet til å gi det enkelte medlem tilgang til å se hvilke forsikringer vedkommende har tegnet via sitt medlemskap i KUNDE X. Pålogging til løsningen foregår ved bruk av den enkeltes medlemsnummer og et passord, og tilgangsstyringen skjer ved bruk av mekanismer i Domino. I tillegg har KUNDE X Notes-baser som støtter saksbehandling og statistikk knyttet til stipend og yrkesskadesaker. Ved implementeringen av Portalløsningen tar vi sikte på å gradvis fase ut alle applikasjoner som er utviklet i Notes/Domino og det vil sånn sett være viktig å tidlig få på plass funksjonalitet som understøtter våre løsninger mot medlemmene på en bedre måte enn slik dette håndteres i dag.
	KUNDE X skal implementere et nytt lønns- og personalsystem i løpet av Q1 2008 og dette vil være Visma Unique. Løsningen er utviklet i Java og kjører på en Oracle database. Visma Unique er tilrettelagt for og inneholder funksjonalitet knyttet til Minside funksjonalitet. I tillegg vil det bli inkorporert et webbasert verktøy knyttet til registrering av timer og fravær.
Visma Unique lønns- og personalsystem	KUNDE X skal implementere et nytt lønns- og personalsystem i løpet av Q1 2008 og dette vil være Visma Unique. Løsningen er utviklet i Java og kjører på en Oracle database. Visma Unique er tilrettelagt for og inneholder funksjonalitet knyttet til Minside funksjonalitet. I tillegg vil det bli inkorporert et webbasert verktøy knyttet til registrering av timer og fravær.
Gruppevare/ e-postløsning	KUNDE X benytter per i dag Lotus Notes som e- postløsning og sametime som internt instant messaging verktøy. Dagens Lotus Notes miljø er satt opp med bruk av ulike workspaces som inneholder ulike håndbøker med mer. I forbindelse med implementering av vårt nye dokumenthåndteringssystem høsten 2007, vil de fleste av

håndbøkene bli flyttet over fra Notes format til annet format i dokumenthåndteringssystemet.

KUNDE X har blant annet som en følge av at vi kun står igjen med Notes som et e-postverktøy, besluttet at Notes skal erstattes av Outlook og Exchange fra og med Q3 neste år og det vil sånn sett være naturlig å fase ut sametime fra samme tidspunkt.

POB (Servicedesk, internbestillinger)

Vi er i gang med å innføre Point of Business(POB) som vårt nye servicedeskverktøy. Denne løsningen er ment å skulle brukes i forhold til feilmeldinger til IT, bestillinger til IT, melding av avvik, vaktmester tjenester med mer.

Løsningen er basert på generering av web-skjemaer som front end ut mot brukerne og er tilrettelagt for tett integrasjon inn mot et portalrammeverk.

Eksisterende infrastruktur (prinsippskisse):

A 2.1.3 Ønsket fremtidsbilde-overordnet nivå

Generelt sett blir ordet Portal ofte brukt til å beskrive en inngang (eller ”gateway”) til en samling av internettsider som tilbyr flere forskjellige applikasjoner og informasjon under en adresse, dvs. logisk sett på ett sted (”one stop”). Dette gjenspeiler en brukers opplevelse og syn på en portal. Innholdet vist i portalen kan være forskjellig for forskjellige brukere, men

felles for alle brukere er at de vil oppleve forenklet og raskere tilgang til de viktigste verktøy og informasjonselementer som hver enkelt av dem trenger i hverdagen.

Portalløsningen skal benyttes av alle ansatte i KUNDE X, politisk valgte, tillitsvalgte, medlemmer, eksterne samarbeidspartnere, pressen og allmennheten og skal være den mest oppdaterte kanalen for informasjon og samhandling. Løsningen bygger på en integrert ”kjerne” som skal anvendes for både internett-, ekstranett- og intranett-kommunikasjon, en såkalt trippelnett-løsning.

Portalløsningen skal automatisere og effektivisere KUNDE Xs arbeidsprosesser og skal bidra til at vi blir en moderne, fleksibel og målfokusert organisasjon. En langsiktig målsetting er at vi skal etablere portalløsningen som vår viktigste arena for samhandling med våre medlemmer.

Portalen skal videre understøtte politisk valgte ledere, tillitsvalgte og administrative lederes behov for tilgang til statistikk og uthenting av styrings- og ledelsesinformasjon.

KUNDE X ønsker å drifte den ferdige løsningen selv.

A 2.2 Generelle krav

Selv om det ikke fremgår eksplisitt av Bilag A, er det en forutsetning at Løsningsbeskrivelsen utarbeides og videre at Komponentene utvikles og tilpasses slik at Leveransen fremstår for Kunden som en helhet, med et enhetlig og konsistent brukergrensesnitt.

Leverandøren skal gi en overordnet beskrivelse av selve løsningen, og hvordan dette produktet kan bidra til å realisere Kundens mål.

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar

(J / N / forbehold)

Utfyllende kommentar

Gi en oversiktlig, overordnet og kortfattet beskrivelse av funksjonalitet, oppbygging, og virkemåte for tilbudt verktøy/løsning.

<Leverandørens overordnet beskrivelse av løsningen>

Portal løsninger bidrar til å øke effektiviteten for en organisasjon gjennom å øke effektiviteten på de tjenester som tilbys for ansatte, kunder og partnere, og gjør organisasjonen i stand til å operere mer smidig i forhold til disse gruppene. Portaler gir bedre og mer konsistent tilgang til innhold, applikasjoner og foretningsprosesser for de forskjellige brukerne.

BEA WebLogic Portal er et fleksibelt portal rammeverk som bygger på tjenesteorienterte prinsipper, og som gjør det mulig å tilby brukere funksjonalitet i forhold til en trippelløsning, internett, ekstranett og intranett, og å gjenbruke funksjonalitet i forhold til de tre, der dette er naturlig. Dette gjelder for innhold, portlets, sider og bøker. En side innholder flere portlets, og en bok består av flere sider.

Videre vil personalisering gjøre det enklere for den enkelte bruker å få tilgang til det denne trenger i forhold til å ivareta sine oppgaver og få dekket sine behov for informasjon og tilgang til relevante applikasjoner og prosesser. Personalisering skjer med bakgrunn av hvilke roller og egenskaper brukeren har. Dette kalles en brukerprofil.

BEA WebLogic Portal understøtter SSO i forhold til de applikasjoner og den funksjonalitet som tilgjengeliggjøres via portalen, og dette sammen med personalisering gjør at brukerne bare får til gang til funksjonalitet i forhold til rolle og egenskaper ved brukerne. Dette gjelder i forhold til bøker, sider og portlets og innhold i portlets.

For å bedre evnen til å respondere på endrede betingelser i forhold til virksomheten, gir en portal med underliggende bruk av tjenester, et fortrinn i forhold til å raskt understøtte de til enhver tid gjeldende behov, og gjør organisasjonen mer fleksibel i forhold til endringer.

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar

(J / N / forbehold)

Utfyllende kommentar

Gi en oversiktlig, overordnet og kortfattet beskrivelse av teknisk arkitektur for tilbudt verktøy/løsning, herunder drifts- og sikkerhetsmessige forhold.

<Leverandørens beskrivelse av overordnet teknisk arkitektur.>

Løsningsforslaget bygger på standard tjenestelagdeling for å sikre at løsningen er utvidbar og modularisert.

Eksisterende applikasjoner

Internet Extranet

Intranet

Internet Extranet

Intranet

Portal / Publisering

Internet Extranet

Intranet

Arbeidsflyt

Tjenestebasert mellomvare-/integrasjonslag

Elektronisk Dokumenthåndtering

Arbeidsrom

Portal / Publisering

Brukeradministrasjon

Rapportering / Statistikk

Søkemotor

Portalen med tilhørende publiseringsfuksjonalitet ligger på toppen og knytter til seg funksjonalitet for arbeidsrom, arbeidsflyt og arkivering fra underliggende standardprodukter. Funksjonalitet for brukeradministrasjon, rapportering og søk utnyttes på tvers av løsningen, mens det integreres med allerede eksisterende applikasjoner via et tjenestebasert mellomvarelag.

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar

(J / N / forbehold)

Utfyllende kommentar

Gi en samlet oversikt over funksjonalitet i tilbudt løsning som ikke er etterspurt i spesifikke krav, men som leverandøren mener kan være til nytte for oppdragsgiver

<Leverandørens utfyllende kommentar skrives her>

For en utfyllende beskrivelse av produktet se Error! Reference source not found..

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar

(J / N / forbehold)

Utfyllende kommentar

Gi en samlet oversikt over funksjonalitet i kravspesifikasjonen som leverandøren mener ikke vil være til nytte for oppdragsgiver

<Leverandørens utfyllende kommentar skrives her>

Det er i løsningen skissert en SOA arkitektur der det ønskes å benytte seg av en Service-Bus for integrasjonslag. Det å legge opp til en modularisert og tjenestebasert arkitektur mener Leverandøren er et lurt valg, men det å gå til investering av en Service-bus er kun lønnsomt dersom en tjeneste benyttes av mange løsninger. Dersom de skisserte tjenestene kun vil benyttes a portalen anbefales det at man heller legger opp til et integrasjonslag på porta- serveren for å redusere lisenskostandene for KUNDE X.

1.1 Overordnet krav til løsningen

Produktet skal ha eksisterende installasjoner og en bredde i implementeringer som gir Kunden trygghet for support og videreutvikling.

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar

(J / N / forbehold)

Utfyllende kommentar

Verktøyet/løsningen skal i størst mulig grad bygge på en standard- løsning og skal ha installasjoner hos kunder med samme kompleksitet og størrelse som for Kunden.

<Leverandørens beskrivelse av referanseinstallasjoner.>

BEA systems har over 18000 kunder. Eksempler på Kunder i Norge som benytter BEA Portal er Nordea, Sparebank1, Oslo Kommune, Kongsberg gruppen, Selvaag, Hafslund, Avinor, Telenor, Troms Kraft, Norges Forskningsråd, GET, Skeidar, Hurtigruten.

Se Error! Reference source not found. for en beskrivelse av løsningsmodellen.

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar

(J / N / forbehold)

Utfyllende kommentar

Verktøyet/løsningen skal være basert på veldefinerte, åpne standarder og de tekniske løsningene skal ikke være bundet til ett eller få operativsystemer.

<Leverandørens beskrivelse av produktets støtte for åpne standarder >

BEA Systems er en pådriver innen åpne standarder, og deltar aktivt i standardiseringsorganisasjonene. BEA WebLogic Portal er basert på BEA WebLogic Server,

som er JEE 5 sertifisert, og portalen har støtte for spesifikasjoner som JSR 168 portlet spesification, JSR 170, Content Management API, WSRP WebServices for Remote Portlets.

BEA WebLogic Portal er tilgjengelig på et bredt sett av operativsystemer, som omfatter flere varianter og versjoner av Windows, Linux, HP-UX, Solaris, AIX, m.fl. For en komplett liste se: xxxx://xxxxx.xxx.xxx/xxxxxxxx/xxxxxxxxxxx/xxxxxxx000/000_xxxx/xxxxxxxx.xxxx#0000000

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar

(J / N / forbehold)

Utfyllende kommentar

Det skal kunne dokumenteres at støtteverktøyet håndterer de angitte datavolumer og bruksmønster.

<Leverandørens dokumentasjon av ytelse.>

BEA WebLogic Server som BEA WebLogic Portal er basert på, har beste ytelse i uavhengige ytelses tester. Videre kan man med bakgrunn i oppgitte referanser se at dette er organisasjoner og bedrifter med meget store krav til volumer og ytelser.

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar

(J / N / forbehold)

Utfyllende kommentar

Leverandøren skal ha dokumenterte rutiner for kvalitetssikring av test og produksjonsstart ved versjonsendringer og implementering av ny funksjonalitet i produktet.

<Leverandørens beskrivelse av rutiner.>

BEA WebLogic Portal leveres med et sett med verktøy, ”best practice rutiner” og dokumentasjon som beskriver hvordan miljøene bygges opp, og hvordan man går fra produksjonstest til produksjon.

Leverandøren har dessuten lang erfaring i å håndtere slik versjonsproblematikk i sine løsninger. Leverandøren’ rutiner og prosedyrer sikrer at de moduler som blir spesialutviklet for løsningen vil videreføres på en trygg og gjennomtestet måte. Se beskrivelse av vår metodikk i Bilag C.

A 2.3 Funksjonell beskrivelse

A 2.4 Funksjonskrav og tekniske krav

Nedenfor inkluderer spesifikke, nummererte krav. Listen kan ikke ses som uttømmende i forhold til ovenstående funksjonelle beskrivelse, men som en utdypning av nødvendige, utvalgte områder.

Brukervennlighet

I en brukervennlig nettløsning kan brukerne lett sette seg inn i og ta i bruk informasjonen og tjenestene som finnes. Brukervennlighet beskriver hvor lett det er for brukerne å sette seg inn i og ta i bruk portalen.

Brukerne må lett kunne navigere seg frem mellom ulike elementer i portalen og enkelt kunne samhandle med andre brukere i portalen.

Systemet vil være hovedverktøyet for flere brukere og det er derfor avgjørende at systemet er effektivt og logisk å bruke.

Effektivitet og navigering

Systemet skal være et effektivt arbeidsredskap. Systemet skal forenkle arbeidsgangen og hjelpe brukerne til å gjennomføre arbeidsoppgaver/håndtere samhandling med KUNDE X så raskt og effektivt som mulig.

Krav nr.	Beskrivelse	Prioritet	Trinn nr.	Leverandørens svar (J / N / forbehold)	Utfyllende kommentar
9.	Portalen skal være et effektivt arbeidsredskap, det skal intuitivt og lett å navigere	A		J	X
10.	Navigasjon i systemet må kunne gjøres både med mus og tastatur (hurtigtaster).	A		J Dette vil støttes i de nettlesere som har funk- sjonalitet for dette.
11.	Hvert av de tre nettstedene (i trippelnettet) skal ha et dynamisk nettstedskart. Endring av struktur, titler på sider, o.l. skal automatisk oppdateres i nettstedskartet	A		J
12.	Det skal være enkelt å opprette, flytte, endre og slette elementer i informasjonsstrukturen, evt. substrukturer og i menyen. Det skal gå an å legge til punkter i menyen(e) som peker til et valgt sted, f. eks. en ny modul, en sak eller et bilde. En slik modul kan for eksempel være en telefonkatalog	A		J	X

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar

(J / N / forbehold)

Utfyllende kommentar

eller et kurs som loser brukeren gjennom kunnskap på en visuell og pedagogisk måte

<Leverandørens utfyllende kommentar skrives her>

Ved å basere seg på gode designprinsipper og erfaringer fra tidligere portalprosjekter så vil Leverandøren sikre at løsningen vil være effektiv og intuitiv å bruke. For å sikre at dette stemmer med KUNDE X sin brukermasse bør brukerne være delaktige i brukertester og design av løsningen.

Det vil legges opp til at det i størst mulig grad vil være enkelt å flytte, endre og slette elementer i informasjonsstrukturen.

Fleksibilitet

Løsningen skal være fleksibel med tanke på personalisering av portalen. Brukere skal selv kunne designe fordelingen av funksjonalitet (portlets) i portalen.

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar

(J / N / forbehold)

Utfyllende kommentar

13.

Portalen skal være fleksibelt, det skal være lett å konfigurere innholdet.

<Leverandørens utfyllende kommentar skrives her>

Ved å benytte seg av standard portalrammeverk fra BEA vil vi oppnå at det er lett å konfigurere innholdet. Hovedsakelig fordi dette er et rammeverk som er ment å dekke et stort utvalg av funksjonsområder, og dermed trenger å være meget fleksibel i sin oppbygging.

Brukergrensesnitt

Det skal følges en standard for grensesnittet som gir konsistens i applikasjonen. Brukergrensesnittstandarden skal også være med å ivareta kvalitet i skjermbildekommunikasjonen mellom system og bruker. Dette innebærer blant annet standardisering og konsistens på tilbakemeldinger og feilmeldinger, knapper etc.

Brukergrensesnittstandarden skal bidra til å gi:

• Økt kvalitet

• Økt produktivitet under bruk av systemet

• Økt forståelse for bruk av systemet

Det ferdige grensesnittet skal være forankret i KUNDE Xs grafiske profil, samtidig som det er forankret i konvensjoner og brukertester for funksjonell og brukervennlig utforming.

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar (J / N / forbehold)

Utfyllende kommentar

Krav nr.	Beskrivelse	Prioritet	Trinn nr.	Leverandørens svar (J / N / forbehold)	Utfyllende kommentar
14.	Systemet skal være brukervennlig og tilgjengelig gjennom design og navigasjon	A		J Sikres ved å bygge på gode designprinsipper og valideres med brukertesting.	X
15.	Portalen skal ha grafisk særpreg basert på enkelhet og kvalitet	A		J	X
16.	Portalen skal tilfredsstille WAI kravene	A		J Leverandøren vil etterstrebe å tilfredsstille WAI kravene, men noen av de andre kravene fra KUNDE X kan være delvis motstridende med disse. Leverandøren vil sammen med KUNDE X vurdere hvilke som skal prioriteres i løsnings- beskrivelses- fasen.
17.	Leverandøren skal beskrive hvilke rammer og muligheter den tekniske løsningen for portalen gir i forhold til grafisk utforming og struktur i portalen	A		J Det legges et portalprodukt i bunnen som har noen føringer på grafisk utforming og struktur. Det er mye fleksibilitet i produktforslaget	X
18.	Leverandøren bes om å oppgi hvilken kompetanse bedriften har på UI og grafisk design	A		J	X

Det vil legges opp til en brukervennlig løsning som tar med seg gode design og navigasjonsprinsipper fra andre løsninger.

For å sikre at løsningen blir designet etter gode designprinsipper og brukertestet på korrekt måte, vil Leverandøren å benytte seg av personer med spesialisering inne UI og grafisk design.

Kvalitetskrav og tilgjengelighet

Vi har et spesielt ansvar for at funksjonshemmede sikres god tilgjengelighet til vårt trippelnett. Det vises i denne sammenhengen til internasjonale krav til tilgjengelighet utarbeidet av World Wide Web Consortium (W3C), ved Web Accessibility Initiative (WAI).

Krav nr.	Beskrivelse	Prioritet	Trinn nr.	Leverandørens svar (J / N / forbehold)	Utfyllende kommentar
19.	Løsningen skal tilfredsstille alle retningslinjer spesifisert i Statskonsults ”Retningslinjer for offentlige webtjenester; Kvalitet på nett”: xxx.xxxxxxxxxxxxxxx.xxx	A		J Postjournal er funksjonalitet som ikke er skissert i denne krav-	X
				spesifikasjonen,
				og er derfor ikke
				inkludert i
				tilbudet.

Retningslinjene som er skissert i xxx.xxxxxxxxxxxxxxx.xxx er retningslinjer som gjelder de fleste offentlige nettsteder. Noen av kravene er rettet direkte mot offentlige etater og deres krav til dokumentasjon, disse kravene gjelder ikke organisasjoner og private selskaper.

Hvilke krav som skal oppfylles bør diskuteres i løsningsbeskrivelsesfasen. De krav som typisk dekkes av WAI kravene vil oppfylles som beskrevet i krav 16.

Personifisering av brukergrensesnitt

Krav nr.

Beskrivelse

Prioritet

Trinn nr.

Leverandørens svar

(J / N / forbehold)

Utfyllende kommentar

20.

Xxxxxxxx skal kunne tilpasse sin egen arbeidsflate med ønsket funksjonalitet. Brukere skal kunne sortere i tabeller etter eget behov. Ved endring av standardoppsettet, skal hver bruker få opp sin spesialtilpassede arbeidsflate etter at endringer i standardoppsettet er lagret.

Portal- rammeverket tillater dette. Hvilke mulig- heter som skal tilbys avklares i løsningsbeskriv elsesfasen.

<Leverandørens utfyllende kommentar skrives her>

Leverandøren anbefaler at mulighetene for å tilpasse sin egen arbeidsflate differensieres for de forskjellige brukergruppene. Det å tillate at alle brukere har sine egne arbeidsflater krever mye av portalen med hensyn på ytelse. Det anbefales derfor at man lager kontrollerte konfigurasjonsmuligheter for eksterne brukere. Typiske tilpasninger som ikke krever mye ytelse er filtrering av nyhetslister basert på interesser m.m. Det å la store deler av portalbildet være konfigurerbart er noe man vanligvis forbeholder intranettbrukere.

Krav til daglig forvaltning av brukergrensesnitt

KUNDE X ønsker full kontroll over den daglige forvaltningen av brukergrensesnittet, og at dette skal kunne håndteres på en effektiv måte av administratorer og web-redaktør.

Følgende modell er en skisse over hvordan dette kan løses:

Siden alt innhold og funksjonalitet i portalen skal presenteres for brukeren gjennom visninger av ulike portlets er det naturlig å tenke seg en modell hvor de ulike sidene i grensesnittet er basert på en rekke grids. Det vil si at visningen av en side i portalen består av en grid som består av et antall mindre vinduer.

Prioritet angis som A (absolutt), B (skal inkluderes, men kan utsettes til senere trinn) og C (ønskelig, men kan utelates). Trinn nr. må ses som en tilleggsopplysning til prioritet og må regnes som tentativt. Dersom Leverandøren tar forbehold som trenger utdypning, skal det gjøres i kapittel A 4, med referanse til kravnummer.

A 3 Grovt løsningsforslag

A 3.1 Funksjonell beskrivelse

De følgende beskrivelsen omhandler, for de ulike modulene skissert i kundens krav, en beskrivelse av foreslått funksjonalitet.Portalløsningen realiseres gjennom portalrammeverket BEA WebLogic Portal, Jabber lynmeldingsprotokoll, JasperReports og eventuelt BEA Aqualogic Enterprise Service-Bus. Ved endelig leveranse vil løsningen inkludere en såkalt trippelnettløsning, det vil si en portalløsning for intranett, ekstranett og internett.

En del elementer vil være gjennomgående for hele portalløsningen. Dette innebærer blant annet at alle sider på nettstedet har KUNDE X’s grafiske profil, og at de har globalmeny for å navigere til ønskede områder. Det vil også finnes en "brødsmulesti" av navigasjonshensyn på alle sider. Alle sider inneholder også for eksempel ”Om nettstedet”, ”Nettstedskart”, Bunntekst (Footer) og Påloggingsfelt. Søk vil også være tilgjengelig fra alle sider i portalløsningen. Error! Reference source not found. viser et forslag til en side som baserer seg på dagens løsning. Brukere vil, etter autentisering, kunne navigere fritt mellom åpne sider og sider som krever innlogging.

A 3.1.1 Tilgjengelighet og brukskvalitet

Krav til tilgjengelighet og brukskvalitet vil også være gjennomgående for hele løsningen. Slik kan alle nye brukere av løsningen raskt bli produktive og bruke løsningen effektivt. Dette gjelder både for eksterne og interne grensesnitt.

Løsningen vil bli utviklet for å innfri relevante tilgjengelighetskrav definert i Web Content Accessibility Guidelines (WAI-standarden – xxx.x0.xxx/XXX ) og Xxxxx.xx (xxx.xxxxx.xx/xxxxxxxx/). Noen av disse kravene går på det tekniske rammeverket og kan innfris en gang for alle når løsningen utvikles, andre krav kan dreie seg mer om det redaksjonelle innholdet på sidene, og kan kreve både teknisk tilrettelegging og kontinuerlig innsats og oppfølging fra redaktørene som vedlikeholder nettstedet.

Alle sider vil bli utformet for optimal ergonomi og brukervennlighet. I dette ligger det blant annet at man i hele portalløsningen enkelt kan knytte hurtigtaster (access keys) til lenker, funksjoner og felter. De fleste moderne nettlesere, inkludert Internet Explorer, Mozilla Firefox og Opera, støtter denne navigeringsmekanismen.

A 3.1.2 Internett

Nettstedet er kundens inngangsport til informasjon og arbeidsflater utenfra. Typiske brukergrupper er medlemmer, pressen eller andre som vil vite noe om KUNDE X.

Leverandøren gjør oppmerksom på at dette skjermbildet kun er ment som illustrasjon, og at det ikke vil være identisk med den endelige løsningen.

A 4 Forutsetninger og forbehold

Krav nr.	Forbehold
22	Det forutsettes at KUNDE X selv utformer eventuelle hjelpetekster.
68	I forhold til responstid tas det forbehold om at underliggende systemer som ikke er inkludert i dette tilbudet kan ha lengre responstider enn det som er spesifisert her. Dersom dette kjører på VMWare-miljø kan ytelsen variere med belastningen på andre servere i miljøet, og dette dekkes ikke av tilbudt løsning.
74	Forutsetter at lingvistikk er riktig.
75	Kun de ting som medfølger Autonomy er inkludert
76	Kun 4 predefinerte søk er inkludert
78	Rapporter over søk er avhengig av logge-nivå på miljøet og vil avklares under prosjektløpet
88, 89	Dette forutsetter at det valgte dokument-håndterings-systemet tillater dette.
90	Avhengig av sikkerhetstilganger kan enkelte ting ikke være søkbare.
93	Arbeidsflytløsning er ikke inkludert i tilbudet
94	I tilbudet er det inkludert å lage 6 publiseringsmaler for innhold
105	Dette krever litt HTML kompetanse
107	Dette forutsetter at LiveLink ECM tilbyr et tjeneste¬grense-snitt som støtter dette
112	Saksbehandlings¬løsning er ikke inkludert i tilbudt løsning, og det forutsettes at det finnes vel-dokumenterte grensesnitt for kobling av metadata mot LiveLink ECM
119, 120	Dette er tenkt løst med å benytte seg av LiveLink ECM, dette forutsetter at det er tilgjengelig vel-dokumenterte tjenestegrense-snitt for dette.
136	Det forutsettes at det eksisterer gode og vel-dokumenterte tjeneste¬grense- snitt mot de under¬liggende systemene som kan tilby den nødvendige informasjonen.
140	Dette gjelder kun godkjennings-flyten som er inkludert i publiserings- løsningen.
142	Dette krever at data fra Visma Business gjøres tilgjengelig på et format som kan bearbeides av det valgte rapporterings-verktøyet. I dette tilbudet er det kun inkludert å lage 2 rapporter, men de resterende vil kunne gjøres på timesbasis basert på en videre løsningsbeskrivelse sammen med kunden.
143	Dette forutsetter at det finnes åpne og vel-dokumenterte grensesnitt for integrasjon.
147	Det taes forbehold mhp. kompleksitet og omfang i forhold til integrasjon mot

	KUNDE Xs reiseregningsmodul siden den ikke er kjent av oss.
149	Inkludert i tilbudet er kun akitivitetskalender, nyheter, prosjekter, dokumenter og hvem er hvem.
151	Det tas forbehold om at noe funksjonalitet ikke er ønskelig at skal legges ut av sikkerhetsgrunner.
153	Det forutsettes her at dette er snakk om grupper i Active Directory.
154, 155	Det forutsettes at brukerne vedlikeholdes i AD og med de verktøy som er tilgjengelig der.
182	Det tas forbehold om at underliggende systemer som ikke er inkludert i dette tilbudet kan ha lengre responstider enn det som er spesifisert her. Dersom dette kjører på VMWare-miljø kan ytelsen variere med belastningen på andre servere i miljøet, og dette dekkes ikke av tilbudt løsning.
188	Det tas forbehold om lenker som legges manuelt inn av forfattere og lenker til eksterne nettsteder.
190	Dette kravet motstrider kravet om at eksisterende historikk og gamle url’er i Google skal videreføres. Noen gamle artikler vil kunne nås både med ny og gammel url.
197	Dette kravet motstrider kravet om at eksisterende historikk og gamle url’er i Google skal videreføres.
204	Et SSL sertifikat er ikke inkludert i tilbudet, og er noe kunden selv må skaffe.
215	Arbeidsflyt er ikke inkludert i tilbudet.

A 5 Usikkerhetsmatrise

Usikkerhetsmatrisen defineres ut fra følgende elementer:

Elem ent nr.	Beskrivelse av usikkerhetselement	Kundens vurdering		Leverandørens vurdering		Tiltak	Ansv- arlig
Elem ent nr.	Beskrivelse av usikkerhetselement	Sannsy- nlighet	Konse- kvens	Sannsy- nlighet	Konse- kvens	Tiltak	Ansv- arlig
1	Presisjonsnivået for målsettinger, behov og krav	1	5	2	4	Tett samarbeid mellom Kunde og Leverandør både i løsnings- beskrivelses- fasen og sprint- forberedelsene (se vedlegg C om prosjekt- gjennomføring ) i konstruksjoKu nde Xasen.	Begge
2	Partenes kjennskap til hverandres virksomhet	2	3	2	3	Som over	Begge
3	Forutsigbarhet og avgrensning av kontraktsleveransen	2	4	3	4	Grundig gjennomgang av krav,mål og forventninger i Løsnings- beskrivelses- fasen	Begge
4	Oppdragets kompleksitet både teknologisk og integrasjonsmessig	3	5	3	5	Allerede i Løsnings- beskrivelses- fasen lages en vertikal prototype som vil avdekke evt. kompleksitet. Dette gjør at man tidlig i sprintene kan fokusere på de ”vanskelige” oppgavene som det er kritisk å få løst.	Begge, men i hoved- sak leveran døren
5	Partenes fleksibilitet	2	4	2	4	Begge parter sørger for at	Begge

Elem ent nr.	Beskrivelse av usikkerhetselement	Kundens vurdering		Leverandørens vurdering		Tiltak	Ansv- arlig
Elem ent nr.	Beskrivelse av usikkerhetselement	Sannsy- nlighet	Konse- kvens	Sannsy- nlighet	Konse- kvens	Tiltak	Ansv- arlig
						nødvendig beslutnings- myndighet finnes i prosjektet.
6	Leverandørens kompetanse innenfor KUNDE X’s organisasjon og fagområder	3	4	3	3	Leverandøren stiller med noen erfarne ressurser som er vant til raskt å sette seg inn i Kundens behov.	Levera ndøren
7	Kundens kompetanse og medvirkning	3	4	3	4	Kunden stiller personer med den rette kompetansen til disposisjon for prosjektet i tilstrekkelig omfang.	Kunden
8	Avhengighet til nytt Medlemssystem som er under implementering	2	4	3	5	Kunde sørger for at den nødvendige informasjon om medlems- systemet blir tilgjengelig for Leverandøren samt at det finnes et testmiljø for integrasjonen mot medlems- systemet. Leverandøren passer på å kommunisere sitt informasjons- behov i forhold til medlems- systemet.	Begge
9	Kundens manglende erfaring i Leverandørens utviklingsmetodikk.			4	3	Opplæring, forberedelser	Kunden
10	Kundens nøkkeldeltakere i prosjektet må prioritere daglig drift hos Kunden			3	3	Midlertidig flytting av personalansvar	Kunden

Elem ent nr.	Beskrivelse av usikkerhetselement	Kundens vurdering		Leverandørens vurdering		Tiltak	Ansv- arlig
Elem ent nr.	Beskrivelse av usikkerhetselement	Sannsy- nlighet	Konse- kvens	Sannsy- nlighet	Konse- kvens	Tiltak	Ansv- arlig
	foran prosjektet					, søke erstatningspers onell for daglig drift
11	Kundens nøkkeldeltakere i prosjektet har ikke, eller anvender ikke tilstrekkelig beslutningsmyndighet i forhold til å gi raske nok avklaringer			4	3	Formalisere beslutnings- myndighet, tydeliggjøre den internt	Xxxxxx
12	Manglende oversikt over integrasjonsbehov i løsningen kan medføre merarbeid i analyse og omfang			3	3	Grundig gjennomgang i Løsnings- beskrivelses- fasen	Begge

Bilag B: Administrative bestemmelser

INNHOLDSFORTEGNELSE

B 1 INNLEDNING 28

B 2 ORGANISERING OG ARBEIDSFORM 29

B 2.1 Organisering av Leveransen 29

B 2.2 Leverandørens bemanning 29

B 2.3 Kundens medvirkning 31

B 3 OPPFØLGING, RAPPORTERING OG MØTER 34

B 4 UAVHENGIG EKSPERT FOR KONFLIKTLØSNING 36

B 1 Innledning

Dette Kontraktsbilag inneholder beskrivelse av hvordan arbeidet med Leveransen organiseres inkludert en rollebeskrivelse, nøkkelpersoner og øvrig personale. Deretter er de administrative bestemmelser knyttet til oppfølging, rapportering og samarbeid mellom partene detaljert. Videre er prosedyrene for eventuelle kontraktskonflikter mellom partene angitt sammen med navn på uavhengig ekspert.

B 2 Organisering og arbeidsform

B 2.1 Organisering av Leveransen

Koordineringsgruppen skal bestå av partenes prosjektansvarlige. <Partenes prosjektansvarlige kan være partenes representanter navngitt i Kontraktsdokumentet, eventuelt være underlagt disse.> Koordineringsgruppen skal ledes av Kundens prosjektansvarlige og Kunden skal i tillegg inneha sekretærfunksjonen for koordineringsgruppen. Partenes prosjektledere har møterett og -plikt i koordineringsgruppen.

Koordineringsgruppen har videre et særlig ansvar for å behandle og følge opp at:

- prosjektorganisasjonen er bemannet med nøkkelpersonale og øvrige kompetent personale i henhold til dette Bilag, slik at arbeidet kan utføres i henhold til milepæler og fremdriftsplan i Bilag C

- resultatet av arbeidet som utføres bidrar til at milepælene i Bilag C nås

- i hvilken grad påløpte kostnader er i henhold til vederlag som beskrevet i Bilag D

- beslutning om implementering av Endringsordre blir tatt og at omtvistede Endringsordre blir behandlet

- nødvendige beslutninger blir foretatt ved behov for avklaringer eller ved avdekkede problemer

- usikkerhetsvurderinger blir foretatt løpende slik at endringer i usikkerhetsbildet kan fanges opp og behandles

Koordineringsgruppen skal således bidra til at Kontrakten etterleves av partene. Hver part utpeker sin ansvarlige prosjektleder med følgende ansvar:

- Leverandørens prosjektleder har det daglige ansvar for at Leveransen planlegges, organiseres og ledes slik at arbeidet blir gjennomført i henhold til kontraktsforpliktelsene. Dette ansvaret inkluderer også den interne kvalitetssikringen hos Leverandøren og eventuelle underleverandører, herunder sørge for at arbeidet utføres i henhold til god forretningsskikk og i henhold til relevante, etablerte bransjestandarder. Leverandørens prosjektleder har ansvar for rapportering til Kundens prosjektleder slik det er beskrevet i dette Bilag.

- Kundens prosjektleder har ansvar for å lede arbeidet med egne forpliktelser, ref. punkt B

2.3 og videre koordinere eget arbeid og leveranser med Leverandørens prosjektleder. Kundens prosjektleder skal videre sørge for oppfølging av og rapportering fra Leverandørens prosjektleder. Kundens prosjektleder rapporterer til koordineringsgruppen og er sekretær for denne.

Partenes prosjektledere skal løpende vurdere potensielle og konstaterte avvik fra kontraktsforpliktelsene, spesielt med hensyn til fremdrift, kostnader og kvalitet i tillegg til endringer i usikkerhetsmatrisen. På denne bakgrunn skal forslag til tiltak fremmes for koordineringsgruppen i forbindelse med den avtalte rapportering.

B 2.2 Leverandørens bemanning

Leverandøren skal utføre Leveransen ved aktiv deltagelse fra følgende utførende personale:

Navn	Rolle	Funksjon	Nøkkel- personale	And el i %	Tidsrom
Navn	Rolle	Funksjon	Nøkkel- personale	And el i %	Fra	Til
	Koordinerings- gruppemedlem	Leverandørens prosjektansvarlige	X	5 %	21.12.07	20.11.08
	Leverandørens prosjektleder	Prosjektledelse	X	80 %	21.12.07	20.11.08
	Leverandørens prosjektgruppe	Systemspesialist	X	30 %	21.12.07	20.11.08
	Leverandørens prosjektgruppe	Systemarkitekt	X	40 %	21.12.07	20.11.08
	Leverandørens prosjektgruppe	Intern kvalitetsansvarlig	X	20 %	21.12.07	20.08.08
	Leverandørens prosjektgruppe	Designer	X	10 %	21.12.07	18.06.08
	Leverandørens prosjektgruppe	Prosessansvarlig/ analytiker	X	20 %	21.12.07	18.06.08
	Leverandørens prosjektgruppe	Konfigurasjons- styringsansvarlig		30 %	21.12.07	18.06.08
	Leverandørens prosjektgruppe	Senior programmerer		10 %	21.12.07	20.11.08
	Leverandørens prosjektgruppe	Junior programmerer		100 %	15.01.08	20.08.08
	Leverandørens prosjektgruppe	Testansvarlig	X	100 %	15.01.08	20.08.08
	Leverandørens prosjektgruppe	Instruktør		100 %	15.01.08	20.11.08
	Leverandørens prosjektgruppe	Dokumentasjons- ansvarlig		100 %	15.01.08	20.11.08
	Leverandørens prosjektgruppe	Opplærings- ansvarlig		30 %	21.12.07	20.08.08
	Leverandørens prosjektgruppe	Konverterings- ansvarlig		10 %	21.12.07	20.08.08

Under tidsrom er det angitt dersom personalet kun benyttes i eventuelt etter Løsningsbeskrivelsesfasen.

Personale som ikke er angitt som nøkkelpersonale kan skiftes ut og supplere etter nærmere avtale mellom partene. Nøkkelpersonalets kompetanse er beskrevet nedenfor, med referanse til relevant tidligere erfaring <eventuelt referanse til vedlagte CVer>:

Navn	Utdanning	<Faglig erfaring>	<Erfaring fra relevante, tilsvarende oppdrag>
	Cand. Scient	Fremgår av CV	Fremgår av CV
	Master of Science, IT	””	””
	Sivilingeniør	””	””
	Prosjektledelse, BI	””	””
	Xx.xxx., databehandling	””	””
	Grafisk Designer	””	””

Det må eksplisitt fremgå om noe av personalet ovenfor representerer underleverandører og således ikke er fast ansatt hos Leverandøren.

B 2.3 Kundens medvirkning

Kunden skal medvirke til arbeidet gjennom deltagelse med eget personale; som skal ha tilstrekkelig kompetanse om egen virksomhet, behov og krav, slik at Leveransen kan gjennomføres i henhold til Kontrakten. Navngitt personale er angitt nedenfor.

Navn	Rolle	Funksjon	Tilgjen- gelighet	Tidsrom
Navn	Rolle	Funksjon	Tilgjen- gelighet	Fra	Til
	Koordineringsgruppe- leder	Xxxxxxx prosjektansvarlige
	Koordineringsgruppe- medlem	Xxxxxxx øvrige ansvarlige personale
	Kundens prosjektleder	Bl.a. sekretær for koordineringsgruppen	100 %
	Kundens prosjektgruppe	Referansegruppe e.l.
	Arbeidsgruppemedlem	Xxxxxxxxxxxxxxxxxx

Dersom tidsrom ikke er angitt, skal dette fremgå av fremdriftsplan i Bilag C.

Følgende oppgaver skal i henhold til de Generelle kontraktsbestemmelser utføres av Xxxxxx:

- Sørge for at forutsetningene for kontraktsinngåelse er oppfylt

- Delta i arbeidsgrupper for å gjennomgå og utdype spesifikasjonene

- Bidra med prioriteringer og løpende funksjonelle avklaringer

- Evaluering og gjennomgang under utvikling

- Sørge for rettidig ferdigstillelse av eventuelle egne leveranser

- Testing og utprøving av utviklede deler av Leveransen

- Informasjonsutveksling mot egen organisasjon og eksternt

- Fremskaffe testdata og testbeskrivelser (inkludert brukerscenarier) i henhold til de forutsetninger og frister som er satt i Bilag A og Bilag C

Tabellen nedenfor oppsummerer Kundens medvirkning i prosjektet. Den dekker ikke Kundens forpliktelser og oppgaver i godkjenningsfasen og Kundens prosjektorganisasjon er ikke tatt med.

Rolle	Antall personer	Krav til kompetanse	Ansvarsområder
Produkteier	1	Samme som for faggruppen, men ikke nødvendig med detaljkunnskap om alle fagområder.	Hovedansvarlig for produktkøen. Sørge for at brukerhistorier blir utarbeidet, prioritert og estimert. Overordnet ansvar for ansvarsområdene til faggruppen
Faggruppe	2 – 3+	Gode kunnskaper om NSFs behov i ny portal. Meget god fagkunnskap om de områdene portalen skal dekke. Erfaren PC-bruker. Fordel med erfaring fra testing. Kjennskap til rapporteringsbehov	Bidra til felles forståelse av målene for prosjektet og funksjonaliteten Prioritering av mål Hovedbidragsytere i utarbeidelse av brukerhistorier til produktkøen. Prioritering av elementene i produktkøen Ansvar for å formidle hva kravene fra NSF betyr for utformingen av portalen, slik at portalen kan forenkle arbeidsdagen for brukerene av portalen. Definere rapporter som skal inn i rapporteringsdelen av portalen Skrive testmanuskripter. Teste utviklede moduler Bidra i systemtest
IKT-ansvarlig	1	God kjennskap til NSFs IKT-løsning	Oppsett og drift av følgende miljø: utvikling, test, godkjenning og drift. Bistå med tekniske avklaringer
Integrasjonsansvarlig	1	Kjennskap til systemene portalløsningen skal integerere mot	Etablere en fullstendig oversikt over integrasjonsbehov i den nye løsningen Koordinere kommunikasjon mellom leverandør og eksterne aktører i arbeidet med utvikling og testing av integrasjonstjenester
Testansvarlig	1		Delansvar for utarbeidelse av testplan Bidra til at det blir skrevet

Rolle

Antall personer

Krav til kompetanse

Ansvarsområder

testmanuskripter

Bidra i systemtest

Opplæring

Kjennskap til funksjonalitet i portalen

Erfaring med opplæring

Ansvar for utarbeidelse og gjennomføring av evt kurs for brukere

Produkteier, faggruppemedlemmene og testansvarlig må påregne opptil fulltids allokering på prosjektet, men dette kan variere avhengig av de forskjellige medlemmenes fagområder. IKT- ansvarlig og integrasjonsansvarlig må påregne fulltidsallokering tidlig i prosjektet, men under utviklingen vil ressursbehovet variere avhengig av i hvilke sprinter man velger å gjennomføre integrasjonsarbeidet. Det er en fordel om det er en overlapp mellom faggruppemedlemmene og de som skal drive med opplæring, men spesielt tiltenkte opplæringsressursene trenger ikke å komme inn i prosjektet før f.eks systemtest.

B 3 Ekstern kvalitetssikring

Som ekstern kvalitetssikrer for å ivareta ansvaret for overordnet kvalitetssikring, slik det er beskrevet i de Generelle kontraktsbestemmelser, er utnevnt:

Navn	Rolle	Funksjon	Tilgjen- gelighet	Tidsrom
				Fra	Til
	Observatør i koordineringsgruppen	Ekstern kvalitetssikrer

B 4 Oppfølging, rapportering og møter

Fremdriftsoppfølging skal foretas i forhold til to ulike referanserammer; milepæler (Hovedmilepæler, Kontrollpunkter og øvrige Milepæler) og planlagt fremdrift i form av periodiserte fremdriftsplaner, slik planene er fastlagt i Bilag C. Milepæler blir enten nådd eller ikke nådd, mens reell fremdrift beregnes og sammenholdes med planlagt fremdrift og timeforbruk.

Timeforbruk skal registreres for alt personale til en aktivitet på laveste nivå i fremdriftsplanen og overleveres til Kunden for godkjenning i løpet av første arbeidsdag i påfølgende uke. Kun godkjent timeforbruk skal kunne faktureres av Leverandøren.

I tillegg til timeforbruk skal det for hver aktivitet på laveste nivå i fremdriftsplanen angis et estimat for gjenstående tid på aktiviteten<, alternativt kan prosent fremdrift anslås (fortrinnsvis etter en forhåndsdefinert nøkkel)>.

Påløpte kostnader skal ajourholdes og inkludere kostnad for timer som er påløpt og godkjent.

Alle avdekkede problemer eller behov for avklaringer skal registreres, dokumenteres og følges opp av Leverandøren, slik at denne til enhver tid kan rapportere status for alle slike saker.

Statusrapporter som utarbeides av Leverandøren skal ha følgende innhold:

1. Kort sammendrag med beskrivelse av eventuelle avvik

2. Fremdrift (S-kurve med planlagt og reell fremdrift i tillegg til timeforbruk, i tillegg inkluderes en budsjettkurve og tilhørende prognose basert på timeforbruk pluss estimat for gjenstående tid)

3. Påløpte kostnader

4. Ressursbruk (organisering og bemanningsstatus)

5. Milepæler nådd i siste periode (alle aktuelle Milepæler for inneværende og kommende periode vises med status nådd / ikke nådd kombinert med på plan / forsinket <, evt. basert på trafikklyskoding>)

6. Endringsstatus (Endringsordre og Endringsanmodninger til godkjenning henholdsvis til behandling, ref. Bilag C)

7. Status og forslag til tiltak for risikoreduksjon for definerte og eventuelle nye usikkerhets- elementer (med grafisk fremstilling av endring i sannsynlighet og konsekvens)

8. Oversikt over nødvendige avklaringer og problemer, inkludert forslag til beslutninger fra koordineringsgruppen, der beslutning ikke er tatt

Slik rapportering skal foretas <ukentlig/månedlig>. Koordineringsgruppen skal møtes for å behandle alle fremlagte statusrapporter.

B 5 Uavhengig ekspert for konfliktløsning

Dersom konfliktløsning ved hjelp av uavhengig ekspert, slik det er definert i de Generelle kontraktsbestemmelser, blir nødvendig, er partene enige om å benytte følgende person eventuelt selskap:

Navn	Adresse	E-post adresse	Telefon

Den utpekte ekspert skal varsles av partene uten ugrunnet opphold etter at en av partene har gitt skriftlig varsel til den annen part om krav om foreleggelse av en tvist for eksperten.

Eksperten får, etter å ha mottatt skriftlig innlegg fra partene, inntil < > kalenderdager på å avgi sitt forslag til løsning for partene. Dersom det ikke skal gjennomføres megling, har partene ytterligere < > kalenderdagers frist for å bringe tvisten inn for alminnelige domstoler eller voldgiftsbehandling, ref. Generelle kontraktsbestemmelser.

Dersom det skal gjennomføres megling, skal eksperten legge en plan slik at meglingen kan være gjennomført etter < > kalenderdager.

Bilag C: Gjennomføring

INNHOLDSFORTEGNELSE

C 1 INNLEDNING 39

C 2 METODER, VERKTØY OG STANDARDER 40

C 2.1 Krav til gjennomføring 40

C 2.2 Krav til metode 40

C 2.3 Krav til verktøy 50

C 2.4 Krav til standarder 51

C 3 UTVIKLINGSMILJØ 53

C 3.1 Beskrivelse av utviklingsmiljøet 53

C 3.2 Drift av utviklingsmiljø i Kundens lokaler 54

C 4 GJENNOMFØRINGSMODELL 56

C 4.1 Resultatet av behovsfasen 56

C 4.2 Løsningsbeskrivelsesfasen 56

C 4.3 Konstruksjonsfase 59

C 4.3.1 Detaljplanlegging / Analyse og design 60

C 4.3.2 Utvikling 61

C 4.3.3 Testing 61

C 4.3.4 Samlet integrasjons- og systemtest 64

C 4.3.5 Intern kvalitetssikring 64

C 4.3.6 Kontrollpunkt 65

C 4.3.7 Delvis overtagelse 65

C 4.3.8 Xxxxxx ytelser. 65

C 4.4 Godkjennings- og avslutningsfase 66

C 5 FREMDRIFTSPLAN 68

C 6 ENDRINGSHÅNDTERING 71

C 1 Innledning

Dette Kontraktsbilag inneholder en beskrivelse av gjennomføringsmodell og fremdriftsplan for Leveransen. Innledningsvis er det inkludert en nærmere beskrivelse av Leveransens metoder, verktøy og standarder og bruk av maskin- og programvare, dokumentert i form av et utviklingsmiljø. Videre er testgjennomføring og godkjenningskriterier dokumentert.

KPn

Detaljplanlegging / Analyse og design

KP2

KP1

Iterativ konstruksjonsfase

Løsningsbes- krivelsesfase

Testing

Utvikling

Progresjon

Gjennomføringsmodellen inkluderer fire faser med tilhørende Hovedmilepæler (HMP), hvorav én av fasene er forutsatt utført før kontraktsinngåelse. Leveransen består av Komponenter som utvikles trinnvis gjennom iterative prosesser med evaluering i form av Kontrollpunkter. Gjennomføringsmodellen er skissert nedenfor:

Behovsfase

Godkjennings- og avslutningsfase

HMP 0

Kontraktsinngåelse

HMP 1

Godkjent løsnings- beskrivelse

HMP 2

Leveranse klar til godkjenning

HMP 3

Godkjent leveranse

Hver runde i den iterative konstruksjonen er i det etterfølgende kalt et trinn. Det vil si at hvert trinn resulterer i et Kontrollpunkt.

Gjennomføringsmodellen utgjør et rammeverk i form av et overbygg til verktøy og metode for systemutvikling/brukertilpasning, slik det er beskrevet i det etterfølgende.

C 2 Metoder, verktøy og standarder

C 2.1 Krav til gjennomføring

Leveransen skal utvikles ved hjelp av en trinnvis prosess, i henhold til Generelle kontraktsbestemmelsers gjennomføringsmodell og spesifikt i henhold til de krav som er beskrevet i etterfølgende punkter.

C 2.2 Krav til metode

Følgende metoder skal benyttes for å realisere Leveransen under gjennomføringsmodellen beskrevet i punkt C 4:

C 2.2.1 Leverandør X sin systemutviklingsmetodikk overordnet

Leverandør X har lang erfaring med iterativ systemutviklingsmetodikk. Med utgangspunkt i iterative metoder som DSDM (Dynamic System Development Method), prosjektledelses- standard som Project Management Institute’s PMBOK1 og innslag fra kontraktstandarden PS2000 har Leverandør X gjennomført en rekke prosjekter av ulik størrelse og kompleksitet. Systemutviklingsmetodikken er nå revidert og justert til Scrum, som er den mest kjente og ”de-facto” standard agile metodikk innen programutvikling i dag. Standardisering av metode har vi gjort for å ytterligere styrke den iterative utviklingen i prosjektet og forenkle kommunikasjon rundt metodikk.

Leverandør X gjennomfører prosjekter og leverer løsninger som er ulike hva angår omfang og kompleksitet. Det vil derfor være et behov for å skalere metodikken avhengig av hva som er hensiktsmessig for hvert enkelt prosjekt.

Leverandør X’ prosjektmetodikk med Scrum har vært gjennomført i flere av våre prosjekter av variende størrelse, f.eks. MATS (Mattilsynets Tilsyns System), eResept-prosjektet for Legemiddelverket og prosjektet som utvikler vår interne portal, Mimesis.

På samme måte som Gjennomføringsmodellen til PS2000 tar Leverandør X’ gjennomførings- metodikk utgangspunkt i de fire fasene (Behovsfase, Løsningsbeskrivelsesfase, Iterativ Konstruksjonsfase og Godkjennings- og avslutningsfase) og milepælene mellom fasene (HMP0, HMP1, HMP2 og HMP3). Vår metodikk passer dermed svært godt sammen med prosjekter som bruker PS2000-standarden. Vi gjør imidlertid oppmerksom på at der PS2000 bruker begrepet godkjenningsprøve, bruker vi begrepet akseptansetest.

Milepæler med aktiviteter knyttet til disse er presentert under. Selve systemutviklings- metodikken Scrum slik den er implementert i Leverandør X er presentert i kapittel C 2.2.2. Metodikken anvendt i de ulike fasene er beskrevet ytterligere i hhv Error! Reference source not found. Løsnings-beskrivelsesfasen, og i Error! Reference source not found.

Konstruksjonsfasen. Kapittelet om konstruksjonsfasen innbefatter også metodikk for analyse og design, samt detaljering av utviklingfasen. Testmetodikk er kort beskrevet i kapittel Error! Reference source not found., og Leverandør X kvalitetssikringsrutiner for prosjektgjennomføring er oppsummert i C 4.2.3 Intern kvalitetssikring

I tabellen under beskrives de viktigste oppgaver innenfor hver av de 4 fasene i gjennomføringsmodellen til PS2000:

1 xxx.xxx.xxx

	Milepæler i prosjektet	Beskrivelse av milepæl
HMP0	Kontraktsinngåelse	Behovsfasen består i legitimering og forankring av prosjektet samt utarbeidelse av en prosjektplan. Ved kontraktsinngåelse, HMP0, finnes en overordnet prosjektplan som bl.a kan inneholde: • Omfangsbeskrivelse • Milepælsplan • Kostnadsbeskrivelse • Overordnet løsningsbeskrivelse av totalleveransen • Ansvarsdeling og faggrupper • Identifisering av interessenter • Dokumenterte forutsetninger og begrensninger • Plan for kvalitetskontroll • Overordnet planlegging av testarbeid • Overordnet planlegging av risikohåndtering.
HMP1	Godkjent løsningsbeskrivelse	I løsningsbeskrivelsesfasen kan totalleveransen evt brytes ned i delleveranser. Hver (del-)leveranse brytes ned i elementer. Det lages en utviklingsplan for hvilke elementer som skal inngå i leveransen (evt delleveransene). Test planlegges og gjennomføring av akseptansetest spesifiseres. Etablere produktkø. Plan for riskohåndtering utarbeides. Ved HMP1 finnes en oppdatert prosjektplan som bl.a. inneholder en prioritert liste over alle elementene som vil kunne inngå leveransen. Elementene er da beskrevet overordnet og xxxxx estimert.
HMP2	Leveranse klar for godkjenning	Det gjennomføres en konstruksjonsfase for prioriterte oppgaver. Denne fasen inkluderer bl.a. utvikling og test av oppgaver og kundeinspeksjon av utviklet funksjonalitet. Ved HMP2 er løsningen ferdig utviklet, enhetstester og integrasjonstester er gjennomført og systemtesten, en samlet test av utviklet funksjonalitet, er utført. Plan for godkjenningsarbeidet er etablert. Denne inneholder bl.a: • Kundens testmanuskripter • Godkjenningskriterier • Plan for lukking av kjente xxxxx Xxxxxx overtar nå fremdriftsansvaret.
HMP3	Godkjent leveranse	I Godkjennings- og avsluttningsfasen gjennomfører Kunden akseptansetest av leveransen, slik at leveransen kan godkjennes av Kunden. Før avslutning av leveransen gjennomføres en

prosjektevaluering hvor Kunde og Leverandør foretar analyser av prosjektgjennomføringen og leveransen. Det utarbeides et oppsummeringsdokument som gjenspeiler de endelige spesifikasjonene, og som inneholder suksess, effektivitet, erfaringer og gevinstrealisering.

C 2.2.2 Metodeverk for systemutvikling

Leverandøren vil gjennomføre systemutvikling generelt basert på et metodeverk allment kjent under betegnelsen Scrum.2 Dette er en metode som hører med blant de agile systemutviklingsmetoder, og understøtter den iterative tankegangen i PS2000 kontraktsstandarden. Leverandøren mener Xxxxx som rammeverk bidrar med smidighet i utviklingsprosjekter ved at den er tilrettelagt for:

• Tidlig og mye involvering av sluttbruker, drift og forvaltning.

• Læring underveis, både på kundesiden og leverandørsiden.

• Å tilfredsstille endringsbehov og ta inn gode ideer underveis.

• Å kontinuerlig fokusere på det som er viktigst, herunder identifisere og angripe risiko tidlig.

• Å få tidlige tilbakemeldinger og avdekke misforståelser og feil tidlig ved hjelp av korte iterasjoner og hyppig testing.

Scrum er et enkelt “inspiser og tilpass” rammeverk som har tre roller, tre seremonier og tre artefakter utviklet for å levere fungerende programvare i sprinter, vanligvis 30-dagers iterasjoner.

• Roller: Produkteier (Product Owner), Scrum-leder (Scrum Master), Scrum-team.

• Seremonier: Sprintplanlegging (Sprint Planning), Sprintgjennomgang (Sprint Review) og daglig Scrum-møte (Daily Scrum)

• Artefakter: Produktkø (Product Backlog), Sprintkø (Sprint Backlog), og Brenndiagram (Burndown Chart)

2 Fra Wikipedia: Scrum is an agile method for project management, first implemented by a team led by Xxxx Xxxxxxxxxx at Easel Corporation in 1993. It has been called a "hyper-productivity tool", and has been documented to dramatically improve productivity in teams previously paralysed by heavier methodologies.

Da g lig Sc ru m

P r io rite rin g Om fa n g

Tid

Sp r in tk ø

Sp r in t

D e m ons tra s jo n V e r ifika sjo n

Va lg t

P ro duk tk ø

K rav sp es ifik as jo n Lø s n in g s -

be s k r iv e ls e

P rod uk te r

P r io rite rin g Om fa n g

V ISJ O N

- a n ta tt fo r t je n e s te

- ov e rordne de p la n e r

- ho v e dm ile pæ le r

Figuren viser en oversikt over tankegangen rundt Scrum, fra prosjektet initieres basert på en visjon, og til løsningen realiseres iterativt via delprodukter. Leveringsomfanget er initielt dokumentert gjennom en kravspesifikasjon som detaljeres videre i en Løsningsbeskrivelse. Løsningsbeskrivelsen er input til den iterative prosessen der Kunden er tett involvert i prioriteringer av arbeidet, samt hyppig verifikasjon og vurdering av delresultater etter hvert som de produseres.

Under gis en nærmere redgjørelse av rollene og seremoniene i Scrum.

C 2.2.2.1 Produkteier

Produkteier er en person. Denne personen representerer alle interessentene i prosjektet og er ansvarlig for at prosjektet leverer merverdi til interessentene. Produkteieren er vanligvis en ansatt hos Kunden og er en som har ansvar for prosjektet etter utviklingsprosjektet.

Prosjekteierens rolle er å oppnå en grunding forståelse for og prioritere funksjonelle og ikke- funksjonelle krav i prosjektet. Produkteier er ansvarlig for å forsikre at den funksjonaliteten som blir prioritert, utviklet og implementert møter behovene til Kunden. En produkteier samarbeider med en faggruppe som utarbeider detaljene og forbereder grunnlaget som produkteieren tar sine beslutninger på grunnlag av.

Faggruppen etableres i starten av prosjektet. Gruppen består av fagpersoner med nøkkelkompetanse innenfor de områdene som systemet skal virke i.. Hensikten med faggruppen er å identifisere fagspesifikke krav og behov gjennom de ulike organisasjons- enhetene. Faggruppen setter opp krav til systemet og verifiserer at systemet er laget i henhold til kravene. Denne form for brukermedvirkning er krevende for kundens personell, men Leverandør X’ erfaring er at fokus på kunnskap i systemutviklingen og representasjon av kunnskap i systemene, gir langt mer slagkraftige og brukervennlige systemer.

I tillegg til å samarbeide om løpende faglige avklaringer, vil Xxxxxx også bli invovert i den faglige delen av testing – både ved testing i sprintene, systemtest og godkjenning.

En faggruppe skal ha beslutningsmyndighet.

C 2.2.2.2 Scrum-leder

En Scrum-leder har mange av de samme funksjonene som prosjektlederen. Rollen kan godt fylles av prosjektlederen, men den kan også besittes av en teknisk team-leder. En Scrum- leder har ansvar for at Scrum-teamet har fokus på de oppgavene de har påtatt seg ansvar for, og sørger for at prinsippene i metodikken blir etterlevd i prosjektet. Dersom det oppstår ting som hindrer team-medlemmene fra å få fullført oppgavene sine er det Scrum-lederens oppgave å fjerne disse hindringene. Scrum-lederen skal, sammen med Scrum-teamet, søke å forbedre utviklingmetodikken og verktøyene som benyttes med mål om å oppnå mer funksjonalitet for Kunden.

Scrum-lederen leder det daglige Scrum-møte (se C 2.2.2.6)

C 2.2.2.3 Scrum-team

Et Scrum-team består av ca. 5 – 9 personer som tilsammen besitter den kompetansen som er nødvendig for å forvandle oppgavene i produktkøen (se C 2.2.2.4) til funksjonalitet i sluttproduktet. Det er Scrum-teamet som er ansvarlig overfor Produkteieren for at de oppgavene som er valgt ut i en sprint (se C 2.2.2.5) blir gjennomført.

Scrum-teamet er selv-organiserende, men veiledes av Scrum-lederen.

C 2.2.2.4 Etablering av produktkø

Scrum er generelt kjennetegnet ved korte iterasjoner der deler av funksjonaliteten blir valgt fra en prioritert liste, utviklet og evaluert, - med læring underveis. I Leverandørens utviklingsprosjekter arbeider Kunden tett sammen med Leverandørens team, spesielt gjelder dette samarbeidet med den som hos Leverandøren innehar rollen Funksjonelt Ansvarlig og Kundens produkteier, for å utdype og prioritere systemfunksjonalitet i form av en ”Produktkø”. Produktkøen definerer Kundens behov som en prioritert liste basert på hva Xxxxxx mener er viktigst å ta tak i først.

Oppgavene i produktkøen kan være brukerhistorier eller tekniske oppgaver. En brukerhistorie er knyttet til funksjonelle krav og forfattes gjerne på følgende måte:

Som en <type bruker eller rolle>,

ønsker jeg å <utføre en eller annen oppgave>, for å oppnå <et mål>.

Identifisering av, og det å forfatte brukerhistorier til produktkøen tar initielt utgangspunkt i kravspesifikasjonen. Tekniske oppgaver blir initiert og forfattet både av Xxxxxx og Leverandøren. Brukerhistorier og tekniske oppgaver prioriteres på lik linje.

Prosessen med å etablere produktkøen bør forøvrig ses i sammenheng med overordnet leveranseplanlegging. Leveranseplanen bør starte med å planlegge inn de viktigste kritiske funksjonene som systemet skal inneholde sammen med etablering av underliggende arkitektur. Det er fornuftig å planlegge for en tidlig lansering av et minimum sett av funksjoner slik at systemet ”kan brukes til noe”. Tidlig lansering og bruk av systemet vil gi uvurderlig tilbakemelding som kan brukes videre i arbeidet med kommende deler.

For å muliggjøre tidlig bruk av systemet bør man legge opp til at man utvikler en tynn vertikal del av systemet, slik at alle lagene i løsningen utvikles, men bare for et begrenset sett sluttfunksjonalitet. Når en slik vertikal del er utviklet bør man organisere produktkøen slik at man oppnår følgende:

1) Oppgaver med høy forretningsverdi før de med lav forretningsverdi

2) Oppgaver med høy risiko og høy verdi før de med lavere risiko

3) Oppgaver som skaper signifikant ny kunnskap før elementer som allerede er godt kjent

4) Oppgaver med lav utviklings- eller etableringskostnad framfor de med høyere kostnad

Når de viktigste oppgavene i produktkøen er beskrevet, prioritert og estimert kan sprintplanleggingen av første sprint starte. Sprintplanlegging er i korte trekk å plukke tilstrekkelig mengde oppgaver fra produktkøen som skal utvikles i kommende sprint.

C 2.2.2.5 Sprintplanlegging

Med utgangspunkt i den definerte produktkøen gjennomføres sprintplanlegging. Tverrfaglige team med deltakelse både fra Kunde og Leverandør vurderer og plukker oppgaver fra produktkøen som skal inngå i neste sprint for Scrum-teamet. Disse settes opp i en prioritert liste, kalt sprintkø. Sprintkøen representerer da det realistiske omfang som teamet skal levere i løpet av en sprint, en fast, kortere tidsperiode (timebox). Hvis det er flere Scrum-team vil summen av omfanget teamene skal levere i sprinten gi hva prosjektet planlegger å levere i sprinten. Tidsperioden besluttes av prosjektet, og kan variere over prosjektets levetid, men varigheten på en kommende, planlagt sprint skal ikke endres. Erfaringsmessig er en sprint hensiktsmessig å gjennomføre på 3 eller 4 uker.

Sprintplanleggingen tar utgangspunkt i de høyest prioriterte oppgavene i produktkøen, splitter om nødvendig opp i flere deloppgaver, og gjør en nærmere vurdering av arbeidsmengde og antatt tidsforbruk knyttet til realisering av hvert element. I tillegg til selve utviklingen av enhetene, skal forberedelser og gjennomføring av testarbeid og andre kvalitetssikringsaktiviteter inngå som en del av de aktiviteter som utgjør arbeidsomfanget.

Basert på sprintens definerte faste varighet, prioritet og antatt arbeidsmengde for hvert element, samt utviklingsteamenes ressurssituasjon, defineres et utvalg oppgaver som skal inngå i sprintkøen for realisering i neste sprint. Kunden og Leverandøren må sammen vurdere underlaget og utarbeide en omforent enighet rundt innholdet i sprintkøen. Kunden bidrar med vurderinger av omfang og prioritet, mens Leverandøren gjør betraktninger basert på utredet arbeidsmengde og tilgjengelige ressurser.

Ressurstilgangen vurderes også i forhold til teamdeltakernes antatte mulighet til å fokusere på arbeidet i sprinten (fokusfaktor). Teamdeltagerene må også sette av tid til å delta i

spesifiseringsarbeidet av nye produktkø-oppgaver, og det kan f.eks også være behov knyttet til vedlikeholdsforpliktelser mot produksjonssatte moduler.

Hyppige sprinter og planlegging knyttet til sammensetning av team før hver sprint gir mulighet for rotasjon også når det gjelder de ressurser fra Kunden som skal ta aktiv del i utviklingen av portalen, ref. kapittel Error! Reference source not found..

Konkret resultat etter sprintplanlegging bør være:

• Et definert mål for sprinten.

• En liste av teamdeltakere, og deres allokering.

• En sprintkø.

• Et fastsatt tidspunkt for scrum demo

• Definert tid og sted for daglige scrummøter (se under).

Det er av avgjørende betydning at representanter fra Kunden, ”Produkteier” (product owner,) kan prioritere deltakelse i sprint-planlegging. I tillegg til at Kunden har en klar rolle i forhold til løpende prioritering av produktkø-oppgavene, er det viktig at Kunden etablerer forståelse for at det kan være aktiviteter som må ligge i realisering av oppgavene i køen i tillegg til selve utviklingsarbeidet. Behov for spesiell tilrettelegging i byggesystemer, tekniske miljøer, konfigurasjonsstyringsverktøy, spesielt omfattende testforberedelser, testgjennomføring osv. kan påvirke arbeidsmengde for aktuelle oppgaver i en sprint. Slike oppgaver kan også trekkes ut som egne tekniske oppgaver. Tekniske avklaringen kan skape grunnlag for å prioritere innholdet i en sprint på en annen måte. Kundens nærvær er også viktig i forhold til å raskt kunne fremskaffe avklaringer på kundefaglige detaljspørsmål.

C 2.2.2.6 Sprintgjennomføring

En sprint gjennomføres av et definert Scrum-team. Denne arbeidsgruppen ledes av en Scrumleder. Metoden understøtter god kommunikasjon og samhandling i teamet ved at det anbefales daglige Scrummøter. Disse møtene bør ha fast agenda og skal avholdes raskt, typisk 15 minutter. Det anbefales at Scrummøtene gjennomføres stående, standup meetings, for å sikre at de blir korte og effektive avklaringsmøter. Scrummøtene vil gjennomføres av prosjektdeltakerne fra Leverandøren, men representanter fra Kunden vil også delta ved behov.

Selv om Scrum vektlegger hyppig interaksjon med Kunden, påpekes også programmerernes behov for arbeidsro under selve utviklingen, og at de i tilstrekkelig grad skjermes i denne fasen.

Sprintens fremdrift visualiseres ved bruk av en sprint-”aktivitetstavle” etablert på prosjektområde som er tilgjengelig for alle. Aktivitetstavlen viser hvilke oppgaver som er valgt for sprinten, hvilken prioritet de har, og hvilket estimat de har, samt hvilke som er påbegynt, hvilke som er til test hos Kunden og hvilke som er ferdige. Aktivitetstavlen for sprinten er utgangspunktet for Scrum-teamets daglige Scrummøter. I tillegg viser man også en grafisk fremstilling av fremdrift i et brenndiagram (Burndown Charts) Hvert team har sin aktivtetstavle og sitt brenndiagram som oppdateres daglig.

Scrum er basert på timeboxing som vil si at sprinten alltid avsluttes og evalueres når den på forhånd fastsatte tidsperiode utløper. Gjenstående eller uferdige oppgaver fra sprintkøen dokumenteres i en restanseliste, og disse elementene vil sammen med resten av produktkøen inngå som grunnlag for planlegging av påfølgende sprinter.

Hvis det viser seg at man blir ferdig med innholdet i sprintkøen før den faste tidsperioden utløper kan Scrum-teamet plukke flere oppgaver fra produktkøen. Dette er i tilfelle en beslutning som bare kan tas av Scrum-teamet.

Metoden åpner for at en sprint kan avbrytes, omdefineres og restartes basert på at det identifiseres uventet høy kompleksitet, avdekkes ny risiko eller oppstår andre forhold som tilsier behov for avbrudd.

Når produktene fra en sprint er levert, blir disse evaluert. Scrum gjøres testdrevet ved at de kvalitetssikringsaktiviteter som produkter fra en sprint skal være gjenstand for defineres, planlegges og beskrives i starten av sprinten. Dette kan omfatte tilrettelegging av testverktøy, skriving av automatiserte tester, spesifisering av manuelle tester, definering av omfanget av kodegransking, kundeinspeksjoner, demonstrasjoner, dokumentgjennomganger osv.

Etter en sprint avholdes et eget møte der teamet gjør et tilbakeblikk for å identifisere forbedringspotensialer til bruk i kommende sprinter.

God framdrift sikres ved at arbeidet med produktkøer gjøres delvis overlappet med gjennomføring av sprinter. Dette vil si at partene begynner å forberede produktkøen for neste sprint i god tid før denne skal starte og at dette glir over i sprintplanlegging, se tegningen under.

Gode forberedelser før sprinten forebygger at Leverandørens prosjektteam forsinkes av at gjennomganger av at brukerhistoriene i produktkøen må ferdigstilles før gjennomføring av neste sprint kan starte.

Arbeidet under sprintforberedelsene og sprintplanleggingen representerer en analyse av de krav og behov som Kunden har. Basert på dette arbeidet og retningslinjer fra Løsningsbeskrivelse, skal Scrum-teamet utarbeide design av de komponenter og funksjoner

som sprinten omfatter. Dette arbeidet må selvsagt baseres på designprinsipper fra tidligere sprinter, og i tillegg fokusere på fleksibilitet, løse koblinger og generelt tilrettelegges for ytterligere forfining og integrasjon mot komponenter man vet kommer i senere sprinter. Man snakker gjerne om agilt design.

Oppsummert omfatter gjennomføringen av en sprint følgende:

- Behovsanalyse basert på Leverandørens deltakelse i Kundens produksjonsplanlegging og overlapp mellom produksjonsplanlegging og sprintplanlegging.

- Testdrevet kvalitetssikring ved tidlig planlegging og tilrettelegging av tester og andre kvalitetsaktiviteter.

- Design basert på prinsipper fra Løsningsbeskrivelse og videre raffinering av designet fra tidligere sprinter

- Utvikling

- Evaluering i form av demonstrasjoner og kundeinspeksjoner

A n a lyse

E v a lue r ing

De s ig n

In te g r .te s t

K o ding

E n h e ts te s t

SPR IN T 1

An a ly s e E v alue r ing

De s ig n A n a lyse

In te g r .te s t

E v alue r ing

K o ding

De s ig n

E n h e ts te s t

In te g r.te s t

SPR IN T 2

Ko d in g E n hets tes t

SPR IN T N

TEST FORBEREDELSE

TEST GJENNOMFØRING

Arbeidesgangen innenfor hver sprint har klare paralleller til en utviklingsmetode kalt V- modellen for test. V-modellen fokuserer på at testplanlegging og testforberedelser gjøres tidlig i prosjektet. I figuren under er denne sammenhengen mellom V-modellen og Scrum illustrert – hver sprint kan ses på som en gjennomkjøring av V-modellen.

TEST FORBEREDELSE

TEST GJENNOMFØRING

Figur 6: Elementer av V-modellen i Scrum

C 2.2.3 Krav til samhandling og kommunikasjon

Sikker og effektiv gjennomføring av prosjektet fordrer god teknisk og menneskelig kommunikasjon mellom Kunden, Leverandøren og de tekniske miljøer disse samhandler rundt. For å sikre at dette behovet dekkes i tilstrekkelig grad, er Kunde og Leverandør enige om de samhandlingstiltak og retningslinjer for kommunikasjon som er beskrevet under, og begge parter er ansvarlig for å påse at dette etterleves i størst mulig utstrekning.

Språk

All kommunikasjon i alle faser av prosjektet skal foregå på norsk.

Kundens medvirkning

Korrekt, god og effektiv implementering av Kundens krav til løsningen vil kreve tett og detaljert samarbeid mellom Kundens og Leverandørens ressurser gjennom store deler av prosjektperioden.

Dette skal oppnås gjennom oppgaver og ansvar som pålegges kunden i kapitell Error! Reference source not found. og gjennom en proaktiv holdning fra Leverandøren i forhold til å dele og oppsøke kunnskap overfor Xxxxxx.

For å få til dette må sentrale ressurser hos Kunden, brukere og fagpersoner, frigjøres fra daglige plikter og tilordnes prosjektet med fast allokering. Disse bør ha personaltilhørighet hos Kundens prosjekt og disponeres av Kundens prosjektleder.

Kunden skal sørge for at de personer som allokeres inn i grupper der beslutninger skal tas, for eksempel arbeidsgrupper, har den nødvendige myndighet til å fronte disse beslutningene innad i Kundens organisasjon.

Scrum som utviklingsmetode medvirker til rask oppnåelse av etterprøvbare delresultater og muligheter til at Kunden og Leverandøren sammen kan evaluere disse opp mot krav og behov. Kunden skal løpende kunne vurdere prioriteringer i produktkøer, delta i sprintplanlegging og være tilgjengelig for detaljavklaringer overfor Scrum-team under gjennomføring. I tillegg må Xxxxxx være forberedt på å bruke tid på realtivt hyppige runder med evaluering og vurdering av resultater.

Kundens representanter vil også spille en aktiv rolle i utarbeidelse av testbeskrivelser underveis og i testing av løsningen.

Det er viktig at Kundens representanter er inneforstått med Scrum som utviklingsmetode og hvordan Scrum anvendes under systemutvikling i prosjektet. Metodikken vil derfor gjennomgås i fellesskap ved oppstart av prosjektet.

Organisering av prosjektet

Prosjektet skal på begge sider organiseres på en slik måte at det finnes en del roller som naturlig skal kommunisere med hverandre hos Kunde og Leverandør. Det er ønskelig med en Prosjektleder hos Xxxxxx og en Funksjonelt Ansvarlig hos Kunden som kommuniserer med tilsvarende roller hos Leverandøren. Det vil også være ønskelig å ha en Testansvarlig rolle på kundesiden, i tillegg til en Testansvarlig hos Leverandøren.

C 2.3 Krav til verktøy

Leveransen skal utvikles ved hjelp av følgende verktøy:

C 2.3.1 Xxx JDK

Det vil benyttes Java JDK fra Sun. Dette inkluderer kompilator, VM og enkelte andre verktøy. Vi vil benytte versjon J2SE 5.0

C 2.3.2 Cygwin

Utviklere som bruker versjoner av Windows som operativsystem, vil bruke Cygwin3 for å ha tilgang til unix-baserte verktøy. Cygwin er et open source-verktøy som er gratis i bruk og lisensieres med GPL4. Lisensen vil ikke ha betydning, da verktøyene bare vil benyttes under utvikling.

C 2.3.3 Maven

Maven5 vil bli brukt til bygging. Maven er et open source-verktøy og er i dag en de facto standard for å bygge Java-prosjekter. Maven er gratis i bruk og lisensieres med Apache Software License6. Lisensen vil ikke ha betydning, da verktøyet bare vil benyttes under utvikling.

C 2.3.4 Junit og relaterte biblioteker

Testrammeverket Junit7 vil bli brukt til enhetstester, integrasjonstester og regresjonstesting. Junit er et open source-verktøy som er gratis i bruk og lisensieres under Common Public Lisence8. Lisensen vil ikke ha betydning, da verktøyet bare vil benyttes under utvikling.

Til testing av GUI vil det bli benyttet verktøyet Watir. Watir er også et open source-verktøy9.

C 2.3.5 Versjonskontrollsystem

Subversion10 vil bli brukt som versjonskontrollsystem. Subversion er et open source-verktøy som er gratis i bruk og lisensieres under Apache/BSD-style open source lisens11. Lisensen vil ikke ha betydning, da verktøyet bare vil benyttes under utvikling.

C 2.3.6 Feilrapporteringssystem

JIRA12 vil bli brukt som feilrapporteringssystem og endringshåndteringssystem. JIRA kan integreres med versjonskontrollsystemet Subversion slik at man i JIRA kan se hvilke versjonerte endringer som retter feilen.

Leverandøren har lisens på JIRA som kan benyttes i dette prosjektet og i et evt. vedlikeholdsprosjekt.

3 xxxx://xxx.xxxxxx.xxx/

4 xxxx://xxxxxx.xxx/XXXXXXX

5 xxxx://xxxxx.xxxxxx.xxx/)

6 xxxx://xxx.xxxxxx.xxx/xxxxxxx.xxxx

7 xxxx://xxx.xxxxx.xxx

8 xxxx://xxx.xxxxxxxxxx.xxx/xxxxxxxx/xxx.xxx

9 xxxx://xxxx.xxxxxx.xxx/xxxxxxx/XXX/XxxxxxxxXxxxxxxxx

10 xxxx://xxxxxxxxxx.xxxxxx.xxx/

11 xxxx://xxxxxxxxxx.xxxxxx.xxx/xxxxxxx-0.xxxx

12 xxxx://xxx.xxxxxxxxx.xxx/xxxxxxxx/xxxx/

C 2.3.7 Java IDE-er

De fleste utviklere bruker et IDE for Java-utvikling. Da BEA WebLogic Portal har plug-ins for Ecplise, og deres egen BEA Workshop bygger på Eclipse 3.2 så vil dette være den IDE som benyttes i dette prosjektet.13

C 2.3.8 Applikasjonstjenere

Løsningen vil kjøre på BEA WebLogic Server Premium som er en JEE (Java Enterprise Edition) sertifisert applikasjonsserver med clustering. Clustringen har til hensikt å gi løsningen failover, sckalering og ballansering av belastning. Transaksjonsstøtte og asynkron behandling av meldinger, sikkerhet med mer er en del av funksjonaliteten som er støttet gjennom å være JEE sertifisert. Oppå denne applikasjonsserveren vil så applikasjonen BEA WebLogic Portal kjøre.

C 2.3.9 Databasetjener og administrasjonsverktøy

Det trengs en felles databasetjener for testing. Det må brukes samme database som løsningen skal kjøre på i produksjon. Det trengs klientverktøy for den type administrasjon man typisk gjør under utvikling: Opprettelse og endring av tabeller, indekser, constraints og lignende, samt kjøring av SQL med visning av resultat. Alle utviklere må ha slike verktøy installert.

Leverandøren forutsetter at Kunden tilgjengeliggjør database og klientverktøy.

C 2.3.10 Rapporteringsverktøy

Vi foreslår å benytte JasperReports som verktøy for rapportene. JasperReports14 er et java-basert open source verktøy for generering av rapporter. JasperReports testes nå også ut som rapporteringsverktøy for Mattilsynet med lovende resultater.

C 2.4 Krav til standarder

Arbeidet med Leveransen skal baseres på følgende standarder for utførelse og dokumentasjon:

C 2.4.1 UML 2.0

UML (Unified Modelling Language) vil bli brukt til modellering og dokumentasjon der hvor det er relevant.

C 2.4.2 Kodestandard

Leverandøren har en etablert kodestandard som er basert på kodestandarden til Sun15. I tillegg benyttes benytte verktøyet PMD16, som er et open source-verktøy for å utføre statisk kodeanalyse i Java-prosjekter, for håndheving av god kodestandard.

C 2.4.3 WAI prioritet 1 krav

Leverandøren vil følge WAI prioritet 1 krav for tilgjengelighet på Web.

13 xxxx://xxx.xxxxxxx.xxx/xxxxx/xxx/xxxxxx.xxx

14 xxxx://xxx.xxxxxxxxxx.xxx/XxxxxxXxxx_XxxxxxXxxxxxx.xxxx

15 xxxx://xxxx.xxx.xxx/xxxx/xxxxxxxx/xxxx/XxxxXxxxXXX.xxx.xxxx

16 xxxx://xxx.xxxxxxxxxxx.xxx/.

C 3 Utviklingsmiljø

Det utviklingsmiljø som skal benyttes for gjennomføring av Leveransen i form av maskin- og programvare, er her beskrevet av Xxxxxx, eventuelt etter forslag fra Leverandøren.

Ansvaret for etablering og drift av utviklingsmiljøet er presisert nedenfor sammen med sanksjoner ved feil og mangler i dette utviklingsmiljøet.

C 3.1 Beskrivelse av utviklingsmiljøet

Leverandøren skal her angi tekniske spesifikasjoner for utviklingsmiljøet (maskinvare, software og infrastruktur).

Identifi- kasjon	Produktnavn	Beskrivelse	Xxxxxx	Xxxxxxx
JDK	Sun JDK	Kompilator, VM, div. verktøy		Se avsnitt C 2.3.1
Cygwin	Cygwin	UNIX-miljø for Windows
Maven	Maven	Byggesystem	1
Junit	Junit	Testrammeverk
Subversion	Subversion	Versjonskontrollsystem	1
JIRA	JIRA	Feilrapporteringssystem	1
Eclipse	Eclipse	Java IDE
BEA WebLogic Workshop	BEA WebLogic Workshop	Java IDE Plugins til Eclipse
Oracle	Oracle 10g R2	Database – bruker den som finnes hos kunden fra før.
Oracle SQL Developer	Oracle SQL Developer	Klientverktøy for database
Oracle JDeveloper	Oracle Jdeveloper	Klientverktøy for database (og Java IDE)
BEA WLS	BEA WebLogic Server Premium	Applikasjonsserver (Inkludert i portal-lisensen)
BEA WLP	BEA Web Logic Portal	Portalrammeverk

BEA ALSB	BEA AquaLogic	Service bus

Identifi- kasjon	Produktnavn	Beskrivelse	Antall	Versjon
	Service Bus

C 3.1.1 Forslag til utviklingsmiljø og testmiljø

Siden kunden benytter seg av VMWare-miljø i dag så foreslås det å benytte dette også i dette prosjektet. BEA WLS og WLP krever minimum 4 GB RAM og vi anbefaler minst 10 GB diskplass for operativsystem og servere. Dersom dette må kjøres på egne servere anbefaler vi en maskin med dual cpu og minimum 1,5 GHz prosessor eller bedre.

I tillegg trengs det tilgang til drifts- eller utviklingsversjoner av alle systemene det skal integreres med, tilgang til databasemiljø for database og kobling mot ActiveDirectory for brukerdatabase

C 3.1.2 Forslag til produksjonsmiljø og systemtestmiljø

Det foreslås at for å sikre oppetid og skalering så skal miljøet kjøre på minimum 2 separate servermiljøer, men dette kan økes avhengig av hva resultatet er av ytelsestesten.

Dersom kunden velger å kjøre dette på sitt eksisterende VMWare miljø så kreves det minimum 4GB RAM og det anbefales 8 GB. Det anbefales min 20 GB diskplass for operativsystem og servere, i tillegg trengs det nok diskplass for logg-filer.

Dersom dette skal kjøres på egne servere anbefaler vi to maskiner med 2x Dual CPU med min 1,5 GHz prosessorer eller bedre og 4 GB RAM. Det trengs i tillegg nok diskplass til å kjøre løsningen. Typisk vil dette være en RAID løsning med 80 GB diskplass eller bedre.

Fortsatt gjelder det at man trenger database, Active Directory og koblinger mot eksisterende systemer.

C 3.2 Etablering og drift av utviklingsmiljø

Kunden er ansvarlig for etablering, drift og vedlikehold av utviklings- og test-miljøet. Leverandøren er ansvarlig for å anskaffe og installere alt utviklingsverktøy i kundens utviklingsmiljø.

Dersom det i samråd med Kunden anses nødvendig å utvide antall prosjektdeltakere, skal kostnader til nødvendige lisenser dekkes av Kunden. Dersom andre vedtatte endringer eller utløste opsjoner krever endring av utviklings- eller testmiljøet skal kostnadene til dette også dekkes av Kunden.

Dersom utviklingsmiljøet er utilgjengelig i mer enn <5 > prosent av normal arbeidstid målt over hver kalendermåned under gjennomføring av Leveransen, og dette skyldes forhold hos Kunden, kan Leverandøren kreve erstatning begrenset i henhold til Generelle

kontraktsbestemmelser. I tillegg kan Leverandøren kreve at fremdriftsplanen forskyves tilsvarende tapt tid som følge av misligholdet. Tapt tid skal fremkomme av dokumentasjonen for eventuelt krav om erstatning.

C 4 Gjennomføringsmodell

C 4.1 Resultatet av behovsfasen

Resultatet av denne fasen er dokumentert i Bilag A, supplert med krav til utviklingsmiljø og Fremdriftsplan slik det er beskrevet i dette Bilag.

C 4.2 Løsningsbeskrivelsesfasen

<Spesifikasjonen kan utarbeides i form av utdypning av brukssituasjoner, eventuelt supplert med objekt- og klassemodeller eller lignende. Løsningsbeskrivelsen skal bygge på den grove løsningsbeskrivelsen som er inntatt i Bilag A.

Nærmere beskrivelse av hvordan Løsningsbeskrivelsen skal utarbeides og inkluderes her.>

I tabellen under gis en oversikt over aktiviteter, tidsplan, estimater, ressurser og metodikk/angrepsmåte for Løsningsbeskrivelsesfasen. Estimatene er Leverandørens estimater. Kundens deltagelse er beskrevet i bilag B.

Delleveranse/ produkt	Aktivitet	Tidsplan	Estimat/ Ressurser	Metodikk/ Angrepsmåte
Prosjektledelse/ Generelle aktiviteter i løsnings- beskrivelsesfasen	• Etablere faggruppe, med representanter fra Kunden/brukere • Skape en felles organisasjon med faggruppen, med felles forståelse av metodikk/ arbeidsform og kommunikasjonsrutiner. • Oppdatert usikkerhetsmatrise • Etablering av en konfigurasjonsstyringsplan • Utarbeidelse av detaljert prosjektplan	Hele Løsnings- beskrivelsesfasen.		Se kapittel Error! Reference source not found.og HMP1 i kapittel Error! Reference source not found.
Etablering av produktkøen	• Etablering av felles forståelse av målene for prosjektet • Skriver brukerhistorier basert på krav i kravspesifikasjonen • Prioritere oppgavene i produktkøen	3,5 uke		Se kapittel C 2.2.2.4
Kvalitetssikring	• Utarbeide kvalitetsplan for prosjektet	3 dager
Testplanlegging	• Etablering av teststrategi og testplaner	3 dager		Se kapittel C 4.2.4
Integrasjons- leveranse	• Identifisere hvilke systemer det skal integreres med og legge opp en integrasjons- strategi	1 uke

Delleveranse/ produkt	Aktivitet	Tidsplan	Estimat/ Ressurser	Metodikk/ Angrepsmåte
Infrastruktur- leveranse	• Installasjon og oppsett av utviklings- og testmiljø • Avklare arkitekturspørsmål • Initielt oppsett av konfigurasjonsstyringsverktøy • Vertikal prototype • Oppsett av kontinuerlig integrasjon • Spesifisere programvare og maskinvare for driftsmiljø	Hele Løsnings- beskrivelsesfasen
Portalpilot	• Velge noe få brukerhistorier som implementeres i den vertikale prototypen som grunnlag for brukertestingen	2 uker
Brukertesting	• Det gjennomføres en brukertesting av papir- prototypen for å avklare hovedretningslinjer for utvikling av portalen.	2 dager testgjennomføring. 3 dager analyse		Se avsnitt C 4.3.3.1.4

Produkter fra løsningsbeskrivelsesfasen vil være:

• En identifisert faggruppe

• Første versjon av produktkøen med prioriterte oppgaver

• Detaljert prosjektplan med plan for hvordan oppgavene i produktkøen skal fordeles mellom sprintene

• Ferdig oppsatt utviklings- og test-miljø med kontinuerlig integrasjon og konfigurasjonsstyringsverktøy

• Vertikal prototype

• Portalpilot

• Analyse av brukertestene med anbefalinger og føringer for prosjektet

• Integrasjonsstrategi

• Definert arkitektur

• Konfigurasjonsstyringsplan

• Kvalitetsplan

• Testplan

I det følgende beskrives de metodikker/angrepsmåter i tabellen over som ikke er standard, i mer detalj.

C 4.2.1 Generelle aktiviteter i løsningsbeskrivelsesfase

Den mest sentrale generelle aktiviteten er oppbygging av prosjektorganisasjonen på kunde- og leverandørsiden. I tillegg til å verifisere rollefordelingen, bemanningen til hver enkelt rolle og lokalisering, er det enkelte andre aktiviteter som støtter opp under dette.

C 4.2.1.1 Etablere faggruppe

Det må opprettes en Faggruppe for løsningsbeskrivelsesfasen som til sammen dekker kompetanse innenfor alle delleveransene.

Videre opprettes en referansegruppe med interne og eksterne interessenter som f.eks kan bestå av utvalgte ansatte, tillitsvalgte, politisk valgte og medlemmer.

Koordineringsgruppe opprettes i henhold til bilag B, kapittel B 2.1.

C 4.2.1.2 Skape en felles organisasjon med faggruppen, med felles forståelse av metodikk/ arbeidsform

Prosjektdeltakere trenger felles forståelse av arbeidsform med gjennomføringsmetodikk. Leverandøren vil arrangere et seminar for prosjektet med opplæring av metoden, og forventninger til de ulike prosjektdeltakere.

Nøkkelpersoner i prosjektet på Kunde og Leverandørsiden vil utarbeide rutiner i forbindelse med prosjektgjennomføring i prosjektet. Disse rutinene må gjennomgås i et oppstartsseminaret. Detaljering av disse rutinene vil gjennomføres etter hvert som prosjektet har behov for dem i de ulike fasene.

C 4.2.1.3 Oppdatert usikkerhetsmatrise

En annen og parallell aktivitet til organisasjonsbygging og metodeforankring, er en større gjennomgang av prosjektets risiki. Her deltar både operativt nøkkelpersonell (fra Kunden og Leverandør), men også beslutningstakere i referansegruppen og kanskje også 1 –2 fra koordineringsgruppen kan bidra. Utgangspunktet er den foreliggende usikkerhetsmatrisen. Det gjennomføres et seminar (f.eks. halv- eller heldags) med brainstorming, gruppering, analyse av sannsynlighet og konsekvens, samt nye forslag til tiltak og evaluering av disse. I etterkant av seminaret produseres en rapport, som blant annet inkluderer en oppdatert usikkerhetsmatrise. Delaktivitetene her blir da:

• Forberedelser til seminar om usikkerhet

• Gjennomføring av seminar om usikkerhet

• Rapport i etterkant av seminaret

C 4.2.1.4 Etablering av en konfigurasjonsstyringsplan

Denne aktiviteten er ikke like omfattende som de foregående, men det er viktig at det også på dette området blir etablert en felles forståelse mellom kunde og Leverandøren. Leverandøren forbereder et utkast med forslag til promoteringsmodell i utviklingsløpet, forslag til hvilke miljøer som skal bygges og med hvilken hyppighet, rutiner for inn- og utsjekking av kode osv. Xxxxxx Xxxxxx har noen kommentarer revideres dokumentet som versjon 1.0 gjeldende ved oppstart av prosjektet. Aktiviteten kan da deles inn i:

• Utarbeidelse av utkast til konfigurasjonsstyringsplan

• Revisjon av Konfigurasjonsstyringsplan versjon 1.0

C 4.2.1.5 Utarbeidelse av detaljert prosjektplan

Basert på produktkø med prioriteringer og estimater utarbeidet i Løsningsbeskrivelsesfasen skal ny prosjektplan for Konstruksjonsfasen utarbeides. Antall sprinter, sprintenes lengde og innhold bør beskrives, også med angivelse av datoer for sprintplanlegginger og sprintgjennomganger.

C 4.2.2 Etablering av produktkøen

C 4.2.2.1 Etablering av felles forståelse av målene for prosjektet

• Felles gjennomgang for å få frem på overordnet nivå målene for prosjektet

• Gjennomgang av krav og besvarelse i tilbud for å oppnå felles forståelse av hvordan det ferdige systemet skal være

• Prioritere målene, slik at det går frem hva som er de mest kritiske målene.

C 4.2.2.2 Prioritering av oppgaver for konstruksjonsfasen i faggruppen

Faggruppen og produkteier må i samarbeid med Funksjonelt Ansvarlige hos Leverandøren gjennomgå kravspesifikasjonen for identifisere brukerhistorier, beskrive, prioritere og estimere disse. Dette arbeidet resulterer i første versjon av produktkøen for leveransen.

Senere i konstruksjonsfasen holdes produktkøen vedlike, omprioriteringer om nødvendig og behandling av endringsbehov som kan ende opp i produktkøen.

C 4.2.3 Kvalitetssikring

C 4.2.3.1 Utarbeide kvalitetsplan for prosjektet

Intern kvalitetsansvarlig utarbeider i løpet av Løsningsbeskrivelsesfasen en kvalitetsplan for prosjektet

C 4.2.4 Testplanlegging

C 4.2.4.1 Etablering av teststrategi og testplaner første iterasjon

Leverandøren forbereder et utkast til teststrategi. Teststrategien skal blant annet adressere testorganisering og roller, kriterier for klassifisering av feil, rutiner for feilregistrering og behandling, testmetodikk og generelle akseptansekriterier. Testplan for første iterasjon er en operativ plan med faser, hvilke tester som skal gjennomføres når, bemanning og pådrag, milepæler, krav til dokumentasjon osv. Delaktivitetene her blir da:

• Utarbeide utkast til teststrategi

• Avholde høring/gjennomganger med kunden

• Bearbeide innspill og kommentarer til leveransene

C 4.3 Konstruksjonsfase

<Selve Konstruksjonsfasen av Leveransen utføres i form av utvikling eller tilpasning av Komponenter gjennom et antall sekvensielle eller parallelle trinn. Komponentene ferdigstilles eller forbedres gjennom en prosess med innlagte Kontrollpunkter. Minimum antall trinn skal

være beskrevet her, dersom dette ikke er valgt overlatt til Leverandørens beskrivelse av metodikk, ref. punkt C 2.2.>

Konstruksjonsfasen gjennomføres iht. det metodeverk for utvikling som er beskrevet i kap. Error! Reference source not found.. Dette vil si at det det som i PS2000 kalles trinn eller iterasjon er det samme som en syklus i Scrum bestående av produksjonsplanlegging, sprintplanlegging, sprintgjennomføring og sluttevaluering (Kontrollpunkt).

Erfaring tilsier at konstruksjonsfasen i denne type prosjekter initielt bør planlegges med sprinter av ca. 3 ukers varighet.

C 4.3.1 Detaljplanlegging / Analyse og design

Partene skal som en innledning til hvert enkelt trinn i fellesskap, men under Leverandørens ledelse og styring, gjennomgå Løsningsbeskrivelsen og legge en detaljplan for utføringen av arbeid i det forestående trinn.

<Nærmere beskrivelse av på hvilke områder og hvordan detaljert analyse og design på bakgrunn av løsningsbeskrivelsen skal gjennomføres, beskrives her. Eventuelle spesifikke krav til Kundens medvirkning og godkjenning av designdokumentasjon må også inkluderes.>

Disse aktivitetene kalles leveranseplanlegging og sprintplanlegging i det metodeverk for utvikling som benyttes og er nærmere beskrevet i kap. C 2.2.2. Partene skal her sammen søke å oppnå at Leverandøren får en forståelse av kundens behov som er så grundig og detaljert at prosjektet blir i stand til å realisere omfanget av hvert trinn så tilfredsstillende som mulig.

Basert på sin forståelse for kundens behov og øvrige tekniske rammer, skal Leverandøren og Kunden i samarbeid i forkant av hver sprint utarbeide design av hvordan sprintens omfang teknisk og funksjonelt skal realiseres. I praksis gjøres dette som en del av den foregående sprinten. Designarbeidet gjennomføres med utgangspunkt i de overordnede designprinsipper som er utarbeidet under Løsningsbeskrivelsen og i raffinering av designprinsippene gjort i tidligere sprinter. Arbeidet vil typisk omfatte:

- Utarbeidelse av skisser til skjermbilder

- Strukturering av programkoden, f-eks i form av komponenter, moduler, klasser, tjenester osv.

- Spesifisering av kommunikasjonsgrensesnitt internt i programvare

- Kartlegging av kommunikasjonsgrensesnitt mot eksterne enheter

- Databasemodellering

Arbeidet kan dokumenteres i form av overordnede skisser, tekstlige beskrivelser og illustrasjonsmåter som dataflytdiagramer osv, men et vesentlig moment ved metoden er å holde dokumentasjonen på et lavt nivå underveis i utviklingen.

Kunden skal ha innsyn i fremgang underveis ved innsyn i produsert dokumentasjon og jevnlige evalueringer av løsningen i forbindelse med hver sprint. Produktene fra en sprint evalueres i form av manuelle tester, demonstrasjoner, kundeinspeksjoner og lignende (se ellers avsnitt C 2.2.2).

C 4.3.2 Utvikling

Hvert trinn skal resultere i et etterprøvbart produkt, normalt i form av demonstrerbare Komponenter. Komponentene kan utvikles eller tilpasses inkrementelt (i delleveranser) eller gjennom stadige forbedringer (iterativt). Leverandøren skal minimum foreta en enhetstest av alle Komponentene før videre testing, ref. punkt C 4.3.3.

<Nærmere beskrivelse av hvordan utviklingen eller brukertilpasning av Komponenter skal gjennomføres, beskrives her. Eventuelle spesifikke krav til Kundens medvirkning må også inkluderes.>

Produksjonsplanlegging og sprintplanlegging er sentrale aktiviteter i forhold til å skape detaljert forståelse av Kundens krav og forventninger i Leverandørens prosjektorganisasjon. Utviklingsmetodikken beskrevet i kap.C 2.2.2 er basert på høy grad av kundemedvirkning i planlegging og tilrettelegging i starten av hver iterasjon, og definerte evalueringsaktiviteter ved slutten av hver iterasjon (kontrollpunkter). Når selve utviklingsarbeidet i hver sprint starter, vil direkte interaksjon med kunden være mer begrenset, og prosjektet vil fokusere på arbeidsro hos utviklere. I slike faser vil Xxxxxxx arbeide være konsentrert om produksjonsplanlegging av neste sprint hovedsaklig i samarbeid med Funksjonelt ansvarlig hos Leverandøren.

Ved behov vil prosjektet dog vurdere om mindre kundeinspeksjoner, f-eks. i form av tilbakemeldinger rundt skjermbildeprototyper osv., kan være formålstjenelig. Leverandøren vil i slike tilfeller være avhengig av at fagpersoner i Kundens prosjektteam er tilgjengelig på relativt kort varsel.

C 4.3.3 Testing

Leverandøren skal som avslutning av hvert trinn teste den del av Leveransen som er utviklet og tilpasset i samarbeid med Xxxxxx.

Antall avdekkede Feil skal etter utløpet av testing i et avsluttende trinn, som resulterer i en delvis overtagelse, ref. punkt C 4.3.7, ikke overstige det antall Feil i hver kategori som fremgår av punkt C 4.4.

Målet for all testing er å verifisere at kunden får riktig og feilfri funksjonalitet. I Leverandøren’ kvalitetssikringssystem omfatter testmetodikken alt arbeid knyttet til planlegging, dokumentasjon, gjennomføring, registrering og rapportering i forbindelse med testing.

Kunden er den som kjenner fagområdet sitt best og vi har god erfaring med nært kundesamarbeid i testarbeidet. Ved å involvere kunden tidlig oppnår vi tidlig sjekk på om utviklingen er på rett vei eller om det må gjøres kursendringer. I tillegg får kunden føling med hvordan systemet vil bli og kan gjøre nødvendige korrigeringer underveis. Et slikt integrert samarbeid er et viktig bidrag til å oppnå rett kvalitet til rett tid.

C 4.3.3.1 Testtyper

Vi skiller mellom følgende testtyper og nivåer:

4.3.3.1.1 Enhetstesting

Hensikt: Formålet med enhetstesting er å rette spesiell fokus mot alle definerte enheter i et programsystem og lete etter feil i hver av disse isolert sett. Dette representerer detaljert testing på laveste nivå og skal verifisere at hver enkelt enhet oppfører seg slik det er spesifisert at den skal.

Metodikk: Denne testingen søkes automatisert ved bruk av JUnit. Prosjektet skal etablere et rammeverk for automatisering av testing i Løsningsbeskrivelsesfasen, og deretter benytte dette og etterstrebe å i størst mulig grad skrive automatiserte tester for definerte enheter som en del av programmeringen av enheten. Testene bør også søke å undersøke enhetens robusthet ved bruk av input-data som skal skape feilsituasjoner som systemet skal håndtere.

Rammeverket for automatisert testing skal støtte automatisk kjøring av enhetstestene regelmessig under hele utviklingsløpet.

For enheter der det er uhensiktsmessig å etablere god automatisert testing, skal det vurderes andre tiltak for å sikre testing av enhetene. Dette kan for eksempel gjelde enheter med brukergrensesnitt som bør testes manuelt.

Prosjektet har en målsetning om at enhetstestingen skal ha en testdekning på minimum 70% av kodelinjene i den koden som er utviklet. Det legges opp til bruk av spesielle verktøy for automatisk måling av dekningsgrad. Erfaringsmessig sikrer en slik høy enhetstestdekning få feil i programkoden som skyldes sideeffekter av ny funksjonalitet i og med at de fanges av automatisk regresjonstesting i utviklingsmiljøet.

4.3.3.1.2 Integrasjonstesting

Hensikt: Formålet med integrasjonstest er å rette spesiell fokus mot koblinger og grensesnitt mellom to eller flere ferdige testede enheter, eller mot systemets eksterne grensesnitt. Her rettes oppmerksomheten mot samspill mellom enheter, og det søkes etter feil knyttet til funksjoner som enhetene bare kan utføre sammen og som ikke er mulig å teste under enhetstesting.

Etter hvert som nye enheter utvikles og testes kan integrasjonstesting inkludere stadig flere komponenter, og etter hvert kan det derfor være aktuelt å prøve ikke-funksjonelle aspekter som ytelse, robusthet, stabilitet osv.

Metodikk: Også integrasjonstestingen skal søkes automatisert ved bruk av tilsvarende verktøy og framgangsmåte som nevnt under enhetstesting i den grad det er mulig og formålstjenelig. I noen tilfeller kan alternative metoder som manuell eller semiautomatisk testing være mest effektiv.

Dekningsgraden under integrasjonstesting bør være slik at alle ulike typer meldinger og typer av data som skal utveksles i et grensesnitt er prøvd ut.

4.3.3.1.3 Systemtesting

Hensikt: Systemtesten skal teste alle funksjonelle og tekniske sider ved systemet, og verifisere hvorvidt det utviklede leveransen inneholder avtalt funksjonalitet og kvalitet. Systemtesten inkluderer både faglige (funksjonelle) tester og ulike tekniske (ikke- funksjonelle) tester.

Metode: Systemtestingen gjennomføres på en slik måte at man bruker løsningen slik Kunden vil bruke den, og så langt det lar seg gjøre simulerer den belastning som vil være typisk for en driftssituasjon. Dette innebærer gjerne testing i form av vanlig bruk av funksjoner via

brukergrensesnitt, datautveksling med simulerte eksterne systemer og ytelsestesting (se under). Systemtesting inkluderer også Brukertesting, se under.

Dekningsgraden under systemtesting bør være slik at alle systemets hovedfunksjoner er prøvd ut.

4.3.3.1.4 Brukertesting

Hensikt: Brukertesting skal for det første undersøke hvorvidt systemet er laget på en tilstrekkelig brukervennlig måte. I tillegg bidrar en brukertest til å undersøke hvorvidt systemet er tilrettelagt for det bruksmønster Kunden har ment at det skal.

Brukertesting er en effektiv sjekk på hvorvidt samhandling mellom Kunde og Leverandør har vært god og detaljert nok og hvorvidt Leverandøren i tilstrekkelig grad har forstått Kundens rutiner og arbeidsprosesser. Denne typen testing foregår kontinuerlig under testing av de forskjellige elementene i sprinten, men bør også gjennomføres konsentert på større oppgaver.

Metode: Brukertesting kan gjennomføres på flere måter, f.eks. mot papirprototyper eller mot det faktisk implementerte systemet. Hvilken måte man velger å gjennomføre brukertesting på avhenger bl.a. av hvilket stadie man er på i utviklingen. I starter kan papirprototyper være eneste valg, mens det mot slutten av prosjektet vil være mer naturlig å gjennomføre brukstesten mot det faktiske systemet (f.eks. på testmiljøet). Uavhengig av fremgangsmåte er det viktig at representanter fra Leverandøren kan nås under brukertesting og er tilgjengelig for svare på spørsmål, delta i evt. diskusjoner og hjelpe til ved tekniske problemer ved behov.

4.3.3.1.5 Installasjonstesting

Hensikt: Installasjonstesting skal verifisere om systemet lar seg installere som beskrevet i Leverandørens installasjonsdokumentasjonen.

Metode: Dette gjøres ved at løsningen installeres på en dertil egnet miljø, typisk i sammenheng med installasjon av leveranser i Kundens godkjenningsmiljø. Test bør gjøres av eller under deltakelse fra Kunden (ved driftsleverandøren). Dette bidrar til at Kunden (ved driftsleverandøren) blir kjent med installasjonsdokumentasjonen og med det arbeid som typisk må gjøres under en installasjon.

4.3.3.1.6 Regresjonstesting

Hensikt: Regresjonstesting gjennomføres for å undersøke hvorvidt funskjoner realisert i tidligere ferdigstilt programkode påvirkes uheldig av ny programkode i forbindelse med viderutvikling eller vedlikehold av systemet.

Metode: Regresjonstesting gjøres gjerne ved å gjenta kjøring av tester som er etablert i sammenheng med tidligere sprinter og leveranser, altså ren retesting av ferdig produsert programkode. Regelmessig, gjerne daglig, kjøring av alle automatiserte enhetstester, under hele utviklingsløpet er derfor en form for regresjonstesting.

På samme måte er gjentakelse av tidligere etablerte ytelsestester en måte å undersøke hvorvidt ny programkode på noen måte forringer ytelse og responstider.

Det etableres og dokumenteres et utvalg faste manuelle testscenarier som dekker systemets viktigste og mest brukte funksjoner, og rutinemessig kjøre igjennom disse som en fast regresjonstest ved kontrollpunkter og i forkant av leveranser eller produksjonssettinger.

4.3.3.1.7 Ytelsestesting

Hensikt: Undersøke hvorvidt systemet tåler den belastning det vil utsettes for i drift og om respons og svartider tilfredsstiller krav.

Metode: Ytelsestesting gjøres oftest ved bruk av egne utviklede testprogrammer som simulerer last. Testprogrammet eller løsningen selv bør da være utstyrt med funksjonalitet som detekterer og logger svartider i ulike sammenhenger. Dette for å dokumentere resultater og detektere eventuelle flaskehalser slik at det er enklere å identifisere bakenforliggende årsaker og å forbedre ytelsen.

Parallelt med at systemet utsettes for belastning kan brukerfunksjoner kjøres manuelt for å teste om opplevd ytelse sett fra bruker er akseptabel.

Å sørge for at databasen er fylt med en datamengde som tilsvarer den som vil være i en driftssituasjon kan også bidra til å avdekke svakheter relatert til systemets ytelse i forhold til store volumer av data.

C 4.3.4 Samlet integrasjons- og systemtest

Leverandøren skal i avsluttende trinn, som resulterer i en delvis overtagelse, ref. punkt C 4.3.7, minimum gjennomføre en helhetlig integrasjons- og systemtest basert på utarbeidede testspesifikasjoner og fremlegge en protokoll som viser resultatet av systemtesten.

Systemtesten har fokus på å avdekke feil og mangler mhp funksjonalitet, ytelse, integrasjon, robusthet med mer. Systemtesten omfatter derfor både funksjonell og ikke-funksjonelle tester av systemet. Plan for systemtest vil fastsette hvilke tester som er aktuelle for leveransen, og hvordan de skal gjennomføres. Testplanen innbefatter også dekningsgrad av testene. Områder med kritisk funksjonalitet skal gjennomgås spesielt nøye. Resultatene fra systemtesten vil dokumenteres i en Systemtestrapport som vil fremlegges Kunden.

Leverandøren har ansvar for planlegging og gjennomføring av alle tester tilhørende systemtesten. Xxxxxx har ansvar for å stille med ressurser for de faglige testene. Dersom det viser seg formålstjenlig, kan Kunden også måtte bistå ved utførelse av enkelte tekniske tester, f.eks. der det kreves innsikt i Kundens andre IT-systemer.

C 4.3.5 Intern kvalitetssikring

Følgende typer kvalitetssikringsaktiviteter skal utføres av Leverandøren og fremgå spesifikt av beskrivelsen nedenfor. Kvalitetssikringsaktivitetene skal inkluderes i den detaljerte plan for hvert trinn, eventuelt av en separat kvalitetsplan vedlagt dette Bilaget.

- Leserunder for løpende gjennomganger av dokumentasjon

- Strukturert gjennomgang av sentrale dokumenter

- Milepælsgjennomganger

- Kodegjennomganger eventuelt ved hjelp av ekstern, tredjeparts bistand

- Kvalitetsrevisjon i henhold til leverandørens kvalitetssystem, eventuelt etter ISO 9001

<Leverandøren skal, dersom det er utført omfattende andel systemutvikling, foreta og dokumentere kodegjennomganger, minimum av følgende Komponenter, ref. Bilag A: >

Leverandøren gjennomfører kodegjennomganger av kritiske programvarekomponenter identifisert i Løsningsbeskrivelsesfasen.

Leverandøren gjennomfører kodegransking på ulike måter avhengig av den aktuelle moduls omfang, innhold og hvordan den er realisert. Aktuelle tilnærmingsmåter er:

- Kodegransking gjort av en større gruppe formalisert i et møte der aktuell kode er identifisert på forhånd og der alle deltakere først har gjort en gjennomgang hver for seg.

- Partnersjekk der en utvikler går igjennom sin kode og forklarer hvordan det er tenkt overfor en annen utvikler.

- Par-programmering der to utviklere gjør programmeringsarbeidet sammen, diskuterer løsninger og foretar løpende kvalitetssikring underveis.

Planlagte kvalitetssikringsaktiviteter fremgår tidsmessig av Fremdriftsplanen.

C 4.3.6 Kontrollpunkt

Det er definert kontrollpunkter ved slutten av hver sprint. Hensikten med et kontrollpunkt er å evaluere om de delprodukter som er produsert i sprinten(iterasjonen) tilfredsstiller Kundens behov. Gjennomføring av kontrollpunkter består typisk av følgende aktiviteter:

- Leverandøren presenterer funksjonalitet som er laget under sprinten og gir demonstrasjoner av kjørende programkode.

- Kunden evaluerer produktene, leser igjennom dokumenter og prøver ut kjørende programkode (Brukertest).

- Kunden gir en tilbakemelding i form av en liste av ting som oppfattes som mangler eller svakheter. Forholdene skal dokumenteres med tilhørende forklaring og referanser til kravspesifikasjon eller løsningsspesifikasjon.

- Kunden og Leverandøren går igjennom listen og etablerer en omforent restanseliste

Omforente restanselister fra kvalitetsaktiviteter knyttet til kontrollpunkt går inn i sprintforberedelsene for å vurderes sammen med andre oppgaver i forhold til prioriteringer knyttet til framtidige sprinter.

C 4.3.7 Delvis overtagelse

Nedenfor er det beskrevet hvilke deler av Leveransen Kunden kan overta og driftssette etter en foreløpig godkjenning, med referanse til gjennomført Kontrollpunkt, ref. punkt C 5:

Delvis overtagelse er ikke aktuelt i denne kontrakten

C 4.3.8 Xxxxxx ytelser

Installasjon

Opplæring

Dokumentasjon

Datakonvertering

C 4.4 Godkjennings- og avslutningsfase

C 4.4.1 Generelt

Alle avvik i forhold til de i Bilag A definerte krav og behov skal regnes som Feil eller mangler, men samme avvik skal kun regnes som én Feil selv om samme avvik oppstår i flere sammenhenger.

Det skal bygges opp et testmiljø før testing i Godkjenningsprøven starter. <Dette er Kundens/ ansvar og er nærmere beskrevet nedenfor:

Leverandøren skal overlevere leveranser til godkjenning komplett med beskrivelse og installasjonsfiler klar til installasjon. Test av installasjonsbeskrivelsene er en del av godkjenningsprøven.

Eventuell prøvedrift inngår i godkjenningsprøven og kan da representere en full produksjon for en begrenset del av Kundens organisasjon. <Dette må da beskrives nærmere i forhold til teknisk miljø og ansvar.>

Leverandørens skal foreta utbedring og optimalisering med henblikk på at følgende definerte, generelle godkjenningskriterier oppfylles:

- Leveransen er i sin helhet gjort tilgjengelig for Kunden

- Det er dokumentert at alle behov og krav slik de fremkommer av Bilag A vil kunne oppfylles

Disse kravene kan ofte være justert noe i forbindelse med analyse, design-beslutninger og prioriteringer som gjøres underveis i prosjektet. Slike justeringer må være omforent mellom Kunde og Leverandør, og tar sikte på at den endelige leveransen oppfyller NSFs behov på best mulig måte.

- Andre avtalte tjenester og ytelser er utført og levert

- Antall gjenstående Feil eller mangler etter gjennomførte testtyper er lavere enn det antall som er beskrevet i det etterfølgende

(Feil eller mangler i eventuelle leveranser som Kunden har ansvar for, skal holdes utenfor i beregningene av gjenstående A-, B- og C-Feil)

Spesifikke kriterier skal avtales mellom partene innen 10 dager før oppstart av systemtest.

C 4.4.2 Inngangskriterier

Det er definert følgende øvre grense for antall gjenstående Feil ved oppstart av Godkjenningsprøven, kalt inngangskriterier:

- antall A-Feil: <0 >

- antall B-Feil: < 5>

C 4.4.3 Avbruddskriterier under Godkjenningsprøven

Det er definert følgende øvre grense for antall gjenstående Feil under de funksjonelle tester, ytelsestester og andre tekniske tester før avsluttende Godkjenningsprøve eller prøvedrift:

- antall A-Feil: <5 >

- antall B-Feil: < 30>

C 4.4.4 Kriterier for forlengelse av Godkjenningsprøven

Dersom totalt antall avdekkede A- og B-Feil Kunden under Godkjenningsperioden inkludert eventuell prøvedrift overstiger

- antall A-og B-feil samlet: < 50>

har Kunden rett til en forholdsmessig forlengelse av Godkjenningsprøven.

C 4.4.5 Avsluttende godkjenningskriterier

Det er definert følgende øvre grense for antall gjenstående Feil ved avslutning av Godkjenningsprøven, som inngår i godkjenningskriteriene:

- antall A-Feil: 0

- antall B-Feil: <3 >

C 5 Fremdriftsplan

Nedenfor følger en beskrivelse av Leveransens Hovedmilepæler, Kontrollpunkter og øvrige Milepæler med tidsangivelse. Hver enkelt Milepæl definert med ytelser og/eller dokumenter som skal være utført, overlevert eller godkjent for at Milepælen skal være oppnådd.

<Hovedmilepæler er foreløpig fastsatt av Kunden, mens Leverandøren angir øvrige Milepæler og Kontrollpunkter. Leverandøren kan eventuelt foreslå tidligere leveransedato for HMP2. Vi ser for oss et hovedløp for å etablere de ulike tekniske deler av løsningen, parallelt med et redaksjonelt løp for etablering av oppsett og innhold.

Resultatet av løsningsbeskrivelsen vil ha føringer for videre prosjektplan, fremdriftsplanen vil kunne derfor revideres/suppleres etter Løsningsbeskrivelsesfasen.>

MP nr.	Milepæl 17	Beskrivelse/definisjon	Dato18	Dagbot- sanksjonert MP?
HMP0	Kontraktsinngåelse		21.12.2007
	Oppstart		03.01.2008
	Utviklingsmiljø etablert
	Løsningsbeskrivelse utarbeidet	Utkast fra Leverandør	+ 30 dager
HMP1	Løsningsbeskrivelse godkjent	Godkjent av Kunde	+ 35 dager	Ja
	1. trinn gjennomført
	1. kontrollpunkt avsluttet	Godkjent av Kunde	+45 dager
	2. trinn gjennomført
	2. kontrollpunkt avsluttet	Godkjent av Kunde	+60 dager
	n. trinn gjennomført
	Testdata fremskaffet	Fremskaffet av Kunde	Fastsettes i løsnings- beskrivelses- fasen
	Spesifikasjoner for systemtest gjennomgått		Fastsettes i løsnings- beskrivelses- fasen
	n. kontrollpunkt avsluttet	Godkjent av Kunde	<+ant.dager>
	Testmiljø klargjort		Fastsettes i løsnings- beskrivelses- fasen
	Brukertilpasning gjennomført
	Spesifikasjoner og plan for Godkjenningsprøve utarbeidet	Utarbeidet av Kunde	Fastsettes i løsnings- beskrivelses- fasen ,

17 Hovedmilepæler er uthevet med fet skrift

18 + antall dager angir dager ift. oppstartOppstart

MP nr.	Milepæl 17	Beskrivelse/definisjon	Dato18	Dagbot- sanksjonert MP?
			tentativt 19.05.2008
	Installasjon og klargjøring gjennomført		Fastsettes i løsnings- beskrivelses- fasen
	Opplæring gjennomført		Fastsettes i løsnings- beskrivelses- fasen
	Dokumentasjon overlevert		Fastsettes i løsnings- beskrivelses- fasen
	Datakonvertering foretatt
HMP2	Leveransen klar til godkjenning	Inngangskriterier er oppfylt	20.06.2008	Ja
	Dokumentasjon godkjent
	Full systemtest gjennomført		18.06.2008
	Godkjenningsprøver gjennomført	Godkjenningskriterier er oppfylt Godkjenningsprøven inneholder evt. også en prøvedriftsperiode

HMP3	Leveransen godkjent	Godkjent av Kunde	HMP2 + 2 måneder	Ja
	Avslutningsfase gjennomført	Evaluering gjennomført og godkjent av Kunde
	Eventuell Garantiperiode utløpt		HMP3 + 3 måneder

Fremdriftsplanen som utarbeides av Leverandøren og vedlegges dette Bilag, skal strukturere aktivitetene frem mot Milepælen, slik at:

- avhengigheter mellom hovedaktiviteter fremkommer,

- aktivitetene blir plassert i tid, slik at de ovenfor beskrevne milepæler og kontrollpunkter kan nås og

- spesifikt ressursbehov fremkommer.

Videre skal Leverandøren inkludere en detaljert fremdriftsplan for første trinn og oppdatert grovplan for etterfølgende trinn. Den detaljerte fremdriftsplanen er basert på en nedbrytnings- struktur med ressursallokering foretatt på laveste nivå i henhold til denne. Fremdriftsplanen må deretter kunne aggregeres opp til kontraktsnivå i henhold til prosjektstrukturen.

Videre skal Leverandøren utarbeide en liste med avklaringer som må gjøres i løsningsbeskrivelsesfasen, samt en liste med avklaringer som må gjøres i løpet av konstruksjonsfasen.

I Gantt-diagrammet nedenfor har vi gitt en visuell fremstilling av den overordnede milepælsplanen. Milepælene er lagt inn som sorte romber (’diamonds’) og avhengigheter er vist ved blå piler.

21.12

13.02

20.02

18.06

13.08

HMP 3: Leveransen godkjent

Akseptansetest

Godkjennings- og avslutningsfase

HMP 2: Leveransen klar til godkjenning

Systemtest

Sprint 5

Sprint 4

Sprint 3

Sprint 2

Sprint 1

Konstruksjonsfasen

HMP 1: Løsningsbeskrivelse godkjent

Løsningsbeskrivelse utarbeidet

Utarbeide løsningsbeskrivelse

Løsningsbeskriveslsesfase

HMP 0: Kontraktsinngåelse

Oct '08

Sep '08

Aug '08

Jul '08

Jun '08

May '08

Apr '08

Mar '08

Feb '08

Jan '08

Task Name

Gantt-diagrammet nedenfor viser en detaljert fremdriftsplan for Løsningsbeskrivelsesfasen

ID Task Name

07 Jan '08

14 Jan '08

21 Jan '08

28 Jan '08

04 Feb '08

11 Feb '08

18 Feb '08

T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S M T W

Løsningsbeskrivelsesfasen Kick off/etablere prosjekt Etablere utviklingsmiljø Utviklingsmiljø etablert Etablere omforent metodikk

Etablering av produktkø og brukerhistorier Etablere teststrategi og testplaner Etablere konfigurasjonsstyringsplan Utarbeide kvalitetsplan

Utarbeide detaljert prosjektplan Utarbeide integrasjons-strategi Utvikle vertikal prototype & portalpilot Brukertesting og analyse Løsningsbeskrivelse utarbeidet

HMP 1: Løsningsbeskrivelse godkjent

07.01

13.02

C 6 Endringshåndtering

Endringshåndtering skal følge de Generelle kontraktsbestemmelser.

Leverandøren skal på bakgrunn av en fremlagt Endringsanmodning innen < 10 > arbeidsdager, slik det er beskrevet i Generelle kontraktsbestemmelser, påføre et overslag over konsekvenser, herunder konsekvensene for

- funksjonalitet og virkning på Leveransen slik den er beskrevet i Bilag A, herunder virkning på ytelse og kapasitet

- virkning på Kontraktsprisen slik den er angitt i Bilag D

- virkning på Fremdriftsplanen i dette Bilag C

- endrede krav til test eller Kundens medvirkning for øvrig

- virkning på fremtidig vedlikehold, ref. Bilag E

- om Endringen anbefales utført i sammenheng med andre Endringsordre

Totalt kan det innenfor rammen av denne Kontrakt inngås endringer som medfører at Målprisen blir endret med inntil <20 > prosent (i Generelle kontraktsbestemmelser benevnt som nettoeffekt) i forhold til kontraktsinngåelse. <Eventuelt kan det avtales ulik prosentsats for økning vs. reduksjon.>

Bilag D: Vederlag

INNHOLDSFORTEGNELSE

D 1 INNLEDNING 74

D 2 VEDERLAG 75

D 2.1 Kontraktspris 75

D 2.2 Kostnader for Løsningsbeskrivelsesfasen 76

D 2.3 Incentiver og sanksjoner knyttet til vederlag 76

D 2.4 Incentiver og sanksjoner knyttet til tid 77

D 2.5 Andre kostnader 77

D 2.6 Kundens kostnader 78

D 2.7 Betalingsbetingelser 78

D 2.8 Vederlag ved avbestilling 78

D 1 Innledning

Dette Kontraktsbilag inneholder Kontraktsprisen, kvantifisering av incentiv- og sanksjonsordninger og videre spesifikke betalingsbetingelser.

Timerater som er angitt, skal benyttes i forbindelse med tilleggsarbeid eller ved andre forhold som ifølge de Generelle kontraktsbestemmelser kan gi grunnlag for krav om tilleggsvederlag.

I tillegg er pris for følgende tjenester:

- etablering og drift av utviklingsmiljø, beskrevet i Bilag C

- opplæring utover minimumskrav, spesifisert i Bilag A og C

- datakonvertering, eventuelt beskrevet i Bilag A og C

- ekstern kvalitetssikring, eventuelt beskrevet i Bilag B inkludert i dette Bilag.

D 2 Vederlag

D 2.1 Kontraktspris

Leveransen baserer seg på produkter fra system Y. Tabellen under viser hvilke priselementer som er estimert inn som fast pris for programvare

Priselement	Pris per CPU	Antall	Sum
X Portal, produksjon
X Portlets for MS exchange, produksjon
X Portal, test og utvikling
X Portlets for MS exchange - dev kit

Fast pris på programvare

Xxxxxx Xxxxxx har behov for flere CPU-er for løsningen enn beskrevet her, vil dette påvirke fast pris på programvare som angitt i ovenstående tabell. Totalprisen overfor er inkludert i tabellen nedenfor.

Vederlaget som Leverandøren skal motta for Leveransen er definert som en Kontraktspris bestående av følgende:

Priselement	Honorar	Estimat for antall timeverk
Fast pris for maskinvare	0
Fast pris på programvare	732.483
Sum fast pris	732.483
Kostnadsestimat Løsningsbeskrivelsesfasen	459.900	450
Kostnadsestimat Konstruksjonsfasen	5.334.840	5.220
Sum timebasert arbeid	5.794.740	5.670
Påslag som konsekvens av usikkerhetsmatrisen (usikkerhetspåslag)	525.308	514
Målpris (sum timebasert arbeid og usikkerhetspåslag)	6.320.048	6.184
Tillegg for Godkjenningsprøven (spesifisert 6 % tillegg til Målpris)	379.162	371
Evt. tillegg for Garantiperioden (spesifisert 3 % tillegg til Målpris)	201.845	197,5
Kontraktspris (sum fast pris + Målpris + tillegg for	7.633.538	6.752,5

Priselement	Honorar	Estimat for antall timeverk
Godkjenningsprøven og Garantiperioden)

Basert på timeratene beskrevet i punkt D 2.5 er det beregnet følgende gjennomsnittlig timerate som grunnlag for Målprisen, hensyntatt planlagt fordeling mellom ulike ressurskategorier:

1022

Øvrige skatter og avgifter er angitt nedenfor:

< >

Alle priser er oppgitt i NOK, uten merverdiavgift, og er uavhengige av endringer i valutakurser, med unntak av følgende elementer:

D 2.2 Kostnader for Løsningsbeskrivelsesfasen

Kostnadsestimat for Løsningsbeskrivelsen er å betrakte som en øvre kostnadsramme dersom Kunden avbestiller etter Løsningsbeskrivelsesfasen.

Dersom Endringsanmodning som Leverandøren har utstedt under utarbeidelse eller i forbindelse med godkjenning av Løsningsbeskrivelsen, innebærer økning av Kontraktsprisen med mer enn < > prosent, gjelder reglene om rett til avbestilling slik de er definert i Generelle kontraktsbestemmelser.

D 2.3 Incentiver og sanksjoner knyttet til vederlag

Følgende incentiv- og sanksjonsordning, slik det er definert i Generelle kontrakts- bestemmelser, skal gjelde som fordelingsnøkkel for differansen mellom virkelig kostnad knyttet til godkjent timeforbruk, basert på reell gjennomsnittlig timerate, for den andelen som inngår i Målprisen og fastsatt Målpris, basert på forhåndsberegnet gjennomsnittlig timerate, ref. punkt D 2.1:

Fordelingsnøkkel ved underskridelse av Målpris (incentiv)	Eventuelt nedre tak for avvik mellom virkelig kostnad og Målpris	Prosentsats
Tillegg i timerate, gjeldende for avvik i forhold til Målpris, inntil nedre tak		50%
Tillegg i timerate for avvik utover det nedre tak	30%	70%

Fordelingsnøkkel ved overskridelse av Målpris (sanksjon)	Eventuelt øvre tak i for avvik mellom virkelig kostnad og Målpris	Prosentsats
Reduksjon i timerate, gjeldende for avvik i forhold til Målpris, inntil øvre tak		50%
Reduksjon i timerate for avvik utover det øvre tak	30%	70%

D 2.4 Incentiver og sanksjoner knyttet til tid

I tillegg skal følgende incentivordning gjelde ved tidlig ferdigstillelse i henhold til de Generelle kontraktsbestemmelser og Milepæler definert i punkt C 5:

Bonus ved tidlig ferdigstillelse

Eventuelt øvre tak i antall kalenderdager

Bonusbeløp i

NOK

Bonus pr. kalenderdag

Tilsvarende skal følgende sanksjonsordning gjelde ved sen ferdigstillelse, slik det er definert i Generelle kontraktsbestemmelser:

Sanksjon ferdigstillelse	Prosentsats
Dagbot pr. kalenderdag	0,15

Beløpet beregnes på det grunnlag som fremgår av Generelle kontraktsbestemmelser.

D 2.5 Honorar for andre tjenester

Nedenfor er honorar for elementer som ikke inngår i Kontraktspris, angitt:

Kostnadselement	Honorar	Estimat for antall timeverk
Etablering og drift av utviklingsmiljø, beskrevet i Bilag C	Gjeldende timepris	På timebasis
Opplæring utover minimumskrav, spesifisert i Bilag A og C	Gjeldende timepris	På timebasis
Datakonvertering, eventuelt beskrevet i Bilag A og C	Gjeldende timepris	På timebasis
Ekstern kvalitetssikring, eventuelt beskrevet i Bilag B	Gjeldende timepris	På timebasis

Disse kostnadene er basert på estimat for antall timeverk, i henhold til timerater definert nedenfor.

Nedenfor er de timerater som er benyttet av Leverandøren ved beregning av målpris, ref. punkt D 2.1 og øvrig arbeid som er beskrevet ovenfor og i de Generelle kontraktsbestemmelser, angitt:

Kategori ressurs (ref. funksjon i Bilag B)	Timerater i NOK
Prosjektleder	1100
Systemspesialist	1100
Systemarkitekt	1100
Intern kvalitetsansvarlig	1050
Designer	1050
Prosessansvarlig/analytiker	1100
Konfigurasjonsstyringsansvarlig	1100
Senior programmerer	1050
Junior programmerer	880
Testansvarlig	1050

Kategori ressurs (ref. funksjon i Bilag B)	Timerater i NOK
Instruktør	1100
Dokumentasjonsansvarlig	1100
Opplæringsansvarlig	1100
Konverteringsansvarlig	1100

Ved reiser som er godkjent av Xxxxxx på forhånd dekkes reisetid og -kostnader etter følgende retningslinjer:

- Reisetid utenfor normal arbeidstid dekkes med 50 prosent av normal timerate, i totalt inntil 4 timer per døgn. Reisetid utover 4 timer per døgn dekkes ikke.

- Direkte reisekostnader, inkludert diett og overnatting, dekkes etter regning, men med en øvre kostnadsbegrensning i henhold til Statens reiseregulativ. I den grad det er hensiktsmessig skal billigste reisemåte benyttes.

Reisetid og øvrige reisekostnader skal ikke inngå i Kontraktsprisen.

Faste priser og timerater kan kun reguleres under følgende begrensninger:

<(lengde på periode / maksimum rateøkning / rateøkning knyttet til en indeks)>

D 2.6 Kundens kostnader

Følgende timerater benyttes i de tilfeller som er beskrevet i de Generelle kontrakts- bestemmelser, hvor Xxxxxx har krav på å få dekket merarbeid:

Kategori ressurs fra Kunde	Timerater i NOK
Egne ansatte	500
Stipulert timerate for innleie av tredjepart	1000

D 2.7 Betalingsbetingelser

Påløpte timer skal dokumenteres av Leverandøren, og godkjennes av Kunden.

Godkjente timer skal faktureres månedlig. Ved hver fakturering foretas det derfor en avregning av påløpte timer i forhold til målpris, for beregning av eventuelle incentiver eller sanksjoner som beskrevet i punkt D 2.3

Godkjenningsperioden faktureres etter at leveransen er godkjent, Garantiperioden faktureres etter at garantiperioden er utløpt.

D 2.8 Vederlag ved avbestilling

Leverandørens vederlag ved avbestilling er begrenset til <> prosent av gjenstående Målpris.

Bilag E: Betingelser for garanti og vedlikehold

INNHOLDSFORTEGNELSE

E 1 INNLEDNING 81

E 2 YTELSER KNYTTET TIL GARANTIPERIODEN 82

E 2.1 Garantiperiodens lengde 82

E 2.2 Omfang av ytelsene 82

E 2.3 Ytelsesnivå 82

E 3 YTELSER KNYTTET TIL ETTERFØLGENDE VEDLIKEHOLD 42

E 3.1 Omfang av ytelsene 42

E 3.2 Forebyggende vedlikehold og annen assistanse 42

E 3.3 Kompetanse 42

E 3.4 Ytelsesnivå 42

E 3.5 Tilgjengelighetsgarantier 84

E 3.6 Xxxxxx og betingelser 84

E 1 Innledning

Dette Kontraktsbilag inneholder forutsetninger og forpliktelser knyttet til garanti og eventuelt senere vedlikehold.

E 2 Ytelser knyttet til Garantiperioden

E 2.1 Garantiperiodens lengde

Det er definert følgende Garantiperiode for Leveransen:

E 2.2 Omfang av garantiytelsene

Garantien dekker feilsøking og utbedring av Feil i Leveransen. Dersom det er tvil om Leverandøren er ansvarlig for feilsituasjonen, skal Leverandøren likevel kontinuerlig bidra i feilsøkingen, frem til det er dokumentert at Kunden eller en tredjepart er ansvarlig for feilsituasjonen og således også for utbedring. Alle Feil som er gjenstående fra Godkjenningsprøven skal utbedres i denne perioden.

Feilsøking og utbedring foretas enten via telefon-/modem-/nettforbindelse fra Leverandøren eller ved utrykning til Kundens lokaler.

All feilretting skjer mot en felles kildekode.

<Leverandøren/Kunden> har ansvar for å installere nye versjoner av programvare som inneholder utbedringer av Feil.

E 2.3 Ytelsesnivå

Følgende ytelsesnivå er avtalt mellom partene for Garantiperioden: <Ta utgangspunkt i nedenstående krav og sanksjoner.>

Ytelse	Frister/tidsrom	Sanksjoner ved manglende overholdelse
Reaksjonstid ved henvendelser, kategori A-Feil	4 timer
Reaksjonstid ved henvendelser, kategori B-Feil	8 timer
Basisperiode	. fra 8:00 – til 17:00
Maksimum antall A-feil avdekket i Garantiperioden	2	10% reduksjon i vederlag for Garantiperioden
Maksimum antall B-Feil avdekket i Garantiperioden	10	10% reduksjon i vederlag for Garantiperioden

Reaksjonstid er definert som tiden fra Kunden har meldt Feilen til Leverandøren og til Leverandøren har gitt tilbakemelding om at utbedring av Feil er påbegynt. Utbedring er definert som reaksjonstiden og frem til Feilen er utbedret hos Xxxxxx og Kunden er gitt melding om at utbedring er foretatt. Arbeidet med å utbedre A-Feil skal pågå kontinuerlig innenfor basisperioden, frem til Feilen er utbedret.

Basisperiode er de arbeidsdager og tidsrom som ytelsene utføres i og som benyttes som avregningsgrunnlag. <Dersom basisperioden skal gjelde også utover vanlige arbeidsdager, må dette angis.>

E 3 Ytelser knyttet til etterfølgende vedlikehold

Vedlikeholdet omfatter Leveransen som er utviklet og levert av Leverandøren.

Nedenfor er det angitt betingelser som vil bli inkludert i en eventuell vedlikeholdskontrakt inngått mellom partene. For at betingelsene i dette punkt skal gjøres gjeldende, må opsjonen om inngåelse av vedlikeholdskontrakt være utløst innen: < >

De etterfølgende betingelser skal da innarbeides i vedlikeholdskontrakten, sammen med definisjonene i punkt E 2.3.

E 3.1 Omfang av vedlikeholdsytelsene

Vedlikeholdet dekker feilsøking og utbedring av Feil i Leveransen. Dersom det er tvil om Leverandøren er ansvarlig for feilsituasjonen, skal Leverandøren likevel kontinuerlig bidra i feilsøkingen, frem til det er dokumentert at Kunden eller en tredjepart er ansvarlig for feilsituasjonen og således også for utbedring. Alle Feil som er gjenstående fra Garantiperioden skal utbedres i denne perioden.

Feilsøking og utbedring foretas enten via telefon-/modem-/nettforbindelse fra Leverandøren eller ved utrykning til Kundens lokaler.

All feilretting skjer mot en felles kildekode.

<Leverandøren/Kunden> har ansvar for å installere nye versjoner av programvare som inneholder utbedringer av Feil.

E 3.2 Forebyggende vedlikehold og annen assistanse

En gang per år skal Kunden og Leverandøren gjennomgå erfaringer og status for vedlikeholdskontrakten og evt. iverksette korrigerende tiltak når det er enighet om dette.

Kontrakten kan utvides til å inkludere kortfattete konsultasjoner per telefon eller elektronisk post. Denne konsultasjonen er i så tilfelle begrenset til kortfattet assistanse i tilknytning til systemet og omfatter ikke konsulentbistand i alminnelighet.

E 3.3 Kompetanse

Leverandøren skal opprettholde nødvendig kompetanse og ressurser for å kunne foreta feilsøking, utbedring av Feil og eventuelle avtalte tilpasninger til Leveransen.

E 3.4 Ytelsesnivå

Følgende ytelsesnivå er avtalt mellom partene: <Ta utgangspunkt i nedenstående krav og sanksjoner.>

Ytelse	Frister/tidsrom	Sanksjoner ved manglende overholdelse
Reaksjonstid ved henvendelser, kategori A-Feil	4
Reaksjonstid ved henvendelser, kategori B-Feil	8

Basisperiode	Fra 8:00 – til 17:00
Tidsfrist for utbedring av A-feil	8 timer	Timebot på 2 prosent av månedlig vedlikeholdsavgift
Bot per A-feil som er avdekket	7000 NOK	Beløpsreduksjon i kommende måneds vedlikeholdsavgift
Tidsfrist for utbedring av B-Feil	5 arbeidsdager	<Dersom aktuelt med tidsfrist>
Tidsfrist for utbedring av C-Feil	Etter nærmere avtale
Periode for sanksjoner (ved eventuell timebot eller lignende)	<Antall kalenderdager>

E 3.5 Tilgjengelighetsgarantier <opsjon>

<Vedlikeholdskontrakten kan inneholde en garanti for Leveransens tilgjengelighet, basert på følgende mekanismer dersom ikke sanksjonene i punkt E 2.3 anses relevante; som et alternativ til disse:

Leveransens tilgjengelighet måles for hver kalendermåned. Tilgjengeligheten (T) beregnes etter følgende formel, hvor BT er kalendermånedens summerte basisperioder og FT er feiltid, dvs. tid hvor Leveransen har vært utilgjengelig grunnet A-Feil som Leverandøren etter Kontrakten har ansvar for å utbedre:

T = (BT-FT) / BT * 100

All tid er omregnet til minutter. T fremkommer i prosent.

Dersom tilgjengeligheten i en kalendermåned ikke er innenfor grensene slik de er definert nedenfor, vil neste måneds vedlikeholdsavgift bli redusert som beskrevet:

Tilgjengelighet	Reduksjon i kommende måneds vedlikeholdsavgift
99-100 %	.... %
98-99 %	.... %
97-98 %	.... %
95-97 %	.... %
>

E 3.6 Xxxxxx og betingelser

Basert på det ovenstående vil den månedlige vedlikeholdsavgiften bli som følger:

< > NOK

Produke

Årlig avgift xxx

XXX

Xxxxxx

Xxx per år

Produke	Årlig avgift xxx XXX	Xxxxxx	Xxx per år
X Portal, produksjon	76.000	1	76.000
X Portlets for MS eKunde Xchange, produksjon	20.000	1	20.000
X Portal, test og utvikling	66.100	1	66.100
X Portlets for MS eKunde Xchange - dev kit	4.041	1	4.041

Sum årlig vedlikehold			166.141

Bilag F: Bruksrett til standard programvare

INNHOLDSFORTEGNELSE

F 1 INNLEDNING 88

F 2 STANDARD PROGRAMVARE SOM INNGÅR I KONTRAKTEN 89

F 2.1 Komponenter definert som standard programvare 89

F 2.2 Komponenter basert på leverandørens programvarebibliotek 89

F 3 RETTIGHETER OG BETINGELSER KNYTTET TIL PROGRAMVARE 90

F 3.1 Opphavsrett 90

F 3.2 Bruksrett 90

F 1 Innledning

Dette Kontraktsbilag inneholder en beskrivelse av de rettigheter partene har avtalt knyttet til de Komponenter av standard programvare som inngår i Kontrakten. Slik standard programvare er nærmere definert i dette Bilaget.

F 2 Standard programvare som inngår i Kontrakten

Rettigheter til programvare inkluderer i tillegg til den definerte programvare også tilhørende ytelser, herunder dokumentasjon.

F 2.1 Komponenter definert som standard programvare

Nedenfor følger en angivelse av de Komponenter som er definert som standard programvare:

Ident.	Komponentbeskrivelse	Versjonsnummer	Antall lisenser
XXX Server YYY	Applikasjonsserver
Portal xxx	Portalrammeverk

Programvaren kan være installert på følgende utstyr:

Ident.	Utstyrsbeskrivelse	Versjonsnummer

Kunden kan få fri tilgang til programvaren via terminaler, PCer eller via Internett uten at dette skal kunne anses som brudd på de Generelle kontraktsbestemmelsene.

F 2.2 Komponenter basert på Leverandørens programvarebibliotek

Nedenfor følger en beskrivelse og klassifisering av den programvare som skal utvikles og hvor det inngår Komponenter fra Leverandørens standard programvarebibliotek:

< >

Følgende Komponenter er utviklet for Kunden, men vil bli regnet som ikke forretningskritisk for Kunden:

<Bare aktuelt å definere slike Komponenter dersom Leverandøren skal få opphavsretten til disse>

F 3 Rettigheter og betingelser knyttet til programvare

F 3.1 Opphavsrett

Leverandøren beholder opphavsretten til alle Komponenter som er definert som standard programvare, ref. punkt F 2.1. I tillegg beholder Leverandøren opphavsretten til de Komponenter som representerer et gjenbruk fra Leverandørens standard programvarebibliotek, ref. punkt F 2.2.

Følgende garantibetingelser gjelder for standard programvare:

<Kun nødvendig å regulere avvik fra Generelle kontraktsbestemmlsers garantibetingelser>

Det henvises til gjeldende lisensbetingelser til system <ref> som er vedlagt

F 3.2 Bruksrett

<Her kan Leverandørens standard lisensbetingelser inkluderes dersom det er formålstjenlig. Eksempelvis kan det reguleres en begrensning i antall samtidige brukere av systemet.

Det bør fremgå at dersom Leverandøren ikke lenger er i stand til å tilby vedlikehold av programvaren, skal Kunden ha rett til en kopi av kildekoden.>

Det henvises til gjeldende lisensbetingelser til system <ref> som er vedlagt

Document Metadata

Table of Contents

PS2000 Kontraktsstandard for leveranse av programvare m. m.

Document Metadata