FjordNett
Governance & Dokumentasjon
1) GOVERNANCE
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.
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
Prinsippet
FNR
FjordNett Rammeverket
•
•
•
FNL
FN
Eier: Fjord Norge AS.
Har strategisk ansvar for videreutvikling av
rammeverket.
Distribusjonsrett (med unntak).
FjordNett Løsning
VO
•
•
•
•
Lisensiert FNR løsning.
Har egenstendig redaksjons- og utviklingsansvar.
Har egenstendig forvaltningsorganisasjon.
Har ansvar å koordinere utvikling mot FNR.
Organisasjonsmodell
FNR
Strategiråd
Prioriteringsråd
Referansegruppe
Prosjektgruppe
FNL-FN
InternettForum
NCE Tourism
FNL
Prosjektgruppe
FNL-VO
Prosjektgruppe
FNL-..
Mandat - FNR
FNR
Strategiråd
Prioriteringsråd
Eier
FN AS (Adm. Dir.)
FN AS (Adm. Dir.)
Medlemmer
• FNL Representant(er?)
• Reaktor
• NCE Tourism
• FNL Representant(er?)
• Reaktor
• NCE Tourism
Mandat
• Strategisk
videreutvikling
• Rammebetingelser
• Årlig evaluering
• Koordinasjon
utviklingsønsker, inkl.
finansiering
• Godkjenning
utviklingsplan
Hyppighet
Årlig (oktober)
Halvårlig (hyppigere etter behov)
Mandat – FNL-FN
FNL-FN
InternettForum
Referansegruppe
Eier
FN AS (Adm. Dir.)
FN AS (Adm. Dir.)
Medlemmer
• Deltakere i løsningen
(med møte- og stemmerett)
• NCE Tourism
• FNL-FN prosjektleder
• 4 Destinasjonsrepresentanter
• NCE Tourism
Mandat
• Valg av referansegruppe
• Diskusjon erfaringer og
videre utvikling
• Prioriterer utviklingstiltak / product backlog
• Definisjon av felles UIelementer
• Oppdragsgiver mot
FNL-FN prosjektleder
Hyppighet
Årlig (juni)
Kvartalsvis
Mandat – FNL-FN
FNL-FN
Prosjektgruppe
NCE Tourism
Eier
Bestilleransvarlig 1)
PL Teknologi & Nye Medier
Medlemmer
•
•
•
•
• NCE Tourism
partnerskap
Mandat
• Gjennomfører prosjektet
på vegne prioriteringsråd
• Spekk Nivå 2; Utvikling;
Test/Aksept; Prod. /
Lansering 2)
• Nyutvikling basert på
partnerskapets ønsker
• Kompetansetiltak
Hyppighet
Etter behov.
-
FNL-FN prosjektleder
Reaktor
Bestiller
Videre medlemmer etter
behov
1) Det er prioriteringsrådet som bestemmer «Bestilleransvarlig».
2) Se «Utviklingsprosess – FNL-FN».
Årshjul
Dev
1-yyyy
Release 2-yyyy
Release 3-yyyy
Release
Release 4-yyyy
FNR
Strategiråd
Prioriteringsråd
Prioriteringsråd
FNL-FN
InternettForum
Referansegruppe
Jan
Feb
Kvartal 1
Mar
Apr
Referansegruppe
Mai
Kvartal 2
Jun
Jul
Referansegruppe
Aug
Kvartal 3
Sep
Okt
Referansegruppe
Nov
Kvartal 4
Des
Utviklingsprosess – FNL-FN
Behov /
Idé
Spekk
Nivå 1
Prioritering
Spekk
Nivå 2
Utviklingsplan
Utvikling
Test /
Aksept
Prod. /
Lansering
Nivå
FNL
FNL
FNL
FNL
FNR
FNR
FNR
FNL
Hva
Identifisering
behov / idé
Beskrivelse av
ønsket og
vurdering
Prioritering av
ønsket
Spesifikasjon
av ønsket og
timeestimat
Endelig
prioritering og
utviklingsplan
Utviklingsarbeid
User
Acceptance
Testing
Lansering
Hvem
• Destinasjoner • Beskrivelse:
• FNR / NCET
søker
• Andre
• Vurdering:
Reaktor
• Referansegruppe
• Prosjektgruppe
• Prioriteringsråd
• Reaktor
• Prosjektgruppe
• Reaktor
• Prosjektgruppe
• Spekk-Mal
• Timeestimat
• Overføring
fra PBL til
DBL
Henvisning /
Verktøy
• Brukerforum • Skjema / Mal
• E-Post
• Størrelse• Diskusjon
vurdering
Product Backlog (PBL)
Development Backlog (DBL)
• Release
Notes
• Dokumentasjon
2) KRAV TIL DOKUMENTASJON
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
Prioritering
Spekk
Nivå 2
Utviklingsplan
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.
Utviklingsplan
Utvikling
Test /
Aksept
Prod. /
Lansering