•Formål med rikt bilde: etablere krav, forstå arkitektur og finne motstridende interesser
•Rikt bilde er uformelt – ikke et formelt UML-diagram
Universell utforming og WCAG
•WCAG = Web Content Accessibility Guidelines (W3C)
•4 prinsipper: Mulig a oppfatte, Mulig a betjene, Forstaelig, Robust
•12 retningslinjer fordelt pa de 4 prinsippene
•Nivaer: A (minimum), AA (norsk lovkrav), AAA (best)
•Likestillings- og diskrimineringsloven paragraf 18 -- krav om UU
•Digitaliseringsdirektoratet (Difi) er tilsynsorgan for UU i Norge
Personvern og GDPR
•
Vanlige feil å unngå
Interessenter og rikt bilde
•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 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.
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 ar. Lær de fire WCAG-prinsippene med eksempler og kjenn til norsk lovverk.
•Nar oppgaven ber deg diskutere konsekvenser av manglende UU, ta med bade konsekvenser for brukerne OG for utviklerne/organisasjonen.
•Bruk konkrete eksempler fra casen i oppgaven -- ikke generelle eksempler.
Personvern og GDPR
•GDPR-sporsmål kommer pa nesten alle eksamener. Lær de fire kravene til samtykke og de seks prinsippene for behandling.
•Nar du lager samtykkeskjema pa eksamen, bruk fiktive navn og inkluder ALLE nodvendige 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 vaert vedlagt som vedlegg pa eksamen (V2020). Oving pa a koble prinsippene til DevOps eller andre temaer.
GDPR = General Data Protection Regulation (EU 2016/679)
•Personopplysningsloven (2018) implementerer GDPR i Norge
•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)
•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.
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 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?
•Knytt testing til DevOps: automatiske tester i CI er en forutsetning for kontinuerlig levering.
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.