FjordNett Governance & Dokumentasjon. 1) GOVERNANCE.

Presentasjon om: "FjordNett Governance & Dokumentasjon. 1) GOVERNANCE."— Utskrift av presentasjonen:

1 FjordNett Governance & Dokumentasjon

2 1) GOVERNANCE

3 Formål Definere klare ansvarsområder for de forskjellige styringsgruppene og råd i Fjordnett-plattformen. Definere klare prosesser for vedlikehold og utvikling. Sikre kommunikasjon mellom partnere og kvalitetsnivå av rammeverket. Danne grunnlag for et årshjul ihht det som er definert i avtalene Governance skal være fleksibel nok til å ta imot flere regionale løsninger.

4 Grunnlag Disse avtalene danner grunnlaget for FjordNett Governance: –«Kontrakt Destinasjons- og landsdelsportal i Epi server», felles portalrammeverk / CMS for Fjord Norge og Destinasjonsselskaper i Fjord Norge regionen v. 1.0  mellom FN og destinasjonene i FN regionen –«Samarbeidsavtale om bruk av publiseringsrammeverket til FjordNett og felles teknologiutvikling»  mellom FN og VisitOslo –«Vedlikeholdsavtale Nye FjordNorge.no»  mellom FN og Reaktor

5 Prinsippet FNR FNL FjordNett Rammeverket Eier: Fjord Norge AS. Har strategisk ansvar for videreutvikling av rammeverket. Distribusjonsrett (med unntak). FjordNett Løsning Lisensiert FNR løsning. Har egenstendig redaksjons- og utviklingsansvar. Har egenstendig forvaltningsorganisasjon. Har ansvar å koordinere utvikling mot FNR. FN VO

6 Organisasjonsmodell FNR FNL FNL-FN Referanse- gruppe Prosjekt- gruppe Prioriteringsråd Strategiråd InternettForumNCE Tourism FNL-.. Egen organisasjon FNL-VO Egen organisasjon Prosjekt- gruppe Prosjekt- gruppe

7 FNR Mandat - FNR Eier Medlemmer Mandat Hyppighet Strategiråd FN AS (Adm. Dir.) FNL Representant(er?) Reaktor NCE Tourism Strategisk videreutvikling Rammebetingelser Årlig evaluering Årlig (oktober) Prioriteringsråd FN AS (Adm. Dir.) FNL Representant(er?) Reaktor NCE Tourism Koordinasjon utviklingsønsker, inkl. finansiering Godkjenning utviklingsplan Halvårlig (hyppigere etter behov)

8 FNL-FN Eier Medlemmer Mandat Hyppighet Mandat – FNL-FN InternettForum FN AS (Adm. Dir.) Deltakere i løsningen (med møte- og stemme- rett) NCE Tourism Valg av referansegruppe Diskusjon erfaringer og videre utvikling Årlig (juni) Referansegruppe FN AS (Adm. Dir.) FNL-FN prosjektleder 4 Destinasjons- representanter NCE Tourism Prioriterer utviklings- tiltak / product backlog Definisjon av felles UI- elementer Oppdragsgiver mot FNL-FN prosjektleder Kvartalsvis

9 FNL-FN Eier Medlemmer Mandat Hyppighet Mandat – FNL-FN Prosjektgruppe Bestilleransvarlig 1) FNL-FN prosjektleder Reaktor Bestiller Videre medlemmer etter behov Gjennomfører prosjektet på vegne prioriterings- råd Spekk Nivå 2; Utvikling; Test/Aksept; Prod. / Lansering 2) Etter behov. NCE Tourism PL Teknologi & Nye Medier NCE Tourism partnerskap Nyutvikling basert på partnerskapets ønsker Kompetansetiltak - 1)Det er prioriteringsrådet som bestemmer «Bestilleransvarlig». 2)Se «Utviklingsprosess – FNL-FN».

10 Dev FNL-FN FNR Årshjul Kvartal 1Kvartal 2Kvartal 3Kvartal 4 JanFeb Mar AprMai Jun JulAug Sep OktNov Des Strategiråd Prioriteringsråd Referansegruppe InternettForum Release 2-yyyyRelease 3-yyyyRelease 4-yyyy 1-yyyyRelease Referansegruppe

11 Henvisning / Verktøy Hvem Nivå Hva Utviklingsprosess – FNL-FN Behov / Idé Spekk Nivå 1 Priori- tering Spekk Nivå 2 Utviklings- plan Utvikling Test / Aksept Prod. / Lansering Identifisering behov / idé Destinasjoner FNR / NCET Andre Brukerforum E-Post Diskusjon Prioritering av ønsket Referanse- gruppe Beskrivelse av ønsket og vurdering Beskrivelse: søker Vurdering: Reaktor Skjema / Mal Størrelse- vurdering Spesifikasjon av ønsket og timeestimat Prosjekt- gruppe Spekk-Mal Timeestimat Endelig prioritering og utviklingsplan Prioriterings- råd Overføring fra PBL til DBL Utviklings- arbeid Reaktor User Acceptance Testing Prosjekt- gruppe Lansering Reaktor Prosjekt- gruppe Release Notes Dokumen- tasjon FNLFNRFNL FNR FNL Product Backlog (PBL)Development Backlog (DBL)

12 2) KRAV TIL DOKUMENTASJON

13 Bestilling og kravspesifikasjon Detaljeringsgraden i bestillingsgrunnlaget og nøyaktigheten i estimatene øker utover i utviklingsprosessen: –Behov/idé: Beskrivelsen må være god nok til at de andre destinasjonsselskapene forstår behovet/idéen. Ingen estimater på dette tidspunktet. –Spekk Nivå 1: Beskrivelsen må være god nok til å gjøre grovestimat og få oversikt over forutsetninger og berørte systemer/komponenter. Eget skjema. Skisser og prototyping etter behov. Grovestimater – gjerne intervall med tilhørende forutsetninger. –Spekk Nivå 2: Beskrivelse god nok til implementering. Detaljert kravspesifikasjon med berørte felter og use-case. Visuelle skisser og/eller klikkbar prototyp. Brukertesting av prototyp etter behov. Detaljerte estimater. Behov / Idé Spekk Nivå 1 Priori- tering Spekk Nivå 2 Utviklings- plan

14 Brukerdokumentasjon og opplæring Omfanget av brukerdokumentasjonen øker utover i utviklingsprosessen: –Utviklingsplan: Oppdatert beskrivelse med evt endringer eller spesifiseringer fra prioriteringsrådet. –Utvikling: Use-cases –Test/aksept: Test-cases –Prod./lansering: Brukerdokumentasjon basert på test-cases. Grunnlag for opplæring og lanseringsmelding. Oppdragsgiver ansvar for dokumentasjonen igjennom hele utviklingsprosessen. Utviklings- plan Utvikling Test / Aksept Prod. / Lansering