Risikoanalyse

En risikoanalyse identifiserer potensielle trusler mot prosjektet, vurderer hvor alvorlige de er, og planlegger forebyggende tiltak. Risikoanalyse gjennomføres tidlig i prosjektet og oppdateres jevnlig. Resultatet presenteres typisk som en usikkerhetsmatrise (risikomatrise) med kolonner for: risiko (beskrivelse av hva som kan ga galt), sannsynlighet (lav/middels/høy), konsekvens (lav/middels/høy), risikoscore (sannsynlighet x konsekvens), tiltak (hva gjøres for å redusere risikoen), og ansvarlig person (hvem følger opp tiltaket).

På eksamen V2020 ble du bedt om minst seks risikomomenter. Typiske risikomomenter i systemutviklingsprosjekter:

Kompetanserisiko: Vanskelig å få tak i nødvendig teknisk kompetanse. Tiltak: opplæring, konsulentbistand, outsourcing av spesialistoppgaver.
Estimeringsrisiko: Feil estimering av tid og kostnad fører til budsjettsprekk og forsinkelser. Tiltak: erfaringsbaserte estimater, planning poker, buffer på 20-30%.
Kravrisiko: Uklare, ufullstendige eller endrende krav. Tiltak: smidig utvikling med hyppige leveranser, prototyping for å avklare krav tidlig.
Teknologirisiko: Ny eller uprøvd teknologi som ikke fungerer som forventet. Tiltak: proof-of-concept tidlig i prosjektet, ha en fallback-løsning klar.
Sikkerhetsrisiko: Datainnbrudd, tap av personopplysninger, eller DDoS-angrep. Tiltak: kryptering, penetrasjonstesting, sikkerhetsgjennomgang, backup-rutiner.
Personellrisiko: Nøkkelpersoner slutter midt i prosjektet (bus factor). Tiltak: kunnskapsdeling gjennom parprogrammering og dokumentasjon, overlappeperioder.
Integrasjonsrisiko: Problemer med å integrere med tredjepartssystemer (betalingsleverandør, renseri-API). Tiltak: tidlig prototyp av integrasjon, avtale SLÅ med leverandorer.
Brukeradopsjonsrisiko: Brukerne tar ikke i bruk systemet. Tiltak: involvere brukere tidlig, brukertesting, gradvis utrulling.

Prosessmodeller

Viktige prosessmodeller i systemutvikling:

Fossefallsmodellen: Lineær modell med sekvensielle faser: krav -> design -> implementasjon -> testing -> vedlikehold. Hver fase må fullføres for den neste starter. Egner seg når kravene er godt kjent fra start og usannsynlig å endre seg (f.eks. innebygde systemer, sikkerhetskritiske systemer).
Inkrementell utvikling: Systemet bygges i inkrementer der hver leveranse legger til ny funksjonalitet. De viktigste funksjonene leveres først. Kombinerer struktur fra fossefall med fleksibilitet fra smidig.
Smidig utvikling: Iterativ tilnærming med korte sprinter (2-4 uker), tett kundesamarbeid og kontinuerlig tilpasning basert på tilbakemelding. Best når kravene er usikre, endrer seg ofte, eller når kunden er tilgjengelig for hyppig tilbakemelding.

Valg av prosessmodell avhenger av: kravstabilitet (stabile krav -> fossefall, ustabile -> smidig), prosjektstørrelse og kritikalitet (stort/kritisk -> mer struktur, lite -> smidig), kundetilgjengelighet (tilgjengelig -> smidig), og teamerfaring (erfaring med smidig -> smidig).

Testing

Testnivær i systemutvikling, i rekkefølge fra smalest til bredest scope:

Enhetstesting: Tester individuelle komponenter (funksjoner, klasser) isolert fra resten av systemet. Utføres av utviklere.
Integrasjonstesting: Tester grensesnittet mellom komponenter -- om de fungerer korrekt sammen. På eksamen V2017 ble dette testet som flervalg: 'Testing av grensesnittet til komponenter' er integrasjonstesting.
Systemtesting: Tester hele systemet som en helhet mot kravspesifikasjonen.
Akseptansetesting: Kunden eller sluttbrukeren tester om systemet oppfyller de opprinnelige kravene og er brukbart i praksis.

Prosess-samsvar (process conformance) betyr samsvar mellom den dokumenterte prosessmodellen og den reelle prosessen teamet faktisk følger. På eksamen V2017 ble dette testet: prosess-samsvar er 'samsvar mellom prosessmodell og reell prosess'.

Eksempel 1: Risikoanalyse for Festklar.no (V2020)

Risikomatrise med seks momenter: 1. Sikkerhetsbrudd i betalingsdata -- sannsynlighet: middels, konsekvens: høy, tiltak: PCI DSS-sertifisering og arlige penetrasjonstester, ansvarlig: sikkerhetsteam. 2. Forsinkelse i renseriintegrasjon -- sannsynlighet: høy, konsekvens: middels, tiltak: tidlig prototyp av API-integrasjon og fallback med manuell bestilling, ansvarlig: teknisk leder. 3. For få utleiere registrerer seg -- sannsynlighet: middels, konsekvens: høy, tiltak: markedsforingskampanje og attraktive vilkar for tidlige utleiere, ansvarlig: produkteier. 4. Høy belastning på populære datoer (17. mai, jul) -- sannsynlighet: høy, konsekvens: middels, tiltak: lastbalansering, caching og belastningstesting i forkant, ansvarlig: infrastrukturteam. 5. Tap av nøkkelpersonell -- sannsynlighet: lav, konsekvens: høy, tiltak: parprogrammering, dokumentasjon og kunnskapsdeling, ansvarlig: teamleder. 6. Endringer i GDPR-regulering -- sannsynlighet: lav, konsekvens: middels, tiltak: følge med på regelverksendringer og ha fleksibel arkitektur, ansvarlig: juridisk radgiver.

Eksempel 2: Valg av prosessmodell (V2020)

For utvikling av Festklar.no-nettsiden: Smidig utvikling (Scrum) er best egnet fordi: 1. Kravene er ikke fullt definert -- brukernes behov vil endres når de ser og tester prototyper av klesutleietjenesten. 2. Markedet for klesutleie er relativt nytt, sa man trenger hyppige tilbakemeldinger fra reelle brukere for å finne riktig produkt-market-fit. 3. Nettsiden kan bygges inkrementelt med tydelige leveranser: først søk og visning, sa bestilling og betaling, deretter kundeklubb og statistikk. 4. Festklar som organisasjon er liten og fleksibel, og produkteier er tilgjengelig for hyppige tilbakemeldinger. For vedlikehold og ny funksjonalitet etter lansering: Kanban egner seg bedre fordi oppgavene er varierende (feilretting, små forbedringer, større features), det er viktig med rask responstid, og det ikke er behov for faste sprinter.

Studieguide: Risikoanalyse og prosessmodeller