Prøveeksamen INF1050: Gjennomgang, uke 15

Transkript

1 Prøveeksamen 2016 INF1050: Gjennomgang, uke 15

2 Overblikk Multiple choice Modellering Aktivitetsdiagram Sekvensdiagram Klassediagram Tilstandsdiagram Krav Ikke-funksjonelle krav og målbarhet Smidig metodikk

3 Multiple Choice

4 Oppgave 1.1 Hvilket av følgende krav til en billettautomat er funksjonelt? a. Utskrift av en billett skal ikke ta mer enn 5 sekunder b. Teksten på skjermen skal være svart med hvit bakgrunn c. Det skal være valg for utskrift av kvittering d. Koden skal være enkel å endre

5 Oppgave 1.1: Løsningsforslag Hvilket av følgende krav til en billettautomat er funksjonelt? a. Utskrift av en billett skal ikke ta mer enn 5 sekunder b. Teksten på skjermen skal være svart med hvit bakgrunn c. Det skal være valg for utskrift av kvittering d. Koden skal være enkel å endre

6 Oppgave 1.1: Notat Kunne redegjøre for ulike typer krav Funksjonelle Ikke-funksjonelle Pensum Forelesning: Kravhåndtering Gjennomgang: Uke03 - Kravhåndtering

7 Oppgave 1.2 Et eksperiment i systemutvikling brukes til å... a. Kartlegge virkningen av å bruke bestemt teknologi b. Finne utviklernes mening om hvor god en teknologi er c. Studere en teknologi i dybden i et prosjekt d. Intervjue utviklere som bruker teknologi

8 Oppgave 1.2: Løsningsforslag Et eksperiment i systemutvikling brukes til å... a. Kartlegge virkningen av å bruke bestemt teknologi b. Finne utviklernes mening om hvor god en teknologi er c. Studere en teknologi i dybden i et prosjekt d. Intervjue utviklere som bruker teknologi

9 Oppgave 1.2: Notat Kunne redegjøre for ulike forskningsmetoder Eksperiment Case-studier Etnografi Aksjonsforskning Spørreskjema Pensum Forelesning: Forskningsmetoder Gjennomgang: Uke13 - Forskningsmetoder

10 Oppgave 1.3 Et inkrement i inkrementell utvikling indikerer... a. Et tillegg i programvaren b. En iterasjon i smidig utvikling c. Et tillegg i kravspesifikasjonen d. En milepæl for prosjektet

11 Oppgave 1.3: Løsningsforslag Et inkrement i inkrementell utvikling indikerer... a. Et tillegg i programvaren b. En iterasjon i smidig utvikling c. Et tillegg i kravspesifikasjonen d. En milepæl for prosjektet

12 Oppgave 1.4 Validering i testing av programvare betyr å teste at... a. Komponenter og delsystemer fungerer sammen b. Produktet bygges på riktig måte c. Systemet gjør det brukeren ønsker d. Systemet er robust

13 Oppgave 1.4: Løsningsforslag Validering i testing av programvare betyr å teste at... a. Komponenter og delsystemer fungerer sammen b. Produktet bygges på riktig måte c. Systemet gjør det brukeren ønsker d. Systemet er robust

14 Oppgave 1.4: Notat Kunne redegjøre for ulike testtyper og deres formål Enhetstesting Integrasjonstesting Systemtesting Akseptansetesting Hvorfor tester vi? Pensum Forelesning: Testing Gjennomgang: Uke08 - Testing

15 Oppgave 1.5 Hva representerer en valgdiamant i et aktivitetsdiagram? a. For-løkke b. Class c. While-løkke d. If-then-else -test

16 Oppgave 1.5: Løsningsforslag Hva representerer en valgdiamant i et aktivitetsdiagram? a. For-løkke b. Class c. While-løkke d. If-then-else -test

17 Oppgave 1.5: Notat Kunne redegjøre for ulike UML-diagrammer Use case-diagrammer Sekvensdiagrammer Klassediagrammer Aktivitetsdiagrammer Tilstandsdiagrammer Pensum Forelesning: / / UML Gjennomgang: Uke04 / Uke05 / Uke06 - UML

18 Oppgave 1.6 Hva er en baseline? a. En kontrollert konfigurasjon av komponenter som fungerer som plattform for videreutvikling b. Et element som er under konfigurasjonskontroll c. En sekvens av mainlines d. En sekvens av branches

19 Oppgave 1.6: Løsningsforslag Hva er en baseline? a. En kontrollert konfigurasjon av komponenter som fungerer som plattform for videreutvikling b. Et element som er under konfigurasjonskontroll c. En sekvens av mainlines d. En sekvens av branches

20 Oppgave 1.6: Notat Kunne redegjøre for hva konfigurasjonsstyring innebærer Hovedaktiviteter Systembygging Versjonhåndtering Endringshåndtering Relsease-håndtering Sentrale begreper Pensum Forelesning: Konfigurasjonsstyring Gjennomgang: Uke11 - Konfigurasjonsstyring

21 Oppgave 1.7 Hva er den viktigste kvalitetsdimensjonen? a. Pålitelighet b. Brukskvalitet c. Vedlikeholdbarhet d. Varierer, må avgjøres av interessentene (stakeholders) for et gitt prosjekt /system

22 Oppgave 1.7: Løsningsforslag Hva er den viktigste kvalitetsdimensjonen? a. Pålitelighet b. Brukskvalitet c. Vedlikeholdbarhet d. Varierer, må avgjøres av interessentene (stakeholders) for et gitt prosjekt /system

23 Oppgave 1.8 Hva kjennetegner EDA (Event-Driven Architecture)? a. Cloud services b. Fysisk arkitektur c. Agenter som subscriber/lytter på hendelser d. Et abstrakt klassehierarki

24 Oppgave 1.8: Løsningsforslag Hva kjennetegner EDA (Event-Driven Architecture)? a. Cloud services b. Fysisk arkitektur c. Agenter som subscriber/lytter på hendelser d. Et abstrakt klassehierarki

25 Oppgave 1.8: Notat Kunne redegjøre for aspekter ved systemarkitektur Ulike views Lagdeling Fysisk og logisk Arkitektoniske stiler Pensum Forelesning: Systemarkitektur Gjennomgang: Uke07 - Systemarkitektur

26 Oppgave 1.9 Hvilket av følgende prinsipper er ikke del av LEAN utvikling? a. Kundefokus b. Fokus på flyt ( flow ) c. Unngå sløsing ( waste ) d. Bruk av tidsbokser

27 Oppgave 1.9: Løsningsforslag Hvilket av følgende prinsipper er ikke del av LEAN utvikling? a. Kundefokus b. Fokus på flyt ( flow ) c. Unngå sløsing ( waste ) d. Bruk av tidsbokser

28 Oppgave 1.9: Notat Kunne redegjøre for ulike prosessmodeller og metoder Prosessmodeller Prinsipper for utvikling Plandrevet og smidig Pensum Forelesning: Prosessmodeller Gjennomgang: Uke02 - Prosesser

29 Oppgave 1.10 Hva brukes i UML for spesifikasjon av grensesnitt (interface)? a. Sekvensdiagrammer b. Klassediagrammer c. Use case-diagrammer d. Tilstandsdiagrammer

30 Oppgave 1.10: Løsningsforslag Hva brukes i UML for spesifikasjon av grensesnitt (interface)? a. Sekvensdiagrammer b. Klassediagrammer c. Use case-diagrammer d. Tilstandsdiagrammer

31 Oppgave 1.10: Notat Kunne redegjøre for ulike UML-diagrammer Use case-diagrammer Sekvensdiagrammer Klassediagrammer Aktivitetsdiagrammer Tilstandsdiagrammer Pensum Forelesning: / / UML Gjennomgang: Uke04 / Uke05 / Uke06 - UML

32 Konfigurasjonsstyring

33 Oppgave 2(1) Hvorfor er konfigurasjonsstyring viktig?

34 Oppgave 2(1): Løsningsforslag Hvorfor er konfigurasjonsstyring viktig? Programvaresystemer er i konstant endring Systemer og kode kan bli veldig komplekse Lett å miste oversikten over endringer / versjoner Varierer fra versjon til versjon Ønsker kontroll over endringer Hva ble endret? Hvem har endret hva? Bringer kontroll over systemutviklingsprosessen! Forenkler teamarbeid og koordinering / Unngår endringsrelaterte problemer

35 Oppgave 2(2) Hva er distribuert versjonhåndtering?

36 Oppgave 2(2): Løsningsforslag Hva er distribuert versjonhåndtering? Versjonhåndtering Oversikt over ulike versjoner av et system og systemkomponenter Sørger for at endringer fra ulike utviklere ikke kolliderer med hverandre Distribuert versjonhåndtering Master repository ligger på en server Utviklere laster ned (pull) en klone til privat arbeidsområde Har nå tilgang til hele historien på egen maskin (Data + metadata) Endringer blir oppdatert privat gjennom commit Endringer oppdateres globalt ved push til master repository

37 Oppgave 2(3) Nevn noen viktige faktorer i endringsanalyse

38 Oppgave 2(3): Løsningsforslag Nevn noen viktige faktorer i endringsanalyse. Konsekvenser Hva skjer dersom foreslåtte endringer ikke følges opp? Fordeler / gevinst av foreslåtte endringer Brukere Hvem, hvor mange, berøres av de foreslåtte endringene? Kostnader knyttet til implementasjon av endringene Erfaringen til utviklerteamet Påvirker hvordan endringer håndteres

39 Oppgave 2(4) Hva er et repository?

40 Oppgave 2(4): Løsningsforslag Hva er et repository? Lagringsplass Kildekode / Programvarekomponenter Verktøy for versjonhåndtering Oversikt over endringer som utføres Kan være Sentraliserte Distribuerte

41 Oppgave 2(5) Hva er systembygging?

42 Oppgave 2(5): Løsningsforslag Hva er systembygging? Bygging av systemet Setter sammen systemkomponentene Programvare Data Biblioteker Kompilering og integrering Skaper et fullstendig, kjørbart system

43 Oppgave 2(6) Nevn noen viktige faktorer som påvirker releaseplanlegging

44 Oppgave 2(6): Løsningsforslag Nevn noen viktige faktorer som påvirker releaseplanlegging. Release-håndtering og planlegging Forberede og ferdigstille programvare for ekstern utgivelse Oversikt over ulike versjoner som har blitt gitt til kunden Påvirkende faktorer Har kunden bruk for det (releasen)? Gir det kunden verdi i form av ny og nødvendig funksjonalitet eller forbedring? Er det en major (betydelig tillegg i funksjonalitet) eller minor release Hvordan ligger man an i forhold til konkurrentene?

45 Oppgave 3: Modellering av krav Du skal modellere deler av et web-basert system for kjøp av billetter til en fornøyelsespark. Billettene kjøpes på web, og du kan kjøpe ulike typer billetter. Alle billetter gjelder én bestemt dag. Det er også mulig å kjøpe billetter i luka, men dette skal ikke modelleres. Når det gjelder billetter til selve fornøyelsesparken, er det mest vanlige å kjøpe en billett som inkluderer alle attraksjoner, bortsett fra én; Air Fantasy. Denne må betales for separat og koster 100 kr per tur. Det er også mulig å kjøpe kun inngangsbillett (uten attraksjoner) for 100 kr.

46 Oppgave 3: Modellering av krav Ved bestilling av billetter på nett (inngangsbilletter med/uten attraksjoner, Air Fantasy, og billetter til mat) skal det være mulig å bestille et vilkårlig antall av hver type billett til vilkårlig mange dager (legg i handlekurv) før man går til betaling. Hvis du vil, kan du i det web-baserte systemet lage en profil med personlig informasjon og opplysninger om bankkort. Hvis du også legger inn ønsket brukernavn og passord slipper du å legge inn personlig informasjon og betalingsopplysninger hver gang du bruker systemet. Systemet har en betalingsmodul. Når betalingen er godkjent, blir billetten(e) tilgjengelige i PDF-format med en strekkode for hver billett som scannes ved inngangen og ved hver attraksjon, og eventuelt spisesteder.

47 Oppgave 3: Modellering av krav Følgende priser gjelder billetter inkludert attraksjoner: Over 120 cm: 400 kr Under 120 cm: 200 kr (noen av attraksjonene er ikke tilgjengelige) Senior (over 60 år): 200 kr I tillegg kan man kjøpe billett(er) til én eller flere turer med Air Fantasy. Følgende priser gjelder billetter til mat, som kan benyttes på to ulike steder Pizzastedet 300 kr for stor pizza 150 kr for liten pizza Burgersjappa 150 kr for stor burger 100 kr for liten burger

48 Oppgave 3(a) Lag et aktivitetsdiagram for Bestill billetter. Det skal være mulig å bestille (én eller flere) av alle typer billetter i vilkårlig rekkefølge.

49 Oppgave 3(a): Løsningsforslag Lager først en oversikt over aktiviteter Aktiviteter som inngår i Bestill billetter Velg dag Velg antall Både for alle attraksjoner eller kun inngangsbillett Velg antall for Air Fantasy Velg flere eller ferdig Velg mat Oppgi personopplysninger og betalingskort Opprett profil Hent / Se billett

50 Oppgave 3(a): Løsningsforslag Kartlegger hvordan aktivitetene henger sammen: Hvordan bestilles billetter? Først velges dag Deretter velges billettype Alle attraksjoner eller kun inngangsbillett? Air Fantasy -billetter? Kan kun kjøpes dersom du har en inngangsbillett Fortsett handelen? Ferdig eller flere: Nye billetter eller Matbilletter? Betaling Direkte? Registrer informasjon / Via innlogging eller opprett profil? Utfør betaling og hent billett(er)

51 Oppgave 3(a): Løsningsforslag

52 Oppgave 3(b) Lag et sekvensdiagram for Bestill billetter.

53 Oppgave 3(b): Løsningsforslag Lager først en tekstlig beskrivelse for Bestill billetter

54 Oppgave 3(b): Løsningsforslag

55 Oppgave 3(c) Lag et klassediagram for Bestill billetter som tilsvarer sekvensdiagrammet i oppgave (b). Ha med attributter, metoder, og assosiasjoner med multiplisitet.

56 Oppgave 3(c): Løsningsforslag

57 Oppgave 3: Fortsettelse Et typisk ikke-funksjonelt krav til systemet er brukskvalitet. Slike krav er ofte uttrykt svært generelt, noe som gjør det vanskelig for utviklingsteamet å teste om kravene innfris. For eksempel: Systemet skal være enkelt å bruke for alle typer brukere og organisert slik at brukerfeil forekommer minst mulig.

58 Oppgave 3(d) Beskriv dette kravet på en måte som gjør det mer testbart.

59 Oppgave 3(d): Løsningsforslag Beskriv dette kravet på en måte som gjør det mer testbart. Kravet må gjøres målbart Hva ønsker vi å måle? Hvor enkelt et system er Hvordan kan enkelthet karakteriseres? Tiden det tar for en bruker å gjennomføre et gitt bruksmønster Antall feil i gjennomføringen Definere metrikker for målene, med følgende spesifisert: Hvem? Hva? Hvordan?

60 Oppgave 3(d): Løsningsforslag Beskriv dette kravet på en måte som gjør det mer testbart. (*) Angir at kravet bør spesifiseres ytterligere

61 Oppgave 3(e) En av attraksjonene er kjøring av radiobil (for én person). Radiobilen kan stå stille eller være i bevegelse, enten forover eller bakover. For at radiobilen skal kunne settes i bevegelse, må det sitte en person i bilen og sikkerhetsbeltet må være festet. Når radiobilen er i bevegelse, er det ikke mulig å ta av sikkerhetsbeltet eller gå ut av radiobilen. Tegn et tilstandsdiagram for radiobilen.

62 Oppgave 3(e): Løsningsforslag Lager først en oversikt over tilstander Tilstander som inngår kjøring av radiobil Står stille (to ulike tilstander) Enten fordi du har festet sikkerhetsbeltet og er klar til å kjøre, Eller fordi sikkerhetsbeltet ikke er festet Kjører forover Tråkker på gassen Kjører bakover Setter bilen i revers

63 Oppgave 3(e): Løsningsforslag Deretter ser vi på tilstandsendringer Står stille (to ulike tilstander) Enten fordi du har festet sikkerhetsbeltet og er klar til å kjøre, Eller fordi sikkerhetsbeltet ikke er festet

64 Oppgave 3(e): Løsningsforslag Deretter ser vi på tilstandsendringer Kjører forover Tråkker på gassen

65 Oppgave 3(e): Løsningsforslag Deretter ser vi på tilstandsendringer Kjører bakover Setter bilen i revers

66 Oppgave 3(e): Løsningsforslag Gir oss tilstandsdiagrammet:

67 Oppgave 4: Smidig utvikling Anta at du er en konsulent som er leid inn til et prosjekt som har som hovedoppgave å rette feil i et stort og avansert system. Det viser seg at teamet som jobber med feilretting ikke klarer å rette alle feil som blir rapportert, raskt nok. Teamet bruker Scrum. Du har god erfaring fra bruk av Kanban fra tidligere og mener at Kanban også kan brukes i dette prosjektet. Argumenter for at teamet bør gå over til bruk av Kanban.

68 Oppgave 4: Løsningsforslag Argumenter for at teamet bør gå over til bruk av Kanban. Kanban Smidig Baserer seg på prinsipper fra Lean-produksjon Fokus på flyt av arbeidsoppgaver (Work in Progress, WIP) Just-in-time Sikre god og effektiv utførelse Waste Redusere tid- og ressursbruk på oppgaver som ikke har verdi for koden Teamets hovedoppgave er å rette feil Enklere å forholde seg til flyt fremfor avgrensede oppgaver innen et gitt tidsrom Kan legge til nye oppgaver når som helst I Scrum må iterasjoner fullføres Ledige utviklere trenger ikke vente på neste sprint

69 Takk til Foilene er basert på Tidligere presentasjoner laget av Emilie Hallgren og Kristin Brænden Eksisterende forelesningsnotater av Dag Sjøberg og Yngve Lindsjørn Sommerville, I. (2010). Software Engineering (9th Edition). Pearson.

70 Takk for meg Neste uke : Gjennomgang av oblig 3