•Forveksle rikt bilde med et UML-diagram – et rikt bilde er bevisst uformelt og «rotete».
•Glemme concerns – uten å vise hva interessentene bryr seg om mister man motstridende interesser.
•Liste bare sluttbrukere – husk indirekte interessenter som ledelse, drift, myndigheter og berørte tredjeparter.
•Blande sammen interessent og aktør – alle aktører er interessenter, men ikke omvendt.
Universell utforming og WCAG
•Forveksle WCAG (tilgjengelighetsstandard) med GDPR (personvern). Begge er viktige i IN1030, men dekker helt ulike omrader.
•Svare for generelt om universell utforming uten å koble til konkrete WCAG-prinsipper eller retningslinjer.
•Glemme at WCAG gjelder for mobilapper også, ikke bare nettsider.
•Tro at automatiserte testverktoy fanger opp alle tilgjengelighetsproblemer -- manuell testing og brukertesting er også nødvendig.
Personvern og GDPR
•Forveksle behandlingsansvarlig og databehandler. Behandlingsansvarlig BESTEMMER formålet, databehandler UTFØRER behandlingen.
•Glemme at samtykke må være en AKTIV handling. Forhandsavkryssede bokser er ikke gyldig samtykke.
•Tro at GDPR kun gjelder private bedrifter. Den gjelder også offentlige virksomheter.
•Skrive et samtykkeskjema uten å nevne formål, ansvarlig, lagringstid eller retten til å trekke samtykke.
Smidige metoder: Scrum og Kanban
•Forveksle Scrum Master og Produkteier. PO bestemmer HVA som skal bygges, Scrum Master sikrer at PROSESSEN fungerer.
•Tro at Kanban har sprinter -- Kanban bruker kontinuerlig flyt uten faste iterasjoner.
•Glemme at stand-up-møtet skal være kort (maks 15 min) og at hvert teammedlem svarer på tre sporsmål: Hva gjorde jeg i går? Hva gjør jeg i dag? Hva hindrer meg?
•Forveksle verifisering og validering. Verifisering = bygger vi produktet riktig (teknisk korrekt). Validering = bygger vi riktig produkt (oppfyller brukerens behov).
Kravspesifikasjon og brukerhistorier
•Skrive brukerhistorier uten alle tre delene (rolle, funksjonalitet, nytte). Alle tre må være med.
•Blande funksjonelle og ikke-funksjonelle krav. 'Systemet skal ha søk' er funksjonelt, 'søk skal svare innen 2 sek' er ikke-funksjonelt.
•Sette opp ikke-funksjonelle krav som IKKE er testbare. 'Systemet skal være brukervennlig' er for vagt.
•Glemme sekundære aktører. Systemadministratorer, tilsynsmyndigheter og betalingstjenester er typiske sekundære aktører.
UML-modellering
•Glemme alternativ flyt i use case-beskrivelsen. Eksamen ber ALLTID om minst en alternativ flyt.
•Tegne sekvensdiagram uten returnpiler (stiplede). Alle meldinger bør ha en returverdi.
•Mangle multiplisitet på assosiasjoner i klassediagrammet. Skriv tall/stjerne i BEGGE ender.
•Forveksle aktører og use cases. En aktør er UTENFOR systemet og initierer interaksjon, et use case er funksjonalitet INNE i systemet.
DevOps og CI/CD
•Forveksle Continuous Delivery og Continuous Deployment. Delivery = KAN deployes (manuell godkjenning). Deployment = deployes AUTOMATISK.
•Tro at DevOps bare handler om verktøy. DevOps er også en KULTURENDRING der Dev og Ops samarbeider.
•Forveksle branching og merging. Branching = opprette ny gren. Merging = flette grener sammen.
•Glemme å nevne tester som en sentral del av CI/CD-pipelinen. Automatiserte tester er fundamentet for alt.
Testing og kvalitet
•Bytte om verifisering og validering – verifisering er mot spesifikasjon, validering mot brukerbehov.
•Tro at integrasjonstesting tester intern logikk – den tester grensesnitt/samspill mellom komponenter.
•Tro at testing kan bevise at systemet er feilfritt – den kan bare påvise at feil finnes.
•Legge all testing til slutt i prosjektet i stedet for løpende i CI-pipelinen.
Brukerundersokelser og datainnsamling
•Glemme at pilotundersokelsen er en TEST av metoden, ikke en del av selve datainnsamlingen.
•Forveksle tidsaksen i Suchmans tabell -- den går VERTIKALT (ovenfra og ned), ikke horisontalt.
•Ikke tenke på etiske utfordringer ved brukerundersokelser med sårbare grupper (eldre, barn, syke).
•Lage et samtykkeskjema som mangler formålet med undersokelsen eller retten til å trekke seg.
Risikoanalyse og prosessmodeller
•Lage en risikomatrise uten tiltak. Eksamen ber ALLTID om både risiko OG tiltak.
•Forveksle testnivå. Integrasjonstesting tester GRENSESNITTET mellom komponenter, ikke enkeltkomponenter.
•Argumentere for kun en prosessmodell uten å diskutere alternativer. Vis at du forstår avveiningen.
•Glemme 'ansvarlig'-kolonnen i risikomatrisen. Hvem følger opp tiltaket?
•Glemme at sikkerhet og brukervennlighet ofte står i konflikt -- diskuter denne avveiningen.
•Tro at kryptering løser alle sikkerhetsproblemer. Sosial manipulering, fysisk tilgang og sarbar kode er også trusler.
•Ikke koble sikkerhetsdiskusjonen til konkrete eksempler fra casen i oppgaven.
Eksamenstips
Interessenter og rikt bilde
•Når oppgaven ber om «minst fem/seks interessenter», ta med både primære, sekundære og indirekte interessenter og gi hver en konkret rolle og interesse.
•Marker minst én konflikt i det rike bildet – sensor ser etter at du forstår motstridende interesser.
•Begrunn alltid hvorfor en aktør er primær eller sekundær (hvem starter samhandlingen?).
Universell utforming og WCAG
•UU-sporsmål kommer HVERT år. Lær de fire WCAG-prinsippene med eksempler og kjenn til norsk lovverk.
•Når oppgaven ber deg diskutere konsekvenser av manglende UU, ta med både konsekvenser for brukerne OG for utviklerne/organisasjonen.
•Bruk konkrete eksempler fra casen i oppgaven -- ikke generelle eksempler.
Personvern og GDPR
•GDPR-sporsmål kommer på nesten alle eksamener. Lær de fire kravene til samtykke og de seks prinsippene for behandling.
•Når du lager samtykkeskjema på eksamen, bruk fiktive navn og inkluder ALLE nødvendige elementer systematisk.
•Koble GDPR til casen i oppgaven -- diskuter hvilke personopplysninger som er relevante for det spesifikke systemet.
Smidige metoder: Scrum og Kanban
•De 12 smidige prinsippene har vært vedlagt som vedlegg på eksamen (V2020). Oving på å koble prinsippene til DevOps eller andre temaer.
•Diskusjonsoppgaver om teamarbeid krever at du argumenterer for OG mot -- vis nyanse, ikke bare en side.
•Flervalgsporsmål om Scrum vs. Kanban er vanlige. Lær forskjellene godt.
Kravspesifikasjon og brukerhistorier
•Eksamen ber typisk om MINST seks brukerhistorier med minst tre forskjellige aktører. Forbered deg på å finne mange roller i casen.
•For ikke-funksjonelle krav: ha med minst ett krav av HVER type (produkt, organisatorisk, eksternt) og forklar hvordan det kan testes.
•Prioriter brukerhistoriene -- sett de viktigste først og begrunn kort.
UML-modellering
•UML-modellering utgjor 30-45% av eksamen. Oving på å tegne alle fire diagramtyper for hånd.
•Les casen GRUNDIG for du begynner å modellere. Understrek nøkkelord som aktører, handlinger og data.
•Start med use case-diagrammet -- det gir deg oversikt over systemets funksjonalitet som du kan bruke i de andre diagrammene.
•På eksamen kan du bruke digital handtegning for modelleringsoppgavene. Tegn tydelig og bruk riktig UML-notasjon.
DevOps og CI/CD
•DevOps-sporsmål ber ofte om å koble til smidige prinsipper. Ha tre gode eksempler klare med begrunnelse.
•Knytt testing til DevOps: automatiske tester i CI er en forutsetning for kontinuerlig levering.
Brukerundersokelser og datainnsamling
•Brukerundersokelser har vært en del av eksamen fra V2017 (INF1055). Lær de ulike metodene og når de passer.
•Når oppgaven ber om risikoer ved en brukerundersokelse, tenk på både praktiske (rekruttering, teknologi) og etiske (samtykke, sårbare grupper) utfordringer.
•Suchmans tabell-sporsmålet (tidsakse vertikalt) er et flervalgs-klassiker.
Risikoanalyse og prosessmodeller
•Eksamen V2020 ba om MINST SEKS risikomomenter. Ha en liste med vanlige risikoer klar i hodet.
•Når du argumenterer for prosessmodell, bruk konkrete egenskaper ved casen (kravstabilitet, kundekontakt, prosjektstørrelse).
•Flervalgsporsmål om testnivær og prosess-samsvar er vanlige. Lær definisjonene nøyaktig.
Sikkerhet og etikk
•Sikkerhet testes ofte som en del av den store casen. Tenk på hvilke sikkerhetsrisikoer som er spesifikke for det aktuelle systemet.
•Når oppgaven ber deg diskutere motstridende krav (f.eks. anonymitet vs. revisjon), vis at du forstår BEGGE sider og foreslå en løsning.
•Referere til konkrete lover og standarder styrker besvarelsen. GDPR for personvern, WCAG for tilgjengelighet.