viktige begreper Flashcards

1
Q

Validering

A

Har vi spesifisert det riktige systemet, dvs. er det dette kunden ønsker eller trenger?

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

Verifisering

A

Er systemet riktig, dvs. har vi minimert antall feil?

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

Smidig utvikling

A

Reduserer risiko at man leverer og evaluerer (validerer og verifiserer) delsystemer fortløpende. Tett kundekontakt.

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

Unified Modelling Language (UML)

A

use case, sekvensdiagram, klassediagram, aktivitetsdiagram og tilstandsdiagram.

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

Prosessmodell

A

En abstrakt representasjon av en prosess. Modellen beskriver en prosess slik noen mener den burde være. Men den faktiske systemutviklingsprosessen kan ha noen avik fra denne prosessmodellen, men burde følge den sånn cirka.
Eksempler på prosessmodeller kan være fossefall, spiral, RUP, Scrum.

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

Systemutviklingsprosess

A

Det er de aktivitetene som utføres i et utviklingsprosjekt.

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

Inkrementell utvikling

Bonus: nevn fordeler og ulemper

A

Utviklingen foregår gradvis gjennom ulike aktiviteter som man veksler mellom. Kan være plandrevet eller smidig. Så prosjektet planlegges litt etter litt og dermed er det lettere å endre prosessen for å tilpasse seg til endrede krav fra kunden.

Fordeler:

  • kostnadene ved endrede brukerkrav reduseres sammenlignet med tunge-prosesser som fossefallmodellen siden delene som må endres er mindre.
  • Enklere å få tilbakemelding fra kunden på de bitene som har blitt utviklet.
  • Lettere å se hvor mye som er utviklet så langt.
  • Lavere risiko for total prosjektfiasko

Utfordringer:

  • Store prosjekter krever en godt og stabil arkitektur som man må forholde seg til, arkitekturen kan ikke utvikles i deler.
  • Strukturen til systemet har en tendens til å bli verre etter hvert som flere deler legges til.
  • Vanskeligere å foreta endringer senere i prosjektet uten å bruke ressurser på re-faktorisering av prosjektet. (re-strukturering).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Aktivitetsdiagrammer

A

Viser forretningsprosesser og arbeidsprosesser.

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

Use case diagrammer

A

viser systemets funksjonalitet og samspillet mellom systemet og omgivelsene (brukere, andre systemer, komponenter). Identifisering av brukere -> aktører.

  • En aktør representerer en rolle som et menneske eller et annet system når det kommuniserer med DETTE systemet.
  • En aktør kommuniserer med systemet via ett eller flere use case.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Sekvensdiagrammer

A

Viser samspill mellom system og omgivelser og mellom de forskjellige delene av systemet (mer detaljert enn use case digrammene).

Modell for interaksjon mellom objektene i et system, for et gitt bruksmønster (use case).

viser:

  • Hvilken interaksjon som foregår og når
  • Informasjon som sendes mellom objektene
  • Interaksjon mellom bruker og system

Nyttig for å:

  • få en oversikt over klasser / objekter som er nødvendige for å gjennomføre et bruksmønster.
  • implementere systemet, kan generere kode automatisk fra et sekvensdiagram.
  • Viser hvordan de ulike objektene kommuniserer. Oversikt over data som sendes mellom objekter.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Klassediagrammer

A

viser objektklassene i systemet og assosiasjonene mellom disse klassene.

En klasse kan bli sett på som en generell definisjon av objekter som er instanser av klassen.

En assosiasjon mellom to klasser angir at det er en forbindelse mellom disse klassene.

Ved utvikling av modeller i den tidlige fasen av systemutviklingsprosessen, vil objekter som regel representere noe i den virkelige verden, som en pasient, en doktor, en bil eller en bankkonto.

eksempel:
class Bank: I en bank skal vi kunne legge inn en ny kunde, fjerne en kunde, sette inn penger på en kundes konto og finne forvaltningskapitalen til bankene. (summen av alle beløpene på alle kontoene).

class Konto: attributter og metoder som man burde kunne gjøre når man har en konto.

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

Tilstandsdiagrammer

A

Viser hvordan systemet reagerer på interne og eksterne hendelser.

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

Primære og sekundære aktører

A

Primære aktører har egne mål, dvs. De initierer use case som oppfyller deres mål.

Sekundære aktører har ikke egne mål, men de nødvendige for å realisere målene til de primære aktørene.

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

Use case

A

Et use case beskriver hvordan systemet oppnår et mål av verdi for en aktør. Skal beskrive en komplett funksjonell enhet.

eksempler:
Krav - Systemet skal på oppfordring vise informasjon om alle tilgjengelige låneprogrammer.
Use case - Be om informasjon om låneprogram.

Krav - Søkeren skal til enhver tid kunne se status for lånesøknaden.
Use case - Se status

Krav - Låneavtaler skal kunne opprettes og sendes til kunden.
Use case - Lag låneavtale.

Krav - Nye lån skal registreres i bankens system for kontooversikter.
Use case - registrer nytt lån.

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

Interessant

A

Samlebetegnelse for alle personer, grupper eller organer som påvirkes av eller påvirker systemets utvikling / bruk. Kan være en kunde, leverandør, brukere.

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

Domenemodell

A

UML-klassediagrammer uten metoder. Hensikten er å forstå OBJEKTENE og få en god oversikt over systemet. For å kartlegge hvilke objekter man bør ta hensyn til.

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

Risikoanalyse

A
  • Vurder sannsynligheten og mulig konsekvens for hver risiko.
  • Sannsynligheten kan være svært lav, lav, moderat, høy eller svært høy.
  • Konsekvensen kan være katastrofal, alvorlig, mindre alvorlig eller ubetydelig.

eksempler:
Det er umulig å rekruttere medarbeidere med kompetansen som er nødvendig.
Sannsynlighet: høy
konsekvens: katastrofal

Databasesystemet kan ikke prosessere antall transaksjoner per sekund som forventet.
Sannsynlighet: moderat
Konsekvens: alvorlig

18
Q

Hva er testing?

A

For en gitt input forventer vi en gitt output.

Hensikten er å vise at systemet gjør det systemet er ment å gjøre og oppdage feil før systemet blir tatt i bruk.

Testing viser bare feil som du oppdager under kjøring av testen. Den beviser ikke at systemet er feilfritt.

Testing burde være repeterbar, systematisk og dokumentert.

19
Q

Enhetstesting

A

Individuelle programenheter eller klasser testes. Fokus på å teste funksjonalitet til objekter og metoder.

20
Q

Integrasjonstesting

A

Ulike individuelle enheter er integrert til sammensatte komponenter. Fokus på å teste grensesnittet til komponenter.

21
Q

Systemtesting

A

Noen eller alle komponentene i et system er integrert og systemet testes som en helhet. Fokus på å teste interaksjoner mellom komponenter.

22
Q

Akseptanstesting

A

Evaluere systemet som skal leveres.

fokus: validere at systemet som er utviklet faktisk er det kunden vil ha.
Mål: bekrefte at systemet imøtekommer kundens krav og er klar for bruk.

23
Q

Regresjonstesting

A

Fokuserer på å finne feil etter endring av kode (som regel større kodeendringer).

  • Søker etter feil som var der tidligere og feil som ikke var der tidligere.
  • Kjører tidligere tester på nytt.
  • Testene må være godkjent FØR kodeendringene blir godtatt (commited).
24
Q

black-box testing

A

Metode/strategi som tester FUNKSJONALITETEN til et program. Lite eller ingen kunnskap om programmering er nødvendig.

Fordeler:

  • Kan bruke uavhengige testere som ikke har vært involvert i utviklingen
  • Unngår at testere gjør samme antagelser som utviklerne.
  • Testing gjøres fra et brukerperspektiv og kan dermed avsløre mangler i kravspesifikasjonen.

Ulemper:

  • Kan kun teste et lite antall input. Derfor vil mye fortsatt være utestet.
  • Man vet aldri hvor mye eller hvilke deler av systemet som er testet.
  • Kan være redundante om utviklerne har kjørt tilsvarende tester før.
  • utføres i sen stadie
25
Q

white-box testing

A
  • tester interne strukturer eller kode i et program, i motsetning til dens funksjonalitet.
  • det kreves bruker og programmerings-ferdigheter til å designe testene.
  • brukes vanligvis under enhetstesting, men kan også brukes i integrasjons- og systemtesting.
  • Kan avdekke mange feil eller problemer, men oppdager ikke ting som ikke er implementert i henhold til kravspesifikasjonen, heller ikke manglende krav.

Fordeler:

  • Kan utføres i tidlig stadie
  • testingen er mer grundig, systematisk og strukturert.
  • Hjelper med optimalisering av koden
  • Tvinger utviklere til å begrunne kode.
  • kan skrelle vekk overflødige kodelinjer.

Ulemper:

  • krever mye kunnskap innenfor programmering og om systemet.
  • Gir ikke alltid riktige svar
  • Vanskelig å gjennomføre hvis implementasjonen forandres veldig ofte.
26
Q

Konfigurasjonsstyring

A

Handler om prosesser og verktøy for å håndtere endringer i programvaresystemer.

  • Programvaresystemer er i konstant endring både under utvikling og bruk.
  • Lett å miste oversikt over hvilke endringer og versjoner av komponenter som har blitt tatt med i hver system versjon.
  • Viktig å ha kontroll på endringer gjort av ulike utviklere.
27
Q

Baseline

A

Spesiell, kontrollert konfigurasjon av komponenter som fungerer som plattform for vidreutvikling av systemet.

28
Q

Codeline

A

Sett av versjoner av en komponent og andre konfigurasjonselementer som denne komponenten er avhengig av.

29
Q

Branching

A

Oppretting av en ny codeline fra en versjon i en eksisterende codeline.

30
Q

Konfigurasjon

A

En samling av alle komponentene til et system hvor hver komponent er representert med nøyaktig en versjon etter bestemte kriterier, f.eks. siste versjon, plattform, spesiell funksjonalitet, etc.

31
Q

Konfigurasjonselement

A

Alt som er assosiert med et systemutviklingsprosjekt (design, kode, test data, dokumentasjon) og som er under konfigurasjonskontroll. Alle elementer har unike navn (eller id).

32
Q

Mainline

A

En sekvens av baselines som representerer ulike versjoner av et system.

33
Q

Fletting (merging)

A

Oppretting av en ny versjon av en programvarekomponent ved å flette separate versjoner i ulike codelines.

34
Q

Release

A

En versjon av systemet som er released til kunden for bruk.

35
Q

Repository

A

Database av ulike versjoner av programvarekomponenter og (meta) informasjon om alle endringer til disse komponentene.

36
Q

Systembygging

A

Oppretting av et kjørbart system ved å kompilere og linke de riktige versjonene av komponentene og biblotekene som utgjør systemet.

37
Q

Versjon

A

En instans av et konfigurasjonselement som er forskjellig fra andre instanser av samme element. Versjoner har alltid en unik ID.

38
Q

Arbeidsområde

A

Privat arbeidsområde der programvare kan endres uten at det berører andre utviklere som jobber med samme programvare. (GitHub når du kopier en repository og jobber med en egen kopi av prosjektet i din egen private mappe)

39
Q

Sentralisert versjonskontroll

A

-Utviklere sjekker ut komponenter fra felles repository inn på deres private arbeidsområde og jobber på denne kopien.
-Når endringene er fullfør, sjekker de komponentene tilbake til repo’en.
-Når flere jobber på samme komponent samtidig, og sjekker ut en komponent som allerede er sjekket ut av en annen, vil det bli gitt en advarsel om at komponenten allerede er sjekket ut.
(I et gruppeprosjekt hvis Per fra sin private repo fikset noen metoder i klassen Student og Pål fra sin private repo la til noen flere metoder, så vil den siste av de to som pusher få en merge conflict error siden det er gjort andre endringer til fila enn det som var gjort opprinnelig når den var lastet ned)

40
Q

Distribuert versjonshåndtering

A
  • Istedenfor å sjekke ut, laster utviklere ned en klone av repo’en til deres private arbeidsområde.
  • Endringene blir commited til deres private repo (branch)
  • Endringer vil så pushes til master repo, hvis de blir godkjent av manageren til repo’et.