Validering
Har vi spesifisert det riktige systemet, dvs. er det dette kunden ønsker eller trenger?
Verifisering
Er systemet riktig, dvs. har vi minimert antall feil?
Smidig utvikling
Reduserer risiko at man leverer og evaluerer (validerer og verifiserer) delsystemer fortløpende. Tett kundekontakt.
Unified Modelling Language (UML)
use case, sekvensdiagram, klassediagram, aktivitetsdiagram og tilstandsdiagram.
Prosessmodell
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.
Systemutviklingsprosess
Det er de aktivitetene som utføres i et utviklingsprosjekt.
Inkrementell utvikling
Bonus: nevn fordeler og ulemper
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).
Aktivitetsdiagrammer
Viser forretningsprosesser og arbeidsprosesser.
Use case diagrammer
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.
Sekvensdiagrammer
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.
Klassediagrammer
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.
Tilstandsdiagrammer
Viser hvordan systemet reagerer på interne og eksterne hendelser.
Primære og sekundære aktører
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.
Use case
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.
Interessant
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.
Domenemodell
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.
Risikoanalyse
- 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
Hva er testing?
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.
Enhetstesting
Individuelle programenheter eller klasser testes. Fokus på å teste funksjonalitet til objekter og metoder.
Integrasjonstesting
Ulike individuelle enheter er integrert til sammensatte komponenter. Fokus på å teste grensesnittet til komponenter.
Systemtesting
Noen eller alle komponentene i et system er integrert og systemet testes som en helhet. Fokus på å teste interaksjoner mellom komponenter.
Akseptanstesting
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.
Regresjonstesting
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).
black-box testing
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
