IN1030 hele pensum til eksamen 2025

Flascards fra oppsummeringspresentasjonene til modul A og B

Funksjonelle brukerkrav

Funksjoner basert på brukerens behov

Påstander om planlagte tjenester og/eller begrensninger til systemet, basert på kunden/brukers behov.

funksjonelle systemkrav

Funksjoner basert på systemets begrensninger.

Detaljert, formell beskrivelse av programvarens funksjoner, tjenester eller operasjonelle begrensninger.

Krav burde være

forståelige: alle interessenter må kunne forstå kravspesifikasjonen

testbare: vi må kunne avgjøre om det ferdige systemet fjør det den skal

sporbare: vi må vite hvilken del av koden som skal endres når det kommer nye krav

Funksjonelle krav

Krav om funksjonalitet. Hvilke funksjoner skal systemet ha?

“Systemet skal…/systemet bør…”

Ikke-funksjonelle krav

Krav om kvalitet. Hvor godt skal systemets funksjoner fungere?

sier noe om kvalitetsattributter, og hvor godt systemet skal funke. de bør være målbare.

Ikke-funksjonelle krav, produktkrav

Brukskvalitet/brukervennlighet, ytelse og effektivitet samt lagringsplass, pålitelighet og lagring av data.

ikke-funksjonelle krav, organisatoriske krav

Kostnader & ressurser, leveransetidspunkt & prosess; utviklingsmodeller, programmeringsspråk, verktøy og komponenter samt generelle standarder og regler.

ikke-funksjonelle krav, eksterne krav

Lovverk, begrensninger & etiske problemstillinger.

Kravhåndteringsprosessen

1: forstudie/målanalyse

2: kravinnsamling og kravanalyse

3: kravspesifisering

4: validering av kravspec

5: håndtering av kravendringer

Forstudie/målanalyse

Kost/nytte-analyser, risikoanalyser og gevinstrealisering utføres.

Kravinnsamling og kravanalyse

Hva ønsker interessentene seg? Hva har de behov for? Prioritering av kravene.

Kravspesifisering

Utgangspunkt for anbud og kontrakt (mellom kunde og leverandør). Utgangspunkt for design, implementasjon og testing. Utgangspunkt for estimater (tid og kostnad).

Validering av kravspec

Evaluere kravspesifikasjonen. Møter vi aktørers faktiske behov? Er det mangler eller feil ved kravspesifikasjonen?

Kravendringer

Når forståelsen av et problem endrer seg. Mange aktører, med noen ganger motstridende behov. Hvordan prioritere? Plan for kravhåndtering: husk å dokumentere kravendringene underveis. Håndtering av kravendringer: veie for og imot endringer. Tid, kostnad, arbeidskraft?

Systemutvikling

De aktivitetene som utføres for å utvikle et IT-system.

Prosessmodell

En forenklet presentasjon av prosessen. Modeller for systemutvikling.

Prosess

vil påvirke kvaliteten både prosjektet selv og systemet som utvikles. Er en serie aktiviteter som gjennomføres for å oppnå et mål.

Prosessmodeller vs. reell prosess

Generelle prosessmodeller (scrum, kanban, fossefall), firmaspesifikke prosessmodeller (ulike standarder i ulike bedrifter), prosjekt/gruppespesifikke prosessmodeller (alle grupper jobber på ulik måte).

Fossefallsmodellen

Mye design tidlig i prosjektet. Separate faser. Vanskelig å tilpasse endringer i krav underveis. jo senere i prosessen endringen er, jo dyrere er den.

Tidsbokser (Scrum)

Velger noen prioriterte oppgaver og jobber med dem i faste tidsintervaller med definerte oppstarts- og avslutningsaktiviteter

Flyt av oppgaver (Kanban)

Definerer et sett med oppgaver (“features”) som skal lages, og lever så snart man er ferdig. Oppgaver skal ”flyte” uten avbrudd gjennom de nødvendige aktivitetene til de er ferdige (”oppgavebokser”)

Planleggingsfasen (Scrum)

Mål for prosjektet etableres og programvarearkitekturen designes. Utvikler product-backlog, og sprint-backlog (samling av user stories).

Gjennomføringsfasen (Scrum)

En serie med iterasjoner (“sprint”), der hver iterasjon leverer et inkrement av systemet. inkluderer flere aktiviteter som sprint planning, daily standup, og retrospective.

Avslutningsfasen (Scrum)

Nødvendig dokumentasjon som hjelpe-funksjoner og brukermanualer fullføres, og man oppsummerer hva man har lært i prosjektet.

User story

“Som en <rolle> ønsker jeg <funksjon> for å oppnå <verdi>”

Product backlog

Komplett samling av alle user stories og systemkrav.

Sprint backlog

Et utvalg av user stories fra product backloggen som man ønsker å fullføre i løpet av sprinten.

Sprint

Tidsintervall på 2-4 uker hvor man jobber for å fullføre deler av systemet basert på de utvalgte user-storiesene fra sprint-backlogen.

Scrum master

Leder de daglige møtene (daily standup), og passer på at teamet rekker å gjøre det de skal i løpet av sprinten. Denne rollen rulleres på, og man bytter gjerne Scrum master etter hver sprint.

Sprint planning

Et møte med teamet som holdes i starten av en sprint for å planlegge sprinten. Hva er målet for sprinten?

Daily Standup

Daglige (korte) møter hvor man sjekker status på teamet. hvordan går det? hva har du gjort? hva skal du gjøre? noe du trenger hjelp til?

Retrospective

Et møte etter en fullført sprint hvor man evaluerer prosessen og prøver å finne forbedringsområder.

Produktbacklog

Prioritert oversikt over alle user stories som skal inkluderes i den endelige løsningen.

Sprintbacklog

Prioritert oversikt over et utvalg user stories fra product backloggen som man ønsker å fullføre i løpet av sprinten. Denne viser estimert tids- og ansvarsfordeling for hver enkelt oppgave.

Large Scale Scrum

I store prosjekter hvor flere team involveres og jobber med ulike deler av samme system på samme tid, stilles det høyere krav til kommunikasjon og organisering.

“sklerer” man opp de vanlige aktivitetene i scrum

Kanban

Fokus på få oppgaver, og man jobber med samme oppgave til man blir ferdig.

Begrenser antall oppgaver som det jobbes med i parallell (WIP = Work In Progress) for å hindre flaskehalser.

Kanban Board

En tavle med oversikt over alle arbeidsoppgaver, som er delt inn i tre kolonner: “Not started”, “In progress”, og “Done”. Gir oversikt over hvilke og hvor mange arbeidsoppgaver som det jobbe med til enhver tid

WIP (Work In Progress)

Antall arbeidsoppgaver som er påbegynt (“In progress”).

WIP Limit

En maksgrense på antall arbeidsoppgaver som får lov til å være påbegynt og ligge i “In progress” kolonnen.

Prosjektledelse

For å sikre at teamet lykkes med prosjektet.

• teamet klarer å levere en løsning til avtalt tid

• teamet holder kostnadene for utvikling under budsjett

• teamet opprettholder produktivitet og gode stemning

• teamet klarer å levere et produkt som møter kundens krav og forventninger

Prosjektledelse inkluderer

risikoanalyse og risikohåndtering

menensker, motivasjon og teamarbeid

prosjektplanlegging

Risikoanalyse og risikohåndtering

Hva er sannsynligheten for at noe uventet skjer, og hvordan takler vi dette?

Tre hovedtyper risko:

• prosjektrisiko

• produktrisiko

• forretningsrisiko

Mennesker, motivasjon og teamarbeid

Menneskene er organisasjonens største ressurs. Manglende prosjektledelse er ofte årsaken til at et prosjekt feiler. Handler om å motivere teamet, fordele ansvar, og styrke teamfølelsen.

Prosjektplanlegging

Hvilke prosessmodell skal man følge? Hvilke verktøy og kommunikasjonskanaler skal man ta i bruk?

Prosjektrisiko

Tidsplan og/eller ressurser.

Produktrisiko

Kvaliteten eller programvaren som utvikles.

Forretningsrisiko

Organisasjonen som utvikler/eier programvaren.

vurderinger for risikoanalyse

sannsynlighet: svært lav - lav - moderat - svært høy

konsekvens: ubetydelig - mindre alvorlig - alvorlig - katastrofal

DevOps prinsipp

Alle ansvarlige for alt. Alle i teamet har delt ansvar for utvikling, utgivelse og vedlikehold/support av programvaren.

Alt som kan bli automatisert burde blid et. legg opp til minst mulig manuelt arbeid med utgivelsen av programvaren

Mål først, endre etterpå.

Fordeler med DevOps

Raskere utgivelse/leveranse, redusert risiko, raskere reperasjon, produktive team.

Code management

Et sett med programvare-støttende praksiser for å administrere en inkrementelt voksende kodebase.

Git pull

Henter en fil lokalt slik at man kan jobbe med den på egen maskin

Git push

sender endringer gjort i lokal fil opp til server hvor alle filene samles

Git commit

viser alle endringer som er gjort lokalt på en fil

Informasjonssikkerhet

Beskytte informasjonsressurser mot skade. Slike informasjonsressurser kan være data, programvare, konfigureringer, utstyr og infrastruktur. (Tilsiktet eller utilsiktet skade)

trussel agenter kan være mennesker og naturlige hendelser.

Konfidensialitet (K.I.T)

At informasjon ikke blir gjort tilgjengelig eller vist til uautoriserte individer, entiteter eller prosesser.

Integritet (K.I.T)

Å sikre at data ikke blir endret/slettet på en uautorisert måte.

System integritet: å opprettholde korrekthet og kompletthet av dataressurser

Tilgjengelighet (K.I.T)

Å sikre at data og tjenester er tilgjengelige og anvendbare ved forespørsel fra en autorisert entitet

Tiltakskategorier

fysiske tiltak (låse inn, overvåke, adgangskontroll)

tekniske tiltak (autentisering, kryptering, autorisering)

administrative tiltak (opplæring, bakgrunnssjekk, internkontroll)

Preventive Sikkerhetstiltak

Forhindre og avskrekke angrep/forsøk.

Detektive Sikkerhetstiltak

Varsler angrep som blir forsøkt gjort eller som allerede har skjedd.

Korrigerende Sikkerhetstiltak

Gjenopprette skader på dataressurser etter angrep.

Kontrakt

En avtale som mellom partene etablerer en bindende forpliktelse til å gjøre eller til å unnlate å gjøre noe.

tilbud + aksept = avtale

ulike kategorier av kontrakter

• “one time off”, leverer en gang så ferdig

• rammeavtaler, atlaer over tid

• løpende tjenestekontrakter, tjenester over tid

• samarbeidsavtaler, hvem skal gjøre hvilken jobb?

• garantier, hvis datterselskap ikke kan levere kommer morselskapet inn og fullfører

UML

Unified Modeling Language, en industristandard for datarelatert modellering.

Use case diagram

Viser interaksjon mellom et system og omgivelsene.

Sekvensdiagram

Viser interaksjon og informasjonsflyten mellom aktørene og systemet og systemkomponentene i form av objektklasser.

Aktivitetsdiagram

Viser aktivitetsflyten i en prosess eller dataprosessering.

Klassediagram

Viser struktur: objektklasser av et system, deres attributter og metoder, og relasjonene mellom klassene.

Hovedflyt

Viser den forventede sekvensen av handlinger. den ideelle situasjonen hvor interaksjonen mellom aktør og system går som planlagt

Alternativ flyt

Viser sekvensen av handlinger som avviker fra hovedflyten. Feilhåndterig eller andre avvik fra hovedflyt. beskriver flyt som ikke går som planlagt

Primær aktør

Eget mål i kommunikasjonen med systemet.

Sekundær aktør

Hjelper primær aktøren med å nå målet, kommuniserer også aktivt med systemet.

Sekvensdiagram

Aktivitetsdiagram

Klassediagram

sosio-tekniske systemer

hvordan mennesker og teknologi forholder seg til hverandre (relasjoner). gjensidig påvirkning.
omfatter tekniske systemer, sosiale prosesser og interessenter som bruker/samhandler med systemet.

nivåer for å forstå samspill og relasjoner på

mikro (individ nivå)
meso (gruppe nivå)
makro (smfunns nivå)

moralsk ansvar

forpliktelser til morals norm, regel eller autoritet

juridisk ansvar

bære følge av skadegjørende handlinger/unnlatelser, f.eks. i form av straff eller erstatningsplikt

interesse

vise faktiske eller bare forestilte behov som søkes til tilfresstilt av en interessent

interessent

en person, gruppe eller organisasjon som kan påvirke eller bli påvirket av en sak

aktør

en som har en aktiv rolle med systemet og faktisk anvender det (kan være interessent samtidig)

rolle

kan ha direkte eller indirekte innflytelse. utfører handlinger som direkte påvirker utfallet

rike bilder

får frem forskjellige perspektiver og viser interessenter og deres interesser. en teknikk for å representere virkeligheten via tegning. en form for interessentanalyse. kan brukes for å utvikle, endre og analysere systemer både før og etter utvikling. stammer fra sosioteknisk tilnærming

rike bilder notasjon

sverd: konflikt
hjerte: godt samarbeid
tanke boble: interesser
pil: relasjon
delvis motstridende relasjoner har både hjerte og sverd

hvorfor undersøkelse av bruk?

vi ønsker å forstå noe som vi lurer på, og gjennom det bringe frem ny kunnskap som skal være til nytte for individer, organisasjoner, og kanskje hele samfunnet (utvikle/forbedre/evaluere/forstå/analysere noe)

metoder for å undersøke bruk

intervju: snakke med hverandre
spørreskjema: svar på bestemte spørsmål
observasjon: følg med om hendelser og aktiviteter
kan delta aktivt eller passivt (ser på)

planlegge datainnsamling

krever mye planlegging teoretisk og praktisk. gjøre pilotundersøkelse og skrive samtykkeskjema

pilotundersøkelse

test undersøkelse som skal avdekke feil og mangler før man begynner hovedstadiet.

samtykkeskjema

kontrakt mellom deltaker og systemutviklere over hvilke rettigheter deltaker har i forhold til data som blir samlet inn
bør spesifisere hva data brukes til, hvordan data skal bli samlet inn, tilgjengeligheten til data, hvordan og hvor lenge den skal være samlet.

samtykkeskjema må tilfredsstille 4 krav

frivillig: samtykket må ikke være et resultat av press
spesifikt: må være knyttet opp til de formål som personopplysninger behandles for
informert: personen har krav på å vite hvilke personopplysninger som blir samlet in, hvordan de blir lagret, hvor lenge, hva de skal bli brukt til, ....
utvetydig: må bekreftes ved aktiv handling

sekvenstabell

undersøker flyten i interaksjon. hvor stopper det opp? hvor er det bra? forstå maskin og mennesker hverandre? funker det optimalt?

sekvenstabellen: bruker

handlinger ikke synlig for maskinen: ting brukeren gjør som ikke kan detekteres av amskinen
handlinger synlig for maskinen: input. brukerens direkte interaksjon av maskinen

sekvenstabellen: maskinen

effekt synlig for bruker: output. feedback ("klikk for å fortsette")
design rasjonale: informasjon og behandling. hva maskinen gjør internt. algoritmer, bits, osv.

tilgjengelighetskultur

ny teknologi: større mulighet til å være tilgjengelig. hva gjør dette med samhandling og relasjoner til dem rundt oss? hvordan påvirker dette hverdagen vår?

grønn informatikk

etisk tema.
fotavtrykk: negativ miljøpåvirkning
håndavtrykk: positiv miljøpåvirkning
hvordan kan vi minke fotavtrykk som informatikere?

personopplyslingsloven sine 6 sentrale definisjoner

personopplysning: identifiserer en person
behandling: operasjon på/med data
register: lagring av data
behandlingsansvarlig: bestemmer formål
databehandler: behandler data på vegne av behandlingsansvarlig
samtykk: frivillig, spesifikt, informert, utvetydig

digital etikk

er: kritisk refleksjon omkring menneskelig utvikling og bruk av digital teknologier
i praksis: være bevisst og kritisk til både utviklingen og bruk av teknolog er en forstening med å jobbe med mennesker og teknologi.

etisk refleksivitet

1. reflektere over egne rolle
2. være oppmerksom på egen rolle
3. evne å diskutere og kritisere son posisjon utenfra.