Komplett pensumoversikt for systemer, krav og konsekvenser ved UiO — med forklaringer, sentrale begreper, eksamenstips og vanlige fallgruver. Eksamensoptimalisert basert på tidligere eksamener.
Innhold
IN1030 Systemutvikling (tidligere INF1055) er et sentralt kurs ved Institutt for informatikk, UiO. Kurset dekker hele livssyklusen til et IT-system -- fra brukerundersokelser og kravspesifikasjon til modellering, utvikling og vedlikehold. Eksamen er en 4-timers skriftlig prove uten hjelpemidler.
Eksamen har typisk to hoveddeler: Del 1 består av flervalgssporsmål og korte diskusjonssporsmål om teori (GDPR, universell utforming, smidige metoder, DevOps). Del 2 er en stor case-oppgave der du får en systembeskrivelse og skal identifisere interessenter, skrive brukerhistorier og kravspesifikasjon, og lage UML-diagrammer (use case, sekvens, klasse, aktivitet). Case-oppgaven utgjor typisk 30-45% av eksamen.
Kurset kombinerer tekniske ferdigheter (UML-modellering, DevOps, versjonskontroll) med samfunnsmessige temaer (personvern, universell utforming, etikk). Du må kunne diskutere lover og retningslinjer, men også tegne presise diagrammer. Les hele oppgavesettet for du begynner, og gjør egne forutsetninger dersom noe er uklart -- oppgaveteksten sier eksplisitt at dette er tillatt.
Identifisering av interessenter (stakeholders) og aktører, skillet mellom primære og sekundære aktører, og bruk av rikt bilde (rich picture) for å kartlegge interesser, relasjoner og konflikter tidlig i systemutviklingen. Fast del av case-oppgaven på eksamen.
En interessent (engelsk: stakeholder) er en person, gruppe eller organisasjon som har en interesse i, påvirker eller blir påvirket av et system. Når man utvikler et IT-system er det avgjørende å identifisere alle interessentene tidlig, fordi de har ulike – og ofte motstridende – behov og interesser. Eksempler på interessenter er sluttbrukere, kunder, ledelse, utviklere, drift, myndigheter, og personer som indirekte berøres av systemet.
I systemutvikling skiller vi mellom aktører som samhandler med systemet:
En aktør er alltid en interessent, men ikke alle interessenter er aktører – ledelsen kan ha sterke interesser i systemet uten å samhandle direkte med det.
Et rikt bilde er en uformell, visuell kartleggingsteknikk som brukes tidlig i systemutviklingen for å skape felles forståelse av en problematisk situasjon. Teknikken stammer fra Soft Systems Methodology (Checkland). Et rikt bilde tegnes for hånd eller i et tegneverktøy og inneholder:
Hensikten er ikke å lage et presist eller formelt diagram, men å fange kompleksiteten og det «rotete» i en virkelig situasjon. Det viktigste er å tydeliggjøre antagelsene man gjør og å få fram potensielle konflikter.
Et rikt bilde brukes i en systemutviklingsprosess for å etablere krav og forstå arkitekturen, og for å identifisere motstridende interesser mellom interessentene. Ved å inkludere concerns tvinges man til å tenke gjennom hva hver interessent faktisk bryr seg om, slik at krav ikke blir oversett. Det er et godt kommunikasjonsverktøy mellom utviklere og oppdragsgiver, og danner grunnlag for senere kravspesifikasjon og use case-modellering.
For et system for elektronisk forhåndsstemming ved stortingsvalg kan interessentene være: velgere (concern: enkel og hemmelig stemmegivning), staten/valgmyndighetene (concern: korrekt og sikkert valg), IT-selskapet som drifter løsningen (concern: sikkerhet, oppetid, ansvar), partiene (concern: rettferdig valg), og personer med funksjonsnedsettelser (concern: universell utforming). En tydelig konflikt: kravet om hemmelig valg (anonymitet) står mot kravet om verifiserbarhet (at man kan kontrollere at opptellingen er riktig). Slike konflikter markeres i det rike bildet og må håndteres i kravspesifikasjonen.
For en nettside der man leier ut festklær (Festklar.no) er interessentene blant annet: kunder som leier (primær aktør, vil leie et plagg), private utleiere som tjener penger (primær aktør), ledelsen (sekundær interessent, vil ha statistikk og inntjening), renseriet (sekundær aktør, samarbeidspartner), og betalingsleverandøren (sekundær aktør). Når du angir aktører til systemet bør du begrunne hvorfor hver er primær eller sekundær: kunden starter use caset «Lei plagg» (primær), mens betalingsleverandøren bare kalles av systemet underveis (sekundær).
Nøkkelformler
Vanlige feil
Eksamenstips
Laster...