Last ned mal - Fjord Norway
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
© Copyright 2024