Eksamen INF1050: Gjennomgang, uke 15

Transkript

1 Eksamen 2012 INF1050: Gjennomgang, uke 15

2 Overblikk Varierte spørsmål fra pensum Modellering Use case Tekstlig beskrivelse Sekvensdiagram Klassediagram Krav Empiriske metoder Smidig metodikk

3 Varierte spørsmål fra pensum

4 Oppgave 1.1 Programmering er sentralt i systemutvikling. Nevn andre aktiviteter som er nødvendige i systemutvikling.

5 Oppgave 1.1: Løsningsforslag Nødvendige aktiviteter i systemutvikling

6 Oppgave 1.2 Beskriv kort forskjellen på hyllevare-systemer og skreddersydde eller spesialtilpassede systemer.

7 Oppgave 1.2: Løsningsforslag Hyllevaresystemer Generiske systemer Kjøpes og konfigureres for å dekke kundens behov Eksempel: Microsoft Office Spesialtilpassede systemer Lages fra bunnen av Skreddersys til kundens spesifikke behov Eksempel: Markasykkelsystemet

8 Oppgave 1.3 Pålitelighet, ytelse og sikkerhet er eksempler på krav av en bestemt type. Hva kalles denne typen?

9 Oppgave 1.3: Løsningsforslag Ikke-funksjonelle krav Beskriver hvordan systemet skal oppføre seg Eller: Hvordan systemet skal innfri de funksjonelle kravene Ulike kvalitetsattributter som skal assosieres med systemet Beskriver ofte systemet som en helhet Motsetning: Funksjonelle krav Beskriver hva systemet skal gjøre Tar for seg spesifikk funksjonalitet

10 Oppgave 1.4 Dersom du skal utvikle et system der du allerede kjenner til krav, bruksmønstre og funksjonsbehov; hvilken prosessmodell kan være egnet da?

11 Oppgave 1.4: Løsningsforslag Plandrevet utvikling Fossefallsmodellen Utviklingen styres av planer Best ved godt forståtte krav / liten sannsynlighet for endring underveis Enklere å koordinere arbeidet

12 Oppgave 1.5 Er sluttbrukere av et system typisk involvert i whitebox- eller blackbox-testing?

13 Oppgave 1.5: Løsningsforslag Blackbox-testing Spesifikasjonsbasert testing Tester funksjonaliteten i henhold til spesifikasjonen Hva skal komponentene gjøre? Gjør komponentene som de skal? Dette kan sjekkes av kunden / sluttbrukere Ikke fokus på underliggende struktur

14 Oppgave 1.5: Løsningsforslag Whitebox-testing Strukturbasert testing Tester den interne strukturen til systemet Hvordan realiseres funksjonaliteten? Hvilken logikk ligger i grunn? Eksaminerer kildekoden Brukes ofte for å måle dekningsgrad av testene Hvor mye er testet?

15 Oppgave 1.6 I et klassediagram deler man ofte opp klasseboksene i to. På den ene siden av streken står klassens metoder. Hva står på den andre siden?

16 Oppgave 1.6: Løsningsforslag Representasjon av klasser i UML Klasser deles i tre Øverste Navn Midtre Attributter med type Nederste Metoder med returverdi Symboler for synlighet + public - private # protected ~ package

17 Oppgave 1.7 Hva kalles metoden hvor man tester systemet utenfra?

18 Oppgave 1.7: Løsningsforslag Blackbox-testing Ser på systemet som en svart boks Bryr oss ikke om hva som ligger inne i boksen Funksjonalitet i henhold til spesifikasjon er det interessante Ønsker kun å se om systemet gjør som det skal Ikke fokus på hvorfor eller hvordan systemet oppfører seg

19 Oppgave 1.8 Hvilket objekt slutter å eksistere i et sekvensdiagram etter at bruksmønsteret er fullført?

20 Oppgave 1.8: Løsningsforslag Forenklet om objekter Forretningsobjekter (entity objects) Skal lagres (eksempelvis i en database) Representerer ting i en virksomhet Kunde, emne, kontrakt, osv. Kontrollobjekter (control objects) Koordinerer alle handlingene i et bruksmønster Representerer noe som skal gjøres i virksomheten Registrer kunde, meld på emne Slutter å eksistere etter at bruksmønsteret er fullført Kantobjekter (boundary objects) Kommuniserer med aktører (via grensesnitt) og kontrollobjekter

21 Oppgave 1.8: Løsningsforslag Om CRC: Class-Responsibility-Collaboration Opprinnelig brukt for å illustrere konsepter innen objektorientering Flashcards Verktøy for modellering

22 Oppgave 1.8: Løsningsforslag Eksempel: Meld på kurs Bruker CRC-kort for å tydeliggjøre avhengigheter og forhold

23 Oppgave 1.8: Løsningsforslag Utdrag til et sekvensdiagram for Meld på kurs Viser kontrollobjektets levetid

24 Oppgave 1.8: Løsningsforslag Utdrag til et sekvensdiagram for Meld på kurs

25 Oppgave 1.9 Nevn to vanlige prosessmodeller.

26 Oppgave 1.9: Løsningsforslag Fossefall Plandrevet utvikling Statisk kravspesifikasjon Prioriterer å utvikle systemet i henhold til en forhåndsdefinert plan Ett endelig produkt Scrum Smidig utvikling Dynamisk kravspesifikasjon Bruk av sprinter (iterasjon) og daglige møter Tett kundekontakt gjennom hele utviklingen

27 Oppgave 1.10 Når egner fossefallsmodellen seg best?

28 Oppgave 1.10: Løsningsforslag Når er det best å bruke fossefall? Ved godt forståtte krav Liten sannsynlighet for endring underveis Store geografiske avstander mellom utviklere Enklere å koordinere arbeidet Sikkerhetskritiske systemer Kravene må være fastsatt / endres ikke underveis Krever grundig dokumentasjon

29 Oppgave 1.11 Forklar forskjellen på et inkrement og en iterasjon.

30 Oppgave 1.11: Løsningsforslag Iterasjon Fase (i tid) / syklus i utviklingen Et aspekt ved prosessen Spesielt brukt i smidige metodikker Sprinter i Scrum Inkrement Tillegg i funksjonalitet Et aspekt ved systemet Utvikles i løpet av en iterasjon

31 Oppgave 1.12 I hvilken metode (eller prosessmodell) er det mest vanlig med inkrementell utvikling?

32 Oppgave 1.12: Løsningsforslag Smidig utvikling Husk det smidige manifest Høyeste prioritet er å tilfredsstille kunden Ønsk endringer i krav velkommen Lever fungerende programvare hyppig Med jevne mellomrom reflekterer teamet Slike prinsipper er best innfridd gjennom inkrementell utvikling Eksempel: Scrum, Kanban

33 Oppgave 1.13 Nevn noen fordeler ved smidig metodikk.

34 Oppgave 1.13: Løsningsforslag Fordeler ved smidig utvikling Enklere å endre prosessen ved endringer i krav Planleggingen gjøres inkrementelt De delene som må endres er mindre sammenlignet med plandrevet utvikling Tettere samarbeid med kunden Fanger opp endringer tidligere Ellers gunstig ved Utvikling av nye/innovative ideer / Små team og prosjekter Prosjekter med betydelig sannsynlighet for at kravspesifikasjonen endres

35 Oppgave 1.14 Hva er forskjellen på en Scrum Master og en tradisjonell prosjektleder?

36 Oppgave 1.14: Løsningsforslag Scrum master Tilrettelegger for Scrum som rammeverk Sørger for at Scrum blir implementert korrekt Bindeledd mellom prosjektet (utviklere) og kunden Ikke en leder for utviklere, men støtter produkteier Prosjektleder Tar avgjørelser, planlegger, overser prosjektets fremdrift Sørget for at prosjektet når sine mål

37 Oppgave 1.15 Hva gjør en PO (product owner)?

38 Oppgave 1.15: Løsningsforslag Produkteier (Product Owner, PO) Ansvarlig for backlog Prioritert liste over arbeidsoppgaver som skal utføres Funksjonalitet som skal implementeres Representerer kunden Sørge for at utviklere jobber best mulig Hvordan kan man oppnå prosjektets mål og jobbe effektivt? Forstår alle backloggen?

39 Oppgave 1.16 Hva er åpen kildekode?

40 Oppgave 1.16: Løsningsforslag Åpen kildekode Open source Desentralisert utvikling Kildekoden gjøres tilgjengelig for alle Finnes mange ulike lisenser for åpen kildekode GNU General Public License Eksempler på programvare med åpen kildekode Apache PHP Mozilla Linux

41 Oppgave 1.17 Hva viser use case-diagrammer?

42 Oppgave 1.17: Løsningsforslag Use case-diagrammer viser Aktører Både primære og sekundære Systemets funksjonalitet Hvilke funksjoner som er tilgjengelige for aktøren Med andre ord: Hvem kan gjøre hva? Samspill mellom systemet og omgivelsene Eks. brukere, andre systemer, komponenter

43 Oppgave 1.18 Hvilke typer krav beskriver et use case?

44 Oppgave 1.18: Løsningsforslag Use case-diagrammer viser funksjonelle krav Hva er det aktøren kan gjøre med systemet?

45 Oppgave 1.19 Hva er en aktør i use case-modellering?

46 Oppgave 1.19: Løsningsforslag Aktører i use case-diagrammer Brukere av systemet Andre systemer og komponenter Som kalles / mottar informasjon Primæraktører Har egne mål med systemet Sekundæraktører Nødvendige for å realisere primæraktørenes mål

47 Oppgave 1.20 Hva viser aktivitetsdiagrammer?

48 Oppgave 1.20: Løsningsforslag Aktivitetsdiagrammer Flytskjema (flowchart) Grafisk representasjon av arbeidsflyt Viser aktiviteter og tilhørende handlinger Viser overordnet kontrollflyt Hvilke aktiviteter som kan utføres parallelt Hvordan mulige utfall av en aktivitet påvirker flyten Aktivitetsdiagram utgjør en del av standarden til UML 2.0

49 Modellering av en nettbank Use case-diagram Tekstlig beskrivelse Sekvensdiagram Klassediagram

50 Oppgave 2: Bakgrunn Du skal lage en modell for et program som skal implementeres for en nettbank. Kunden logger seg inn i nettbanken med brukernavn og passord (som genereres fra en ID-brikke). Følgende tabell beskriver funksjoner som skal være tilgjengelig etter vellykket innlogging.

51 Oppgave 2: Krav

52 Oppgave 2(a) Bruk tabellen til å lage et use case-diagram. Inkluder alle nødvendige bruksmønstre for å oppfylle de funksjonelle kravene.

53 Oppgave 2(a): Løsningsforslag Bruk tabellen til å lage et use case-diagram.

54 Oppgave 2(a): Løsningsforslag Bruk tabellen til å lage et use case-diagram. Hva er de funksjonelle kravene? Hvordan kan dette uttrykkes som use case?

55 Oppgave 2(a): Løsningsforslag Bruk tabellen til å lage et use case-diagram. Hva er de funksjonelle kravene? Hvordan kan dette uttrykkes som use case?

56 Oppgave 2(a): Løsningsforslag Bruk tabellen til å lage et use case-diagram. Hva er de funksjonelle kravene? Hvordan kan dette uttrykkes som use case?

57 Oppgave 2(a): Løsningsforslag Bruk tabellen til å lage et use case-diagram. Hva er de funksjonelle kravene? Hvordan kan dette uttrykkes som use case?

58 Oppgave 2(a): Løsningsforslag Bruk tabellen til å lage et use case-diagram. Hva er de funksjonelle kravene? Hvordan kan dette uttrykkes som use case?

59 Oppgave 2(a): Løsningsforslag Bruk tabellen til å lage et use case-diagram. Hva er de funksjonelle kravene? Hvordan kan dette uttrykkes som use case?

60 Oppgave 2(a): Løsningsforslag Bruk tabellen til å lage et use case-diagram. Hvilke antakelser gjør vi? Visning av transaksjoner (siste / tidsintervall) skjer via visning av kontoer <<include>> Legg til betalingsmottaker Utvidelse av betal regning <<extend>> Endring av betalingsmottaker Trenger en oversikt over de man skal endre <<include>>

61 Oppgave 2(a): Løsningsforslag Bruk tabellen til å lage et use case-diagram.

62 Oppgave 2(b) Du skal nå fokusere på bruksmønsteret Betal regning der aktøren nettbankkunde skal kunne betale en regning fra en konto tilgjengelig i nettbanken til en betalingsmottaker. Dersom mottakeren ikke finnes fra før, skal det være mulig å legge inn denne som fast mottaker. Når alle opplysningene om betalingen (mottakers konto, beløp, KID, dato) er lagt inn og brukeren trykker OK, legges betalingen til godkjenning, forutsatt at alle opplysningene er korrekte. Ved godkjenning av betalingen blir kunden bedt om brukernavn og passord. Gi en tekstlig beskrivelse for bruksmønsteret Betal regning med pre- og postbetingelser, hovedflyt, og minst én alternativ flyt.

63 Oppgave 2(b): Løsningsforslag Gi en tekstlig beskrivelse for Betal regning

64 Oppgave 2(c) Lag et sekvensdiagram for Betal regning. Følgende objekter kan være nyttige: bank: Sjekker om brukernavn, passord, mottakers kontonummer og KID er gyldige konto: Sjekker om det er dekning på konto for å betale beløpet

65 Oppgave 2(c): Løsningsforslag Lag et sekvensdiagram for Betal regning.

66 Oppgave 2(d) Lag et klassediagram for Betal regning. Diagrammet skal inkludere metoder, assosiasjoner og attributter som er nødvendig for utførelsen av bruksmønsteret med hovedflyt og variasjonene at kontonummer eller KID-nummer ikke eksisterer. Du trenger ikke spesifisere parametere eller returverdier i metodene.

67 Oppgave 2(d) Lag et klassediagram for Betal regning.

68 Krav og empiriske metoder Ikke-funksjonelle krav Design av studier

69 Oppgave 3(a) Foreslå tre ikke-funksjonelle krav som kan være fornuftige i en nettbankløsning. Begrunn svaret.

70 Oppgave 3(a): Løsningsforslag Foreslå tre ikke-funksjonelle krav. Krav om brukervennlighet Nye brukere må kunne benytte seg av systemet uten opplæring Krav om sikkerhet Systemet skal ikke la en bruker logge seg inn på to ulike steder samtidig Systemet skal ikke autentisere brukere med feil passord Systemet skal ikke la innloggede brukere se andres data / historikk Krav om pålitelighet Ikke mulig å utføre en ny transaksjon før alle tidligere transaksjoner er blitt belastet

71 Oppgave 3(b) Tenk deg at nettbanken beskrevet i oppgave 2 har vært i bruk i to år, med blant annet kravene du foreslo under punkt (a). Du får beskjed om å undersøke i hvilken grad disse kravene faktisk er oppfylt. Beskriv en egnet studie for å undersøke dette. Du velger selv metode(r).

72 Oppgave 3(b): Løsningsforslag Foreslå egnet studie for å undersøke om de ikkefunksjonelle kravene oppfylles. Krav om brukervennlighet Eksperiment / Case studie / Brukertester Intervju og spørreundersøkelser Krav om sikkerhet Sikkerhetstester for å avdekke eventuelle feil / mangler i implementasjonen Krav om pålitelighet Stress- og pålitelighetstester

73 Smidig metodikk Hvorfor smidig? Utfordringer med smidig tilnærming

74 Oppgave 4(a) Hva tror du er årsaken til at smidig metodikk har blitt så vanlig i systemutvikling?

75 Oppgave 4(a): Løsningsforslag Hva tror du er årsaken til at smidig metodikk har blitt så vanlig i systemutvikling? Kunden er mer involvert Korte iterasjoner som leverer verdi til kunden Sørger for at man bygger det som faktisk skal bygges Kunden føler økt eierskap til systemet Enklere å håndtere endringer underveis i utviklingen Tilpasningsdyktig Man er ikke bundet til en forhåndsdefinert plan Reduserer risiko for prosjektfiasko

76 Oppgave 4(b) En matvarekjede skal utvikle et nytt system for å holde orden på logistikken i alle sine butikker (prising, varelager, osv.). Systemets hovedleverandør er et programvareselskap med utviklingsressurser både i Norge og i India. Til sammen er det ti ulike team som står for utviklingen av systemet (fem i Norge og fem i India). Det er bestemt at teamene skal benytte smidig metodikk (Scrum) under utviklingen. To av teamene har også teammedlemmer som sitter i India og er med på blant annet sprintplanlegging og daglige møter. I tillegg er det tre av teamene i India som jevnlig må ha koordineringsmøter med ett av teamene i Norge. Diskuterer eventuelle utfordringer ved denne ordningen.

77 Oppgave 4(b): Løsningsforslag Diskuter eventuelle utfordringer ved denne ordningen. Scrum ikke like godt tilrettelagt for geografisk spredte prosjekter Baserer seg på det smidige manifest Beste måten å kommunisere på er ansikt-ti-ansikt Praktiske utfordringer Tidsforskjeller Vanskelig å holde daglige standups Kulturelle utfordringer Arbeidsmåte, hierarki, kommunikasjons, osv.

78 Oppsummering

79 Spørsmål? Ta kontakt Yulai Fjeld uio.no Husk å inkludere emnekoden! Andre gruppelærere Delta på gruppetimene

80 Takk til Foilene er basert på Erik Arisholm. ( ). Fra krav til objekter. UiO, IFI. 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.

81 Takk for meg Neste uke : Forskningsmetoder