PROSJEKT Systemutvikling Rudi Østerhus, Kais Kristensen, Joakim Walstad

Transkript

1 PROSJEKT 2013 UDRUNKBRO? Systemutvikling Rudi Østerhus, Kais Kristensen, Joakim Walstad

2 Forord Denne rapporten er skrevet i løpet av fjerde semester i forbindelse med utgitt prosjektoppgave i faget systemutvikling ved Forsvarets Ingeniørhøgskole, år Rapporten er skrevet av Kais Kristensen, Joakim Walstad og Rudi Østerhus. Først og fremst vil vi takke Harald Liodden for god veiledning, retningslinjer og god tilgjengelighet under rapportskrivingen. Vi vil også takke våre venner, familie og klassekamerater for deres tålmodighet og forståelse i forbindelse med denne hektiske perioden. Det som inspirerte oss til å arbeide effektivt med dette prosjektet var relevansen til temaer som databaser, programmering og ulike typer programvare. Vi har hatt en lærerik periode og håper at det kommer til å bli like lærerikt for den som leser rapporten i ettertid. I

3 Sammendrag Formålet med udrunkbro er å tilføre markedet for mobile enheter en applikasjon som kan forene festdeltakere sosialt gjennom bruk av teknologi. udrunkbro gir folk på samme arrangement mulighet for å registrere sitt konsum av drikke og på denne måten skaffe seg poeng. I applikasjonen kan brukeren se statistikk for sitt eget konsum samt alle andre som deltar på arrangementet. Fortløpende vil udrunkbro presentere nyheter for arrangementet som distribueres til alle enheter på festen, slik sørger udrunkbro for at også teknologien kan brukes til noe sosialt. udrunkbro er en applikasjon utviklet for Android og rettet mot aldersgruppen år, Denne rapporten tar for seg mange aspekter ved utvikling av udrunkbro. Først presenteres en innledende beskrivelse. Videre følger forslag til prosjektorganisering og valg av systemutviklingsmodell samt en risikoanalyse. Informasjon om selve implementasjonen av udrunkbro legges fram i kravspesifikasjonen og arkitekturmodellen II

4 Innhold Forord... I Sammendrag... II Forprosjekt Mål og rammer Bakgrunn Prosjektmål Effektmål Resultatmål Læringsmål Rammer Omfang Oppgavebeskrivelse Oppsummering av hovedfunksjoner Prosjektorganisering Ansvarsforhold Øvrige roller Rutiner og regler i gruppa Planlegging, oppfølging og rapportering Ulike systemutviklingsmodeller Fossefallsmodellen Unified Prosess (UP) Extreme Programming (XP) Scrum Krav til systemutviklingsmodell Oppfølgning Dokumentasjon Tidsfrister, plan Rolledeling Kommunikasjon Valg av systemutviklingsmodell Risikoanalyse Kritiske suksessfaktorer Risikoevaluering Risikoprofil Gjennomføring III

5 6.1 Work-Breakdown Structure Ganttskjema Produkt backlog Ekstrafunksjonalitet Kravspesifikasjon Overordnet use-casediagram Risikoanalyse av overordnet use-casediagram Høynivå use-casebeskrivelser Detaljerte use-casebeskrivelser og sekvensdiagram Logg inn Registrer drink Kvalitetsmessige krav Funksjonskrav Økonomiske krav Brukervennlighet og brukergrensesnitt Ytelse Lagring Pålitelighet Sikkerhet (personvern) Portabilitet Dokumentasjon Interoperabilitet Konseptuelt klassediagram Arkitektur Ulike arkitekturmodeller Repository Klient-tjener Distrubert Objektakritektur Lagdelingsmodell Valg av arkitektur Deployment view Designklassediagram Kontrollmodeller Evaluering av eget arbeid Diskusjon Konklusjon IV

6 Forprosjekt 1 Mål og rammer 1.1 Bakgrunn Fest og moro i helgene er vanlig for mange ungdommer i Norge. Det finnes flere forskjellige metoder ungdommen har funnet på for å more seg med drikkingen sin. Dette kan være alt fra kortspill til rene snakkeleker for å få flere til å drikke mer. Vi har funnet ut at for å gjøre dette litt mer morsomt, og som teknologiinteresserte elever, går det an å blande inn teknologien vi har til disposisjon inn sammen med drikkelekene. Vi har sett at flere og flere har forsøkt å få til drikkeleker på mobile enheter, men svært få har lykkes. Det er derfor et svakt utvalg av slike applikasjoner til mobile enheter. Det skaper et marked for oss. Vi har funnet en mulighet til å være kreative og skape et produkt som vi håper vil selge hos ungdommer. Oppgaven vår blir å skape et produkt som ikke bare promoterer drikking, men som også kan gjøre det mulig for ungdommer å bli mer oppmerksom på hvor lenge alkohol faktisk sitter i kroppen før det blir brutt ned. Vi ønsker å la det være mulig for brukerne å observere sitt eget forbruk og reflektere over det. Denne informasjonen kommer som en indirekte funksjon i applikasjonen. Brukeren kan lese ut denne informasjonen selv ved å utforske applikasjonen. Det finnes flere metoder denne funksjonen kan implementeres på. Vi må derfor være bevisst på at fokuset ikke blir å formidle hvor lenge alkohol sitter i kroppen, men la det være en ekstra funksjon som kan rettes i en mer morsom retning ettersom vi ikke vil gjøre applikasjonen mindre attraktiv. Google sitt operativsystem Android er det mest voksende operativsystemet på mobile enheter for øyeblikket og vi har valgt at applikasjonen skal i første omgang utvikles til dette operativsystemet. Dette gir oss en mulighet til å gjøre suksess på én plattform først, før vi eventuelt utvikler videre. Side 1 av 41

7 1.2 Prosjektmål I dag er det ingen ekstreme behov for en drikkelek på fest. Dette ønsker vi å forandre på. Festdeltakere har en større og større tendens til å bli oppslukt av deres smarttelefoner når de sitter på fest. Dette gjør festdeltakerne mindre sosiale på festen. Applikasjonen vår kan bidra til et økt sosialt samvær, glede og litt konkurranse ved bruk av en smarttelefon. Målet er at det skal være lav terskel for å starte applikasjonen Effektmål - Øke ungdommers bevissthet på hvor mye de drikker. - Øke bevissthet om konsekvenser i form av hvor høy promille en får av konsumering av alkohol. - Øke humøret ved sammenkomster blant venner. - Alle festdeltakere skal kunne se statistikk for å få ett større bilde av hva som skjer på festen Resultatmål Løsningen som vi kommer med er en enkel og ryddig applikasjon. Det skal ta minst mulig tid for å kunne registrere en enhet som konsumeres. Vi ønsker å få jobbet og fremmet vårt produkt så raskt som mulig. Derfor foreligger følgende faste holdepunkter som: - Implementering skal være påbegynt innen 1. august Lansering på Google Play 7. februar brukere innen 1. juni Reklameinntekter skal dekke driftskostnader Læringsmål Dette prosjektet krever at vi legger til grunn kunnskap som vi allerede har. Læringsmålene for prosjektet er å få innblikk i utarbeiding av dokumentasjon og kravspesifikasjon, planlegging og samarbeid. Dette er essensielle faktorer for at prosjektet skal kunne ferdigstilles som det produktet vi ser for oss og for at vi skal oppnå ønsket resultat. Under utviklingen av applikasjonen vil ideutviklerne gjøre seg erfaringer og eventuelt skaffe seg ny programmeringskunnskap. Med denne kompetansen kan vi eventuelt i etterkant videreutvikle og forbedre applikasjonen. Fordi dette er første gang vi gjennomfører et prosjekt med relativt stort omfang, krever dette gode løsninger og godt samarbeid. Dette pålegger oss god planlegging. For å kunne gjøre dette krever det god struktur og kreativ tankegang gjennom hele prosjektet. Dokumentasjon vil være en av faktorene innenfor planlegging og struktur som vi må lære oss å utarbeide og forholde oss til. Erfaringer vi kan dra ut i fra prosjektet i etterkant vil være hvordan det er å kunne jobbe med et større prosjekt som en gruppe. Vi vil kunne se hvor viktig det er med samarbeid i slike situasjoner vi ofte finner i arbeidslivet. Løsningen vi utarbeider skal kunne implementeres i applikasjonsbutikken «Google Play», det er derfor viktig at vi følger retningslinjer som er utstedt av applikasjonsbutikken. Ettersom dette er en idé som kommer ut av kreativitet trenger vi å sette oss inn i hvordan de forskjellige typer programmeringsspråk vi skal kode i og hvordan forskjellig programmer vi skal bruke fungerer. For å kunne implementere ideene våre i applikasjonene, krever dette at vi kjenner til begrensninger både i programvare og i språk. Deretter kan vi innføre det vi ønsker å implementere. Side 2 av 41

8 1.3 Rammer Juridiske rammer - Applikasjonen i seg selv og måten den blir brukt på skal ikke bryte med norske eller internasjonale lover. - Personopplysninger skal kun være synlig for brukeren selv. - Brukerens aktivitet loggføres midlertidig og Dataene lagres bare i perioden et arrangement varer, i praksis lengden til en fest (arrangement i systemet). Teknologiske rammer - Systemet skal være lett å drifte og vedlikeholde. - Systemet behandler og lagrer informasjon sentralt i en database. Økonomiske og tidsmessige rammer - Lønn til utviklere vil bli satt ved en sum for ferdig produkt. Dette vil i senere tid kunne endres ved mulig videreutvikling. - Serverplass og båndbreddeleie er en utgift som vil bli begrenset ved en fast månedlig sum som skal budsjetteres. - Prosjektet skal utvikles og ønskes satt i drift i løpet av de neste 6 måneder. Kostnadsrammen for prosjektet er på NOK. Denne rammen settes for ikke å ha et stort overskridende tap i forhold til forventet inntekt. - Utviklingen av systemet har en tidsramme på 6 måneder. Side 3 av 41

9 2 Omfang 2.1 Oppgavebeskrivelse udrunkbro er en sosial applikasjon hovedsakelig rettet mot aldersgruppen fra 18 til 30 år. Applikasjonen tilbyr en grafisk framstilling av alkoholinntaket til en vennegjeng. De vil med hver sin håndholdte enhet, for eksempel en mobil, registrere sitt forbruk av drikke og på den måten delta i en sosial konkurranse. Hver deltaker er representert med en brukerprofil i systemet og gjennom applikasjonen vil brukeren registrere inntaket av øl, vin og sprit. Applikasjonen som kjører på en håndholdt enhet vil beregne promillen basert på faktorene vekt, volum og tid, og ut i fra dette beregne en poengsum. Systemet baserer seg på en klient-servermodell. Poengberegning utføres av den håndholdte enheten til brukeren, som sender disse dataene til en sentral server. Serveren eies eller leies og driftes av leverandøren/utvikleren av applikasjonen. Den håndholdte enheten kan framstille dataene i databasen som en grafisk framstilling. Algoritmen for å gjøre dette ligger altså bare på de håndholdte enhetene, men applikasjonen må få tilsendt nødvendig data fra serveren. Å la poengberegning bli utført i telefonen fører til en enkel serverstruktur, noe som sparer regnekraft og båndbredde ettersom alt som sendes er ferdigberegnede data. Distribuering av data er basert på at brukere deltar i arrangementer. Når en enhet ønsker å framstille grafiske resultater vil den få tilsendt data for alle brukere på samme arrangement. Når en bruker ønsker å opprette et nytt arrangement oppdaterer brukeren profilen sin med et nytt arrangementnavn. Andre brukere kan bli med i arrangementet ved å skrive inn dette arrangementnavnet i sin applikasjon. Systemet kan deles opp i ulike moduler. Disse er nærmere beskrevet i 6 Gjennomføring. Side 4 av 41

10 De grafiske framstillingene innebærer poengsummer, inntak og promille i form av stolpediagrammer, kakediagrammer og punkter i et aksesystem. Figur 1: Skisse av grafiske framstillinger av data Ved oppstart av applikasjonen skal brukeren registrere sitt valgfrie kallenavn, for- og etternavn og vekt. Disse dataene står til en unik ID på serveren. 2.2 Oppsummering av hovedfunksjoner Lagret informasjon i systemet omfatter bruker- og konsumregistrering i en sentral database. Brukeren tilbys et grafisk brukergrensesnitt for denne registreringen. Databasen distribuerer data til enheter for å kunne framstille data grafisk, i form av tabeller og grafer. Systemet lar brukerne opprette arrangementer der de kan la sine venner delta. Det er denne delen sammen med det grafiske som skaper interaksjon mellom flere brukere. Se punkt 6 Gjennomføring for nærmere beskrivelse Side 5 av 41

11 3 Prosjektorganisering Dette prosjektet er startet på bakgrunn av interesser hos ideutviklerne. Innledningsvis vil prosjektgruppa settes sammen og velge en leder. 3.1 Ansvarsforhold Prosjektet er vedtatt å utvikles av en prosjektstab utformet etter modellen: Prosjektleder Økonomi / innkjøpsansvarlig Teknisk sjef Grafisk utseende Kvalitetssikrer Modulansvarlig Databehandling / Database Modulansvarlig Grafisk framstilling Modulansvarlig Bruker/Arrangementer Testpersonell Figur 2: Ansvarsforhold Modellen ovenfor beskriver prosjekts stab samt gruppeledere. Øvrige prosjektmedlemmer er underlagt ledere og ansvarsområder beskrevet i modellen. Rudi Østerhus er prosjektleder og har ansvaret for prosjektrapporten. Han styrer den daglige ledelsen av prosjektet. Øvrige ansvarsområder lederen har er å utarbeide og endre prosjektplanen, organisere ressurser og tildele oppgaver, kontrollere resultater og framdriften, identifisere avvik og foreta justering av planen i henhold til fremdriften. Til prosjektlederen er det stilt en rekke krav. Ut i fra bakgrunn og erfaring fra tilsvarende prosjekter er det konkludert med at lederen innehar: forretningsmessig forståelse, tekniske kunnskaper, lederegenskaper, kommunikasjonsferdigheter, beslutningsdyktighet og organiseringsferdigheter. Prosjektstaben, ledet av prosjektleder, er underlagt styringsgruppen som består av ideutviklerne. Styringsgruppen er tillagt ansvar for å forvalte prosjektets overordnede økonomi (koordinering mot økonomiansvarlig), forvalte prosjektets målsetninger, godkjenne prosjektplaner og endringer og håndtere problemer som prosjektleder ikke kan løse. Vi valgte å ha en styringsgruppe for at det skal være mulig å ha kontroll over systemet mens det er til utvikling hos en tredjepart. Ved bruk av en styringsgruppe vil vi ha full kontroll og mulighet til å bestemme hva som vil skje med systemet under utvikling. Prosjektets skjebne avgjøres alltid av styringsgruppa. Ved en eventuell utvidelse av programvaren så vil denne prosessen være mye enklere fordi en styringsgruppe har god oversikt og et klart bilde av de overordnede målene for prosjektet. Slik utgjør styringsgruppa en handlekraftig enhet. Side 6 av 41

12 Dersom dette prosjektet medfører suksess kan styringsgruppa være starten på en bedrift. Styringsgruppa kan da fortsette med applikasjonsutvikling ved å starte opp nye prosjekter. En overordnet styringsgruppe gjør det lettere å starte opp lignende prosjekter. Side 7 av 41

13 3.2 Øvrige roller Prosjektets systemutviklingsmodell Scrum (nærmere beskrevet i punkt 4.3 Valg av systemutviklingsmodell) definerer tre klare roller: Scrummaster: Torgeir Swift Utgjør ledelsen for prosjektet. Personen med denne rollen jobber for å fjerne hindringer som oppstår og sørger for at teamet fungerer og er produktivt. Han er ansvarlig for å etablere Scrum i praksis, definere regler, sørge for at alle arbeiderne har nødvendig maskinvare og programvareressurser tilgjengelig. Produkteier: Arne Ødegård Har ansvar for innhold, frister, prioritering av implementasjonene og godkjenner både modifikasjon av funksjonalitet og ferdig arbeid. Produkteier leder styringsgruppa. Teammedlemmer: Bjørnar Fjellheim, Karl Ivar Hansen, Leif Kornelius, Pål Antonsen, Halgeir Jensen, Arnfinn Simonsen Består av utviklere, testere, grafisk-grensesnittdesignere og øvrige roller gitt i figuren ovenfor. De utfører de aktuelle utviklings- og implementeringsjobbene. Medlemmene innehar spesifikk kompetanse, men tildeles ingen titler og hver av dem kan bli involvert i hvilken som helst aktivitet, uavhengig av deres kompetanseområde. Prosjektet skal i tillegg ha en økonomi og innkjøpsansvarlig fordi den økonomiske rammen skal holdes så rimelig som mulig og samtidig som prosjektet holder best mulig kvalitet. Personen skal bistå både i innkjøp og valg av teknologi. For å oppnå ønsket suksess vil prosjektet i stor grad ha behov for kvalitetssikring. En gruppe bestående et lite utvalg fra målgruppen vil representere testpersonellet. Det er disse som vil bruke systemet i praksis. Målgruppen vet mye om funksjonalitet og tjenester i applikasjoner laget for sosiale medier. De vil teste brukervennligheten til systemet og gi konstruktive tilbakemeldinger fortløpende. En person fra utviklingsteamet vil stå med hovedansvaret for kvalitetssikringen. Den tekniske utviklingen og grafiske utformingen av prosjektet er under ansvar av personell i prosjektgruppa. Prosjektgruppa er avhengig av å inneha kompetansen den trenger selv grunnet økonomi og mulig konkurranse i markedet, vi ønsker ikke at ideen skal lekke ut tidligere enn nødvendig. 3.3 Rutiner og regler i gruppa Gruppereglene for vår gruppe er: Hvert gruppemedlem er selv ansvarlige for å jobbe med prosjektet i minst 30 timer i uka. Gruppemedlemmene fører arbeidslogg på et felles dokument etter endt arbeidsdag. Arbeidsoppgavene diskuteres og delegeres i fellesskap. Hvis en avtalt oppgave ikke er gjennomført, skal det begrunnes godt. Ved fravær skal vedkommende varsle det andre gruppemedlemmet så fort som mulig, Skal kunne dokumenteres. Ved signering av dokumenter som har med prosjektet å gjøre, skal begge parter signere. Avgjørelser blir tatt i fellesskap der 2/3 flertall gjelder. Hvis brudd på reglene blir dette tatt opp med prosjektveileder, Harald Liodden. Side 8 av 41

14 4 Planlegging, oppfølging og rapportering 4.1 Ulike systemutviklingsmodeller Fossefallsmodellen Fossefallsmodellen er en streng modell når det kommer til hvilket utviklingsstadium man jobber i. Her jobber man med en og en aktivitet. Aktiviteten eller delen av programmet utvikles ferdig før man begynner på neste del. Det er altså en god orden og struktur i utviklingen. Det er en fordel fordi hver fase kan dokumenteres grundig. Ulempen med en stegvis tilnærming er at feil oppdages ofte etter at en fase er avsluttet, for eksempel under utvikling av neste modul eller ved testing av systemet. De feil og mangler som oppdages får man ikke endret på, løsningen blir å programmere slik at de andre delene av programmet kan håndtere svakhetene man har oppdaget. Det betyr at denne modellen bør brukes når alle krav er klart definert og kjent på forhånd, slik kan man forhåpentligvis forutse de utfordringer man står ovenfor. Fossefallsmodellen gjør sin risikoanalyse i en tidlig fase. Det kan by på problemer senere i utviklingen, fordi når fasen er avsluttet er det ingen mulighet til å gå tilbake å endre risikoanalysen selv om nye risikoer skulle oppstå. Det er derfor lite rom for endringer i fossefallsmodellen. På grunn av den strenge, trinnvise utviklingen vil man ha et usynlig produkt fram til ferdigstilling av hele prosjektet. Fossefallsmodellen utelukker også all form for parallellitet og simultan utvikling, det gjør modellen treg Unified Prosess (UP) Dette er en modell som henter ulike prinsipper og tar det beste fra andre modeller og forener alt i en stor verktøykasse. UP har implementert fasedeling og dokumentasjonskrav fra fossefallsmodellen. Faseinndeling bygger på tanken om inkrementell utvikling ved å bygge systemet opp del for del. UP implementerer prinsippet om å være evolusjonær ved å ha iterasjoner i utviklingsprosessen. Det går ut på å gjenta samme prosess flere ganger med endringer underveis for å forbedre produktet. Fra spiralmodellen henter UP muligheten for å håndtere risikoer systematisk. UP er en helhetlig og omfattende modell. Den beskriver hvem som produserer hva, hvordan og når. UP deles inn i fire faser: idefasen, utdypningsfasen, konstruksjonsfasen og overgangsfasen. I alle fasene inngår flere fokusområder og arbeidsoppgaver, noen av disse er forretningsmodellering, kravspesifisering, testing og prosjektstyring. Hvor mye arbeidsmengde som legges i hvert arbeidsområde varierer med fasene. Kompleksiteten gjør at teamarbeid er viktig og modellen egner seg for store prosjekter. Modellen har også et sterkt fokus på tidsforbruk og krever god kompetanse for å benyttes. Det er fordi dette er en sterkt modell- og diagramdrevet prosess. Det legges mye fokus i å bygge arkitektur og å tegne modeller og diagrammer. Det legger et grunnlag for god dokumentasjon Extreme Programming (XP) Grunntanken i XP er at kunden må være en del av prosjektet. Det er kunden som har det siste ordet i hva som trengs og kvaliteten på det som utvikles. Kunden er med gjennom hele utviklingsprosessen. XP bygger derfor på prinsippet om enkelhet: man gjør det kunden ber om, ingenting mer. Prosjektplanlegging skjer i XP både før utviklingen starter og regelmessig gjennom utviklingen, risikoanalysen skjer derimot hovedsakelig i etableringsfasen. Videre jobber XP etter iterasjonsprinsippet. Den første dagen i hver iterasjon kalles «planning game». Her bestemmes hva som skal utvikles og hvem som jobber med hvem. Det legges opp til daglige møter der kunden og utviklere står i sirkel og legger frem en fremgangsrapport. Etter at en iterasjon er avsluttet vurderes Side 9 av 41

15 prosjektet opp mot en plan for å vurdere hvordan prosjektet ligger an tidsmessig. Et prosjekt som utvikles etter XP skal ha små og hyppige utgivelser. Med brukeren tilstede kan man sikre at systemet fungerer slikt som ønsket. XP setter en øvre grense på maksimalt tolv personer per utviklingsteam. Hvis det er flere medarbeidere så kollapser den muntlige kommunikasjonen. XP sier noe også om hvordan utviklerne skal jobbe: i par fordi det gjør det lettere å løse problemer med flere hoder. Teamarbeid kan også bety at feil oppdages tidligere enn hva individene ville klart på egenhånd. Modellen har et krav til 40 timers arbeidsuke. Det krever opplagte arbeidere og overtid skal aldri forekomme to uker på rad. En skal heller ikke sitte lenge om gangen med en arbeidsoppgave da dette kan lettere føre til feil, som kan ta lang tid å rette opp i etterkant. Ofte bytte av arbeidsoppgaver krever at alle skal ha tilgang til all kode til enhver tid og at alle i prosjektet skal kunne endre kode som andre har skrevet, for å forbedre den Scrum Hovedtanken bak Scrum er at komplekse prosesser best håndteres ved en empirisk tilnærming, som innebærer at man bygger på erfaring og observasjon. Denne empiriske metoden krever synlighet, inspeksjon og tilpasning (agile metoder). Synlighet innebærer at de som styrer selve prosessen må ha innsyn i de faktorer som styrer utfallet av prosessen. Inspeksjon betyr at de forskjellige delene i prosessen må inspiseres ofte nok slik at avvik fanges opp og korrigeres. Avvik som kan føre til at produktet ikke blir akseptert må føre til at noe tilpasses. De nødvendige tilpasningene må gjøres så tidlig som mulig for å sikre at konsekvensene blir så små som mulig. Et prosjekt som benytter Scrum starter med en visjon for produktet som skal utvikles. Dette legger grunnlaget for utarbeidelsen av en prioritert liste over krav og ønsker til produktet, dette kalles produktbacklogg. Utviklingen av prosjektet utføres i intervaller med fast lengde, kalt sprinter. Scrum er altså iterativt og inkrementell, produktfunksjonaliteten vokser inkrementelt ved å legge til nye funksjoner ved hver iterasjon. Hver sprint starter med et planleggingsmøte der utviklerne velger et punkt fra produktbackloggen de tror de kan levere i løpet av kommende sprint. Under selve sprinten møtes utviklerne til en daglig Scrum. Hensikten med møtene er å sikre framdriften. Sprinten avsluttes med et møte der det presenteres hva som er laget i løpet av sprinten. Sprinten skal også evalueres i etterkant. De ulike møtene sikrer en kontinuerlig oppfølgning av både prosjektet og utviklerne. Det er slik avvik kan fanges opp i praksis og korrigeres inn tidlig. Møtene gir verdi til prosjektlederen og sikrer at alle har samme oversiktsbilde. Scrummodellen definerer tre klare roller som er involvert i prosjektet: produkteier, scrummaster og teamet. Hver av rollene har et klart ansvarsområde. I Scrum er det helt greit at alle har sitt spesialområde, dette er en motsetning til XP der alle skal kunne jobbe med alt. For utviklerne som spesialiserer seg kan det gi gode læringsmuligheter og tekniske utfordringer. Ved at de også involveres i diskusjon om hvordan prosjektet samt koding skal løses, har utviklerne naturlig mye motivasjon gjennom prosjektet. Mot slutten av utviklingen skal programmererne få jobbe i fred, da skal det ikke kommer inn nye ting med mindre det er systemkritiske misforståelser. Det innebærer at kunden har en mer tilbaketrukket rolle i Scrum sammenliknet med i XP. Scrum har noen svakheter. Utover produktbackloggen er det ingen krav om dokumentasjon. Modellen gir få muligheter til å fastsette krav og resultater på forhånd. Nøyaktig hva hver iterasjon skal innebære og planen for hver iterasjon avgjøres på møtene i forkant av hver sprint. Det innebærer noe uforutsigbarhet og gjør prosjektet vanskelig eller utfordrende å selge inn til prosjekteiere som ikke er kjent med eller trygg på metodikken. Scrum er derimot enklere å tilpasse Side 10 av 41

16 til eksterne faktorer og endringer, nettopp dette reduserer behovet for å kunne forutsi endringene og framtidige behov. 4.2 Krav til systemutviklingsmodell Valg av systemutviklingsmodell gjøres ut i fra kriteriene som følger: Oppfølgning Det kan hende at kravspesifikasjonen og den økonomiske rammen til produktet må endres på underveis i utviklingen, eksempelvis hvis det oppstår behov for en ny funksjon som skal tilbys. I tillegg ønsker vi å oppdage feil så tidlig som mulig. På grunn av dette må systemutviklingsmodellen inkludere muligheter for oppfølgning. Motivasjonen for dette er at det er mer kostbart å revidere arbeid som er gjort desto lengre tid som går. Jo tidligere revideringer og endringer gjøres, desto billigere er det for prosjektet Dokumentasjon Med god dokumentasjon vil gruppen sitte med samme helhetsbilde av produktet som skal utvikles. Da kan gruppen som helhet jobbe mot samme mål. Med fordel kan gruppen hente inn utenforstående for å få en ny vinkling på problemløsningen. Tredjeparter kan enkelt lese seg opp på systemet dersom god dokumentasjon foreligger Tidsfrister, plan Vi ønsker at prosjektet er såpass forutsigbart at det kan gjennomføres til gitte tidsfrister. For at dette skal innfris, må vi ha en systemutviklingsmodell som kan tilby god planlegging. Faktorer som kan bidra til levering innenfor gitte tidsfrister er Parallell utvikling fordi prosjektet består av gjenkjennbare delelementer Gruppemedlemmer tildeles konkrete arbeidsoppgaver Statusoppfølginger og felles kontinuerlig helhetsoppdatering i gruppa I vårt tilfelle har vi ikke behov for ekstremt hyppige lanseringer av iterasjoner. Vi ønsker heller at delelementene utgis med fokus på kvalitet. Grunnen til det er at delelementene av prosjektet utgjør en relativt stor del av det totale produktet. Hvis man kan identifisere delelementer i prosjektet som kan utvikles separat, kan disse delelementene fordeles på gruppemedlemmene. På denne måten kan prosjektets delelementer utvikles parallelt. Parallell utvikling har den fordelen at implementering og testing av de ulike delene kan skje uavhengig av hverandre Rolledeling For å få et ryddig arbeidsmiljø med faste personer å forholde seg til ønsker vi at systemutviklingsmodellen åpner for rolletildelinger. Da kan gruppemedlemmer tildeles et ansvarsområde som de kan fordype seg i, og på den måten inneha en spesialisert funksjon. Tilleggseffekten er at de vil få dyperegående tekniske utfordringer og læremuligheter Kommunikasjon Vi ønsker en god kommunikasjon innad i teamet for å kunne bistå hverandre og komme med innspill til videre arbeid. For å få til dette ønsker vi en modell med statusmøter som gir hele teamet samme forståelse av framgangen i prosjektet. I tillegg vil det være gunstig med et godt lederskap og tildelte roller som kan skape en god og relevant informasjonsflyt. Møtene vil også gi muligheter for personutvikling i for av konstruktive tilbakemeldinger. Side 11 av 41

17 I utgangspunktet har vi ikke behov for hyppig kommunikasjon med kunden. I noen grad utgjør vi selv denne funksjonen, og har en klar visjon om hva vi ønsker av produktet. Derimot kan vi med fordel innhente en test/målgruppe som underveis kan gi tilbakemeldinger og komme med ideer. 4.3 Valg av systemutviklingsmodell Med utgangspunkt i kriteriene ovenfor og argumentasjonen som følger i denne delen mener vi Scrum som systemutviklingsmodell passer for vårt prosjekt. Kort oppsummert er Scrum en evolusjonær og iterativ metode. Evolusjonær betyr at modellen lar oss legge til funksjonalitet etter behov. Systemet kan bygges opp for bit for bit gjennom flere iterative prosesser, kalt sprinter. Planlegging og dokumentasjon i Scrum innebærer å lage en overordnet liste med krav og funksjonalitet, som heter «produktbacklog». Dette legger en klar ramme for utviklingen. I hver iterasjonsfase (hver sprint) lages det en sprint backlog som definerer syklusens arbeidsoppgaver. Disse faktorene hadde avgjørende effekt på vårt valg av systemutviklingsmodell. Indirekte vil Scrum være forutsigbar med tanke på tidsbruk og planlegging. Produktet kan deles opp i håndterbare delelementer(iterasjoner) som er lettere å beregne tidsbruk på, når disse legges til en sprintperiode. I tillegg vil det være lettere å holde tidsfrister eksempelvis hvis avvik fra kravspesifikasjonen er gjort, ved at det fanges opp tidlig i statusmøter. Da kan tiltak iverksettes så fort som mulig, i motsetning til at avviket oppdages seint og unødvendig mye arbeid har blitt gjort i gal retning. Om ikke annet vil bevisstheten om avviket muliggjøre en ny realistisk tidsfrist, og følgelig er prosjektet mer forutsigbart. XP-modellen har iterasjoner og planlegging underveis på lik linje med Scrum, men XP er derimot veldig uforutsigbar når det kommer til tidsbruk og det å sette sluttdato for ferdigstillelse. Det skyldes blant annet de hyppige utgivelsene som også gjør det vanskelig å vite hvordan sluttproduktet blir. Dette gjør modellen lite tiltrekkende. Klare rammer og målsetninger er motiverende, noe fossefallsmodellen tilbyr. Allikevel blir den for lite fleksibel for vårt prosjekt. Den tillatter ikke oss å tilpasse systemet underveis. Unified Process er på lik linje med Scrum en inkrementell og evolusjonær modell. Etter disse prinsippene som modellen bygger på ville UP være et like godt valg som Scrum. Dokumentasjon og planlegging er ivaretatt i Scrum-modellen i form av produktbackloggen. Utover det er det ingen krav om dokumentasjon, men vi ønsker at alt arbeid av ansatte skal dokumenteres. Produktbackloggen er en kravspesifikasjon med prioritert liste over alt arbeid som skal utføres. Hvert enkelt element beskrives med hvilken verdi det har for brukerne. Det betyr at alle arbeidsoppgaver har en mening, som i tur virker motiverende og retningsledende for arbeidet. Fossefallsmodellens klare struktur og disiplin legger grunnlaget for en mer omfattende dokumentasjon enn hva Scrum krever. For å heve kravet til dokumentasjon har vi altså lagt inn noen ekstra kriterier. Fossefallsmodellen egner seg godt når alle krav er klart definert og kjent på forhånd, slik kan man forhåpentligvis forutse de utfordringer man står ovenfor. Nok en faktor som spiller inn her er risikoanalysen, den gjøres tidlig i fossefallsmodellen. Endringer og feil som dukker opp underveis må løses der og da. Unified Process er en sterkt modell-drevet prosess. Det legges mye fokus i å bygge arkitektur og å tegne modeller. Det legger et grunnlag for god dokumentasjon, men ulempen med dette er at det er vanskelig å benytte diagrammer for å vurdere om systemet dekker brukerens behov. I tillegg er en omfattende utvikling av diagrammer både kostbart og lite effektivt. Scrum er ikke egnet for store systemer og passer som utviklingsmetode for vårt mindre system. Som sagt før; «jo flere kokker, desto mer søl». Unified Process blir i dette tilfellet «å skyte spurv med kanon», da verktøykassa blir for formell og dyptgående for hva som er hensiktsmessig for dette Side 12 av 41

18 prosjektet. Kompleksiteten i modellen krever godt teamarbeid, men vi har ikke god nok kompetanse eller relevant erfaring med modellen for å utnytte dens potensiale til det fulle. XP har en øvre grense på maksimalt tolv personer i utviklingsteamet. Fordi vårt prosjekt ikke er veldig omfattende ville XP kunne fungere, men det er slik at i XP skal alle utviklerne delta i daglige møter med kundene. Der legges det fram en fremgangsrapport. Vi ser det som lite hensiktsmessig at verken utviklerne eller kunden er med på å styre framdriftsplanen. I Scrum har vi definerte lederroller som tar seg av dette. Både i for - og etterkant av en arbeidsperiode er det satt av tid som skal synkronisere prosjektet med tanke på hva som må gjøres og hva som har blitt gjort. Dette kalles «sprint planleggingsmøte» og «sprint vurderingsmøte». I tillegg til daglige statusmøte hvor alle teamdeltakerne er med, tilfredsstiller dette kommunikasjonskravet vi ønsker innad for å gi tilbakemeldinger og oppdatere hverandre. Av dette får vi også mulighet til oppfølgning og revidering av prosjektet, da leder og medlemmer får sett arbeidet i en større sammenheng. Da er det mulig å vurdere eventuelle utbedringer. En kontinuerlig oppdatering gjør at dette er en agil metode, som gir et utgangspunkt hvor produktet kan revideres og testes ut først og fremst internt i bedriften før man videre leverer til betatest. Denne egenskapen finner man ikke i fossefallsmodellen, hvor arbeidet er ferdigstilt og fastlåst etter hvert faseskifte. Fossefall som modell er for lite fleksibel for vårt tilfelle, samtidig som den ikke gir noe produkt før komplett ferdigstillelse. Ved bruk av Scrum trenger vi ikke å kommunisere med kunder på møtene, slik for eksempel XPmodellen gjør det. I denne modellen er kunden med i hele utviklingsfasen og man kan føre en kontinuerlig dialog med kunden. Dette hadde blitt overflødig ettersom vi selv har en visjon om hvordan produktet skal være. I stedet er det mulig å ta imot tilbakemeldinger etter hvert inkrement fra en testgruppe. Målene og estimering av risiko har blitt fastsatt på forhånd i vårt prosjekt, og derfor vil spiralmodellen være mindre hensiktsmessig. I denne modellen gjøres risikovurderingen på nytt for hver iterasjon. Denne måten å håndtere risiko på brukes også i UP. Vi anser ikke det som nødvendig for vår framgangsmåte. Deltakerne i teamet har ansvarsområder og sine spesialiteter, og temaet har ledere med klare definerte roller. Arbeidere har et fritt utgangspunkt for måten de vil arbeide på. Dette kan føre til økt motivasjon for arbeidet som skal utføres og da gi et raskere og bedre resultat i forhold til hva det kunne blitt ved en mer fast og bestemt metode som for eksempel fossefallsmetoden. Beskrivelse av hvordan vi fordeler rollene beskrives i punkt 3 Prosjektorganisering. XP som modell ville ikke tillatt denne spesialiseringen og rolledelingen. Et prosjekt utviklet etter XP skal gi alle deltakere mulighet for å jobbe med enhver del. Side 13 av 41

19 5 Risikoanalyse 5.1 Kritiske suksessfaktorer Server som håndterer alle forespørsler Brukere som er villige til å benytte applikasjonen Applikasjonen må godkjennes av Google for lansering i Google Play God dokumentasjon slik at utvikleren leverer det produktet vi har forestilt oss 5.2 Risikoevaluering Sannsynlighet: er «ikke sannsynlig» 0,5 «noe sannsynlig» 1 er «sannsynlig» Virkning: er «ubetydelig» 2 liten skade 3 betydelig skade 4 Svært alvorlig 5 er «katastrofalt» Tabell 1: Risikoevaluering Sannsynlighet Virkning Risiko Strategi 1 Overbelastning på server Utvide serverkapasitetet 2 Datatap(ingen backup) 0,1 5 0,5 Iverksette systemgjenoppretting, innkalle ekstern ekspertise på området 3 Forsinket leveranse av serverløsning 0,3 3 0,9 Leie midlertidig serverkapasitet. Stille med egen midlertidig server. 4 Programvare ikke samsvar med krav 0,2 2 0,4 Nytt hovedmøte i Scrum 5 Liten brukermasse (få som laster ned) 0,2 5 1 Markedsføring for å nå nye brukere. 6 Umotiverte arbeidere 0,1 3 0,3 Hjemmekontor. 7 Prosjektet i helhet overskrider tidsfrist 0,5 1 0,5 Tydeligere ledelse, tettere oppfølgning. 8 Godkjenning for lansering av butikkansvarlig (Google) tar lengre tid enn forventet 0,2 2 0,47 Lansering på alternativ plattform/os Side 14 av 41

20 Virkning 5.3 Risikoprofil Sannsynlighet Figur 3: Risikoprofil, virkning og sannsynlighet Vårt prosjekt har høy risikovillighet (risikotolerant policy). Overbelastning på server er den eneste risikofaktoren som ligger utenfor vår risikovillighet. Det betyr at vi må være forberedt på å iverksette vår strategi kjapt for å håndtere risikoen. Vi må være proaktive mot denne risikoen. Side 15 av 41

21 6 Gjennomføring 6.1 Work-Breakdown Structure Figuren under beskriver systemets hovedmoduler. Figuren viser også hvilke moduler som må utvikles før andre (utviklingsgang fra venstre mot høyre): Database Dataregistrering Distribuere data til enheter fra database Grafisk framstilling av data (tabeller + grafer) Registrering av brukerprofiler Arrangemeter Grafisk utseende Mottakk og lagring av data sentralt Databasestruktur Felter Relasjoner Brukergrensesnitt for registrering (av konsum) Enheter skal motta data fra database Grafer på enheten (i brukergrensesnittet) Brukerinformasjon mates inn via brukergrensesnittet Interaksjon mellom brukere Designmessig Estetikk TID TID TID Figur 4: Systemets moduler i prioritert implementeringsrekkefølge Side 16 av 41

22 6.2 Ganttskjema Figur 5: Prosjekts plan for idefase og implementering Side 17 av 41

23 6.3 Produkt backlog 1. Sette opp database med felter og relasjoner 2. Dataregistrering av konsum 3. Distribuere data til enheter fra database 4. Grafisk framstilling av data (tabeller + grafer) i klientprogrammet 5. Registrering av brukerprofiler: Brukerinformasjon mates inn via brukergrensesnittet 6. Arrangementer: Interaksjon mellom brukere. En bruker oppretter et arrangement som andre brukere kan bli med på. Brukere i samme arrangement får opp statistikken til hverandre 7. Grafisk utseende Ekstrafunksjonalitet 8. Webapplikasjon (nettsted) som viser statistikk 9. ios og WP8-Versjon 10. Achievements: oppnår poeng for hver milepæl 11. GPS-tracking for å finne bortkommende venner Side 18 av 41

24 Kravspesifikasjon 7 Overordnet use-casediagram Figur 6: Overordnet use-casediagram for udrunkbro Overordnet use-casediagram for udrunkbro er en enkel modell fordi det kun er én aktør, brukeren. Han initierer enhver handling i systemet, altså er han primæraktør. Det hele starter med opprettelsen av en profil. For å kunne benytte systemet må brukeren foreta en innlogging. Det gir vedkommende mulighet for å administrere profilen sin, opprette et arrangement og registrere konsum for å opparbeide seg poeng. Når som helst etter dette kan brukeren presentere statistikk og grafer. Det ingen relasjoner mellom brukstilfellene: alle brukstilfellene kjøres separat og ingen brukstilfeller avhenger av andre tilfeller. Alle brukstilfellene kan gjentas et uendelig antall ganger, gitt at deres prebetingelser er oppfylt (beskrevet nedenfor). Side 19 av 41

25 7.1 Risikoanalyse av overordnet use-casediagram Hvert enkelt brukstilfelle er delt i tre forskjellige risikoområder. Det er utarbeidet høynivåbeskrivelser for de mest risikable brukstilfellene (se beskrivelse nedenfor). Vi har klassifisert risiko etter: Teknologisk risiko: I hvor stor grad er det vanskelig å lage eller hvor sannsynlig vil det være at vi ikke har tilstrekkelig med teknologi til å gjennomføre det Forretningsmessig risiko: I hvor stor grad er de ulike brukstilfellene viktige for at systemet skal fungere etter de krav som er satt Prosjektmessig risiko: I hvilken grad brukstilfellene kan føre til problemer med tanke på samarbeid og organisering i utviklingsprosessen Tabell 2: Individuell risikoanalyse for brukstilfeller Brukstilfelle Teknologisk Forretningsmessig Prosjektmessig Total Opprette profil lav høy lav medium Logg inn lav høy lav medium Administrere profil lav lav lav lav Opprette arrangement lav medium medium medium Registrere drink lav høy høy høy Presentere grafisk / statistikk medium høy medium medium Ved å vurdere risikoen til de forskjellige brukstilfellene kan vi velge de to mest risikable vi skal lage detaljerte beskrivelser for. Den ene er Registrere drink, som resultat av høyest totalrisiko. Hele systemet bygger på statistikk, og dette brukstilfellet sørger for innsamlingen av data. Logg inn velges over de andre brukstilfellene med samme totalrisiko. Argumentet for dette er at brukeren i det hele tatt må ha tilgang til systemet for å benytte dets tjenester, altså er det en mer kritisk funksjon å få til. Side 20 av 41

26 8 Høynivå use-casebeskrivelser Use case Logg inn Aktør Hensikt Beskrivelse Bruker Logge seg inn på applikasjonen for å få en identitet i arrangementet Ved oppstart av applikasjonen vil brukeren bli spurt om et kallenavn og passord. Denne identiteten følger brukeren gjennom sesjonen, og benyttes for å knytte rett alkoholkonsum til rett bruker på serveren. Kallenavnet vil også identifisere brukeren ved grafisk statistikkpresentasjon. Use case Aktør Hensikt Registrer drink Bruker Registrere alkoholkonsum i sentral database Beskrivelse Inne på applikasjonen vil brukeren ha mulighet til å velge hvilken type enhet og hvor mye han har inntatt. Applikasjonen beregner poengsum og sender deretter informasjonen videre til en sentral databaseserver. Use case Aktør Hensikt Beskrivelse Opprett arrangement Bruker Danne arrangement for å avgrense hvem brukeren samhandler med i systemet Ved en funksjon i applikasjonen vil en bruker kunne opprette et unikt arrangement med navn. I denne prosessen vil det være mulighet å invitere andre deltakere ved navn for å delta i arrangementet. Use case Aktør Hensikt Beskrivelse Presenter statistikk Bruker Vise nåværende status for alle deltakere i et arrangement I applikasjonen vil det være mulighet for brukeren å få vist en grafisk oversikt over all alkoholinntak som er blitt registrert av alle brukerne i arrangementet. Statistikken/informasjonen som benyttes for å tegne det grafiske bildet blir sendt fra en sentral server. Side 21 av 41

27 9 Detaljerte use-casebeskrivelser og sekvensdiagram 9.1 Logg inn Navn: Aktører: Mål: Type: Prebetingelser: Postbetingelser: Logg inn Bruker Få tilgang til systemets funksjonalitet Implementering Bruker er ikke innlogget, men har internettilkobling Brukeren har tilgang til systemets funksjonalitet Normal hendelsesflyt 1. Brukeren starter applikasjonen på sin lokale klient 2. Brukeren blir presentert med et grafisk brukergrensesnitt med felt for brukernavn og passord for innlogging 3. Brukeren trykker en knapp for å logge inn etter å ha fylt inn feltene 4. Systemet sjekker om brukernavn og passordkombinasjonen er gyldig (sjekk mot databasen) 5. Når autentiseringen er vellykket blir brukeren presentert med systemets funksjonalitet Alternative flyter 4: Brukernavn og passordkombinasjonen er ikke gyldig 4.1: Applikasjonen viser en melding som forteller at autentiseringen mislyktes 4.2: Applikasjonen returnerer til det grafiske brukergrensesnittet for å tillate brukeren å prøve på nytt (repetere steg 3) Sekvensdiagram Figur 7: Sekvensdiagram for å logge inn Side 22 av 41

28 9.2 Registrer drink Navn: Registrer drink Aktører: Bruker Mål: Registrere drink som fører til oppdatert poengsum. Type: Implementering Prebetingelser: Bruker er innlogget Postbetingelser: Databasen oppdateres med ny informasjon for brukeren Normal hendelsesflyt 1. Brukeren starter prosessen med registreringen av alkoholenhet ved å trykke på en knapp 2. Applikasjonen bytter brukergrensesnitt til registreringsform 3. Brukeren oppgir type alkoholenhet og volum 4. Brukeren trykker knapp for å registrere og lagre informasjonen 5. Applikasjonen beregner poengsum og promille ved forhåndsbestemt algoritme med disse størrelsene som input 6. Applikasjonen sender data til en sentral databaseserver 7. Brukeren får tilbakemelding om registreringen var vellykket 8. Applikasjonen lar de registrerte dataene være igjen i registreringsfeltene slik at brukeren raskt kan repetere punkt 4. Alternative flyter 3. Brukeren oppgir ugyldig informasjon 3.1 Brukeren får feilmelding og må gjenta steg 3 6. Applikasjonen får ikke forbindelse med serveren. Data kan derfor ikke lagres sentralt 6.1. Brukeren får tilbakemelding om at serveren ikke kan nås 6.2. Applikasjonen mellomlagrer de feltene som er fylt inn 6.3. Applikasjonen viser samme brukergrensesnitt med de fylte feltene, gir brukeren mulighet til å repetere steg 4 Sekvensdiagram Figur 8: Sekvensdiagram for å registrere en drink Side 23 av 41

29 10 Kvalitetsmessige krav 10.1 Funksjonskrav Systemet benytter en server som lagrer data bruker plotter inn. Alle brukere har en klientapplikasjon på sin mobil der de registrerer sitt konsum. Applikasjonen vil gjøre alle beregninger og laste opp rådata til serveren, for å minske belastningen på serveren. Den sentrale serveren lagrer rådata. Informasjonen som lagres er brukerprofiler og konsum tilknyttet en profil. Det vil ikke bli lagret detaljert informasjon om antall enheter eller detaljert informasjon om hva som er konsumert. En serverløsning vil - ikke begrense antallet brukere av systemet. Systemets server, eventuelt bruk av flere servere, kan håndtere et ønsket antall brukere. - ikke ha begrensning på fysisk nærhet mellom deltakerne. Brukere kan være interaktive uavhengig av geografisk plassering. Brukerdata legger grunnlag for statistikk og poenggivning til brukerne. Dette presenteres grafisk i applikasjonen om brukeren ønsker ved at applikasjonen får tilsendt nødvendig data fra serveren. Serveren har ikke mulighet for å vise grafisk data. Algoritmen for grafisk framstilling er altså bare tilgjengelig på de mobile enhetene. Hver bruker oppretter en brukerprofil. Når de oppretter arrangementer kan de invitere andre brukere til å delte på arrangementet. Deretter kan man se de andre brukernes statistikk Økonomiske krav Lønn. Utviklerne skal ha lønn under utviklingsprosessen. Pris på server. Vi trenger en server som er rimelig, men som allikevel tilfredsstiller kravene vi har satt Reklamebasert inntekt etter distribusjon skal finansiere utgiftene i utviklingsprosessen Programvareutgifter (innkjøp av nødvendig programvare) Egenkapital 10.3 Brukervennlighet og brukergrensesnitt Brukergrensesnittet skal være så enkel at det ikke skal være behov for brukeropplæring Det skal ikke ta en bruker lengre tid enn 30 sekunder å registrere en drink Hver bruker kan opprette en brukerprofil Brukeren skal kunne endre på sin egen brukerinformasjon Hver bruker kan opprette arrangementer og invitere andre brukere til å delta Man skal kunne se statistikk for de andre brukerne i samme arrangement Etter innlogging skal all funksjonalitet være tilgjengelig fra hovedskjermen Systemet skal bestå av maksimalt fem ulike skjermbilder Innlogging på systemet skal ikke ta mer enn 5 sekunder Side 24 av 41

30 10.4 Ytelse Registrering av drink skal inneholde minimalt med informasjon, slik at registreringen verken blir forsinket grunnet programvare eller nettverksforbindelsen Systemet skal kunne kjøre stabilt med 2000 brukere av systemet simultant Systemet skal kunne grafisk fremstille statistikk innen 2 sekunder ved HSPA+ båndbredde eller bedre Algoritmen for den grafiske fremstillingen finnes kun hos de mobile enhetene og vil ikke kunne vises frem via serveren selv 10.5 Lagring All brukerinformasjon skal lagres på en server All informasjon om arrangementer skal bare lagres midlertidig på en server Den lagrede informasjonen om brukeren kan hentes ut av brukeren selv og administratorer Informasjon om arrangementer kan hentes ut av brukere tilkoplet dette arrangementet Informasjon om arrangementer skal ligge lagret i 24 timer etter at arrangementet er slutt Systemet benytter en sentral database, MySQL. Den sentrale serveren tjener en database bestående av to tabeller med få felter, se figur 9. Bruker BrukerID Kallenavn Fornavn Etternavn Vekt Poeng Promille VolSprit VolOl VolVin SisteInntak ArrangementID * Deltar på 1 Har deltakere Arrangement ArrangementID Slutter Figur 9: Databasemodell for udrunkbro 10.6 Pålitelighet Serveren skal være operativ 24 timer i døgnet Serveroppdatering skal kun skje på dager og tidspunkter hvor det er lite aktivitet. Tidsrommet fra torsdag til søndag er uaktuelt. Side 25 av 41

31 10.7 Sikkerhet (personvern) Brukere kan kun se statistikk fra andre brukere som er i samme arrangement som seg selv En bruker kan søke opp andre brukere for å invitere de til sitt eget arrangement Det skal ikke være mulig å hente ut andre sin brukerinformasjon, kun deres statistikk dersom de er i samme arrangement Systemet krever innlogging av bruker ved bruk av brukernavn og passord Systemet skal innrette seg etter personvernloven når det gjelder lagring av persondata Brukervilkårene skal advare mot at den oppgitte promillen for brukeren i systemet ikke er en erstatning for lisensierte produkter som måler promillen Systemet lagrer kun informasjon om mengden konsum. Fraværet av detaljoppføringer sørger for et bedre personvern 10.8 Portabilitet Systemet skal være nedlastbar til Android Systemet krever internettilkobling over enten WiFi eller mobilnettet for kommunikasjon med serveren Systemet skal ha en innloggingsprosess som gjør at man kan bytte enhet uten å miste tilgang til applikasjonen og sin brukerprofil 10.9 Dokumentasjon All dokumentasjon skal samles i en rapport Grunnet god teknisk dokumentasjon vil det i etterkant være lett å kunne vedlikehold systemet ved en eventuell bug eller for å innføre en utvidelse Interoperabilitet Videre utvikling vil gi mulighet for å kunne koble opp i mot Facebook, Google+ og Twitter for å kunne publisere nyheter fra applikasjonen på disse sosiale mediene Side 26 av 41

32 11 Konseptuelt klassediagram Figur 10: Et konseptuelt klassediagram for udrunkbro Modellen viser hvordan produktet kan deles opp i klasser, med påfølgende attributter, assosiasjoner og multiplisiteter, i henhold til objektorientert analyse og design Klassen Bruker representerer selve brukeren i systemet og muliggjør hans interaksjon med systemet. Det instansieres ett objekt av klassen per klient som deltar i arrangementet. Attributtene som beskriver objektet er i tillegg til brukernavn og annen personlig data de samme som feltene som brukeren sender til serveren når han registrerer en drink. Operasjonene som objektet kan utføre er å registrere en drink, logge inn på systemet, be om å grafisk statistikkfremvisning, bli med i og opprette arrangement. Arrangement er en klasse som samler flere brukere sammen. En bruker tar initiativ til å opprette et arrangement og andre brukere kan bli med i dette arrangementet. I systemet instansieres det ett objekt av klassen per festarrangement. Hvert arrangement har en unik ID (en fortløpende, autogenerert teller) og en dato for når arrangementet slutter. Sluttdatoen sikrer at informasjon om gamle arrangementer ikke lagres, i henhold til krav til personvern og lagringskapasitet. Klassen arrangement har relasjonen til brukerklassen at flere brukere kobler seg til samme arrangement. I tillegg har hvert arrangement ett gjeldende statistikkobjekt. Statistikk er en klasse hvor det instansieres ett objekt per arrangement. Klassen sørger for informasjonen som Figur 1: Skisse av grafiske framstillinger av data bygger på. Attributtene i denne klassen er for samlet statistikk, altså beregninger gjort ut fra verdiene til attributtene for alle brukerne. -Volum(Sprit/Ol/Vin)Total beregnes via operasjonen +kalkulervolumtotal() som tar Side 27 av 41

33 summen av volumene til alle brukere i arrangementet. Disse tre attributtene benyttes videre i +kalkulertype() som gir prosentandelen denne type alkohol utgjør i kakediagrammet. Beregningen er forholdet mellom volum av alkoholtypene og totalvolumet som er inntatt, altså de tre respektive forholdene mellom øl, sprit, vin og totalsummen volumtotal. +KalkulerLedertabell() genererer en liste med poengsummen til hver bruker i arrangementet i synkende rekkefølge. Denne listen presenteres på ledertavlen (skissert i figur 1). Ledertavlen er ut i fra disse beskrivelsene også et konkret objekt i applikasjonen. Listen over personer på ledertavlen forandres ofte, basert på beregninger. Dette objektet, ledertavlen, er altså dynamisk og vi ser det ikke som hensiktsmessig å lagre informasjonen på ledertavlen da dataene forandres hyppig. Ettersom Statistikk og Arrangementklassen har et forhold på 1 til 1, er det mulig å realisere dem som én klasse. Dette er på grunn av at kun ett objekt fra hver klasse skal instansieres. Allikevel virker det fornuftig å splitte de i to forskjellige klasser da arrangementet er fast per festsesjon, mens Statistikk blir kalt hver gang en bruker ønsker. Disse klassene har en sterk assosiasjon mellom seg, ettersom statistikkobjektet bare kan instansieres når det eksisterer et arrangement som en bruker har opprettet. Nyhet er en klasse med attributter som forteller om siste hendelsene i et arrangement. Verdiene til attributtene i et nyhetsobjekt hentes fra registreringshandlingen til en bruker. Her inngår brukernavn, tidsstempel for registrering og en nyhetstekst. En bruker kan ha flere nyheter, men hver nyhet står til kun én bruker. Operasjonen som objektet kaller er +lagnyhet(), som viser nyheten med attributter fra Nyhet og Brukerobjektet. Ett objekt av denne klassen vil instansieres per nyhetsrad illustrert i Figur 1: Skisse av grafiske framstillinger. Side 28 av 41

34 Arkitektur Arkitekturen i et programvareprosjekt kan baseres på ulike modeller. Noen slike modeller er repository, distribuert objektarkitektur, klient-tjener og lagdeling. 12 Ulike arkitekturmodeller 12.1 Repository Denne arkitekturen bygger på systemer som bruker store mengder data organisert rundt en felles database. Modellen egner seg til bruk når store mengder med data skal deles av flere brukere. Hovedsaklig fungerer modellen slik at subsystemer utveksler data. Repository er egnet for anvendelse hvor data blir lagret av et subsystem og brukt av et annet subsystem. Dette kan skje ved at dataen lagres i en sentral database og kan nås av subsystemene. Alternativt kan det foregå ved at hvert subsystem vedlikeholder sin egen database og sender data til andre subsystemer via meldinger. Dette kan medføre unødvendig mye datatrafikk og belastning på båndbredden sammenliknet med en modell der klientene skal hente ut informasjonen selv på en sentral database etter eget behov Når en sentral database benyttes gir denne modellen muligheten for en effektiv måte å dele store mengder data på. Her trenger ikke subsystemene være opptatt av hvordan data produseres. Dette er fordi subsystemene bare benytter seg av dataene som andre subsystemer har generert og ikke foretar noen andre handlinger basert på disse dataene. I utgangspunktet er dette en modell som kunne passet til vårt system. Problemet som ligger ved denne modellen er at utvikling og innføring av nye funksjoner og teknologi er vanskelig og dyrt. Dette er fordi om et system skal oppgraderes og utvikles, skjer dette ved at alle subsystemene innenfor systemet må oppdateres. For at hele systemet skal fungere da, betinger dette at alle subsystemene har samme versjon av systemet. Dette er nødvendig for at alle skal kunne ha de samme funksjonene tilgjengelig og for at alle subsystemene skal forstå hverandre. Ettersom vi har planlagt å utvikle dette videre om applikasjonen blir en suksess vil dette gi et problem for oss. En annen ulempe med denne modellen er at den gir liten mulighet for administrasjonpolitikk. Dette vil ikke være et problem for oss med tanke på hvordan vi i utgangspunktet ønsker å utvikle programvaren, men i forhold til senere utvikling kan dette skape et problem for oss. Fordi modellen har en spesifikk administrasjonspolitikk, som for eksempel backup og sikkerhet, gjør dette at den blir litt interessant allikevel. Dette er noe vi trenger i systemet vårt, for at systemet ikke skal bryte ned eller miste informasjon under arrangementer som pågår Klient-tjener Denne arkitekturmodellen angir klart hvordan kommunikasjonen skal foregå mellom ulike komponenter i systemet samt hvordan data skal deles og behandles. Databehandlingen foretas av ulike komponenter innenfor et nettverk. Serveren kan tilby ulike tjenester som dataadministrasjon, datalagring og printing. Flere servere kan også benyttes, hvor de enten samarbeider om en oppgave eller fokuserer på sin egen tildelte oppgave. Side 29 av 41

35 I denne modellen er det klienten som tar initiativet til å be om en tjeneste. Serveren er passivt ventende på å motta en forespørsel. Når den har blitt igangsatt utfører den en tjeneste, og blir deretter ventende på ny forespørsel. Klient-server modellen kan ha flere variasjoner i forhold til fordelingen av ansvar og oppgaver til de ulike nettverkskomponentene. Tykke klienter er en betegnelse på klienter som har stor nok drivkraft til å kjøre applikasjoner selv, en kapasitet de fleste smarttelefoner i dag har. Tynne klienter er betegnelsen på klienter som innehar mindre funksjonalitet selv, den viser eksempelvis bare frem innhold som er generert på en server. Hensikten med tynne klientene kan være at de ikke har stor nok drivkraft i seg selv til å drive applikasjonen, eller fordi det av andre faktorer er ønskelig å flytte ansvaret og funksjonaliteten vekk fra klientene. En fordel med klient-servermodellen er at distribueringen av data er enkel og ukomplisert. Dette har en sammenheng med at maskinvaren utnyttes effektivt og at systemet ikke trenger å være komplisert eller bestå av avanserte komponenter. I tillegg er ikke serverkapasiteten nødvendigvis konstant. Ved behov kan kapasiteten økes grunnet arkitekturens egenskaper når det kommer til skalerbarhet. En ulempe med modellen er at datautveksling kan bli ineffektivt, ved at ulike data på forskjellige servere ikke nødvendigvis er likt organisert. Derfor blir det nødvendig å administrere servere individuelt, noe som er ressurskrevende. Det samme forholdet gjør det komplisert å organisere hvilke servere og tjenester som er tilgjengelige til hva og når de er ledige Distrubert Objektakritektur Distribuert objektarkitektur (DOA) likner på klient-tjener ved at systemet består av flere klienter. DOA derimot skiller ikke mellom klient og tjener, den består av samarbeidende objekter. Arkitekturen kan derfor sammenliknes med peer-to-peer, hvor alle maskinene som er koblet sammen kan sende forespørsler til hverandre for å få tilsendt data. Klienter i DOA kommuniserer på samme måte, bare at en maskin vil spørre en annen maskin som er tilkoblet systemet om å utføre tjenester som den forespørrende maskinen kan benytte seg av. Dette prinsippet medfører at dersom man skal få informasjon fra alle brukere, må man forespørre samtlige brukere om informasjonen man ønsker. Det er fordi informasjonen om en bruker ligger lokalt på brukerens klient. I praksis medfører dette unødvendig mye nettverkstrafikk, men man fjerner problemet med ett sårbart punkt, nemlig serveren Lagdelingsmodell Lagdelingsmodellen beskriver et system fra to sider, i en fysisk arkitektur og i en logisk arkitektur. Den fysiske modellen viser maskiner og hva som kjører på dem sett fra en brukers synspunkt. Den logiske modellen viser programvarekomponenter sett fra en utviklers synspunkt. En arkitektur bygd på lagdelingsprinsippet gir god mulighet for inkrementell utvikling, lag for lag. Det at systemet er delt i mer eller mindre uavhengige lag gjør det lettere å vedlikeholde og å eksportere deler av systemet. Det skyldes at lagene kan jobbes på uavhengig av hverandre. En revidering av systemet kan gjøres på et lag, og man sparer seg for en revidering av hele systemet. Funksjonaliteten i systemet kan gjøres tilgjengelig for brukerne etter som lagene ferdigstilles. I lagmodellen kommuniserer lagene ved å utveklse informasjon. Derfor kan lagmodellen by på ytelesesutfordringer fordi kommandoer ofte må oversettes i de ulike lag før de kan behandles. Flere lag kan også gjøre strukturen komplisert. Side 30 av 41

36 Fysiske lag kan være klienter, applikasjonsserver og database. Tilsvarende logiske lag er presentasjonslag, forretningslogikklag og datalag. Tabell 3: Sammenheng mellom fysiske og logiske lag Klienter Applikasjonsserver Database Presentasjon Forretningslogikk Data Presentasjonslaget er det øverste laget i systemet og er det laget brukeren kan samhandle med. Forretningslogikklaget kontrollerer systemets funksjonalitet ved å utføre prosessering og beregninger. Datalaget består av systemets lagringsenheter, ofte en eller flere databaser. Å skille selve dataene fra applikasjonen forbedrer skalerbarheten og ytelsen Side 31 av 41

37 13 Valg av arkitektur Med utgangspunkt i diskusjonene rundt de forskjellige modellene velger vi å benytte klientservermodellen og lagdelingsmodellen for vårt system. Vårt system baserer seg på tykke klienter. Datadistribueringstjenesten som systemet baserer seg på er ikke krevende og passer derfor klient-servermodellen utmerket. Serveren tjener kun databasen og all logikk kjører på klientene. Ulempen som gikk ut på at datautveksling mellom forskjellige servere kunne bli vanskelig å koordinere vil ikke utgjøre et stort problem for oss, da dataen for et gitt arrangement holdes på én server. Gitt at applikasjonen vår blir populær vil trafikkmengden øke, da må vi ha muligheten til å ekspandere serverkapasiteten. Dette er noe modellen tilbyr oss. Figur 11: Klient-tjenermodell for udrunkbro Fokuset for repositorymodellen er at mye data kan deles med flere brukere. Dette er ikke nødvendig for vår applikasjon, hvor arrangement i seg selv avgrenser hvor mye data som er relevant å dele for en gruppe med deltakere. Databasefeltene utgjør ikke mye data i seg selv, og reell trafikk vil være relativt lite. Sannsynligheten for å videreutvikle applikasjonen ved en eventuell suksess er stor og dette er noe repository vanskeliggjør. Derfor er ikke denne arkitekturen ønskelig å benytte. Det som derimot gjør denne arkitekturen noe interessant er administrasjonspolitikken som fokuserer på backup og sikkerhet som er noe vi ønsker å implementere. Lagdelingsmodellen er også et naturlig valg for vårt system. Systemet kan beskrives enklere ved å gjøre et skille på den fysiske og logiske arkitekturen. I tillegg vil en differensiering av hva sluttbrukeren opplever og de prosesser som foregår automatisk i bakgrunnen letteregjøre oversikten over virkemåten til systemet Side 32 av 41