P r o s j e k t p l a n. BarentsWatch, del 1: En åpen portal

Transkript

1 P r o s j e k t p l a n BarentsWatch, del 1: En åpen portal

2 Innhold: 1 Introduksjon Formelt underlag for prosjektet Prosjektperiode Navnet Definisjoner, akronymer og forkortelser Sammendrag Mål, forutsetninger og tidsrammer Prosjektets hovedmål Regjeringens forslag til Stortingets budsjettvedtak for 2011: Fra Hovedrapport, kapittel 2.4: Sentrale milepæler: Forutsetninger ved valg av løsning Ytre forutsetninger (rammebetingelser): Indre forutsetninger: Kritiske suksessfaktorer Samarbeid Framdrift Den tekniske løsningen Datakvalitet Nye brukerapplikasjoner Interaksjonsdesign og presentasjondesign Prosjektets organisering Oppdragsgiver (Fiskeri- og kystdepartementet) Departementsgruppen Prosjektansvarlig (Kystdirektøren) Styringsgruppen Prosjektleder (Kystverket) Ressursgruppen Aktiviteter og ressursrammer Prosjektledelse Etablere prosjektorganisasjonen Etablere organisasjon for drift- og videreutvikling Prosjektmøter Informasjonsvirksomhet Kravspesifikasjonsarbeid Klargjøring av kravspesifikasjonens forutsetninger Kravspesifikasjon åpen del (del 1) Utarbeidelse av beslutningsunderlag for lukket del (del 2) Anskaffelser systemutvikling og drift Prekvalifisering systemutvikling Anbud systemutvikling åpen del Kontraktsinngåelse åpen del Kontraktstyring Utredning av driftsform Etablering av drifts-løsningen Systemutvikling Systemutviklingsplaner fra leverandører Test av løsning (intern) Sluttevaluering og rapportskriving Aktivitetsplan: Kostnader... 24

3 1 INTRODUKSJON Denne prosjektbeskrivelsen er utarbeidet i hovedsak basert på rapporten BarentsWatch - et beslutningsgrunnlag: I tillegg er føringer mottatt fra FKD så lang som mulig tatt implementert i planen. Prosjektbeskrivelsen skal tjene som prosjektorganisasjonens overordnede styringsdokument. Av denne grunn beskriver prosjektplanen prosjektet, delprosjekter og aktiviteter på et overordnet nivå. For delprosjekter og aktiviteter der det er behov for mer detaljerte beskrivelser og planer, vil dette bli utarbeidet som vedlegg til denne overordnede prosjektplanen underveis. 1.1 Formelt underlag for prosjektet Vedtak i regjeringen juni 2010 ( 1.2 Prosjektperiode Prosjektet starter og skal være avsluttet innen Prosjektet vil deretter gå over i en fase for drift og videreutvikling. 1.3 Navnet Hovedrapporten omtaler muligheten for navneskift. Dels begrunnes dette med mismatch mellom den geografiske tilknytningen navnet gir (Barents) og BWs faktiske virkeområde, dels med at systemet ikke er et rent overvåkingssystem (Watch), men også i stor grad et informasjonsformidlingssystem. Navn og logo (grafisk profil) er utarbeidet og prosjektet legger til grunn at navn og logo er det som skal benyttes videre og vil implementere dette i løsningen. 1.4 Definisjoner, akronymer og forkortelser Følgende definisjoner og akronymer gjelder for dette dokumentet: FOA Iterativ utvikling KYV LOA Metadata PO PL SCRUM Forskrift om offentlige anskaffelser Tidsbokser med fast lengde og klart definerte kriterier for måloppnåelse. Varighet (SCRUM) fra en til fire uker. Kystverket Lov om offentlige anskaffelser Data om data, f.eks. publiseringsdato og forfatter av en rapport. Prosjektorganisasjonen Prosjektleder Scrum er et rammeverk laget med henblikk på å utvikle komplekse produkter i en iterativ prosess. Det brukes i hovedsak til å utvikle programvarebaserte systemer, men kan i prinsippet brukes til å håndtere alle slags prosjekter av en viss kompleksitet

4 Workflow Trinn i en arbeidsprosess med definert rekkefølge og ansvar på hvert trinn

5 2 SAMMENDRAG Mål BarentsWatch skal bli et helhetlig overvåkings- og informasjonssystem for de nordlige hav- og kystområder. Etableringen forutsetter et nært samarbeid med en rekke andre institusjoner. Systemet vil bestå av en åpen og en lukket del. Den åpne delen vil være en offentlig tilgjengelig informasjonsportal for havområdene. Den skal formidle informasjon til allmennheten knyttet til områdene klima og miljø, sjøtransport, marine ressurser og fiskeri, og olje og gass. Den lukkede delen er tenkt å være et operativt system for relevante myndigheter som skal kunne kombinere informasjon for å gjøre det lettere å håndtere spesielle situasjoner som forurensning, ulykker mv. Kritiske suksessfaktorer Det er to avgjørende faktorer for at prosjektet skal lykkes: Et godt samarbeid med alle involverte partnere og høy kvalitet i utviklingsarbeidet. Utviklingsarbeidet skal gjøres eksternt. For å minimere risikoen i denne prosessen, vil vi gjennomføre utviklingsarbeidet etter en iterativ metodikk (f.eks. SCRUM): Oppgavene deles opp mindre deler. For hver del vil det bli utarbeidet en kravspesifikasjon som grunnlag for konkurranse på hver del (innenfor inngåtte avtaler). På denne måten oppnår vi stor fleksibilitet og dynamikk både i forhold til endrede forutsetninger / betingelser, muligheten til å ta i bruk ny teknologi underveis og mulighet for å terminere kontrakter uten at utviklingsarbeidet stopper opp. Vi får bedre kontroll med utviklingsarbeidet og arbeidet med kravspesifikasjonen vil bli mindre i den innledende fasen: Vi kommer fortere i gang, men blir nødvendigvis ikke tidligere ferdig. Denne metoden vil imidlertid kreve mer intern utviklerkompetanse i organisasjonen for å følge opp leverandørene. Kravspesifikasjon Forutsetningene for å lykkes i prosjektet legges gjennom at man klarer å gjennomføre en kravspesifikasjonsprosess hvor partnerne i prosjektet danner felles konsensus for hva BW skal levere av tjenester, til hvem og i hvilket omfang. Rent teknisk innebærer dette å klarlegge alle funksjonelle og ikke funksjonelle krav til systemet. Prosessen vil etter hvert også avdekke hvilke forpliktelser som de enkelte partnerne vil måtte ha til BW, og danne grunnlaget for nødvendige samarbeidsavtaler. Mer spesifikt vil prosessen bl.a. klargjøre hvilke data partnerne skal levere til BW, hva som skal presenteres ut, hvilke krav som skal stilles til datakvalitet og hvilke retningslinjer gjelder for 3.parts bruk av data (også i kommersiell virksomhet). Det er mange interessenter i prosjektet som både skal levere data inn (partnere) og som skal få data ut (brukere). Det vil være viktig å avklare disse interessentenes forventninger til BW. Det store antall vil gjøre det nødvendig å avgrense omfanget av selve kravspesifikasjonsprosessen i den innledende fasen. Når det gjelder den lukkede delen av BW, er denne ikke besluttet opprettet. Prosjektet skal utarbeide et beslutningsunderlag som vil danne grunnlag for videre behandling i regjeringen Kravspesifikasjonsarbeidet for den åpne delen vil også være avhengig av at man avklarer hvilke grad av integrasjon man ønsker mellom de to delene, og alle tekniske forutsetninger for den ønskede integrasjonen mellom de to delene. Det vil derfor være viktig at man tidlig starter opp arbeidet med beslutningsunderlaget for del 2, og at dette arbeidet også innbefatter nødvendig overordnet kravspesifikasjon som muliggjør sammenkopling med del 1. Hovedrapporten legger også føringer på at BW også skal kunne brukes i en internasjonal sammenheng, både i et mulig samarbeid med skandinaviske land, medlemslandene i Arktisk råd og EU. Det vil derfor være særdeles viktig at man både for del 1 og del 2 klarlegger internasjonale / europeisk regelverk for utveksling av data mellom åpne og lukkede systemer, hvilke krav som gjelder for nedlasting og bruk av data, hvilke standarder / formater som skal brukes og at dette blir beskrevet som en del av kravspesifikasjonen.

6 Denne kravspesifikasjonen skal være overordnet i den forstand at den identifiserer mål, forpliktelser og del-leveranser innenfor hvert av områdene design, publisering, kart og metadatakatalog, Detaljert spesifisering av innholdet i hver del-leveranse vil skje som del av den iterative systemutviklingsprosessen. Anbud utvikling Anbudet skal resultere i avtaler med to eller flere leverandører. Anbudet skal utformes slik at prosjektet får tilgang til best mulig utviklerkompetanse på hvert av områdene design, publisering, kart og metadatakatalog - til en akseptabel pris. Dokumentert kompetanse vil derfor være et sentralt tildelingskriterium. I tilbudet må det også gis en timepris og et ikke bindende anslag på hvert av områdene design, publisering, kart og metadatakatalog som tilbyder vil gi tilbud på. Konkurranse på alle utviklingsoppgaver sikrer oss stor grad av fleksibilitet. Det er derfor viktig at kravene til forutsigbarhet og gjennomsiktighet ivaretas i form av tilstrekkelig informasjon om innholdet i anskaffelsen, fremgangsmåten ved avrop under avtalen og de tildelingskriterier som skal benyttes for inngåelse av den enkelte kontrakt. Milepæler : Prosjektplanen godkjennes av styringsgruppen Innspill til satsningsforslag 2012 oversendes FKD : Godkjenning av kravspesifikasjon for del 1 i styringsgruppen : Avtale(r) om utvikling inngått : Godkjenning av beslutningsgrunnlag for del 2 i styringsgruppen, alt. kun godkjenning av integrasjonen mellom del 1 og del 2. (Dvs. fullstendig beslutningsunderlag kommer opp til behandling på et senere tidspunkt) Beslutningsgrunnlag lukket del sendes departementsgruppen v/fkd Underlag for budsjettbehov 2012 (det totale med både åpen og lukket del) sendes FKD : Pilot tilgjengelig : Lansering av BarentsWatch del 1

7 3 MÅL, FORUTSETNINGER OG TIDSRAMMER 3.1 Prosjektets hovedmål Regjeringens forslag til Stortingets budsjettvedtak for 2011: «Regjeringa har gitt Kystverket i oppdrag å forberede etableringen av BarentsWatch, et helhetlig overvåkings- og informasjonssystem for de nordlige hav- og kystområder. Etableringen forutsetter et nært samarbeid med en rekke andre institusjoner. Basert på foreløpige planer vil systemet bestå av en åpen og en lukket del. Den åpne delen vil være en offentlig tilgjengelig informasjonsportal for havområdene, som skal formidle informasjon til allmennheten knyttet til områdene klima og miljø, sjøtransport, marine ressurser og olje og gass. Det er den åpne delen som nå planlegges etablert, mens en lukket, operativ del skal utredes nærmere. Den lukkede delen er tenkt å være et operativt system for relevante myndigheter som skal kunne kombinere informasjon for å gjøre det lettere å håndtere spesielle situasjoner som forurensning, ulykker mv. Det arbeides for at en eventuell lukket del av systemet skal knyttes til sjøtrafikksentralen i Vardø.» Fra Hovedrapport, kapittel 2.4: BarentsWatch Fase 1 forutsettes å bygge på følgende grunnforutsetninger: a) En portal for formidling av åpent tilgjengelig og gratis informasjon og webtjenester fra partnerne. Informasjonen lagres i partnernes servere, og de enkelte partnerne er ansvarlige for at informasjonen/tjenesten holder den kvalitet som er angitt i de beskrivende metadata. b) Et enhetlig presentasjonsformat. Fem temaområder prioriteres: klima og miljø, sjøtransport, marine ressurser, olje- og gassaktivitet, og suverenitetshåndhevelse. c) For utvalgte bruksområder, sammenstilt informasjon fra ulike partnere. d) Brukergrensesnitt på norsk og engelsk. e) En informasjons- og tjenestekatalog med søkefunksjon som viser tilgang så vel som karakteren/kvaliteten av informasjonen og tjenestene. f) Brukerstøtte i vanlig arbeidstid. g) Systemløsning som muliggjør utveksling av informasjon med lukkede systemer etter en nærmere spesifikasjon. 3.2 Sentrale milepæler: : Prosjektplanen godkjennes av styringsgruppen Innspill til satsningsforslag 2012 oversendes FKD : Godkjenning av kravspesifikasjon for del 1 i styringsgruppen : Avtale(r) om utvikling inngått : Godkjenning av beslutningsgrunnlag for del 2 i styringsgruppen, alt. kun godkjenning av integrasjonen mellom del 1 og del 2. (Dvs. fullstendig beslutningsunderlag kommer opp til behandling på et senere tidspunkt) Beslutningsgrunnlag lukket del sendes departementsgruppen v/fkd Underlag for budsjettbehov 2012 (det totale med både åpen og lukket del) sendes FKD : Pilot tilgjengelig : Lansering av BarentsWatch del Forutsetninger ved valg av løsning Ytre forutsetninger (rammebetingelser): 1. Lov om offentlige anskaffelser.

8 2. Stortingets budsjettvedtak (saldering av budsjettet for 2011) Indre forutsetninger: 1. Prosessen leder fram til formulering av realistiske målsetninger som er akseptert av de impliserte parter; mål som alle involverte har forplikta seg på. 2. Alternative løsninger for å nå målsetningene er vurdert. 3. Den valgte løsninga kan med sikkerhet sies å være teknologisk realiserbar. 4. De økonomiske rammene for prosjektet er avklart, finansiering er ordnet og budsjettet godkjent. Det forutsettes at eventuelt endrede forutsetninger / uforutsette hendelser som har budsjettmessige konsekvenser ikke fører til underfinansiering. 3.4 Kritiske suksessfaktorer Det er to avgjørende faktorer for at prosjektet skal lykkes: Et godt samarbeid med alle involverte partnere og høy kvalitet i utviklingsarbeidet. Utviklingsarbeidet skal gjøres eksternt. For å minimere risikoen i denne prosessen, vil vi gjennomføre utviklingsarbeidet etter en iterativ metodikk (f.eks. SCRUM): Oppgavene deles opp mindre deler. For hver del vil det bli utarbeidet en kravspesifikasjon som grunnlag for konkurranse på hver del (innenfor inngåtte avtaler). På denne måten oppnår vi stor fleksibilitet og dynamikk både i forhold til endrede forutsetninger / betingelser, muligheten til å ta i bruk ny teknologi underveis og mulighet for å terminere kontrakter uten at utviklingsarbeidet stanser opp. Vi får bedre kontroll med utviklingsarbeidet og arbeidet med kravspesifikasjonen vil bli mindre i den innledende fasen: Vi kommer fortere i gang, men blir nødvendigvis ikke tidligere ferdig. Denne metoden vil imidlertid kreve mer intern utviklerkompetanse i organisasjonen for å følge opp leverandørene Samarbeid. Det er mange parter / interessenter i dette prosjektet. Det er mange organisasjoner som skal levere innhold og det er mange som har sterke ønsker i forhold til hva BW skal bli. Det endelige resultatet vil i stor grad avhenge av at prosjektet lykkes med å skape en felles forståelse for hva målet skal være, og den enkeltes ansvar for å nå målet. Dette må prosjektet lykkes med. God kommunikasjon, åpenhet og godt samarbeid i ressurs- og styringsgruppen skal bidra til dette. Dersom det oppstår utfordringer på dette området som setter prosjektets mål og fremdrift i fare, må styringsgruppen og prosjekteier bli orientert så raskt som mulig slik at nødvendige tiltak kan settes inn raskt. Prosjektet er i stor grad avhengig av den kapasitet i form av kunnskap, kompetanse, data og tjenester som partnerne i prosjektet besitter. Gjennom å invitere partnerne aktivt inn i prosjektet gjennom for eksempel utvikle nye og innovative tjenester for BarentsWatch vil en søke å utnytte disses kapasiteter. Viktige elementer som prosjektet vil fokusere på for å sikre godt samarbeid: Så tidlig som mulig å inngå samarbeidsavtaler med partnerne der forventninger, roller og ansvar avklares. Gjennom et godt informasjons- og kommunikasjonssystem sikre at alle partnere i prosjektet hele tiden har tilgang til nødvendig og oppdatert informasjon i prosjektet. Bl.a. vil det bli opprette en prosjektplass som alle partnere har tilgang til. Fysisk samling av ressursgruppen: Gjennomføre regelmessige møter i prosjektorganisasjonen som arena for beslutninger, informasjon, problemløsning, nettverksbygging og faglige innspill i prosjektet Gjennomføre behovsanalyser hos BWs brukere som grunnlag for iverksetting av nye delprosjekter for utvikling av nye tjenester i BW. Ansvar og gjennomføring av delprosjektene legges til prosjektets partnere og delfinansieres av BW. Tjenestene skal i hovedsak være av en slik karakter at det fordrer sammenstilling av data på tvers av to eller flere partnere Arbeide for at de samarbeidende etater får nødvendige tildelinger for å kunne levere sin andel inn i BW.

9 Ved prosjektstart har 12 av prosjektets partnere levert oversikter over bl.a. hvilke data de kan bidra med. Oversikten følger som vedlegg til prosjektplanen Framdrift. En pilot skal være tilgjengelig og lansering 1. mai. Dette fordrer: God kommunikasjon mellom prosjektets mange partnere. God kontroll på utviklingsarbeidet. Iterativ utvikling med systematisk rapportering på kvalitet og framdrift. Kontroll med budsjett i forhold til mulige uforutsette kostnader. Kanskje må målene justeres i forhold til funksjonalitet vs. tid - dersom bevilgningene ikke øker når behovet eventuelt oppstår. For at dette ikke skal hemme fremdriften, er det viktig at prosjektet har best mulig oversikt til en hver tid - og dermed er i stand til å behandle avvik på et tidlig tidspunkt Den tekniske løsningen. BarentsWatch skal utvikles på en moderne teknisk plattform som muliggjør interaksjon med data og tjenester fra mange ulike parter. Teknologisk skal BarentsWatch fremstå robust, fleksibel og innovativ. Utviklingsarbeidet vil derfor være krevende og uforutsette problemer vil alltid oppstå. Som regel vil de kunne løses innen kontraktens rammer, men det er viktig at kontrakten har klare formuleringer som beskriver oppsigelsesmulighet der dette åpenbart ikke er mulig. Prosjektet vil ha bl.a. ha fokus på: Å utforme kontraktene slik at det å skifte utviklingspartner er en opsjon dersom det er åpenbart at partneren ikke vil være i stand til å levere som avtalt. Å sørge for samsvar mellom valg av plattform for utvikling / drift og krav, herunder også spesiell fokus på å fastsette krav til responstider gitt bl.a. et definert antall samtidige brukere og disses behov for datakapasitet. Tidlig avklaringer i forhold til innhold, interaksjonsdesign med stor vekt på grensesnittets visuelle uttrykk og design Datakvalitet For prosjektet vil det være helt avgjørende at de data som presenteres i løsningen er av en slik kvalitet at de gir troverdighet hos brukerne. Troverdighet til data vil også bli styrket gjennom tilgjengelig metadata som dokumentasjon på kvalitet. Prosjektets bygger på et viktig prinsipp der det er dataeierne som er ansvarlig for kvaliteten på dataene. Prosjektet vil derfor prioritere data fra de leverandørene som kan levere en høy og stabil datakvalitet, og utvikle metoder/rutiner for hvordan BW best mulig skal kunne kontrollere datakvaliteten. Rutinene må også beskrive hvordan, og til hvem, BW skal rapportere evt. avvik i datakvalitet. Disse metodene/rutinene vil også være en del av grunnlaget for de avtaler som vil bli inngått med partnerne som leverer data til prosjektet. Krav til kvalitet vil også gjelde redaksjonelt innhold. Det vil også være viktig at prosjektet avklarer og etablerer rutiner for redaksjonell styring og workflow i forhold til lokale redaktører i BW-samarbeidet Nye brukerapplikasjoner Det er iverksatt 4 delprosjekter som skal ta fram nye brukerapplikasjoner for BW: Oljesølstatistikk Forbedrede drivbaneberegninger Tilstandsrapport for Nordområdene Biologiske bestander og menneskelig aktivitet

10 Prosjektene er valgt ut som eksempler på områder der BW etablerer tjenester som ikke finnes i dag. Etter hvert vil flere slike prosjekter bli iverksatt. For prosjektet vil de være viktig at disse brukerapplikasjonene realiseres på en slik måte at både data og måtene data presenteres på framstår med høy kvalitet - både hva angår data, brukervennlighet og visuelt. Resultatet fra disse prosjektene vil dels bli nye applikasjoner klar for implementering I BW, dels dokumenter som beskriver mulighetsbildet for løsningene og hva som må gjøres videre for å utvikle løsningene. For de delprosjektene som ikke vil resultere i ferdige applikasjoner tilrettelagt for anvendelse i BW, vil det være viktig å avklare hvilke oppgaver respektive parter må løse for å ta fram den tekniske løsningen og hvordan dette er tenkt finansiert. Det er en målsetning at alle de fire omtalte brukerapplikasjonene skal være implementert ved systemets lansering. Både utvikling og implementering av disse nye tjenestene i BW må også lede til klart definerte grensesnitt for implementering av fremtidige tjenester etter hvert som portalen utvikler seg Interaksjonsdesign og presentasjondesign Den ferdige løsningen må ovenfor alle brukere gi gode brukeropplevelser. Løsningen må framstå som intuitiv i bruk og gi gode visuelle presentasjoner. Dette fordrer god interaksjons- og presentasjonsdesign og vil stille krav til leverandører om særskilt god kompetanse på området. Kvaliteten på grensesnittet vil, sammen med kvaliteten på tjenestene portalen leverer, være avgjørende for hvor vellykket prosjektet blir. Dokumentert kompetanse på dette feltet vil derfor bli tillagt stor vekt i anbudsprosessen.

11 4 PROSJEKTETS ORGANISERING Følgende prosjektorganisasjon etableres: Styringsprinsipp i prosjektorganisasjonen: Arbeidet skal styres etter konsensus. Ved uenighet løftes saken opp ett nivå jf. nedenstående. De ulike gruppers mandater: Oppdragsgiver (Fiskeri- og kystdepartementet): Har i samråd med departementsgruppen det overordnede ansvaret for at målsetningen med oppdraget nås. Ansvar: Lede departementsgruppen som skal sikre forankring og samarbeid på departementsnivå Følge opp framdrift og resultater gjennom fastsatt rapportering og styringsdialog med Prosjekteier (Kystverket) Utøve styring av arbeidet med BW på bakgrunn av beslutninger og føringer gitt av departementsgruppen.

12 Sikre finansiering av oppdraget Departementsgruppen: Består av representanter fra de sentrale departementene som samarbeider om BW (FKD, UD, MD, KD, NHD, JD, FD, OED) med følgende oppgave: Foreta overordnede og prinsipielle beslutninger og godkjenne eventuelle endringer i forutsetninger, mandat eller rammer Vedta endelig arbeidsplan og budsjett, samt årsrapport og årsregnskap, etter forslag fra Styringsgruppen. Samordne føringer i tildelingsbrev til underliggende etater Samordne prioriteringer og satsinger mellom departementer og etater Følge opp budsjettprosess Møtes ved behov Styres etter konsensus Prosjektansvarlig (Kystdirektøren): Ansvarlig for den utførende etat (Kystverket) som har påtatt seg å utføre oppdraget for oppdragsgiver, og skal: Rapportere til oppdragsgiver om fremdrift, resultater og avvik gjennom styringsdialog, og sikre samarbeid om BarentsWatch på etatsnivå Lede styringsgruppen Løfte opp evt. interessekonflikter og behov for avklaringer til departementsgruppen Være ansvarlig for prosjektets gjennomføring og leveranser i henhold til mandat Gi klarsignal for oppstart og avslutning av de forskjellige fasene i prosjektet Utnevne prosjektleder Sette sammen et prosjektsekretariat i samarbeid med prosjektleder Sørge for hensiktsmessig opplegg for rapportering og oppfølging Sørge for at arbeidet utføres i henhold til fastsatte spesifikasjoner og krav og at prosjektet gjennomføres i henhold til fastsatte rammer (øk/tekn/adm) Styringsgruppen: Ledes av prosjektansvarlig (Kystdirektøren) og består av ledere på høyt nivå i de viktigste etatene som samarbeider om BW. Styringsgruppen følger opp prosjektets status, fremdrift, prioriteringer etc. iht. oppdrag og prosjektplan. Styringsgruppen er sammensatt for å ha nødvendig myndighet til å kunne løse flest mulig av de problemer som oppstår underveis i arbeidet. Deltakere: Kystverket, Havforskningsinstituttet, Fiskeridirektoratet, Polarinstituttet, Statens Kartverk, Meteorologisk institutt, Forsvarets operative hovedkvarter, Klima- og forurensningsdirektoratet, Norsk romsenter. Styringsgruppens viktigste ansvarsområder: Godkjenne for framleggelse for departementsgruppen forslag til mandat for arbeidet med BarentsWatch Godkjenne for framleggelse for departementsgruppen forslag til arbeidsplan og budsjett, samt årsrapport og årsregnskap. Oversende departementsgruppen 1.november hvert år forslag til en 3-årig arbeidsplan og budsjett for BarentsWatch, der det første året må planlegges i detalj. Oversende departementsgruppen 1.mars hvert år forslag til årsrapport og årsregnskap Godkjenne prosjektplan og detaljplaner for de enkelte fasene i prosjektet Godkjenne deltakeravtalen som regulerer rettigheter og plikter for samarbeidspartnerne, dvs. alle institusjoner som leverer data/ informasjoner/ tjenester inn i BarentsWatch. Konsulteres underveis om prinsippielle veivalg av faglig/teknologisk karakter. Konsulteres om de internasjonale koplinger/samarbeidsavtaler som vil komme i en senere fase, når BarentsWatch er etablert.

13 Sørge for at prosjektet har de nødvendige ressurser til rådighet og at nøkkelpersoner frigjøres eller avlastes i tilstrekkelig grad fra sine vanlige plikter Følge opp prosjektets fremdrift med milepæler, kostnadsbruk og øvrig overordnet rapportering fra prosjektleder Ta stilling til hvordan avvik fra prosjektplanen skal håndteres og godkjenne forandringer i prosjektopplegg eller kravspesifikasjon / teknisk spesifikasjon Skape arena for godt samarbeid mellom samarbeidspartnerne / bidragsyterne Styres etter konsensus, ved uenighet løftes saken til departementsgruppen Prosjektleder (Kystverket) Prosjektleder har det daglige ansvar for ledelse og gjennomføring av prosjektet. Lede prosjektsekretariatets daglige arbeid, orientere og holde kontakt med prosjektdeltakerne og ressursgruppen Utarbeide forslag til arbeidsplan Velge ut prosjektdeltakere i samarbeid med basisorganisasjon og prosjektansvarlig Forestå den daglige ledelsen av prosjektet i samsvar med fastlagte mandat, mål og planer Sørge for at mål og planer, totalt og for den enkelte medarbeider, er forstått og akseptert Etablere gode kommunikasjons- og samarbeidsforhold innenfor prosjektet og i forhold til samarbeidspartnere og andre berørte parter Følge opp fremdriften i prosjektet, kontrollere innsats mot planer og resultat mot mål, og til enhver tid å være klar over prosjektets status Foreslå og iverksette tiltak ved forsinkelser, avvik og overskridelser Sørge for nødvendig dokumentasjon, rapportering og registreringer Bidra til forankringen og profileringen av prosjektet Ressursgruppen: Ressursgruppen består av en fast representant/kontaktpunkt utpekt fra hver av samarbeidspartnerne / bidragsyterne til BarentsWatch (BW). Med bidragsyter menes hver enkelt institusjon som bidrar med data, informasjon og/eller brukertjenester inn i BW, og som har/vil undertegne samarbeidsavtalen som regulerer rettigheter og plikter for partnerne. Ressursgruppen skal: Være kontaktpunkt for BarentsWatch i sin institusjon, og koordinere de interne ressurser/øvrige fagspesialister som skal bidra i arbeidet Legge til rette for samarbeidspartnernes egen anvendelse av BarentsWatch Legge til rette for effektive leveranser fra partnerne av datasett og informasjoner som skal tilgjengeliggjøres og settes i sammenheng gjennom BW Konsulteres underveis om viktige veivalg av faglig/teknologisk karakter. Møtes minst 4 ganger i året, oftere ved behov Styres etter konsensus, ved uenighet løftes saken til styringsgruppen Ressursgruppen kan opprette undergrupper for ulike spesialtema, faste eller tidsavgrensete. Institusjonene bør også utpeke en vararepresentant, som får kopier av innkallinger og referater osv, og kan delta hvis representanten er forhindret. Ressursgruppen kan konsulteres i det forberedende utredningsarbeidet for BarentsWatch lukket del, på forespørsel fra prosjektlederen.

14 5 AKTIVITETER OG RESSURSRAMMER De følgende aktiviteter og aktivtestbeskrivelser er ikke nødvendigvis en fullstendig beskrivelse av alle påkrevde aktiviteter og oppgaver som skal løses i prosjektet. Bruk av interne ressurser og foreløpige estimater. Prosjektplanen vil derfor måtte være gjenstand for regelmessig revisjon underveis. I prosjektet skal følgende aktiviteter skal gjennomføres: 5.1 Prosjektledelse PL, PO og eksterne ressurser 2280 h - estimert Effektmål: Aktiviteten skal sikre prosjektet framdrift og måloppnåelse gjennom å etablere en kompetent organisasjon som kan sikre kvaliteten både i forhold til samspillet mellom prosjektet og de involverte parter, og mellom prosjektet og de som skal utvikle systemet. I tillegg skal den: Etablere all nødvendig infrastruktur (administrative systemer, lokaliteter, leieavtaler, utstyr, mv.) som er nødvendige i både prosjekt- og driftsfasen. Etablere organisasjonen for drift og videreutvikling i FRAM-senteret i Tromsø Etablere prosjektorganisasjonen. PL, PO og eksterne ressurser 320 h Resultatmål: Fysiske lokaler og bemanning er på plass - og nødvendige samarbeidsrelasjoner er etablert. Respektive deltakeres roller og ansvar i prosjektet skal være klargjort og forankret. Utvikling av selve systemløsningen vil bli gjort av eksterne kompetansemiljøer, og prosjektet vil ikke bygge opp en egen organisasjon for systemutvikling. Prosjektorganisasjonen vil bli etablert i samsvar med organisasjonskartet. Underveis vil organisasjonen bli tilført de ressurser og kompetanse den trenger for å løse oppgavene i prosjektet. Enten i form av tilsettinger, eller ved kjøp av eksterne tjenester. Ved prosjektavslutning vil prosjektorganisasjonen i sin helhet oppløses. Dog vil det være slik at deler av prosjektorganisasjonen vil gå over i organisasjonen for drift og videreutvikling Etablere organisasjon for drift- og videreutvikling. PO 320 h Arbeidet i prosjektperioden vil gi kunnskap og erfaringer i forhold til hva det faktiske behovet vil bli i driftsorganisasjonen mht. kompetanse og omfang. I første omgang vil det bli rekruttert personell tilknyttet teknisk utvikling og drift i prosjektorganisasjonen. Innen utløpet av 2011 skal det være etablert kompetanseprofiler og en bemanningsplan for driftsorganisasjonen, samt gjennomført en rekrutterings-prosess. Utgangspunktet er hovedrapportens føringer.

15 Følgende funksjoner skal fylles (fritt fra Hovedrapporten): 1. Rene driftsfunksjoner. Organisering av denne funksjonen vil være avhengig av hvilken driftsform som velges (se 5.3.5). Daglige IKT-drift, håndtere avbrudd, teknisk oppfølging/vedlikehold. Driften skal sikre størst mulig tilgjengelighet/oppetid, samtidig som det løpende vil være behov for tekniske oppgraderinger. Anslått ressursbehov: ca. 1 årsverk. 2. Videreutvikling. Etter at BarentsWatch er blitt operativ i fase 1, vil det pågå kontinuerlig videreutvikling i mange år: Nye samarbeidspartnere nasjonalt og internasjonalt, bygging og tilpassing av lukkete systemer, mv. Vi legger til grunn at hovedvekten av det faktiske utviklingsarbeidet vil foregå hos samarbeidspartnere eller konsulenter. Det trengs likevel en kompetent kjerne i driftsorganisasjonen som kan lede og koordinere de ulike aktivitetene, og understøtte de ulike samarbeidsforaene. Anslått ressursbehov: 2-4 årsverk. 3. Brukerstøtte, redaksjon, nyhetsformidling. En hovedoppgave er å gi brukerstøtte, være helpdesk, både til forespørsler fra allmennheten og fra enkelt-medarbeidere i samarbeidende organisasjoner. Dette bør kunne skje både per epost og telefon, minimum innenfor normal arbeidstid. Det trengs dessuten en redaksjon for å markedsføre BW, formidle nyheter på forsiden til BW osv. Vi anslår behovet til å være 1-2 årsverk. Det vil også være nødvendig å vurdere organiseringen av den åpne delen i forhold til den lukkede delen. Utredningen av den lukkede delen må derfor vurderes i denne sammenhengen. Beslutning om hvordan man skal organisere drift og videreutvikling av den åpne delen bør derfor ikke tas uten at man har vurdert organiseringen av den lukkede delen. Oppbygging og lokalisering av driftsorganisasjonen vil følge Hovedrapportens føringer. Styringsgruppen vil med bakgrunn i ovenstående få forelagt et forslag til framtidig organisering når man har klarlagt alle sider ved drift og videreutvikling Prosjektmøter PL, PO og eksterne ressurser 300 h Prosjektmøter med departementsgruppe, styringsgruppe, ressursgruppe og prosjektgruppe gjennomføres etter prosjektplanen. Det forutsettes at det skrives referat i fra hvert møte Informasjonsvirksomhet. PO 3000 h Resultatmål: En helhetlig informasjons- og kommunikasjonsstrategi for prosjektet og for driftsorg. Den skal sikre at alle involverte parter blir aktive medspillere i prosessen, og potensielle brukere får kjennskap til tjenesten på tjenlige måte og tidspunkt. Informasjons- og kommunikasjonsstrategien skal resultere i et godt omdømme for prosjektet BarentsWatch. Informasjons- og kommunikasjonsstrategien vil bli utformet som et eget dokument som behandles i styringsgruppen. Informasjonsarbeidet har to målgrupper: Selve prosjektet og dets deltakere: Det er en utfordring å serve interessenter pr. Mail og telefon. Det vurderes derfor å etablere et samarbeidsforum der vi kan legge all informasjon og samhandle internt i prosjektet.

16 Opinionen, media, allmennheten: Det må vurderes hvilke behov vi har for å kommunisere eksternt fra prosjektet. Basert på en slik vurdering klarlegges det hvordan man evt. skal informere. For eksempel må det vurderes om det er behov for markedsføring av systemet i en periode før lanseringen, og hvordan man i så fall skal gjennomføre dette. Videre må det vurderes på hvilken måte evt. kritiske hendelser i prosjektet vil kunne skape behov for informasjon ut i media for å ivareta omdømmet til prosjektet. Sannsynligvis vil det være en fordel å etablere en offentlig tilgjengelig informasjonskanal i forhold til prosjektet. Denne aktiviteten må ta stilling til hvordan dette i tilfelle skal gjøres. Lansering: Prosjektet vil lage en nasjonal lansering i form av en offisiell åpningsseremoni. 5.2 Kravspesifikasjonsarbeid. PO, innleid konsulenthjelp og ressurser fra samarbeidsinstitusjoner 580 h Effektmål: En kravspesifikasjon som uttrykker en omforent forståelse for hva systemet skal levere og dermed også hvilke forpliktelser dette stiller til de samarbeidende institusjonene i prosjektet i forhold til deltakelse i BW. Forutsetningene for å lykkes i prosjektet legges gjennom at man klarer å gjennomføre en kravspesifikasjonsprosess hvor partnerne i prosjektet danner felles konsensus for hva BW skal levere av tjenester, til hvem og i hvilket omfang. Rent teknisk innebærer dette å klarlegge alle funksjonelle og ikke funksjonelle krav til systemet. Prosessen vil etter hvert også avdekke hvilke forpliktelser som de enkelte partnerne vil måtte ha til BW, og dermed danne grunnlaget for nødvendige samarbeidsavtaler. Mer spesifikt vil prosessen bl.a. klargjøre hvilke data partnerne skal levere til BW, hva som skal presenteres ut, hvilke krav som skal stilles til datakvalitet og hvilke retningslinjer gjelder for 3.parts bruk av data (også i kommersiell virksomhet). Det er mange interessenter i prosjektet som både skal levere data inn (partnere) og som skal få data ut (brukere). Det vil være viktig å avklare disse interessentens forventninger til BW. Det store antall vil gjøre det nødvendig å avgrense omfanget av selve kravspesifikasjonsprosessen. Prosessen skal derfor prinsipielt gjennomføres på en måte der spesielt partnerne vil være med å legge de overordnede føringer for systemet. Detaljspesifisering av de enkelte modulene innen hovedområdene (design, publisering, kart og metadatakatalog) vil være en del av den iterative utviklingsprosessen. Ressursgruppen skal involveres også i denne prosessen. Når det gjelder den lukkede delen av BW, er denne ikke besluttet opprettet. Prosjektet skal utarbeide et beslutningsunderlag som så skal behandles av Stortinget. Kravspesifikasjonsarbeidet for den åpne delen vil derfor være avhengig av at man avklarer hvilke grad av integrasjon man ønsker mellom de to delene, og alle tekniske forutsetninger for den ønskede integrasjonen mellom de to delene. Det vil derfor være viktig at man tidlig starter opp arbeidet med beslutningsunderlaget for del 2 og at dette arbeidet også innbefatter nødvendig overordnet kravspesifikasjon som avklarer nødvendige tekniske implikasjoner i forhold til den åpne delen. Hovedrapporten legger også føringer på at BW også skal kunne brukes i en internasjonal sammenheng, både i et mulig samarbeid med skandinaviske land, medlemslandene i Arktisk råd og EU. Det vil derfor være viktig at man både for del 1 og del 2 klarlegger internasjonale / europeisk regelverk for utveksling av data mellom åpne og lukkede systemer; hvilke krav som gjelder for nedlasting og bruk av data, hvilke standarder / formater som skal brukes og at dette blir beskrevet som en del av kravspesifikasjonen. I kravspesifikasjonsarbeidet for del 2 bør det også gjøres en vurdering av i hvilken grad det vil være mulig å kjøpe hele, eller deler av tilsvarende etablerte systemer som er etablert i andre land.

17 Det svenske Sjøbasissystemet vil i denne sammenheng kunne være et prosjekt som man både kan hente erfaringer fra etableringen, og å vurdere mulighet for kjøp av hele eller deler av teknologien. Denne kravspesifikasjonen skal være overordnet i den forstand at den identifiserer mål, forpliktelser og del-leveranser innenfor hvert av områdene design, publisering, kart og metadatakatalog, Detaljert spesifisering av innholdet i hver delleveranse vil skje som del av den iterative systemutviklingsprosessen Klargjøring av kravspesifikasjonens forutsetninger. Interne ressurser, innleid konsulenthjelp og ressurser fra samarbeidsinstitusjoner 160 h Kommer fra budsjett Resultatmål: En felles forståelse for prosjektets målsetninger og krav til alle parter er etablert gjennom samarbeidsavtaler. Denne aktiviteten skal klarlegge hvilke ambisjoner, ressurser og mål de samarbeidende institusjonene har definert for sin rolle i prosjektet. Prosessen skal lede fram til en samarbeidsavtale som beskriver: 1. Hvilke tjenester skal den enkelte part levere? 2. Hvilket grensesnitt skal partneren levere tjenester / data gjennom? 3. Hvilke protokoller skal brukes i overføringen av data? 4. Hvilken rolle skal de samarbeidende institusjonene ha i driftsfasen: Skal de levere kun ferdige tjenester, eller skal de levere data for bearbeiding / sammenstilling? Skal de ha redaktøransvar på en egen del av portalen? 5. Hvordan handteres kvalitetskontrollen på data og tjenester? 6. Hvordan behandles avvik i forhold til datakvalitet og tilgang: Rapportering og ansvar? Kravspesifikasjon åpen del (del 1). Interne ressurser, innleid konsulenthjelp og ressurser fra samarbeidsinstitusjoner 320 h Det forutsettes at kostnadene ikke overskrider forskriftens grense på NOK 500. Resultatmål: En ferdig overordnet godkjent kravspesifikasjon for del 1. Den skal: Legge føringer på innholdet i samarbeidsavtalen som må inngås med partnerne i prosjektet. Utgjøre et godt grunnlag for en åpen anbudsinnbydelse i EØS-området. Tjene som kontraktgrunnlag ovenfor leverandører av systemutviklingen, og bidra til et fornuftig grunnlag for akseptsansetesting. Beskrive integrasjons-muligheter mellom den åpne og den lukkete delen, og komme med en anbefaling om i hvor stor grad de skal integreres. Beskrive alle reelle tekniske forutsetninger for at BW åpne del kan integreres med den lukkede delen. Med basis i hovedrapporten, vil vi organisere dette arbeidet i et delprosjekt med følgende aktiviteter: Sammenstille og forankre overordnede krav (et arbeidsmøte og møte med ressursgruppe) Detaljere og dokumentere krav til ønsket løsning Forankre krav i ressursgruppe Ferdigstille og kvalitetssikre en overordnet kravspesifikasjon Utarbeide anbudsinnbydelse for avtaler med tilbyder(e) innenfor hvert av områdene design, publisering, kart og metadatakatalog, og kriterier for evaluering Ressursgruppen bør involveres for forankring av overordnede krav og endelig kravspesifikasjon.

18 Innledningsvis bør arbeidet ta utgangspunkt i hovedrapporten. Dette er et godt grunnlag for å arbeide videre med og strukturere og dokumentere overordnede krav, f.eks. ved hjelp av aktører og brukstilfeller. Ytterligere detaljering av kravene blir en del av utviklingsprosessen. Den overordnede kravspesifikasjonen skal legge alle nødvendige føringer for utviklingen og foreslå en veiledende oppdeling av arbeidet innenfor hvert av områdene design, publisering, kart og metadatakatalog i egnede deloppgaver - tilpasset en iterativ utviklingsprosess. Detaljering av kravene innenfor hver deloppgave gjøres først når oppgaven skal løses. Forholdet til leverandøren(e) ivaretas ved at det innhentes tilbud på hver oppgave, basert på en inngått avtale. Ressursgruppen, eller deler av den, involveres i tråd med de overordna målsetningene for prosjektet. Den overordnede kravspesifikasjonen må godkjennes av prosjektets styringsgruppe. I tillegg til selve kravspesifikasjonen bør det utarbeides en anbudsinnbydelse som bl.a. angir formelle krav til tilbyderne. I denne forbindelse må arbeidet med kravspesifikasjonen avklare om det skal inngås avtaler med mer enn en part. Skal det være mer enn en part, må det være minst tre. Prosessen bør avklare hvordan BW skal driftes, vedlikeholdes og videreutvikles. De nye brukerapplikasjonene: De fire pågående delprosjekter for utvikling av nye brukerapplikasjoner (Tilstandsrapport for nordområdene, Forbedrede drivbaneberegninger, Oljesølstatistikk og Biologiske bestander og menneskelig aktivitet) er applikasjoner som skal gi BW merverdi. Kravspesifikasjonsarbeidet må også avklare nødvendige implikasjoner for at disse tjenestene skal realiseres i BW. Kravspesifikasjon og framdrift i prosjektet: Framdriftsplanen legger opp til at man medio mars 2011 skal være klar med et overordnet underlag for å inngå avtaler om leveranser til BW. Rent praktisk medfører dette at man også innen denne tidsfrist har fått utarbeidet nødvendig detaljert kravspesifikasjon for den første modulen innenfor hvert av områdene design, publisering, kart og metadatakatalog Utarbeidelse av beslutningsunderlag for lukket del (del 2). Pl, Sjøsikkerhetsavdelingen i Kystverket og partnere i prosjektet 160 h Resultatmål: Et godkjent beslutningsgrunnlag for del 2 som legges fram for styringsgruppen. En kritisk suksessfaktor er at de samarbeidende parter i den lukkede delen kommer fram til konsensus i forhold til beslutningsunderlaget. Denne aktiviteten organiseres derfor som et delprosjekt der de samarbeidende etater som Forvaret (Kystvakta), Kystverket, politi- og tollmyndighet samt redningstjeneste, inngår i prosjektorganisasjonen. Det opprettes en intern arbeidsgruppe i Sjøsikkerhetsavdelingen i KYV får ansvar for å lede en prosess som skal resultere i et forslag til beslutningsgrunnlag. Sjøsikkerhetsavdelingen må også vurdere i hvilken grad, og på hvilken måte, ev. respektive departementer skal involveres i arbeidet. Arbeidsgruppen rapporterer til PL, og styringsgruppen godkjenner den endelige versjon som går til overordnet myndighet. Rapportens innhold kan ta Hovedrapporten for den åpne delen som utgangspunkt. I tillegg skal arbeide særskilt omtale følgende forhold: 1. Gi en beskrivelse av hvilken merverdi den lukkede delen skal gi operasjonell virksomhet i nordområdene, og hvordan dette tenkes oppnådd. 2. Særlige kritiske suksessfaktorer for å lykkes, med forslag til tiltak for å redusere risikoelementet i disse. 3. En prioritering av hvilke tjenester som skal inn, og i hvilken rekkefølge de skal integreres. 4. Hvilke hensyn må tas til eksisterende operative systemer 5. Tekniske implikasjoner for integrasjon mot BarentsWatch åpne del 6. Hvordan man tenker seg å organisere drift- og videreutvikling av systemet også relatert til driftsorganisasjonen for den åpne delen.

19 5.3 Anskaffelser systemutvikling og drift. PO og innleid konsulenthjelp 2280 h Effektmål: Prosjektets mål realiseres gjennom det utviklingsarbeidet som er gjort og det driftskonseptet som etableres. Prosessen gjennomføres i henhold til Lov om offentlige anskaffelser 16. juli 1999 nr. 69 (LOA) og forskrift om offentlige anskaffelser (FOA) av 7. april 2006 nr. 406 del III Prekvalifisering systemutvikling. PO, innleid konsulenthjelp 160 h Resultatmål: Avtale med en eller tre prekvalifiserte leverandører til hvert av prosjektets anskaffelsesområder: design, publisering, kart og metadatakatalog. Det skal utarbeides en profil for leverandør på de ulike deler av systemet som grunnlag for å lyse ut prekvalifiseringen. I tillegg til mer standard formelle krav som soliditet, skatt, erfaring fra tidligere prosjekter osv., skal det i tillegg vurderes om der er særskilte krav som skal stilles til leverandør. Slike krav kan være for eksempel særskilt kompetanse og erfaring på presentasjonsdesign. Basert på profilene gjennomføres det en prekvalifiseringsprosess i samsvar med KYV s retningslinjer for dette i EØS området Anbud systemutvikling åpen del 1. PO, innleid konsulenthjelp 100 h Resultatmål: Anbudet gjennomføres i tråd med lov og forskrift (se over). Anbudet skal resultere i avtaler med en, tre eller flere leverandører for hver modul som utvikles. Anbudet skal utformes slik at prosjektet får tilgang til best mulig utviklerkompetanse på hvert av områdene design, publisering, kart og metadatakatalog - til en akseptabel pris. Dokumentert kompetanse vil derfor være et sentralt tildelingskriterium. Grunnlaget for anbudsutlysningen er den overordnede kravspesifikasjonen. I tilbudet må det også gis en timepris og et ikke bindende anslag på hvert av områdene design, publisering, kart og metadatakatalog som tilbyder vil gi tilbud på. Konkurranse på alle deloppgaver sikrer oss stor grad av fleksibilitet. Det er derfor viktig at kravene til forutsigbarhet og gjennomsiktighet ivaretas i form av tilstrekkelig informasjon om innholdet i anskaffelsen, fremgangsmåten ved avrop under avtalen og de tildelingskriterier som skal benyttes for inngåelse av den enkelte kontrakt. Kontrakt innenfor avtalen kan kun inngås mellom de opprinnelige parter i avtalen. Tildeling skjer i samsvar med de betingelser som følger av avtalen, dog med den viktige begrensningen at det ikke er anledning til å gjøre vesentlige endringer i avtalevilkårene, jf. 6-1(4). Tildeling av konkrete utviklingskontrakter skal skje med en fornyet konkurranse på den enkelte delleveranse. Dette forholdet, og at prosjektet ikke forplikter seg på kontrakter ut over dette, må fremgå tydelig av konkurransegrunnlaget.

20 5.3.3 Kontraktsinngåelse åpen del 1. PO, innleid konsulenthjelp 100 h Resultatmål: Minimum en eller tre avtaler skal inngås fra hvert av prosjektets anskaffelsesområder, design, publisering, kart og metadatakatalog. Avtalene skal inngås med de to tilbyderne som ut fra tildelingskriteriene er best skikket til å konkurrere om del-leveransene. Alle leverandører som får avtale på de fire utviklingsområdene (design, publisering, kart og metadatakatalog), skal inviteres til å gi tilbud på alle del-oppgaver innenfor utviklingsområdet. Dette gjelder uavhengig av om avtalene skal gjelde hele utviklingen, eller bare et av utviklingsområdene: Det skal være konkurranse på hver del-oppgave Kontraktstyring. PO 1500 h Resultatmål: Utviklingsarbeidet gjennomføres iht. kontrakt. Det er svært viktig at kontrakten med utviklingspartnerne inneholder bestemmelser som gjør det enkelt å korrigere kursen dersom vi ser at vi kommer skjevt ut. Valget av en iterativ systemutviklingsmodell med del-leveranser, og konkurranse på hver del-leveranse, gir maksimal fleksibilitet og minimal risiko. Men dette stiller krav til intern utviklingskompetanse og prosjektledelse, og kan gi utfordringer i forhold til ansvarsforhold og integrasjon av komponenter som er laget av forskjellige leverandører. Dette krever avklaringer i form av klart definerte (standard) grensesnitt mellom komponentene. Det er også et poeng at del-leveransene ikke er større enn at utviklingstiden er maks 4 uker. Dersom dette ikke er mulig, må kontraktene ha bestemmelser om rutinemessig rapportering, innsyn i framdrift og kvalitet og bestemmelser i forhold til terminering av kontrakten Utredning av driftsform. PO, innleid konsulenthjelp. 100 h Resultatmål: Den valgte driftsform skal gi best ytelse/pris-forhold, skalèrbarhet og sikkerhet. Aktiviteten skal utrede hvilke alternativ som finnes, basert på den plattformen systemet bygges på. Valg av drifts-løsning skal godkjennes av styringsgruppen. Det må vurderes spesielt hvilken betydning en eventuell integrasjon mellom den åpne og den lukka delen av BW vil ha i denne sammenhengen. Utviklingsmetoden som er valgt gjør det mulig å lansere deler av systemet på et tidlig stadium. Det vil derfor være en fordel at valg av drifts-løsning skjer når plattformvalgene er gjort. I praksis betyr det når anbudsrunden på første del-leveransen er gjennomført: Da er plattformvalget gjort Etablering av drifts-løsningen. PO 320 h

21 Resultatmål: Implementert valgt driftsløsning og opplæring gitt til det personell som skal drifte løsningen. Valg av driftsform vil legge føringer på innholdet i denne aktiviteten skal gjennomføres. I prinsippet har vi to ytterpunkter for drift: 1. Hele driften outsources 2. Hele driften gjøres internt i Kystverket Det vil måtte gjennomføres en anskaffelsesprosess i samsvar med Lov om offentlige anskaffelser. 5.4 Systemutvikling. PO, innleide konsulenter og samarbeidspartnere 2880 h Effektmål: Arbeidet gjennomføres i henhold til kravspesifikasjon og kontrakt Systemutviklingsplaner fra leverandører. PO, innleide konsulenter og samarbeidspartnere 2400 h Resultatmål: Underveis ferdige del-løsninger av systemet. Ved avslutning av prosjektet: En helhetlig løsning av BW. Systemutviklingsmetodikken tilsier at utviklingen vil foregå i flere faser. For hver fase vil det bli inngått kontrakter med leverandører. Som en del av kontraktene skal leverandørene etablere planer for gjennomføring av leveransene. Planene vil etter hvert implementeres i prosjektplanen. Planene fra leverandører skal omfatte utvikling og test av modulen Test av løsning (intern). PO og samarbeidspartnere 480 h Ingen Resultatmål: Den tekniske løsning for hele systemet og drift er testet ok. Det skal gjennomføres en fullskala test av hele systemet. Testen skal omfatte både test av funksjonelle krav og ikke funksjonelle krav. Grunnlaget for planlegging og gjennomføring av testen er en samlet kravspesifikasjon for hele systemet. 5.5 Sluttevaluering og rapportskriving. PO