Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12

Transkript

1 Løsningsforslag: Oblig 1 INF1050: Gjennomgang, uke 12

2 Obligatorisk oppgave 1: Pensum Bakgrunn for systemet Aktører og interessenter Utviklingsprosesser Kravhåndtering og kravspesifikasjon Use case-modellering

3 Oppgave 1: Bakgrunn for systemet Systemet for utleie av markasykler ønsker å benytte seg av en eksisterende betalingsløsning, og valget har falt på project det title samme betalingssystemet som brukes for Ruter. Dette betyr at man kan betale via Ruter-appen eller benytte seg av betalingsautomatene. Ved henting og levering av sykler bruker man enten Ruterappen og oppgir kode, eller skanner Ruter-kortet.

4 Oppgave 1(a) Nevn fordeler og ulemper ved å benytte Ruters løsning fremfor å utvikle en betalingsløsning selv.

5 Oppgave 1(a): Løsningsforslag Nevn fordeler og ulemper ved å benytte Ruters løsning fremfor å utvikle en betalingsløsning selv. Fordeler Ressursbesparende Mindre å utvikle selv Sparer tid Færre eksterne krav å ta hensyn til Den eksisterende løsningen fungerer Godt testet Kunden har kjennskap til løsningen Mindre å forholde seg til for kundene Mange benytter seg allerede av den eksisterende betalingsløsningen

6 Oppgave 1(a): Løsningsforslag Nevn fordeler og ulemper ved å benytte Ruters løsning fremfor å utvikle en betalingsløsning selv. Ulemper Økte kostnader for å få lov til å benytte seg av den eksisterende løsningen Ruter kan kreve betaling for løsningen Avhengig av Ruters teknologi Implementasjon Løsningen er ikke laget for sykkelsystemet Kan være vanskelig å implementere Får ikke satt opp betalingsautomater uten Ruters samtykke Kunder må forholde seg til to aktører; én for betaling og én for kunderegistrering

7 Oppgave 1: Bakgrunn for systemet Det finnes allerede et system for bysykler. Selv om sykling i byen og marka har en del fellestrekk, skiller de seg fra hverandre på flere punkter. Derfor velger utviklerne å utvikle et nytt system for markasykler.

8 Oppgave 1(b) Hvilke aspekter ved markasykler skiller seg fra bysykler? Nevn fordeler og ulemper ved å benytte et nytt system.

9 Oppgave 1(b): Løsningsforslag Hvilke aspekter ved markasykler skiller seg fra bysykler? Nevn fordeler og ulemper ved å benytte et nytt system. Aspekter som skiller markasykler fra bysykler Utleietid av syklene Type sykler som kan leies GPS-system som kartlegger de ulike turene Syklene krever økt vedlikehold Andre forhold Vanskeligere å hente eller flytte sykler Sykler plasseres på steder som ikke er lett tilgjengelige

10 Oppgave 1(b): Løsningsforslag Hvilke aspekter ved markasykler skiller seg fra bysykler? Nevn fordeler og ulemper ved å benytte et nytt system. Fordeler Får et spesialtilpasset system Skreddersydd for markasykler Blir uavhengig av systemet for bysykler Kan bli billigere for kundene dersom man kun bruker markasykler En fellesløsning kunne krevd at man var kunde hos begge parter

11 Oppgave 1(b): Løsningsforslag Hvilke aspekter ved markasykler skiller seg fra bysykler? Nevn fordeler og ulemper ved å benytte et nytt system. Ulemper Tid Sparer tid hvis man implementerer løsningen fra bysykler Tungvint for kunder som benytter seg av begge løsningene Enklere å registrere seg kun ett sted

12 Oppgave 2(a) Hva er forskjellen på en aktør og en interessent?

13 Oppgave 2(a): Løsningsforslag Hva er forskjellen på en aktør og en interessent? Aktør En som bruker systemet Et annet system som brukes av systemet Interessent Mengde personer / grupper / organer som har interesse av systemet Blir påvirket av eller påvirker systemets utvikling og bruk Direkte / indirekte Interessenter både påvirker og påvirkes av kravspesifikasjonen Alle aktører er interessenter, men ikke alle interessenter er aktører

14 Oppgave 2(b) Kartlegg minst seks interessenter knyttet til systemet for markasykler. Få med navn, ansvarsområder, og interesser tilhørende hver interessent.

15 Oppgave 2(b): Løsningsforslag

16 Oppgave 2(c) Hvilke av interessentene er også aktører?

17 Oppgave 2(c): Løsningsforslag Hvilke av interessentene er også aktører? Aktører Må være brukere av systemet Interessenter som også er aktører Kunde (bruker) Benytter seg av systemet for å leie sykler Kundebehandler Benytter seg av systemet for å bistå med utleie Ruter Eier Kan hente ut rapporter og lignende

18 Oppgave 3(a) Hva kjennetegner plandrevne utviklingsprosesser?

19 Oppgave 3(a): Løsningsforslag Hva kjennetegner plandrevne utviklingsprosesser? Plandrevet utvikling Prosessaktivitetene er planlagt på forhånd Progresjon måles i henhold til planen Fortunge prosesser Inkluderer mange aktiviteter og roller Krever formelle og detaljerte prosjektdokumenter Statisk kravspesifikasjon Utfordrende å tilpasse endringer i brukerkrav underveis Brukes ofte i store og sikkerhetskritiske prosjekter Eller prosjekter som utvikles på ulike (geografiske) steder

20 Oppgave 3(b) Hva kjennetegner smidige utviklingsprosesser?

21 Oppgave 3(b): Løsningsforslag Hva kjennetegner smidige utviklingsprosesser? Smidig utvikling Planleggingen gjøres inkrementelt Litt etter litt underveis i utviklingen Vektlegger kode Fremfor omfattende design og dokumentasjon up front Enklere å endre prosessen for å kunne ta høyde for endringer i krav fra kunden Dynamisk kravspesifikasjon Vektlegger samarbeid og dialog med kunden Fremfor kontraktsforhandlinger

22 Oppgave 3(c) I hvilken grad bør man ta høyde for at kravspesifikasjonen til markasykkelsystemet må endres underveis?

23 Oppgave 3(c): Løsningsforslag I hvilken grad bør man ta høyde for at kravspesifikasjonen til markasykkelsystemet må endres underveis? Faktorer man bør ta hensyn til Det eksisterer allerede en lignende løsning for bysykler Utviklere vet omtrent hvilket system som skal utvikles Allikevel aspekter som skiller bysykler fra markasykler Kan kreve markante endringer Eksempelvis: Grensesnitt Fare for at bysykkelteknologien ikke fungerer like bra i marka Lokasjon Vedlikehold Materialer

24 Oppgave 3(d) Hvilken type utviklingsprosess mener dere er best egnet for dette systemet? Forklar hvorfor.

25 Oppgave 3(d): Løsningsforslag Hvilken type utviklingsprosess mener dere er best egnet for dette systemet? Forklar hvorfor. Plandrevet utvikling med elementer fra smidig utvikling Backend Kan i stor grad utvikles med utgangspunkt i bysykler God kravspesifikasjon gjør det mulig å unngå de store endringene Frontend Vanskeligere å unngå kravendringer Ta i bruk smidige elementer Inkrementell levering

26 Oppgave 4(a) I smidig utvikling kan brukerhistorier utgjøre deler av kravspesifikasjonen. Mengden av brukerhistorier kalles product backlog (produktkø). Gi eksempler på ti brukerhistorier. Nevn minst tre forskjellige aktører. Sett opp brukerhistoriene i en prioritert liste basert på hva som er viktigst for sluttproduktets funksjonalitet.

27 Oppgave 4(a): Løsningsforslag Gi eksempler på ti brukerhistorier. Ta med minst tre ulike aktører, og sett og en prioritert liste. Brukerhistorier Beskriver hva brukeren ønsker å få ut av systemet Verdi Inneholder Brukerens rolle Ønsket funksjonalitet Nytteverdi Som [ROLLE] ønsker jeg [FUNKSJON] for å [NYTTEVERDI]

28 Oppgave 4(a): Løsningsforslag Gi eksempler på ti brukerhistorier. Ta med minst tre ulike aktører, og sett og en prioritert liste.

29 Oppgave 4(a): Løsningsforslag Gi eksempler på ti brukerhistorier. Ta med minst tre ulike aktører, og sett og en prioritert liste.

30 Oppgave 4: Krav Funksjonelle og ikke-funksjonelle krav er viktige deler av den fullstendige kravspesifikasjonen for systemet. De tar for seg ulike aspekter ved systemet, og forteller oss hva som må implementeres, samt hvilken kvalitet som skal stilles til implementasjonen. Kravene må være målbare.

31 Oppgave 4(b) Sett opp en liste over ti funksjonelle krav

32 Oppgave 4(b): Løsningsforslag Sett opp en liste over ti funksjonelle krav 1. Systemet skal kunne registrere nye brukere via en nettside 2. Systemet skal kunne generere oversikt over mest brukte stasjoner 3. Systemet skal gi kunden informasjon om tidsbruk og rute (via GPS) 4. Systemet skal kunne vise oversikt over omsetning 5. Systemet skal lage en oversikt over sykler som ikke er levert i tide 6. Systemet skal kunne vise informasjon sykler på de ulike stasjonene 7. Systemet skal kunne la bruker sende inn ønske om nye stasjoner 8. Systemet skal kunne vise oversikt over antall ledige plasser på hver stasjon 9. Systemet skal la brukeren fylle på reisekort 10. Systemet skal kunne finne nærmeste stasjon, basert på brukerens lokasjon

33 Oppgave 4(c) Sett opp en liste over ti ikke-funksjonelle krav Del kravene inn i: Produktkrav Organisatoriske krav Eksterne krav Få med minst to krav fra hver kategori

34 Oppgave 4(c): Løsningsforslag Sett opp en liste over ti funksjonelle krav Produktkrav 1. Nettsiden skal kunne håndtere opptil samtidige brukere 2. Systemet skal kunne håndtere opptil samtidige utlånere 3. Førstegangsbrukere skal registrere seg på under 5 minutter 4. Nettsiden skal være universelt utformet

35 Oppgave 4(c): Løsningsforslag Sett opp en liste over ti funksjonelle krav Organisatoriske krav 1. Systemet skal holde et budsjett på maksimalt 30 millioner NOK 2. Systemets grensesnitt skal utvikles ved hjelp av smidige metoder 3. Nettsiden skal utvikles ved hjelp av HTML, CSS, og JavaScript 4. Systemdokumentasjonen skal dokumenteres på engelsk

36 Oppgave 4(c): Løsningsforslag Sett opp en liste over ti funksjonelle krav Eksterne krav Systemet skal følge personvernloven Systemets betalingsløsning må følge Ruters krav til samarbeid

37 Oppgave 4(d) Forklar hvordan de ikke-funksjonelle kravene skal evalueres

38 Oppgave 4(d): Løsningsforslag Forklar hvordan de ikke-funksjonelle kravene skal evalueres Produktkrav 1 og 2 (Samtidige brukere / utleie) Evalueres ved hjelp av stresstester Produktkrav 3 (Brukervennlighet) Evalueres ved hjelp av brukertester, her måles tid for registrering Produktkrav 4 (Universell utforming) Testes opp mot sjekklisten til DIFI

39 Oppgave 4(d): Løsningsforslag Forklar hvordan de ikke-funksjonelle kravene skal evalueres Alle organisatoriske krav er direkte målbare Ja/Nei-tester Kontroller Eksterne krav Krever innhenting av personer med ekspertise Sjekke gjeldende lovverk og føringer

40 Oppgave 5(a) Tegn et use case-diagram som trengs for å oppfylle de funksjonelle kravene spesifisert i oppgave 4. Ta med alle involverte aktører, både primæraktører og sekundæraktører.

41 Oppgave 5(a): Løsningsforslag Listen over funksjonelle krav 1. Systemet skal kunne registrere nye brukere via en nettside 2. Systemet skal kunne generere oversikt over mest brukte stasjoner 3. Systemet skal gi kunden informasjon om tidsbruk og rute (via GPS) 4. Systemet skal kunne vise oversikt over omsetning 5. Systemet skal lage en oversikt over sykler som ikke er levert i tide 6. Systemet skal kunne vise informasjon sykler på de ulike stasjonene 7. Systemet skal kunne la bruker sende inn ønske om nye stasjoner 8. Systemet skal kunne vise oversikt over antall ledige plasser på hver stasjon 9. Systemet skal la brukeren fylle på reisekort 10. Systemet skal kunne finne nærmeste stasjon, basert på brukerens lokasjon

42 Oppgave 5(a): Løsningsforslag Hvem gjør hva? 1. Systemet skal kunne registrere nye brukere via en nettside [KUNDE, KUNDEBEHANDLER] 2. Systemet skal kunne generere oversikt over mest brukte stasjoner [EIER] 3. Systemet skal gi kunden informasjon om tidsbruk og rute (via GPS) [KUNDE] 4. Systemet skal kunne vise oversikt over omsetning [EIER, KUNDEBEHANDLER] 5. Systemet skal lage en oversikt over sykler som ikke er levert i tide [KUNDEBEHANDLER] 6. Systemet skal kunne vise informasjon sykler på de ulike stasjonene [KUNDE] 7. Systemet skal kunne la bruker sende inn ønske om nye stasjoner [KUNDE] 8. Systemet skal kunne vise oversikt over antall ledige plasser på hver stasjon [KUNDE] 9. Systemet skal la brukeren fylle på reisekort [KUNDE] 10. Systemet skal kunne finne nærmeste stasjon, basert på brukerens lokasjon [KUNDE]

43 Oppgave 5(a): Løsningsforslag

44 Oppgave 5(b) Lag en tekstlig beskrivelse til ett av use casene du foreslo i oppgave 5(a). Ha med pre- og postbetingelser, og minst to alternative flyt.

45 Oppgave 5(b): Løsningsforslag Lag en tekstlig beskrivelse til ett av use casene

46 Oppgave 5(b): Løsningsforslag Lag en tekstlig beskrivelse til ett av use casene

47 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.