Eksamensspørsmål Flashcards

1
Q

Hvilke grunner har vi for å gjøre brukerundersøkelser?

A
  • Utvikle nye produkter, tjenester, omgivelser, interaksjonsmekanismer
  • Forbedre noe eksisterende
  • Evaluere noe, hvordan fungerer det i praksis?
  • Forstå noe, forske, forstå, undersøke
  • Analysere, kartlegge
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Hvorfor er brukerundersøkelser relevant og viktig?

A
  • Kritiske systemer (helse, liv, fly) “Failure is not an option”. Brukeren MÅ være med.
  • Universell utforming - tilgjenglighet. Brukere MÅ være med.
  • Kostnader og ressurser ved utvikling. Det kan være “dyrt” at brukeren ikke er med.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Hva er brukervennlighet?

A
  • Lett å lære
  • Effektivt
  • Lett å huske
  • Relativt feilfritt og feiltolerant
  • Behagelig å bruke
    ISO-standard for brukevennlighet: «the extent to which a product can be used by specified users to achieve specific goals with effectiveness, efficiency and satisfaction in a specified context of use”.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Måling og tolkning av brukerundersøkelser

A
  • Kvantitativt: Måle metrikker. Antall klikk, antall feil, time spent
  • Kvalitative: Tolke meninger: Bra, dårlig, kjedelig, spennende, jævlig dårlig
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Hvilke aktiviteter må man gjøre i gjennomføring av brukerundersøkelser?

A
  • Planlegging
  • Samtykke
  • Pilotundersøkelse
  • Gjennomføring
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Hvilke aktiviteter i hele brukerundersøkelsesprosessen?

A
  • Planlegge
  • Gjennomføre: samle data
  • Beskrive og representere dataene
  • Analysere dataene
  • Bruke resultatene
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Hvilke måter kan man samle inn data på?

A
  • Intervju
  • Observasjon
  • Spørreskjema
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Er observasjon lett?

A
  • Se, høre, følge med, delta?
  • Observasjon fra et sted, en posisjon, fra et perspektiv
  • Hvor står kameraet?
  • Utvalg og rekkefølge
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Når gjør man brukerundersøkelser?

A

Kort sagt: Ved behov, hvis man kan.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Hvorfor er det viktig med samtykkeerklæring når man samler inn data med brukere?

A

a. Det er svært viktig med samtykkeerklæring når man samler inn data fra mennesker, fordi ofte inneholder denne dataen direkte og/eller indirekte personopplysninger/sensitive personopplysninger. For å ivareta personvernet og rettighetene til deltakerne, opprettholde profesjonalitet og lovlydighet og regulere vår behandling av dataen, bruker vi samtykkeskjema, elektronisk samtykke eller muntlig samtykke.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q
  1. Hva er et samtykke?
A

a. Et samtykke må være frivillig, informert, og uttrykkelig.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q
  1. Hva er en personopplysning?
A

a. “En personopplysning er opplysninger og vurderinger som kan knyttes til en enkeltperson” – Loven
b. Skiller mellom direkte(navn, fødselsnummer) og indirekte(Ip-adresse) personopplysninger. Mosaikk-identifikasjon: kombinere data fra ulike kilder for å så finne personen knyttet til disse opplysningene.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q
  1. Hva må være med i et samtykkeskjema?
A

a. Hva er formålet med datainnsamlingen?
b. Hvor vil opplysningene lagres?
c. Hvor lenge vil opplysningene lagres?
d. Hvem vil ha tilgang til, og/eller behandle, disse opplysningene?
e. Dine, eller din virksomhets, kontaktopplysninger
f. Hva er deltakerens rettigheter

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q
  1. Hvorfor er det viktig med pilotundersøkelse som en del av datainnsamling
A

a. En pilotundersøkelse er en testundersøkelse som skal avdekke feil og mangler ved gjennomføring og metodebruk før man utfører hovedundersøkelsen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q
  1. Redgjør for analyseverktøyet fra Sekvens av handlinger mellom menneske og maskin:
A

a. Fire kolonner. 2 hovedkategorier, med 2 underkategorier hver: Bruker og maskin.
b. Bruker: Handling ikke synlig for maskin og handling synlig for maskin.
c. Maskin: Design rasjonale og effekt synlig for bruker.
d. Skrives sekvensielt nedover, men mellomrom mellom hver handling.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q
  1. Nevn noen lover som er relevant å kunne som informatiker og hvorfor det er viktig å ha kjennskap til dem.
A

a. Lov om behandling av personopplysninger: Innsamling av personopplysninger og samtykkeerklæring.

Diskriminering- og tilgjengelighetsloven: Universell utforming

Arbeidsmiljøloven: Arbeidstaker har krav til tilrettelegging, medvirkning og utvikling av IT systemer i bedriften sin.

Åndsverksloven: Rettigheter rundt et kreativt verk. Hvem eier et dataprogram?

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q
  1. Hva er universell utforming?
A

a. Universell utforming er et konsept innen samfunnsplanlegging, design, arkitektur, tjeneste- og produktutvikling.
b. Konseptet handler om å utforme samfunnet slik at så mange som mulig kan delta aktivt uavhengig av funksjonsevne.
c. Universell utforming av Informasjons- og IKT løsninger er lovpålagt.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q
  1. Nevn noen prinsipper i universell utforming:
A

a. 1. Like muligheter for bruk
b. 2. Fleksibel i bruk
c. 3. Enkel og intuitiv i bruk
d. 4. Forståelig informasjon
e. Toleranse for feil
f. 6. Lav fysisk utfordring
g. 7. Størrelse og plass for tilgang og bruk

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q
  1. Hva er WCAG 2.0?
A

a. Web Content Accessibility Guidelines. Universell utforming av nettinnhold.
b. - WCAG er en standard for universell utforming
c. - Denne standarden utgjør minimumskrav for universell utforming av nettinnhold
d. - Målet er at nettinnhold skal gjøres tilgjengelig for brukere med ulike funksjonsevner og ulike typer begrensninger og utfordringer.
e. - … samtidig som det vil bli bedre å anvende for alle brukere

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q
  1. Hva er de fire hovedprinsippene til WCAG?
A

a. 1. … mulig å oppfatte
b. 2. … mulig å betjene
c. 3. … mulig å forstå
d. 4. … robust

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q
  1. Hva består WCAG av?
A

a. Består av prinsipper, retningslinjer, suksesskriterier, og veiledning

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q
  1. Hva er et sosioteknisk system?
A

a. Et sosio-teknisk system består av både mennesker og teknologi, og beskriver samspillet mellom disse komponentene og aktørene.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q
  1. Hva er rike bilder?
A

a. Rike bilder er en kartleggingsteknikk som kan anvendes i en systemutviklingsprosess.
b. Målet er å få en oversikt over interessenter og hvordan deres concerns kan påvirke utviklingen og bruken av det planlagte systemet.
c. Å lage et rikt bilde er en iterativ prosess. Baseres på innhenting av data fra ulike kilder (dokumentasjon, kontekstuelle intervju, observasjon, osv)
d. Har et uformelt notasjonssytem

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q
  1. Hvilke elementer må/burde være med i et rikt bilde?
A

a. - Strukturer (Interessenter/aktører
b. – Prosesser
c. - Concerns (tankebobler)
d. - Konflikter (Kryssede klinger)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q
  1. Hva et krav?
A

a. Krav er en sentral del i de alle fleste systemutviklingsprosjekter, og kan beskrives på ulike abstraksjonsnivå.
b. Brukerkrav er høynivå, relativt abstrakte beskrivelser av systemets tjenester eller de begrensningene det opererer under.
c. Systemkrav er detaljerte og formelle beskrivelser av programvarens funksjoner, tjenester, og operasjonelle begrensninger.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q
  1. Hvorfor har vi krav?
A

a. Krav forteller noe om hva som skal lages, hvilket problem som skal løses og hvordan man skal løse det.
b. Gode krav fører til mindre feil, som fører til mindre kostnader.
c. Dårlige krav fører ofte til problemer i utviklingsprosessen og ikke minst etterpå.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q
  1. Hva er kravhåndtering?
A

a. Kravhåndteringsprosessen består av de aktivitetene man gjennomfører for å identifisere/analysere/spesifisere/validere kravene til et system.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q
  1. Hvilke aktiviteter er det i kravhåndtering?
A

a. Forstudie/målanalyse: er det gjennomførbart?
b. Kravinnsamling og kravanalyse: Hva ønsker interessentene seg? Hva er behovene?
c. Kravspesifisering: Skriver om kravene til et sammenhengende dokument.
d. Validering av kravspesifikasjonen: Uttrykker kravspecen det kunden og interessentene ønsker seg?

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q
  1. Hva er en kravspesifikasjon, og hvorfor har vi det?
A

a. Kravspesifikasjonen er et dokument som beskriver alle kravene til systemet som skal utvikles.
b. Definerer hva som skal lages – ikke hvordan.
c. Spesifiserer system og brukerkrav
d. Kravspesifikasjonen sier noe om systemets funksjonalitet og oppførsel, og er utviklernes “kildedokument”
e. Kravspesifikasjonen har mange funksjoner:
i. - Utgangspunkt for anbud og kontrakt mellom kunde og leverandør
ii. - Utgangspunkt for design, implementasjon og testing
iii. - Utgangspunkt for estimater (tid og kostnad)
iv. - Grunnlag for testing av systemet
f. Ofte en del av kontrakten for prosjektet

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q
  1. Hva er kjennetegnene til smidig utvikling?
A

a. Planlegging gjøres inkrementelt
b. Enklere å endre prosessen ved endring i krav
c. De delene som må endres er mindre sammenlignet med plandrevet utvikling
d. Derfor gunstig ved..
i. - Utvikling av nye/innovative ideer
ii. - Små utviklingsteam og prosjekter
iii. - Prosjekter med betydelig sannsynlighet for at kravspesifikasjonen endres

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q
  1. Hva er et funksjonelt krav?
A

a. Et spørsmål om hva og hva brukeren skal gjøre. Hva brukeren skal kunne gjøre, ikke hvordan.
b. Funksjonelle krav beskriver hva systemet skal gjøre. Kan også beskrive hva systemet ikke skal gjøre.
c. Beskrives med formen: «Systemet skal… eller Systemet bør…». For eksempel systemet skal kunne vise en oversikt over brukerens betalte billetter.
i. Forretningskrav: Hva forretningen ønsker seg
ii. Brukerkrav: Hva brukeren ønsker seg
iii. Systemkrav: Mer detaljert av hva som skal implementeres sett fra brukerens perspektiv

32
Q
  1. Nevn noen grunner for hvorfor det er viktig å ha gode beskrivelser av krav:
A

a. Viktig for kontrakt og oppdragsgiver – leverandør
b. Planleggingen og oppfølgingen
c. Arkitektur, design og test
d. Å støtte videreutvikling og vedlikehold

33
Q
  1. På hvilken måte bør krav være beskrevet?
A

a. Forståelige: Alle må kunne forstå kravspesifikasjonen
b. Testbare: For å avgjøre om det ferdige systemet gjør det det skal
c. Sporbare: Vi må vite hva som må endres når det kommer nye krav

34
Q
  1. Hva er noen utfordringer i kravhåndtering?
A

a. Kommunikasjon
b. Felles forståelse
c. Balansen mellom fag og IT. Fag dominerer kravspec, og man vet ikke om det kan bli reaslisert. IT dominerer språket og det blir vanskelig å få kravene riktig.
d. Sporbarhet fra krav til arkitektur, design og kode er viktig

35
Q
  1. Hvordan kan krav beskrives?
A

a. Tekst
b. Strukturert tekst
i. User stories
ii. Use case
c. Modeller
i. UML
ii. BPMN

36
Q
  1. Hva er brukerkrav?
A

a. Krav uttrykt i naturlig språk eller diagrammer som viser ønskede tjenester (funksjoner) til systemet og føringer som gjelder (kvalitetsegenskaper)
b. Skal forstås av kunden

37
Q
  1. Hva er systemkrav?
A

a. Strukturert, detaljert beskrivelse av systemets funksjoner og føringer som gjelder (kvalitetsegenskaper)
b. Definerer hva som skal implementere
c. Utgangspunkt for kontrakt mellom kunde og utviklerorganisasjon

38
Q
  1. Hvorfor er det nødvendig å lage en kravspesifikasjon?
A

a. For å lage et system som møter brukerens krav og behov
b. Også basis for anbud
c. Basis for kontrakt/design og implementasjon av systemet

39
Q
  1. Hvorfor er det nødvendig å lage en god kravspesifikasjon?
A

a. Det skaper felles forståelse
b. Det skaper enighet
c. Forhindrer evt konflikter
d. Grunnlag for kontrakt

40
Q
  1. Hva er en interessent?
A

a. En interessent er en person/gruppe/organisasjon som deltar i, eller som har interesse av systemet. En som blir påvirket enten direkte eller indirekte av utviklingen og innføring av et system
b. Det er gjerne fire hovedgrupper: Kunde, bruker, leverandør, andre.

41
Q
  1. Hva er ikke-funksjonelle krav?
A

a. Ikke-funksjonelle krav definerer hvordan systemet skal innfri de funksjonelle kravene.
b. Beskriver ofte operasjonelle begrensninger på systemet.
c. MÅ være testbare
d. Sier noe om kvalitetsattributter og oppførsel
e. Skrives gjerne på denne formen: «Systemet skal være…». For eksempel En ny kunde skal kunne betale en billett innen 3 min.

42
Q

Hva er noen typer ikke-funksjonelle krav?

A

f. Det er noen flere typer ikke-funksjonelle krav:
i. Produktkrav: beskriver brukskvalitet/brukervennlighet, ytelse, effektivitet samt lagringsplass, pålitelighet og lagring av data
ii. Organisasjonskrav: omhandler gjerne kostnader og ressurser, leveringstidspunkt, prosess og utviklingsmodeller, programmeringsspråk, verktøy og komponenter samt generelle standarder og regler
iii. Eksterne krav: andre krav knyttet til for eksempel personvern, sikkerhet eller etiske problemstillinger

43
Q
  1. Hvilken type krav er krav om universell utforming?
A

a. Er et ikke-funksjonelt krav.

b. Sier noe om brukskvalitet og brukervennlighet, og er derav produktkrav.

44
Q
  1. Hva vil det si å validere et system og hvorfor er det viktig?
A

a. Man sjekker om hvorvidt systemet faktisk møter brukerens behov.
b. Er systemet man har laget, det brukeren faktisk trenger?
c. Man kan validere en kravspesifikasjon for å sjekke om kravet beskriver det kunden ønsker seg.
d. Det er viktig, fordi det koster mye å endre et system når det er ferdig.
e. Et system kan være godt laget, men ubrukelig hvis det ikke møter kunden behov.

45
Q
  1. Hva er en brukerhistorie?
A

a. En brukerhistorie er en kort beskrivelse av en bruker i en brukskontekst, med hensikt å klargjøre kravene til et system
b. Brukerhistorier beskriver hva brukeren ønsker å få ut av systemet.
c. Består av disse elementene:
i. Brukerens rolle
ii. Ønsket funksjon
iii. Nytteverdi av funksjonen
d. For eksempel, Som rolle ønsker jeg funksjon for å oppnå nytteverdi
e. Som en bruker ønsker jeg å vurdere en restaurant for at jeg og andre kan få nytte ut av disse tilbakemeldingene

46
Q
  1. Hva er noen fordeler ved å bruke denne teknikken til å beskrive krav?
A

a. Enkelt og kommuniserer kontekst der systemet skal tas i bruk, og hva brukeren faktisk har behov for.
b. Man forstår raskt hvorfor det er nødvendig å implementere funksjoner
c. Det er lettere å se hvem kravet er tiltenkt
d. Kravene uttrykkes på en kort og konsis måte

47
Q
  1. Nevn noen fordeler og ulemper med kundeinvolvering
A

a. Fordeler:
i. Raske tilbakemeldinger
ii. Involverer en person med god domeneforståelse
iii. Sørger for at systemet opprettholder brukerens behov
b. Ulemper:
i. Krever mye tid og ressurser av kunde
ii. Krever at kunde er tilgjengelig

48
Q
  1. Forklar hvorfor det er nødvendig med to krav-aktiviteter i prosessen for gjenbruksbasert systemutvikling?
A

a. Baserer seg på dette:
i. Komponentbasert utvikling: - Benytter seg av komponenter fra ulike pakker
ii. Tjenesteorientert utvikling: - Benytter seg av tjenester som finnes på nett/i skyene
b. Vi trenger følgende krav-aktiviteter ved gjenbruksbasert utvikling:
i. Standard kravinnsamling, bestemmer hva som skal lages og hvordan det skal gjøres.
ii. Etter å ha undersøkt hva som finnes på markedet modifiserer man kravspesifikasjonen med utgangspunkt i den eksisterende programvaren. Ønsket funksjonalitet vil ofte variere fra det som allerede finnes

49
Q

Hvilke fordeler har Kanban?

A
  • Flaskehalser i prosessen blir synlige
    o Fokus på å bli ferdig med oppgaver som hindrer gjennomstrømning fremfor å begynne på flere oppgaver som vil hope seg opp
  • Kan drive smidig utvikling uten å bruke “tidsbokser”
    o Spesielt for drifts- og supportoppgaver og vedlikeholdsoppgaver vil veldefinerte “sprinter” ofte ikke gi mye mening
  • Gunstig der det er svært vanskelig å estimere oppgavene
50
Q

Hva er Kanban?

A

Kanban er en smidig utviklingsmodell med fokus på:

a. Fokus på å få oppgaver (arbeidspakker) raskt utført = antall brukerhistorier (features) implementert per tidsenhet
b. Begrense antall arbeidspakker som det jobbes med i parallell (WIP = Work In Progress) for å hindre flaskehalser
c. Antakelse: Jo høyere WIP, jo saktere flyter arbeidspakken gjennom arbeidsprosessene
d. Når en pakke er ferdig, kan man etterspørre en ny som man begynner å jobbe med (pull)
e. Slakk i tidsplanen er OK, dvs. en utvikler vil kunne vente hvis det optimaliserer overordnet flyt
f. Mindre fokus på estimering av tid og kostnader

51
Q

Hva er noen fordeler med Scrum?

A
  • Systemet blir delt opp i en mengde forståelige og håndterbare deler
  • Ustabile krav hindrer ikke progresjon i prosjekt-gjennomføringen
  • Hele teamet observerer hva som skjer i prosjektet, og kommunikasjon innen teamet blir god
  • Kundene får inkrementer levert fortløpende og kan gi tilbakemelding på hvordan deler av systemet fungerer
  • Tillit mellom kunder og utviklere kan etableres tidlig
  • Kryss-funksjonelle team (kompetansene på ulike områder finnes innen teamet) sikrer framdrift og reduserer risiko
52
Q

Hva er Scrum?

A

a. Scrum er en smidig utviklingsprosess som følger en del prinsipper fra smidige utvikling. Scrum har fokus på inkrementell levering, sprinter og daglige møter.
b. Scrum har tre faser:
i. Planleggingsfasen: overordnede mål for prosjektet etableres og programvarearkitekturen designes
ii. Gjennomføringsfasen: en serie med iterasjoner (kalt ”sprint”), der hver iterasjon leverer et inkrement av systemet
iii. Avslutningsfasen: nødvendig dokumentasjon som hjelpfunksjoner og brukermanualer fullføres, og man oppsummerer hva man har lært i prosjektet

53
Q

Hva er et sekvensdiagram?

A

Et sekvensdiagram er et interaksjonsdiagram som modellerer en interaksjonssekvens for et bestemt use case. Det viser objektene, interaksjonen i rekkefølge og hvilke data som blir sendt mellom objektene

54
Q

Hva er et use case diagram?

A

Et use case diagram viser systemets funksjonalitet og samspillet mellom systemet og omgivelsene (brukere, andre systemer, komponenter)

55
Q

Hva er et klassediagram?

A

Et klassediagram viser objektklassene i systemet og assosiasjonene mellom disse klassene

56
Q

Hva er aktivitetsdiagram?

A

Aktivitetsdiagram er et strukturert flytskjema (flowchart) som viser flyten fra én aktivitet i systemet til en annen.

En aktivitet kan beskrives som en operasjon
eller en funksjon utført av systemet. Flyten i aktiviteter kan være sekvensiell,
parallell, eller forgrenet.

Viser hvordan forskjellige utfall av aktiviteter kan påvirke flyten.

57
Q

Hva er en domenemodell?

A

En domenemodell er en representasjon av de ulike objektene et system består av.

58
Q

Hvorfor er det viktig å benytte seg av sekvensdiagram?

A
  • Viktig å kunne vise hva som skjer/burde skje ved kjøretid.
  • Oversikt over nødvendige klasser og objekter for å gjennomføre et bruksmønster. Kan
    gjøre det enklere å implementere et system
  • Viser hvordan objektene kommuniserer|
59
Q

Hva må være med i en tekstlig beskrivelse av et use case?

A
  1. Navn
  2. Aktører
  3. Prebetingelse
  4. Postbetingelse
  5. Hovedflyt
  6. Alternativ flyt
60
Q

Nevn eksempler på bruksområde for rike bilder:

A
  1. Participatory design

2. Utviklingsprosjekt med brukere

61
Q

Hva er concerns?

A

Concerns er høy nivå målsettinger som betydelige begrenser på måten arbeid blir gjort.

62
Q

Hva er de tre viktigste komponentene i et rikt bilde?

A

Struktur: referer til aspektene av arbeidet som forandrer seg sagte. For eksempel organisatorisk hierarki, geografiske områder, fysisk equipment.
Viktigst, inkluderer det alle menneskene som bil bruke, eller som vil bli blir berørt av introduksjonen av, et nytt system

Prosess: refererer til transformeringene som skjer i en arbeidsprosess. For eksempel flow of goods, documents or data, or transofrmations of goods, money and enjoyment. Or the process by which the different roles influence eachother.

Concerns: den mest nyttige komponenten. Concerns fanger opp ideen om et spesifikt individs motivasjon for å bruke systemet. De ulike motivasjonene fremstiller de ulike perspektivene hver person har.

63
Q

Hvilke teknikker kan man kombinere med bruk av rike bilder?

A

Feks:

  • Brainstorming
  • Storyboarding
  • Papir-basert prototyping
64
Q

Hva er de tre hovedtypene innen etikk?

A

Pliktetikk
Konsekvensetikk
Holdningsetikk

65
Q

Hva er etisk refleksivitet?

A
  1. Se din egen rolle i utviklingsprosjekter.

2. Oppmerksomhet og evnen til å diskutere og kritisere din egen posisjon fra et distansert perspektiv/utenfra

66
Q

Hva er typiske aktiviteter i utviklingsprosjekter?

A
Planlegging
Kravinnsamling og kravanalyse
Design
Implementering
Testing
Vedlikehold og annet etterarbeid
Konfigurasjonsstyring og versjonshåndtering
67
Q

Aktiviteter varierer ettersom hvilken utviklingsprosess man har, men aktiviteten vil alltid ha elementer fra:

A

o spesifisering av kravene, dvs. hva systemet skal gjøre
o design av systemet (for eksempel lage en datamodell)
o implementering av koden (programmering)
o validering av at systemet gjør det kunden ønsker
o endringer av systemet i forhold til nye og endrede krav hos kunden

68
Q

Hva er forskjellen på en systemutviklingsprosess og en prosessmodell?

A

Systemutviklingsprosess: de aktivitetene som gjennomføres i et utviklingsprosjekt.
Prosessmodell: En abstrakt, forenklet representasjon av en prosess. Her skiller vi mellom:
- Normativ: beskriver en prosess slik noen mener den bør være (vanligste betydning).
- Deskriptiv: beskriver en prosess slik vi mener vi utfører den

69
Q

Hva er fossefallsmodellen?

A

Fossefallsmodellen er en plandrevet utviklingsmodell.
Prinsippet med denne modellen er at man ikke går tilbake til tidligere aktiviteter for å endre på ting. Man fullfører hele løpet først, før man evt går tilbake til start.

70
Q

Hva er en iterasjon?

A

En iterasjon er en syklus i utviklingen – et aspekt ved prosessen
o Et nytt inkrement utvikles gjennom en ny iterasjon
o En ny iterasjon kan også forbedre kvaliteten på samme funksjonalitet, dvs. man lager ikke noe nytt inkrement, men bare forbedrer det eksisterende systemet

71
Q

Hva er et inkrement, og hva er inkrementell utvikling?

A
  • Et inkrement er et tillegg i funksjonaliteten – et aspekt ved systemet

Inkrementell utvikling

  • Systemet utvikles gradvis i form av nye inkrementer som blir lagt til. Hvert inkrement evalueres før utviklingen av neste inkrement starter
  • Evalueringen gjøres av en bruker- eller kunderepresentant (produkteier)
  • Viktigste krav utvikles først
  • Når utviklingen av et inkrement er startet, så fryses kravene til det inkrementet. Krav til senere inkrementer kan fortsatt endres
  • Vanlig tilnærming i smidige metoder
72
Q

Hva kjennertegner plandrevne prosesser?

A
  • Prosessaktivitetene planlagt på forhånd. Progresjon måles i henhold til planen
  • En tung prosess inkluderer mange aktiviteter og ofte roller. Krever formelle, detaljerte og konsistente prosjektdokumenter
  • Ofte “for-tunge”, dvs. vektlegger aktiviteter som gjøres tidlig i prosessen (planlegging, analyse & design)
73
Q

Hva kjennetegner smidige prosesser?

A
  • Planleggingen gjøres litt etter litt. Enklere å endre prosessen for å tilpasse endrede krav fra kunden
  • Fokuserer mer på fundamentale prinsipper (f.eks. ”kontinuerlig testing”). Har færre formelle dokumenter
74
Q

Hva er noen prinsipper i smidig utvikling (ref Agile Manifesto)?

A
  1. Kundefokus
  2. Positiv til endringer
  3. Levere inkrementer hyppig
  4. Kundeinvolvering
  5. Stol på den enkelte
  6. Ansikt-til-ansikt kommunikasjon
  7. Kode er hovedpunktet
  8. Stabile omgivelser
  9. Teknisk kvalitet
  10. Enkelthet
  11. Selvstyrte team
  12. Kontinuerlig prosessforbedring
75
Q

Hva er et domenekrav?

A

Fagområdet (domenet) til et system gir også opphav til krav.

Viktig å forstå domenet. Ignorering av domenekrav kan føre til at systemet blir ubrukelig.

76
Q

Hva er det alle ikke-funksjonelle krav MÅ være?

A

Testbare.