•Autentisering = hvem er du? Autorisasjon = hva har du lov til?
•Sikkerhetskrav er typisk ikke-funksjonelle krav (produktkrav/eksterne krav)
•Kryptering: TLS (data i transitt), AES/bcrypt (data i ro)
•Hemmelig valg: usett (privat stemmegiving) + anonym (alle spor slettes)
Vanlige feil å unngå
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 a koble til konkrete WCAG-prinsipper eller retningslinjer.
•Glemme at WCAG gjelder for mobilapper ogsa, ikke bare nettsider.
•Tro at automatiserte testverktoy fanger opp alle tilgjengelighetsproblemer -- manuell testing og brukertesting er ogsa nodvendig.
Personvern og GDPR
•Forveksle behandlingsansvarlig og databehandler. Behandlingsansvarlig BESTEMMER formalet, databehandler UTFORER behandlingen.
•Glemme at samtykke ma vaere en AKTIV handling. Forhandsavkryssede bokser er ikke gyldig samtykke.
•Tro at GDPR kun gjelder private bedrifter. Den gjelder ogsa offentlige virksomheter.
•Skrive et samtykkeskjema uten a nevne formal, ansvarlig, lagringstid eller retten til a 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-motet skal vaere kort (maks 15 min) og at hvert teammedlem svarer pa tre sporsmål: Hva gjorde jeg i gar? Hva gjor 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 ma vaere med.
•Blande funksjonelle og ikke-funksjonelle krav. 'Systemet skal ha sok' er funksjonelt, 'sok skal svare innen 2 sek' er ikke-funksjonelt.
•Sette opp ikke-funksjonelle krav som IKKE er testbare. 'Systemet skal vaere brukervennlig' er for vagt.
•Glemme sekundaere aktorer. Systemadministratorer, tilsynsmyndigheter og betalingstjenester er typiske sekundaere aktorer.
UML-modellering
•Glemme alternativ flyt i use case-beskrivelsen. Eksamen ber ALLTID om minst en alternativ flyt.
•Tegne sekvensdiagram uten returnpiler (stiplede). Alle meldinger bor ha en returverdi.
•Mangle multiplisitet pa assosiasjoner i klassediagrammet. Skriv tall/stjerne i BEGGE ender.
•Forveksle aktorer og use cases. En aktor 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 verktoy. DevOps er ogsa en KULTURENDRING der Dev og Ops samarbeider.
•Forveksle branching og merging. Branching = opprette ny gren. Merging = flette grener sammen.
•Glemme a nevne tester som en sentral del av CI/CD-pipelinen. Automatiserte tester er fundamentet for alt.
Brukerundersokelser og datainnsamling
•Glemme at pilotundersokelsen er en TEST av metoden, ikke en del av selve datainnsamlingen.
•Forveksle tidsaksen i Suchmans tabell -- den gar VERTIKALT (ovenfra og ned), ikke horisontalt.
•Ikke tenke pa etiske utfordringer ved brukerundersokelser med sarbare grupper (eldre, barn, syke).
•Lage et samtykkeskjema som mangler formalet med undersokelsen eller retten til a trekke seg.
Risikoanalyse og prosessmodeller
•Lage en risikomatrise uten tiltak. Eksamen ber ALLTID om bade risiko OG tiltak.
•Forveksle testniva. Integrasjonstesting tester GRENSESNITTET mellom komponenter, ikke enkeltkomponenter.
•Argumentere for kun en prosessmodell uten a diskutere alternativer. Vis at du forstar avveiningen.
•Glemme 'ansvarlig'-kolonnen i risikomatrisen. Hvem folger opp tiltaket?
•Vis at du forstar forskjellen mellom CI, CD og Continuous Deployment -- dette er et vanlig flervalgs-/diskusjonstema.
Brukerundersokelser og datainnsamling
•Brukerundersokelser har vaert en del av eksamen fra V2017 (INF1055). Lær de ulike metodene og nar de passer.
•Nar oppgaven ber om risikoer ved en brukerundersokelse, tenk pa bade 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.
•Nar du argumenterer for prosessmodell, bruk konkrete egenskaper ved casen (kravstabilitet, kundekontakt, prosjektstorrelse).
•Flervalgsporsmål om testnivaer og prosess-samsvar er vanlige. Lær definisjonene nøyaktig.
Sikkerhet og etikk
•Sikkerhet testes ofte som en del av den store casen. Tenk pa hvilke sikkerhetsrisikoer som er spesifikke for det aktuelle systemet.
•Nar oppgaven ber deg diskutere motstridende krav (f.eks. anonymitet vs. revisjon), vis at du forstar BEGGE sider og foreslå en losning.
•Referere til konkrete lover og standarder styrker besvarelsen. GDPR for personvern, WCAG for tilgjengelighet.