Prosess for systemutvikling i Difi. Versjon 1.0

Transkript

1 Prosess for systemutvikling i Difi Versjon 1.0 1

2 Innhald 1 INNLEIING SENTRALE OMGREP OG DEFINISJONAR DEFINISJON AV ROLLAR PROSESS FOR SYSTEMUTVIKLING Analyse og design Implementasjon Systemtest GODKJENNING VERSJONSKONTROLL... 7 Side 2 av 7

3 1 Innleiing Dette dokumentet beskriver IDU sin prosess for systemutvikling. Prosesseigar er seksjonsleiar for SSU. Han er ansvarleg for at prosessen er tilpassa Difi og brukarane sine behov og at den blir etterlevd og revidert. 1.1 Sentrale omgrep og definisjonar Begrep Definisjon Kommentar Utviklingsplan Prioritert liste over hoved- og delfunksjonalitet fordelt utover neste 12 måneder. Spesifisert på leveranse-nivå Leveranserapport Leveranserapporten omfattar systemtestrapport og utviklingsleiar sin godkjenning av denne. Brukarhistorie Løysing Ein brukarhistorie ein ein kort tekstlig beskrivelse av ein eigenskap / behov ved løysinga sett frå ein gitt brukar(rolle) sin ståstad. Brukarhistorien representerer eitt spesifikt krav til løysinga. Det aktuelle produktet i leveransen. Kan være eit nytt system eller endringar i eksisterande system. 1.2 Definisjon av rollar Begrep Definisjon Kommentar Utviklingsleiar Ansvarleg for utviklingsarbeidet og systemarkitekturen for det aktuelle produktet. Er Utviklingsleiar har også eit overordna ansvar for ansvarlig for å godkjenne bestillingar, systemtest sikkerheit, både i forhold til prosess og produkt. og leveransar. Testleiar Bestillar Teamleiar Utviklar Ansvarlig for å planlegge og gjennomføre systemtest og tilhøyrande aktivitetar. Den som bestiller endringar. Ansvarlig for å utarbeide utviklingsplan og tilhøyrande krav. Ansvarlig for organiseringen av utviklingsarbeidet. Er ansvarlig for å fasilitere arbeidet som blir utført. Utviklar er ansvarlig for å implementere dei definerte endringane. Deltar både i arbeid med løysingsarkitektur og implementasjon. Når Scrum blir nytta som arbeidsmetodikk fungerer ofte teamleiar også som scrum-master Side 3 av 7

4 2 Prosess for systemutvikling Figuren under viser korleis arbeidsflyten ser ut på eit overordna nivå og forklarer kva som må gjerast. Der det er behov for det utarbeidast det prosedyrar der det står korleis dette skal gjerast på eit detaljert nivå. Dei ulike aktivitetane til rollene i prosessen blir forklart i eigen tabell. Det er viktig å merke seg at denne prosessen er uavhengig av valgt arbeidsmetodikk (t.d. scrum), og aktivitetane som er definert her vil gjerne utførast i fleire iterasjonar. Figur 1 Flytdiagram Prosessen består av 3 ulike faser: «Analyse og design» - Aktivitetar knytta til detaljering av krav og utarbeiding av løysingsarkitektur. Denne fasen krev tett samarbeid mellom bestillar og utviklingsteamet. «Implementasjon» - Aktivitetar knytta til implementasjon av den føreslegne løysingsarkitekturen. «Systemtest» - Aktivitetar knytt til å verifisere at den implementerte løysinga møter dei krava som bestillar har satt, og at den møter dei kvalitetsmessige krava som er forventa. Denne prosessen har tette grenseflater opp mot andre prosessar i IDU. Dei viktigaste der vil vere «endringsstyringsprosessen» og «prosess for styring av produksjonssetting» Endringsstyringsprossessen vil vere den prosessen som initierer oppstart av systemutviklingsarbeidet. Frå denne prosessen vil utviklingsplanen vere input til systemutviklingsprosessen. Den ferdig systemtesta leveransen vil så gå tilbake til ein akseptansetest-fase i endringsstyringsprosessen. Prosess for styring av produksjonssetting vil omhandle korleis aksepterte leveransar skal settast i produksjon. Side 4 av 7

5 2.1.1 Analyse og design Tabellen under forklarer aktivitetane. Det er lagt inn referanse til andre dokument. Aktivitet Forklaring Dokument/referanse Lage brukarhistoriar Med utgangspunkt i dei forretningsmessige krava frå bestillar blir det utarbeid brukarhistoriar som representerer dei endelige krava til løysinga. Brukarhistoriane skal ha definerte akseptanse-kriterier. Ansvarleg: Bestillar Utarbeide overordna systemarkitektur ny / revidert systemarkitektur for løysinga.. Viss nøvdvendig må brukarhistoriane oppdaterast. Utarbeide datamodeller nye / revidert logiske datamodellar for løysinga der dette er relevant. Viss nøvdvendig må brukarhistoriane oppdaterast. Utarbeide sikkerhetsarkitektur ny/ revidert sikkerhetsarkitektur for løysinga der dette er relevant. Involvere intern sikkerheit. Viss nøvdvendig må brukarhistoriane oppdaterast Definere Interne og eksterne grensesnitt nye eller endra grensesnitt der det er nødvendig. Viss nøvdvendig må brukarhistoriane oppdaterast. Brukargrensesnitt Med utgangspunkt i brukerhistoriane skal det vurderast om det må lages nye brukargrensesnitt eller endre eksisterande. Ved større endringar vil ekstern interaksjonsdesign involverast. Vurdering av produkt/rammeverk Brukarhistoriane oppdaterast om nødvendig. Ansvarleg: Bestillar, med bidrag frå utviklingsleiar Med utgangspunkt i den føreslegne systemarkitekturen skal det vurderast om nye produkt/rammeverk skal innførast i løysinga. Mal for vurdering av nye produkt / rammeverk. 5

6 Prosess for systemutvikling i Difi Versjon: 1.0 Dato: Implementasjon Tabellen under forklarer aktivitetane. Det er lagt inn referanse til andre dokument. Aktivitet Forklaring Dokument/referanse Bryte ned brukarhistoriar til implementasjonsoppgåver Implementasjon i henhold til kodestandard Kodegjennomgang Dei ulike brukerhistoriane må brytast ned i dei konkrete oppgåvene som gjennomførast for å realisere brukarhistorien., teamleiar Dei definerte oppgåvene skal utførast i henhold til kodestandard for det aktuelle produktet. Enhetstesting inngår som ein naturlig del av denne aktiviteten. Ansvarleg: Utviklarar Alle implementerte endringar skal gjennomgås i henhold til prosedyre for code review. Ansvarleg: Utviklarar Mal for detaljering av oppgåver Krav til kodestandard for aktuelt produkt Krav til enhetstesting frå master testplan Prosedyre for code review Systemtest Tabellen under forklarer aktivitetane. Det er lagt inn referanse til andre dokument. Aktivitet Forklaring Dokument/referanse produktrisikoanalyse Utarbeide testplan funksjonell testing ytelsestesting sikkerhetstesting Godkjenning av testog leveranserapport Produktrisikoanalyse for leveransen skal gjennomførast i henhold til master testplan for det aktuelle produktet. Testplan for leveransen skal utarbeides iht. master testplan. funksjonell testing i henhold til testplan ytelsestesting i henhold til testplan og ytelsesteststrategi Ved gjennomføring av PRA vil ein vurdere den sikkerhetsmessige effekten av kvar endring. Dette dannar grunnlaget for å beslutte om det skal utførast sikkerhetstest av leveransen. Utviklingsleiar er ansvarlig for å godkjenne gjennomføringa av test Ytelsesteststrategi Mal for leveranserapport Difi Side 6 av 7 Utskriftsdato:

7 Prosess for systemutvikling i Difi Versjon: 1.0 Dato: Godkjenning Prosessbeskrivelsen sendast til godkjenning gjennom P360. Prosessbeskrivelsen godkjennast av avdelingsdirektør IDU. 3 Versjonskontroll Versjon Dato Initiert av Endringsårsak juni 2016 Kristine Håland Prosess lagt fram for og godkjent av leiargruppe IDU. Difi Side 7 av 7 Utskriftsdato: