Kunderbjudande i molnet : Projektarbete för  Byggvarulistan AB

Linköpings universitet

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

Vårterminen 2017 | LIU-IDA/LITH-EX-G–17/048–SE

Kunderbjudande i molnet

Projektarbete för Byggvarulistan AB

Mattias Evaldsson

Fredrik Grahn

Lenny Johansson

Simon Karlsson

Alexander Sääf

Oscar Thunberg

Richard Wigren

Handledare : Carl Brage Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

c Mattias Evaldsson Fredrik Grahn Lenny Johansson Simon Karlsson Alexander Sääf Oscar Thunberg Richard Wigren

Sammanfattning

Målet med denna rapport är att beskriva hur erbjudandesystemet i kandidatprojektet Kun-derbjudande i molnet kan implementeras så att man skapar värde för kunden. Utöver detta behandlas erfarenheter från projektet, vilket stöd man kan få genom att skapa och följa upp en systemanatomi samt vilken effekt verktyget Slack har haft på gruppens kommunikation. Vidare tas följande ämnen upp i individuella bidrag till rapporten:

• Xamarin test recorder

• Lättviktig kodgranskning med GitHub pull requests

• Utveckling av mobilapplikation till flera plattformar i Xamarin • Kvalitetsplanens roll i programutveckling

• Kanban med Trello i kandidatprojekt

• Reacts koddelning mellan webb och mobilapplikationer • Tidsbudgetering och estimering inom projektet

Kunden Byggvarulistan AB var i behov av en prototyp till ett system där användare kan spara sina kvitton direkt i mobilen och sedan använda dessa för att ta del av erbjudanden.

Metoden för att åstadkomma detta var att utveckla ett system som möjliggör hantering av kvitton. Via detta system skulle det även gå att erbjuda cashbacks och kampanjer till användaren. Under utvecklingen användes Slack för kommunikation och en systemanatomi togs fram och användes. Utvecklingen delades upp i fyra iterationer och baserades på agila arbetsmetoder.

Systemet är uppdelat i tre moduler: en mobilapplikation, en molntjänst och ett webbgränss-nitt. Mobilapplikationen är utvecklad för Android med verktyget Xamarin. Molntjänsten består av ett webb-API som har utvecklats med webbramverket ASP.NET och en databas som implementerades med ORM-ramverket Entity framework core. Webbgränssnittet utveck-lades i JavaScript och biblioteket React. Dessa tre delar samverkar och ger en användare möjlighet att genom applikationen hitta och utnyttja erbjudanden från Byggvarulistan och en administratör möjlighet att modifiera erbjudanden och användardata genom webbgränssnit-tet.

Slutsatser från de erfarenheter som har observerats under projektets gång är att det är effektivare att arbeta tillsammans inom teamet än att arbeta individuellt samt att valet av utvecklingsmiljö hade större effekt på utvecklingen än man först trodde. Slutsatser kunde även dras om att skapandet av en systemanatomi var fördelaktigt då alla gruppmedlem-mar fick en gemensam bild över systemet. Till sist så drogs även en slutsats om att Slack underlättade kommunikationen väsentligt både generellt för hela gruppen och för de olika utvecklingsteamen.

Författarens tack

Tack till Byggvarulistan AB som har bidragit med ett spännande projekt. Ett stort tack också till Carl Brage som har agerat handledare för projektgruppen.

Innehållsförteckning

3.2 Hela projektet . . . 7 3.3 Mobilapplikation . . . 7 3.4 Molntjänsten . . . 8 3.5 Webbgränssnitt . . . 9 4 Metod 10 4.1 Tilldelning av ansvarsområden . . . 10 4.2 Utbildning . . . 10

4.3 Kanban med Trello . . . 10

4.4 Kommunikation med Slack . . . 11

4.5 Systemanatomi . . . 11

4.6 Iterationer . . . 11

4.7 Gemensamma erfarenheter . . . 14

4.8 Slack som kommunikationsverktyg . . . 14

4.9 Arbetet i ett vidare sammanhang . . . 15

5 Resultat 16 5.1 Systembeskrivning . . . 16

5.2 Gemensamma erfarenheter . . . 23

5.3 Kommunikation med Slack . . . 24

5.4 Arbetet i ett vidare sammanhang . . . 24

6 Diskussion 26

6.1 Resultat . . . 26

6.2 Metod . . . 26

6.3 Användning av systemanatomi . . . 27

6.4 Slack som kommunikationsverktyg . . . 27

6.5 Arbetet i ett vidare sammanhang . . . 27

7 Slutsats 30 7.1 Hur kan produkten implementeras så att man skapar värde för kunden? . . . . 30

7.2 Vilka erfarenheter kan dokumenteras från projektet Kunderbjudande i molnet som kan vara intressanta för framtida projekt? . . . 30

7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 31

7.4 Vilken effekt har verktyget Slack på kommunikation inom gruppen? . . . 31

A Xamarin Test Recorder, ett alternativ till användartester? Av Alexander Sääf 32 A.1 Introduktion . . . 32 A.2 Bakgrund . . . 32 A.3 Teori . . . 33 A.4 Metod . . . 34 A.5 Resultat . . . 35 A.6 Diskussion . . . 36 A.7 Slutsatser . . . 37

B Lättviktig kodgranskning med GitHub pull request av Lenny Johansson 38 B.1 Inledning . . . 38 B.2 Bakgrund . . . 38 B.3 Teori . . . 39 B.4 Metod . . . 40 B.5 Resultat . . . 41 B.6 Diskussion . . . 42 B.7 Slutsatser . . . 43

C Utveckling av mobilapplikation till flera plattformar i Xamarin av Fredrik Grahn 44 C.1 Inledning . . . 44 C.2 Bakgrund . . . 45 C.3 Teori . . . 45 C.4 Metod . . . 46 C.5 Resultat . . . 47 C.6 Diskussion . . . 49 C.7 Slutsatser . . . 50

D Kvalitetsplanens roll i programutveckling av Simon Karlsson 52 D.1 Introduktion . . . 52 D.2 Bakgrund . . . 52 D.3 Teori . . . 53 D.4 Metod . . . 54 D.5 Resultat . . . 55 D.6 Diskussion . . . 57 D.7 Slutsatser . . . 58

E Kanban med Trello i kandidatprojekt av Mattias Evaldsson 60 E.1 Introduktion . . . 60

E.4 Metod . . . 61

E.5 Resultat . . . 63

E.6 Diskussion . . . 63

E.7 Slutsatser . . . 65

F Koddelning i webb- och mobilapplikationer med React av Oscar Thunberg 66 F.1 Introduktion . . . 66 F.2 Bakgrund . . . 66 F.3 Teori . . . 67 F.4 Metod . . . 68 F.5 Resultat . . . 69 F.6 Diskussion . . . 70 F.7 Slutsatser . . . 71

G Tidsbudgetering och estimering inom projektet av Richard Wigren 72 G.1 Introduktion . . . 72 G.2 Bakgrund . . . 72 G.3 Teori . . . 73 G.4 Metod . . . 74 G.5 Resultat . . . 76 G.6 Diskussion . . . 76 G.7 Slutsatser . . . 78 H Bilagor 79 H.1 Enkätsvar - kodgranskning med GitHub pull request . . . 80

H.2 Enkätsvar - Kanban med Trello . . . 82

H.3 Enkät: Kommunikation med Slack . . . 84

Ordlista

API Application Programming Interface, ett gränssnitt som program kommunicerar med.

Auktorisering Handlingen att bekräfta rättigheterna till en resurs eller funktion.

Autentisering Handlingen att bekräfta en angiven identitet.

Azure En samling molntjänster med månadskostnader som Microsoft förser utvecklare med.

Byggvarulistan AB Ett företag som erbjuder en internetbaserad jämförelsetjänst med fokus på prisjämförelse inom gör-det-själv marknaden.

Cashback Ett återbäringsprogram som innebär att varuhus ger en procentsats av kostnaden för inhandlade varor tillbaka till kunden.

EER En modell för databaser som representerar relationer mellan entitetstyper.

Förgrening Processen att duplicera en gren för att skapa en ny utvecklingslinje ifrån grenen som duplicerades.

GitHub En web-baserad versionshanteringstjänst.

Google Drive En molntjänst som låter användare lagra filer i molnet.

Gren En utvecklingslinje i ett versionshanterat projekt.

HTTP Hypertext Transfer Protocol är ett överföringsprotokoll som används för kommunika-tion på webben.

Huvudgren En stabil gren som färdigutvecklade förgreningar sammanfogas med.

IDE Integrated Development Environment eller utvecklingsmiljö på svenska är ett program som innehåller verktyg för programvaruutveckling.

JSON JavaScript Object Notation är ett format för dataöverföring.

Kanban En agil arbetsmetodik som ämnar att minska WIP.

OCR Optical Character Recognition eller maskininläsning är omvandling av bilder med text till text i en form som en dator kan hantera.

Postman Ett program som kan användas för att testa webb-API:er.

SDK Software Development Kit, en uppsättning utvecklingsverktyg för att underlätta utvecklingen av en viss applikation.

Slack Ett verktyg för kommunikation mellan medlemmar i ett team.

SPA Single Page Application, en webbsida som laddar innehåll i bakgrunden och ändrar dokumentet som visas istället för att ladda sidor på nytt.

Tesseract En OCR motor tillgänglig som öppen källkod.

Trello Ett verktyg för att organisera projekt med hjälp av anslagstavlor.

UI User Interface, den del av ett program som användaren interagerar med, t.ex. knappar och textfält.

URI Uniform Resource Identifier, en sträng av tecken som kan identifiera eller namnge en resurs.

URL Uniform Resource Locator, en sträng av tecken som identifierar en resurs på internet såsom en hemsida.

Versionshanteringssystem Ett system som sparar och hanterar tidigare versioner av filer, exempelvis källkod vid mjukvaruutveckling.

WIP Work In Progress, mängden arbete som utförs parallellt.

Lista av figurer

3.1 Exempel på en systemanatomi. . . 5

5.1 Mobilapplikationens systemanatomi . . . 17

5.2 Molntjänstens systemanatomi . . . 19

5.3 Webbgränssnittets systemanatomi . . . 22

Lista av tabeller

5.1 Roller . . . 20

A.1 Uppgiftsgenomförande (Totalt 4 användare) . . . 35

A.2 Automatiserade tester . . . 36

B.1 Fördelning av pull requests . . . 41

B.2 Fördelning av godkända pull requests med anmärkningar . . . 41

B.3 Beskrivning av nekade pull requests . . . 41

C.1 Android-specifika filer med kod skrivna i C#. . . 48

C.2 Android-specifika resursfiler skrivna i XML. . . 49

C.3 Delade filer med kod skriven i C#. . . 49

D.1 Metrics från undersökningen . . . 57

F.1 Lista över vilka bibliotek som undersöks från Webbgränssnittet. . . 68

F.2 Lista över hur aktiviteterna kategoriserades. . . 69

F.3 Tidsåtgång till respektive område . . . 70

F.4 Beräknad tidsbesparing . . . 70

G.1 Statistik över reell tid . . . 76

G.2 Uteslutna aktiviteter . . . 76

H.1 Fråga 1: Hur ofta har du tittat till Kanban-brädet? . . . 82

H.2 Fråga 2: Hur ofta har du ändrat i Kanban-brädet? . . . 82

H.3 Fråga 3: Hur ofta har du kollat till de andra modulernas Kanban-bräden? . . . 82

H.4 Fråga 4: Märkte du någon skillnad i hur du använde Kanban-brädet över projek-tets gång? . . . 82

H.5 Fråga 5: Hur bra tyckte du att Trello som verktyg fungerade att bedriva Kanban genom? . . . 83

H.6 Fråga 6: Tror du att det hade fungerat bättre eller sämre med ett fysiskt Kanban-bräde istället för ett på internet? . . . 83

H.7 Fråga 7: Vad tyckte du att projektet drog för fördelar av att använda Kanban-bräden? 83 H.8 Fråga 8: Var det något med Kanban-brädena som du tyckte påverkade projektet negativt? . . . 83

H.9 Fråga 1: Hur nöjd är du med Slack som kommunikationsverktyg? . . . 84

H.10 Fråga 2: Upplever du att det varit lätt att få kontakt med de gruppmedlemmar du behöver kontakta? . . . 84

H.11 Fråga 3: Upplever du att det varit lätt att hitta information som tagits upp i Slack (webadresser, lösenord, etc.)? . . . 84

H.12 Fråga 4: Upplever du att Slack på något vis har stört ditt arbete? . . . 84

H.14 Fråga 6: Finns det något alternativt kommunikationsverktyg du skulle ha föredra-git i projektet? Varför? . . . 85

1

Introduktion

Det här kapitlet sammanfattar rapportens innehåll och presenterar dess syfte och frågeställ-ningar. Det beskriver också rapportens avgränsfrågeställ-ningar.

1.1

Motivation

I projektet Kunderbjudande i molnet har ett system utvecklats åt Byggvarulistan AB. Systemet har flera uppgifter, som alla kretsar kring att ge systemets användare erbjudanden och cash-backs på deras köp av byggvaror och verktyg. Detta ska ges på köp i fysiska butiker genom att låta användarna ladda upp bilder på sina kvitton. När kvittot mottagits och behandlats betalas pengar ut till kunden. Systemet ska dessutom lagra användarens kvitton för att un-derlätta för användare som behöver ha kvar sina kvitton för t.ex. skatteskäl.

För att åstadkomma detta byggdes en mobilapplikation för Android med hjälp av Xamarin, en molntjänst i C# ASP.NET Core som körs på Microsoft Azure och ett admingränssnitt i React. I mobilapplikationen kan användarna se aktiva erbjudanden, ladda upp kvitton och se sina tidigare uppladdade kvitton. För att autentisera användare används inloggning via Facebook med hjälp av Facebooks SDK. Molntjänsten låter mobilapplikationen hämta de erbjudanden som finns, och tar dessutom emot och lagrar de kvitton som användaren tar bild på med mobilapplikationen. Administratörgränssnittet kan användas av Byggvarulistans administratörer för att hantera erbjudanden, användare och kvitton. Molntjänsten fungerar som en central enhet som både mobilapplikationen och administratörgränssnittet kommuni-cerar med; kommunikationen sker med hjälp av ett REST-API.

Systemet utvecklades av en grupp studenter vid Linköpings universitet. Arbetssättet var en blandning av traditionell mjukvaruutveckling enligt vattenfallsmodellen och agila meto-der som iterativ utveckling, iterativ utvärmeto-dering av arbetssättet och regelbundna möten med hela gruppen. I utvecklingen användes verktyg som Trello, Slack och GitHub.

1.2. Syfte

1.2

Syfte

I den här rapporten kommer systemet och dess olika delar beskrivas. Även gruppens arbets-sätt, verktyg och teknikval kommer beskrivas, utvärderas, och motiveras för att samla ihop kunskap och erfarenheter från projektet.

1.3

Frågeställningar

Rapporten kommer behandla följande frågeställningar:

1. Hur kan erbjudandesystemet i Kunderbjudande i molnet implementeras så att man skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från projektet Kunderbjudande i molnet som kan vara intressanta för framtida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Vilken effekt har verktyget Slack haft på kommunikation inom gruppen?

1.4

Avgränsningar

Rapporten avgränsas av det underliggande projektets omfattning. Den kommer därför försö-ka svara på frågeställningarna utifrån det egna projektet. Därmed kommer frågeställningar som Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? framförallt besvaras utifrån vilket stöd det gav i just detta sammanhang.

2

Bakgrund

Det här avsnittet ger en kort bakgrund till kunden och motiverar varför kunden vill utveckla produkten som rapporten beskriver. Avsnittet ger även en kort beskrivning av gruppmed-lemmarnas tidigare projekterfarenheter.

Kunden som bidragit med uppdraget för det här kandidatprojektet är Byggvarulistan AB. Byggvarulistan är en internetbaserad jämförelsetjänst med fokus på prisjämförelse för bygg-material. Tjänsten riktar sig mot privatpersoner för att underlätta inhandlingen av material och verktyg vid byggprojekt.

Byggvarulistan AB har för avsikt att komplettera sin existerande tjänst genom att ge si-na kunder tillgång till cashback och kampanjer direkt i deras smartphone. Cashback är ett återbäringsprogram och fungerar genom att varuhusen ger en procentsats av kostnaden för inhandlat material till Byggvarulistan för de kunder som kommit till varuhusen genom Byggvarulistan. Byggvarulistan delar sedan återbäringen med sina kunder för att de använ-der använ-deras tjänst. Cashback har länge funnits i matvarubutiker och har på senare tid blivit mer och mer populärt i samband med handel över internet, men byggvarumarknaden ligger efter. Kampanjerna som ska ingå i produkten är kampanjer som leverantörer av verktyg och byggmaterial ger ut till Byggvarulistan. Byggvarulistans kunder ska kunna ta del av dessa kampanjer genom att köpa kampanjprodukten vid vilket varuhus de än väljer. Leverantörer-na betalar Byggvarulistan som sedan delar återbäringen med kunden. I dagsläget finns det ingen liknande tjänst för byggmaterial, därför ämnar Byggvarulistan tidigt etablera sig i den marknaden.

Gruppmedlemmarnas tidigare projekterfarenheter består till största del av grupprojekt under sin utbildning med projektgrupper som varierat i storlek från två till sju medlem-mar. Tidigare kurser inom gruppmedlemmarnas utbildningsprogram har bidragit med teori och riktlinjer för projektplanering och grupparbeten. Teorin har använts vid planeringen av projektet och valen av arbetsmetoder. Tidigare projekterfarenheter har motiverat flera av gruppens val av tekniker, som Slack för gruppkommunikation och Google Drive för att samla gemensamma dokument.

3

Teori

Det här kapitlet beskriver de verktyg, arbetsmetoder och ramverk som har använts under projektets gång.

3.1

Utvecklingsverktyg och metoder

Här beskrivs de utvecklingsverktyg och metoder som har bidragit till utvecklingen.

3.1.1

Slack

Slack är ett molnbaserat verktyg för kommunikation [1]. Det tillåter ett team att skicka med-delanden och dela filer mellan medlemmarna. Utöver detta finns funktionalitet för olika ka-naler samt videosamtal. Detta gör att varje team kan ha en egen kanal och diskutera saker som är relevant för just det teamet. Slack har även stöd för att ansluta flertalet andra verktyg, till exempel Trello.

3.1.2

Kanban

Kanban är en agil arbetsmetodik som ämnar att begränsa ”Work In Progress” (WIP) i ett projekt. I Kanban har man ett bräde som är synligt för samtliga projektmedlemmar. På brä-det sätts aktiviteter som ska göras upp, och flyttas mellan olika kolumner baserat på var i utvecklingsprocessen de befinner sig. Ofta begränsas antalet aktiviteter som får finnas i var-je kolumn, för att se till att aktiviteter blir färdiga istället för att nya startas. Mer teori om Kanban återfinns i bilaga E

3.1.3

Scrum

Scrum är ett agilt ramverk för projekt primärt inom mjukvaruutveckling som lämpar sig för större och mer komplexa projekt [2]. Tre viktiga begrepp för Scrum är transparens, inspektion och anpassning. Transparens syftar på att viktiga delar av utvecklingsprocessen ska vara synliga för de som är med och påverkar resultatet av processen. Med inspektion menas att inspektioner ska ske ofta, men inte så ofta att de förhindrar en effektiv arbetsgång. Under en inspektion kan det beslutas att en förändring måste ske för att resultatet av processen ska

3.1. Utvecklingsverktyg och metoder

bli tillfredsställande. I så fall justeras processen så fort som möjligt för att undvika vidare problem. Det är denna justering som står för begreppet anpassning.

En viktig del av Scrum är teamet som består av en Scrum master och ett team av utveck-lare [2]. Utöver teamen finns även en produktägare som försöker effektivisera arbetet så mycket som möjligt. Det är upp till Scrum Master:n att se till så att alla under utvecklingen förstår sig på hur Scrum fungerar.

Det mest kännetecknande för Scrum är sprinten som är en tidsbaserad utvecklingsperiod på en månad eller mindre [2]. Ett projekt består av en eller oftast flera iterationer av dessa. Efter varje sprint ska en mer eller mindre färdig och användbar produkt ha producerats. Varje sprint består av planering, dagliga möten, utvecklingen av produkten, en recension av arbetet och en återblick i slutet. Varje sprint har även ett satt mål med vad som ska imple-menteras under tidsperioden. Under sprintens gång görs inga förändringar som kan riskera att målet med sprinten inte uppnås. Omfattningen av arbetet kan däremot ändras genom förhandlingar mellan produktägaren och utvecklingsteamen.

3.1.4

Systemanatomi

En systemanatomi är ett diagram som beskriver ett systems förmågor och dess beroenden. Ett exempel på en systemanatomi som beskriver en registrering av ett konto ses i figur 3.1.

Figur 3.1: Exempel på en systemanatomi.

3.1.5

Visual Studio

Visual Studio är en integrerad utvecklingsmiljö med stöd för flertalet programspråk och ram-verk, vilket bland annat inkluderar programspråket C# och .NET-ramverket [3]. Utvecklings-miljön kan bland annat användas för utveckling av applikationer till Windows, mobilappli-kationer till Android, iOS och Windows Phone via Xamarin samt utveckling av molntjänster via Microsoft Azure.

3.1. Utvecklingsverktyg och metoder

3.1.6

Microsoft Azure

Azure är en samling molntjänster med månadskostnader som Microsoft förser utvecklare med [4]. Azure kan användas för att skapa och distribuera program via Microsofts datacenter.

3.1.7

Git

Git är ett populärt och effektivt distribuerat versionshanteringssystem och används för att versionshantera källkod vid mjukvaruutveckling [5]. En av kärnorna i Git är att effektivt kunna skapa och sammanfoga grenar. Arbetsflödet består vanligtvis av att utvecklingsgrenar skapas genom förgrening från en stabil huvudgren. De nya grenarna används för att im-plementera nya funktioner eller för att förbättra systemet. När implementationerna är klara på en gren och grenen är stabil så sammanfogas den med huvudgrenen. Vid tillägg av nya funktioner och för att testa alternativa implementationer kan nya grenar skapas från utveck-lingsgrenarna.

3.1.8

GitHub

GitHub är en versionslagringstjänst för mjukvaruprojekt som använder sig av versionshante-ringssystemet Git [6]. GitHub bidrar med ett enkelt grafiskt webbgränssnitt för versionshan-tering och har inbyggd funktionalitet för att bland annat felrapportera, skapa pull requests, begära funktionalitet och hantera tillgång till projekt. Se bilaga B för mer information om GitHub pull requests.

3.1.9

Postman

Postman är ett program som kan användas för att testa webb-API:er. Med Postman skickas olika typer av HTTP-förfrågningar till en server och sedan visas svaret på valfritt format i ett GUI [7].

3.1.10

Google Drive

Google Drive är en molntjänst som Google erbjuder, som låter användare lagra filer i molnet [8] . Tjänsten är gratis och låter dessutom användare dela mappar och filer med varandra. Google Drive har dessutom verktyg för att skriva och ändra dokument direkt i en webbläsare, vilket även fungerar när fler användare har dokumentet öppet samtidigt.

3.1.11

ER och EER

Entity relationship-modeller (ER-modeller) i databassammanhang är konceptuella model-ler som representerar relationer mellan entitetstyper i databaser [9]. ER-diagram är en samling ER-modeller och representerar även entitettypernas egenskaper. Enhanced enti-ty relationship-modellen (EER-modellen) är en förlängning av ER-modellen för att repre-sentera koncepten generalisering, specialisering, superklasser, subklasser och union. ER-modeller/diagram och EER-ER-modeller/diagram används vid konceptuell design av databa-ser.

3.1.12

Trello

Trello är ett webbaserat verktyg för organisera projekt med hjälp av anslagstavlor [10]. Verk-tyget fungerar på samma sätt som en anslagstavla fungerar enligt Kanban. En tavla kan in-nehålla flera kategorier, till exempel ”Att göra”, ”Under testning” och ”Färdigt”. Inom dessa kategorier kan aktiviteter läggas in som beskriver en arbetsuppgift.

3.2. Hela projektet

3.2

Hela projektet

Här beskrivs allmän teori som behövs för att få en grundläggande förståelse över de tekniker som använts under utvecklingen.

3.2.1

HTTP

HTTP (Hypertext Transfer Protocol) är ett överföringsprotokoll som används för kommuni-kation på webben [11]. Kommunikommuni-kationen sker genom att en klient skickar en förfrågan till en server som sedan svarar. Förfrågan(request) ser generellt ut på följande sätt:

metod URI HTTP-version CRLF

Där metod är t.ex. ”GET” och CRLF (Carriage Return Line Feed) är koden för en ny rad som säger att förfrågan slutar här. Ett HTTP svar innehåller bland annat en statuskod och even-tuellt information som efterfrågades (body). Statuskoden beskriver resultatet av förfrågan och faller i en av fem olika kategorier. Är det den tresiffriga kombinationen 1xx förmedlar det allmän information, som t.ex. att server ber klienten att skicka ytterligare en förfrågan. 2xx betyder att förfrågan lyckades. 3xx betyder att förfrågan inte var tillräcklig och att klien-ten måste göra något ytterligare för att fullfölja förfrågan. 4xx betyder att något fel skett på klientsidan och 5xx betyder att felet skedde på serversidan.

3.2.2

Cookies

En cookie eller en HTTP-kaka är en fil som innehåller information om en klient [12]. Kakan skapas av servern som sedan tilldelar den till klienten som sparar den lokalt. Kakan används sedan för att identifiera klienten genom att klienten skickar med kakan vid HTTP-anrop. Det-ta möjliggör till exempel inloggningsfunktionalitet eller att en webshop kan spara innehållet i kundvagnen mellan anrop.

3.2.3

JSON

JSON (JavaScript Object Notation) är ett format för dataöverföring [13]. Det är lättläst för människor och nästan alla programspråk stödjer JSON, antingen inbyggt eller genom tredje-partstillägg.

3.3

Mobilapplikation

Här beskrivs den teori som behövs för en grundläggande förståelse av de tekniker som an-vänts under utvecklingen av mobilapplikationen.

3.3.1

Xamarin

Xamarin är en plattform för utveckling av mobilapplikationer till flera plattformar [14]. Det ägs av Microsoft och finns tillgänglig som ett plugin till utvecklingsmiljön Visual Studio. Plattformen tillåter användaren att skriva gemensam C#-kod till Android, iOS och Windows Phone. Se bilaga C för mer information om hur Xamarin användes i projektet.

3.3.2

Xamarin Test Recorder

Xamarin Test Recorder är ett verktyg som gör det möjligt att skapa tester till Xamarin-applikationer genom att spela in en sekvens av handlingar antingen på en mobil enhet eller en emulator [15]. Dessa tester kan sedan köras automatiskt för att säkerställa att sekvensen fortfarande ger samma resultat. Se bilaga A för mer om Xamarin Test Recorder.

3.4. Molntjänsten

3.3.3

PCL Storage

Portable Class Libraries (PCL) Storage är ett multiplattform-API till Xamarin som möjliggör att spara och ladda data lokalt till filsystemet som applikationen körs på [16].

3.3.4

Facebook-inloggning

Facebook tillhandahåller API:n och SDK:er för att använda funktioner från Facebook i Android- och iOS-applikationer [17]. En av de funktioner som detta möjliggör är inloggning via Facebook. Det låter användare identifiera sig med sitt Facebook-konto vilket gör att de inte behöver ett nytt konto och lösenord för applikationen. När användare godkänt att ap-plikationen får utnyttja Facebook-inloggning och loggat in kan apap-plikationen kommunicera med Facebooks API för att hämta information om användaren.

3.4

Molntjänsten

Här beskrivs den teori som behövs för en grundläggande förståelse av de tekniker som an-vänts under utvecklingen av molntjänsten.

3.4.1

REST

REST (Representational State Transfer) är en arkitekturstil som kan användas för utveckling av webbgränssnitt. Ett system som är byggt enligt REST ska följa fem olika principer [18].

• Klient-server - Systemet ska vara klient-server orienterat så att gränssnitt skiljs från datahantering för att göra systemet portabelt.

• Tillståndslös - Servern ska inte behöva lagra information om klienten, d.v.s. all nödvän-dig information skickas vid varje förfrågan.

• Cache - Data i ett svar kan markerats som "cacheable", det vill säga servern tillåter att data tillfälligt lagras lokalt av klienten mellan förfrågningar för att öka effektivitet. • Enhetligt gränssnitt - Olika komponenter ska skicka data enligt samma standard. • Lager - Systemet skall bestå av lager, d.v.s. enskilda komponenter behöver inte veta

hur andra lager än de som de är direkt ihopkopplade med beter sig. Detta medför att implementation och användning blir enklare till priset av mer kod.

3.4.2

ASP.NET Core

ASP.NET Core är ett lättviktigt webbramverk utvecklat av Microsoft och är en multiplatt-formvsersion av webbramverket ASP.NET tillgänglig som öppen källkod [19]. Ramverket är optimerat kring utveckling av applikationer som körs i molnet.

3.4.3

Object Relational Mapping

Object Relational Mapping (ORM) är en teknik som möjliggör mappning mellan databasen-titeter och objekt skapade i något objektorienterat programmeringsspråk [20]. Tekniken gör det möjligt att arbeta objektorienterat med databaser.

3.4.4

Entity Framework Core

Entity Framework Core (EF Core) är ett ORM-ramverk utvecklat av Microsoft [21]. EF Core stödjer flera olika databasleverantörer, bland annat Microsoft SQL Server, MySQL och SQLite

3.5. Webbgränssnitt

3.4.5

Firebase Cloud Messaging

Firebase Cloud Messaging (FCM) är en tjänst som används för att skicka notifikationer och datameddelanden till olika plattformar [23].

3.4.6

OneSignal

OneSignal är en push-notifikationstjänst som använder FCM och ger utvecklare ett enkelt verktyg att skicka notifikationer till flera olika plattformar [24]. OneSignal erbjuder SDK:er för alla stora plattformar och erbjuder möjligheten att skicka notifikationer till anslutna en-heter genom att göra API-anrop till deras tjänst och genom en instrumentpanel på deras hemsida.

3.5

Webbgränssnitt

Här beskrivs den teori som behövs för en grundläggande förståelse av de tekniker som an-vänts under utvecklingen av webbgränssnittet.

3.5.1

AJAX

Asynchronous JavaScript and XML (AJAX) används i webbläsare för att ta emot och skicka data mot en server utan behovet att ladda om hela sidan [25]. Exempel på data som skickas är ofta av typerna JSON, XML, HTML eller oformaterad text.

3.5.2

ECMAScript 2015

En nyare standard av JavaScript som medförde bland annat klasser och moduler till språket. Benämns ofta ES6 men är inte ett officiellt namn för standarden [26].

3.5.3

React

React är ett bibliotek till JavaScript med öppen källkod för att bygga gränssnitt [27]. Det ut-vecklades av Facebook för att lättare skapa vyer till hemsidor, men har sedan sin lansering även fått stöd för mobilapplikationer genom React Native.

3.5.4

SPA

SPA (Single Page Application) är ett namn för webbsidor eller webbapplikationer som inte laddar om all data på sidan utan använder laddning i bakgrunden för att byta ut delar av sidan [28]. Då webbläsare byggdes för att ladda om sidor på nytt så används med fördel HTML5 History API för att byta URL och möjliggöra navigation med bakåt- och framåt-knappar. För att SPA ska fungera bra behöver även servern som tillhandahåller sidan vara medveten om att det är en SPA-sida, detta då laddningar alltid ska hämta en och samma fil oavsett URL.

3.5.5

Redux

En modifierad implementation av Facebooks Flux som är en applikations arkitektur eller ett programmeringsmönster [29]. I grova drag ger det ett sätt för information att bara flyta åt ett håll (unidirectional data flow) vilket ska ge mer förutsägbara och lätthanterliga tillstånd.

4

Metod

Det här kapitlet ämnar förklara de metoder och tekniker som teamet använt sig av i utföran-det av projektet.

4.1

Tilldelning av ansvarsområden

I projektet fanns det tre översiktliga moduler som skulle byggas. Dessa moduler var mobi-lapplikation, molntjänst och webbgränssnitt. Därför tedde det sig naturligt att i teamet göra en uppdelning med projektmedlemmarna till de olika modulerna. Av dessa bedömdes webb-gränssnittet vara det minsta, och fick därför endast en huvudansvarig. För att inte ha en för kritisk länk sattes en person till med på gränssnittet med delat ansvar mellan webbgränssnitt och molntjänst. På de andra två modulerna var det tre personer på vardera.

4.2

Utbildning

Första delen i projektet blev att utbilda sig inom de programvaror och språk som skulle kom-ma att användas i projektet. Varje projektmedlem fick ansvar att utbilda sig inom den mo-dul man skulle jobba med. Inom momo-dulerna spriddes utbildningen genom diskussioner och mini-föreläsningar om någon utbildat sig djupare inom ett område som flera behövde kunna.

4.3

Kanban med Trello

Inom projektet togs vissa praxis från Kanban. Utgångspunkten var den erfarenhet och upp-fattning projektgruppen hade av Kanban sedan innan. Detta innebar ett moment i början av projektet där gruppen tillsammans uppskattade vilka aktiviteter som skulle behöva ut-föras för projektets fullbordan. Dessa aktiviteter rangordnades och tidsuppskattades sedan. I detta moment letade projektgruppen även beroenden mellan aktiviteter, för att kunna få en uppfattning om i vilken ordning aktiviteterna skulle utföras. Efter detta uppfördes ett Kanban-bräde med fyra kolumner: ”Att göra”, ”Under utveckling”, ”Testning” och ”Färdigt” i verktyget Trello. Varje aktivitet blev där en lapp. Brädet arbetades med iterationsvis. I bör-jan på varje iteration utvärderades vilka lappar som skulle föras in i kolumnen ”Att göra” utifrån tidsuppskattning och rangordning. Som målsättning sattes att varje projektmedlem

4.4. Kommunikation med Slack

bara skulle vara inbegripen på max en aktiv lapp åt gången. I början på tredje iterationen omformaterades brädet, så att varje modul hade ett enskilt bräde istället för att alla moduler fanns med på samma bräde. I den tredje iterationen infördes också en veckovis uppföljning av Kanban-brädet. Gruppen samlades och diskuterade om brädet hade använts korrekt samt vad som hade hänt den gångna veckan.

4.4

Kommunikation med Slack

Kontinuerligt under hela utvecklingen av produkten användes Slack som verktyg för kom-munikation. Kommunikationen delades upp i ett antal olika kanaler där varje utvecklings-team hade en egen kanal för enkel kommunikation inom utvecklings-teamet. Utöver detta användes en generell kanal för allmän kommunikation med hela gruppen. Utvecklingskanalerna använ-des för att dela information och erfarenheter angående utvecklingen samt för att organisera utvecklandet när detta behövdes. Den generella kanalen användes huvudsakligen för att för-medla viktig information till hela gruppen, såsom vilka lokaler som är bokade för utveckling.

4.5

Systemanatomi

Systemanatomin över systemet framtogs tidigt under första iterationen för att få en tidig bild över systemet. Den användes senare vid framtagningen av aktiviteter eftersom det var lätt att översätta den till aktiviteter och automatiskt få med beroenden mellan aktiviteter. Systemanatomin användes även som underlag för arkitekturbeskrivningen.

4.6

Iterationer

Arbetet i projektet har genomförts under fyra iterationer som varit mellan två och fyra veckor långa. Mellan dessa iterationer utvärderades föregående samt planerades kommande itera-tion. Nedanför beskrivs arbetssättet i varje iteration för sig.

4.6.1

Iteration 1

Under iteration 1 framställdes dokument så som kravspecifikation och projektplan. När verktygen till utvecklingsfasen hade bestämts lades också tid på utbildning i dessa. Allt detta i syfte att förbereda inför utvecklingsfasen av projektet.

Dokumenten som skapades under iteration 1 togs fram genom både enskilt arbete och under gruppmöten. För varje dokument utsågs en huvudansvarig som författade huvudde-len av respektive dokument, men alla besluts som togs i dokumenten diskuterades under möten så att samtliga medlemmar var överens om vad som skrevs. Samtliga dokument granskades också av flera medlemmar innan första versionen av dokumenten ansågs kla-ra. Utöver nedanstående dokument påbörjades även arbetet på arkitekturdokument och testplan. De dokument som skapades var:

• Kravspecifikation. Tidigt i projektets skede hölls ett kundmöte med en representant från Byggvarulistan. Utifrån detta möte och det tidigare erhållna projektförslaget formule-rades en kravspecifikation. Analysansvarig var huvudansvarig för detta dokument • Projektplan. Teamledaren hade huvudansvar för framtagning av detta dokument.

Do-kumentet beskriver projektmedlemmarnas roller inom projektet, hur arbetet ska ge-nomföras och fördelas, samt riskhantering i projektet.

• Kvalitetsplan. Kvalitetssamordnare hade huvudansvar för framtagning av detta doku-ment. Kvalitetsplanen beskriver vilka verktyg och standarder som ska följas för att både dokument och själva produkten som tas fram ska vara av hög kvalitet.

4.6. Iterationer

• Systemanatomi. Denna framställdes under ett gruppmöte och beskriver vad som är nödvändigt för produkten för att denna ska uppfylla de krav som beskrivs i kravspeci-fikationen.

• Dokumentmall. Dokumentansvarig tog fram detta dokument som användes som mall för samtliga dokument exklusive denna rapport.

För att kunna fördela arbetsbördan tog gruppen beslut om att dela upp projektet i tre primära delar: mobilapplikation, molntjänst, och webbgränssnitt. Beslut togs även om hur dessa delar skulle utvecklas. Mobilapplikationen skulle framställas med verktyget Xamarin. Molntjäns-ten skrivas i C# i programutvecklingsmiljön Visual Studio och webbgränssnittet utvecklas med JavaScript-biblioteket React. Projektmedlemmarna valde sedan vilken del de ville vara med att utveckla så att varje område hade mellan två och tre personer som ansvarade för det. Under hela iteration 1 lades mycket tid på individuell utbildning inom respektive område. Områdena delades även upp i mindre delar där varje enskild person ansvarade för var sin del.

4.6.2

Iteration 2

Under iteration 2 påbörjades utvecklingen av programvaran. Kommentarer från handledaren på de redan skapade dokumenten åtgärdades. Utöver detta skrevs och påbörjades även nya dokument:

• Testplan. Testledaren hade huvudansvaret för att framställa denna. Testplanen beskri-ver hur testningen går till i projektet. Här specificeras vilka testrambeskri-verk som ska an-vändas för de diverse olika modulerna. Det framgår även vilka delar av varje modul som det ska finnas strukturerade test för, samt när dessa ska göras. Eftersom de olika modulerna skiljer sig i många aspekter så följer det att testningen inte kan utföras på samma sätt för alla.

• Arkitekturbeskrivning. Här var teamets arkitekt huvudansvarig. Arkitekturbeskriv-ningen ämnar ge teamet en gemensam bild om hur systemet ska se ut och byggas upp. Här nedtecknas även designbeslut och liknande som tas under projektets gång. • Projektrapport. För att underlätta skrivningen av denna rapport till kandidatprojektet

påbörjades den tidigt, redan i iteration två. De tidigare rubrikerna i dokumentet kunde skrivas redan här, och skisser till individuella bidrag till rapporten fanns med. Med detta underliggande utkast var det enkelt att i kommande iterationer succesivt fortsätta skriva på rapporten så fort underlag erhölls som skulle vara med i rapporten.

4.6.3

Iteration 3

I början av iterationen var alla dokument färdigskrivna och uppdaterade efter opposition vil-ket gav oss en klar bild över systemet och vad som skulle göras. Eftersom den huvudsakliga dokumentationen var färdig kunde det under denna iteration fokuseras nästan enbart på ut-vecklingen. På grund av detta gjordes en stor del av utvecklingen just under denna iteration och systemet började närma sig en färdig produkt.

Mobilapplikationen

Under iterationen skedde mycket stora framsteg med mobilapplikationen och all funktiona-litet som behövdes enligt kravspecifikationen implementerades mer eller mindre. Trots att det mesta av huvudfunktionaliteten implementerades så återstod fortfarande några problem som var viktiga att fixa för att applikationen skulle kunna användas enligt specifikationer.

4.6. Iterationer

Under iterationen skedde mycket av utvecklingen tillsammans där eventuella problem eller designbeslut kunde diskuteras direkt. Detta var för att kontra den något långsamma utvecklingen under tidigare iterationer och ledde till en mycket snabb och effektiv utveckling. I slutet av iterationen påbörjades användartestning för att få lite andra perspektiv på de-signen av gränssnittet. Några större tester med Xamarin Test Recorder hade inte påbörjats i detta skede. Dessa tester hade dock under denna iteration blivit definierade men på grund av svårigheter att installera Xamarin Test Recorder på våra utvecklingsdatorer blev testningen försenad till nästa iteration.

Molntjänsten

I iteration 3 utfördes majoriteten av arbetet med molntjänsten. Alla olika HTTP-anrop till API:et utökades och färdigställdes. API:et fick nu funktionalitet så att användare kunde göra fyra elementära operationer på objekten (kvitton, erbjudanden, och användare) i databasen. De fyra operationerna består av att skapa, visa, uppdatera och ta bort objekt. Funktionalitet för att komma åt objektens bilder, som lagras i separata bord i databasen, implementerades. API:et tillät också användare till en viss mån skräddarsy anrop genom att be om alla kvitton för en specifik användare och be om alla kvitton tillhörande ett visst erbjudande.

Molntjänsten fick också inloggnings-funktionalitet. Inloggning av användare sker med hjälp av Facebooks API genom att en användare erhåller ett användartoken i applikation som denne sedan skickar med till molntjänsten för att logga in. För administratörer används istället webbgränssnittet där de skickar med användarnamn och lösenord som verifieras mot databasen. Autentisering sker med hjälp av HTTP-kakor och auktorisering sker med samma cookie som innehåller information om klientens rättigheter. De tre behörighetsnivåerna som implementerades är användare, administratör och root.

Funktionalitet för push-notifiering implementerades också under iteration 3. För notifiering används OneSignals API genom vilket kunder med applikationen installerad nu erhåller notifikationer om deras inlagda kvittons granskad- och godkänd-status och nyligen tillagda erbjudanden.

När allt detta implementerats lades sedan molntjänsten upp på Azure vilket gav mobi-lapplikationen och webbgränssnittet möjlighet att testa mot molntjänsten. Mycket tid lades därefter på att korrigera fel och rätta till buggar som upptäcktes i molntjänstens programvara under tiden som de resterande delarna fick mer funktionalitet.

Webbgränssnittet

Iterationen påbörjades med en kodbas som inte uppfyllde ett enda krav och slutade i en som uppfyllde alla grundläggande krav från kunden. Utvecklingen krävde ibland att moln-tjänsten hade fungerande anrop medan vissa saker implementerades. Detta för att kunna integrationstesta funktioner som var under utveckling i webbgränssnittet mot ett fungerande API.

Webbgränssnittet började med att visa information om användare, men för att komma till det stadiet så behövde annat implementeras först. Tillstånd och data behöver kunna lagras någonstans så Redux implementerades väldigt tidigt. Efter att en grund hade lagts med Redux så påbörjades arbetet med nätverksanrop och AJAX. När detta väl var upplagt implementerades funktioner för att hämta och visa data om användare, någonting som fanns tidigt i molntjänsten.

4.7. Gemensamma erfarenheter

Då målet var att utveckla modulen som en SPA behövdes en metod för att kunna växla vad som visas på skärmen beroende på vilken URL man står på. För detta användes React-Router som är ett bibliotek för hantering av navigation på klientsidan [30].

Iterationen genomfördes mycket tillsammans med moln-teamet för att snabbt kunna dis-kutera lösningar på problemet att få tag på data på ett smidigt sätt från servern. Detta underlättade även debug-processen då webbgränssnitts-teamet snabbt kan testa lösningar och olika typer av förfrågningar som servern kan stöta på.

4.6.4

Iteration 4

Under den fjärde iterationen var det mesta av utvecklingen färdig, endast några småsaker fanns kvar att fixa. Iterationen bestod till stor del av dokumentskrivande och testning för att förse kunden med en stabil produkt.

Mobilapplikation

Det som återstod att fixa efter den tredje iterationen var att fixa så att kakor och annan information gick att spara på telefonen. Innan den fjärde iterationen var användare av appli-kationen tvungna till att logga in varje gång de startade den för att bli tilldelad en ny cookie och återhämta all information som behövs.

Utöver att implementera det som nämns ovan så var ett huvudsakligt mål med denna iteration att testa applikationen och se till att den är stabil för överlämning. Testningen utfördes med hjälp av Xamarin Test Recorder samt användartester.

Molntjänsten

Under den sista iterationen var fokus på testning och bugg-fixning, och därmed verifiering av att molntjänsten uppfyller de krav som ställts på den. Testning gjordes dels med Postman genom att göra anrop till molntjänstens API och kontrollera data som returnerades. Även integrationstester utfördes genom att testa de övriga två delarna mot molntjänsten.

Webbgränssnitt

Även för webbgränssnittet låg störta fokuset på testning, främst integrationstester mot moln-tjänsten.

4.7

Gemensamma erfarenheter

Halvvägs in i projektet tillkom en punkt i dagordningen på de interna veckomötena där ge-mensamma lärdomar och erfarenheter togs upp, för att stödja att projektmedlemmarna tog med sig det de lärt sig i projektet till framtida arbetsuppgifter.

4.8

Slack som kommunikationsverktyg

För att undersöka hur Slack fungerat som kommunikationsverktyg skickades en enkät ut till hela gruppen med frågor om hur de upplevt att Slack fungerat och om de var nöjda med verktyget. Denna enkät skickades ut i slutet av projektet för att låta gruppmedlemmarna användarna använda Slack så länge som möjligt innan de lämnade sina svar.

4.9. Arbetet i ett vidare sammanhang

4.9

Arbetet i ett vidare sammanhang

För att undersöka hur systemet passar in i ett vidare sammanhang gjordes en utvärdering kring hållbar utveckling. Målet med denna utvärdering var att få en förståelse om systemets påverkan i ett större perspektiv. I projektets senare skede (Iteration 4) hölls ett seminarium där temat var att ta fram krav för systemet som tog hållbar utveckling i åtanke. Dessa krav jämfördes sedan med de krav som faktiskt tagits fram i början av projektet, och vilken skill-nad dessa krav skulle kunna lett till om de varit med i början av projektets uppstart.

För att hjälpa till med att ta fram de nya kraven användes en modell för att resonera kring hållbar utveckling och mjukvara som baserades på den modell som presenteras i ”Framing Sustainability as a Property of Software Quality” [31]. Modellen delar upp hållbar utveckling i 4 dimensioner och försöker sedan placera in olika aspekter som t.ex. teknikval i dessa. Mellan dessa aspekter dras pilar som visar hur de påverkar varandra, antingen positivt eller negativt. De fyra dimensionerna täcker 4 synvinklar på hållbar utveckling: social, miljö, teknik och ekonomi. När systemets olika aspekter delats upp och samband hittats tas sedan mål fram för att förbättra systemets hållbarhet.

5

Resultat

Det här avsnittet beskriver det resulterande systemet som implementerats med de arbetsme-toder och tekniker som teamet har använt under projektets gång. Avsnittet beskriver även teamets gemensamma erfarenheter och ger en kort översikt över de individuella bidragen.

5.1

Systembeskrivning

Den här delen ger en översiktlig beskrivning av systemets moduler samt vad kunden har för värde av systemet.

5.1.1

Mobilapplikation

Mobilapplikationen är utvecklad i Xamarin och består av ett Android-projekt och ett delat projekt. Med delat menas att koden kan användas på både Android och iOS. För att under-lätta en framtida iOS-version av applikationen hölls så stor del av koden som möjligt i det delade projektet. Applikationen låter användare se aktiva kampanjer och cashbacks, utnyttja dem genom att ladda upp kvitton samt se status för sina uppladdade kvitton. Användare kan också ladda upp kvitton som inte är kopplade till ett erbjudande (kampanj eller cashback) för att lagra dem i molnet, något som kan vara användbart för t.ex. bokföring.

Systemanatomi

I figur 5.1 ses systemanatomin över mobilapplikationens olika moduler.

Delad kod

Kod som inte har med plattformsspecifika funktioner som t.ex. GUI att göra har placerats i det delade projektet. Det innebär att projekt på olika plattformar kan göra samma funktions-anrop till den delade koden. På så sätt kan man undvika duplicering av kod mellan olika plattformar. Det som framförallt har delats är kommunikation med molntjänsten och lagring av data. När dessa funktioner behövs kallar Android-projektet på funktioner i det delade projektet som sedan tar över.

5.1. Systembeskrivning

Figur 5.1: Mobilapplikationens systemanatomi

Registrering och inloggning

För autentisering vid registrering och inloggning används Facebooks SDK. Användaren log-gar in med sitt Facebook konto och godkänner att systemet får tillgång till deras information. Exakt vilken information som systemet får tillgång till specificeras i applikationen. Utöver den information som alltid ges tillgång till (namn, användar-id, etc.) kräver applikationen tillgång till att läsa av användarens e-postadress. När användaren loggats in med Facebook fås en token ut som kan användas för att identifiera användaren.

Nästa steg är att användaren loggas in i systemet genom ett anrop till molntjänsten, där det token som mottogs vid Facebookinloggningen skickas med. Med hjälp av Facebooks API kan molntjänsten verifiera att det token de fick är giltigt och även få veta användar-id för den användare som loggat in. När applikationen får ett svar från molntjänsten undersöks svarets statuskod, och om det var ett lyckat anrop tas användaren vidare in i applikationen. Om anropet inte lyckades visas ett felmeddelande för användaren och sedan loggas användaren ut från Facebook så att ett nytt försök kan påbörjas.

Notifikationer

För att hantera notifikationer används OneSignal. Implementationen av OneSignal i applika-tionen är väldigt enkel. Först inkluderades OneSignals SDK i projektet, och sedan initieras

5.1. Systembeskrivning

OneSignal, vilket kan göras med bara en rad kod. För att kunna skicka notifikationer till spe-cifika användare behöver molntjänsten ha ett id för varje användare. Detta id erhålls med hjälp av SDK:t, och skickas sedan med när användaren loggar in.

Kommunikation

Kommunikation med molntjänsten sker via en HTTP-klient med stöd för att hämta eller lad-da upp lad-data till en viss adress inom molntjänsten. Exempelvis vid asynkron uppladdning av ett kvitto används följande kod:

var response = await client.PostAsync(

"http://cloudservice11.azurewebsites.net/api/receipts/", stringContent);

Variabeln stringContent ovan innehåller all data som ska skickas i JSON-format och http://cloudservice11.azurewebsites.net/api/receipts/ är adressen det ska skickas till.

Hantering av cookies

Vid kommunikation mellan applikationen och molntjänsten används cookies för auktorise-ring. När applikationen gör ett inloggningsanrop till molntjänsten skickar molntjänsten med en cookie i sitt svar. Denna måste lagras i applikationen för att skickas med i varje anrop till molntjänsten. I cookien finns ett unikt användar-id som molntjänsten använder för att verifi-era vem användaren är och att den är inloggad. På så sätt behövs inte användaren verifiverifi-eras mot Facebook för varje anrop från applikation till molntjänst.

Permanent data

När applikationen stängs ner försvinner data som har skapats under sessionens gång utan att sparas till permanent minne. För att ha kvar det data som finns bland annat i de datastruktu-rer runt kvittobilder tagna i applikationen används API:et PCL Storage. När kvitton skapas sparas de samtidigt till kvittolistan i applikationen och till filsystemet. Till filsystemet sparas kvitto-objektet i JSON-format sist i en fil där alla kvitto-objekt ligger sparade. Dessa laddas sedan in vid nästa uppstart av applikationen.

Gränssnitt

För att presentera kampanjer och cashbacks för användaren har applikationen ett antal listor. Dessa listor visar information om erbjudandet och har knappar för att utnyttja erbjudandet. För kampanjer visas en kampanjbild, beskrivning, produktnamn, företag och slutdatum. Kampanjbilden har en upplösning som är hög nog för att hämtningen av bilderna ska ta märkbar tid. För att undvika väntetid för användaren hämtas därför inte bilderna på samma gång, utan först när kampanjen ska visas. När listan öppnas laddas alltså bara de första få kampanjbilderna ner. Varje kampanj har dessutom en knapp för att ladda upp ett kvitto. För cashbacks visas varuhusets logotyp, namn och den procent som erbjuds. Dessa logo-typer är tillräckligt små för att de ska kunna laddas ner samtidigt utan att användaren behöver vänta någon märkbar tid. Cashbacks har precis som kampanjer en knapp för att ladda upp ett kvitto, men de har även en knapp för att öppna varuhusets hemsida i mobilens webbläsare. Detta görs med en speciell länk som gör att kunden får cashback på köp som görs online. Detta sköter byggvaruhusets hemsida och Byggvarulistan, mobilapplikationen behöver bara öppna den länk som laddats ner tillsammans med cashbacken.

5.1. Systembeskrivning

5.1.2

Molntjänst

Molntjänsten i systemet består av ett webb-API och en databas. Användare av applikatio-nen och webbgränssnittet kommunicerar med molntjänsten genom att göra API-anrop. Syftet med molntjänsten är att ta emot, lagra och skicka information om kvitton och erbjudanden till applikationen och webbgränssnittet. Molntjänsten använder OCR för att extrahera text från bilder av kvitton som sedan lagras tillsammans med bilden och notifikationer för att medde-la kunder om nya erbjudanden och statusuppdateringar för inskickade kvitton. Molntjänsten körs på molnplattformen Microsoft Azure.

Systemanatomi

I figur 5.2 ses systemanatomin över molntjänstens olika moduler.

Figur 5.2: Molntjänstens systemanatomi

Autentisering och auktorisering

Molntjänsten utnyttjar cookies för att auktorisera användarna av API:et. Administratörer som loggar in genom webbgränssnittet autentiseras mot användaruppgifter som finns lagrade i databasen. En administratör skickar med sitt lösenord och e-postadress som administratö-ren angav vid registrering. Användare av applikationen autentiseras med hjälp av Facebook. Roller har implementerats för att hantera auktorisering av olika resurser. Molntjänsten har tre olika roller som motsvarar användarnas accessnivåer 5.1.

5.1. Systembeskrivning

Roll Beskrivning

Root Full tillgång till molntjänstens API. Möjligheten att lista registre-rade kunder, lägga till och ta bort administratörer och erbjudan-den samt hämta och godkänna kvitton.

Admin Möjligheten att lista registrerade kunder, lägga till och ta bort er-bjudanden samt hämta och godkänna kvitton.

User API-rättigheter begränsade till att ladda upp kvitton samt hämta erbjudanden och egna kvitton.

Tabell 5.1: Roller

API

API:et har utvecklats med webbramverket ASP.NET Core och består av en uppsättning API-anrop som används för att utföra arbete i databasen. Genom dessa API-API-anrop kan användare av mobilapplikationen ladda upp kvitton till databasen och hämta erbjudanden från data-basen. Webbgränssnittet låter administratörer lägga till och ta bort erbjudanden samt hämta och granska kvitton och användare. Genom webbgränssnittet kan även administratörer med roträttigheter lägga till och ta bort administratörer.

Databas

Databasen implementerades med ORM ramverket Entity Framework Core (EF Core) och använder sig av databasleverantören Microsoft SQL server. Beslutet att använda EF Core för databashantering togs för att underlätta implementationen av databasen och hanteringen av databasaccesser. EF Core och SQL server är välanpassat till ASP.NET Core vilket motiverade beslutet ytterligare.

Databasen skapades med ett tillvägagångssätt som kallas code-first. Code-first kan översikt-ligt beskrivas som att klasser skapas för att representera entitetstyper i databasen, därefter genereras databasschemat från koden. Det medförde att ett databasschema i SQL inte behöv-de skrivas.

Ett EER-diagram togs fram för att underlätta implementationen av databasen. Struktu-ren av databasen ändrades under implementationen för att anpassas efter nya behov som växte fram under projektets gång. Även då strukturen av databasen förändrades gav EER-diagrammet ett mycket bra stöd vid den initiala implementationen.

Eftersom molntjänsten behöver kunna lagra bilder togs beslutet att bilderna skulle lag-ras direkt i databasen. Ett annat alternativ hade varit att lagra bilder direkt i filsystemet och spara sökvägar till bilderna i databasen istället. Det första alternativet valdes eftersom det kändes enklare att hantera, framförallt vid migrationer av molntjänsten, än det senare alternativet. För att optimera disk I/O togs beslutet att lagra bilder i egna bord och kartlägga dem med ett ’ett till ett’ förhållande till entiteterna de tillhör.

OCR

Den OCR som används i projektet bygger på ett projekt kallat Tesseract [32] som finns till-gängligt som öppen källkod. Tesseract är utvecklat i programmeringsspråket C++ och hu-vudsakligen för operativsystemskärnan Linux. För att få detta att fungera med resten av sy-stemet har ett nerskalat API, med kombinationer av funktioner från Tesseract, skrivits i C++.

5.1. Systembeskrivning

Till detta API har sedan en wrapper skrivits sådan att API:et går att använda med ASP.NET Core, vilket resten av systemet är skrivet i.

Notifikationer

OneSignal används för att skicka notifikationer från molntjänsten till applikationen. Notifika-tioner skickas när nya erbjudanden läggs till och när inskickade kvitton har blivit granskade av en administratör. OneSignal använder Firebase Cloud Messaging för att skicka notifika-tioner till mobilapplikanotifika-tioner. Första gången en användare av applikationen loggar in regi-streras användarens mobilenhet med OneSignal. För att skicka notifikationer till registrerade enheterna gör molntjänsten API-anrop till OneSignal. API-anropen innehåller ett meddelan-de som ska skickas och meddelan-de enheter som ska ta emot medmeddelan-delanmeddelan-det. OneSignal skickar därefter meddelandet vidare till angivna enheter. OneSignal och Firebase Cloud Messaging valdes att användas för deras stöd att skicka notifikationer till flera olika plattformar.

5.1.3

Webbgränssnitt

Webbgränssnittet är utvecklat i JavaScript och biblioteket React. Modulen ger administratö-rer ett sätt att hantera alla erbjudanden, användare, kvitton och annat som tillhandahålls av molntjänsten. Exempel på detta är att lägga till kampanjer och godkänna tillhörande kvit-ton. Webbgränssnittet är alltså en admin-panel för hela produkten. Webbgränssnittet har för uppgift att visa data från servern.

Systemanatomi

I figur 5.3 ses systemanatomin över webbgränssnittets moduler.

Nätverkskommunikation

All interaktion med molntjänsten sker genom API-anrop, detta sker över HTTP och all data kodas i JSON. För att göra anrop behövs en speciell klient. I det här projektet användes Axios. För att minimera duplicerad kod i så stor grad som möjligt används samma metod för att göra alla nätverksanrop. För att detta ska vara möjligt behöver anropet vara flexibelt och inte allt för krångligt att använda vid simpla frågor.

function ajaxRequest(method, url, actions, data=undefined, successHandler=undefined,

errorHandler=undefined)

Där method är en HTTP metod (GET, POST osv.) url sökvägen till API (t.ex. ”/campaigns”) och actions ett objekt som håller namnen för de actions som ska hanteras i Redux. För vissa frågor så är data även relevant. Detta är den data som skickas från klienten till servern. I vårt fall är det nästan uteslutande skapande och uppdaterande av resurser som använder fältet. Utöver dessa finns två valbara fält successHandler och errorHandler som tar emot funktioner som körs efter att nätverksförfrågan avslutats. På detta sätt skickas meddelandet iväg som beskriver om man är inloggad eller hanterar den omedelbara förändringen vid granskning av kvitton.

Registrering och inloggning

Då webbgränssnittet endast är till för administratörer så finns ingen självregistrering av kon-ton, ett konto är någonting man får tilldelat av en root-admin.

5.1. Systembeskrivning

Figur 5.3: Webbgränssnittets systemanatomi

Navigering

React Router används för att skriva och tolka positionen som visas i URL-fältet i webbläsaren. Baserat på URL:en så växlas vilken komponent som renderas och det skickas med informa-tion om hur länken ser ut. I vårt fall skickas nästan alltid vilket id resursen har och sedan om något speciellt läge ska visas för den. Standard (tomt argument) är visning men vissa typer kan editera eller granska resursen. Skickas inget id med så visas en lista av resurstypen istället.

Exempelvis, visning utav kampanjer tar emot kampanj-id och läge (mode). return <Campaigns campaignid={match.params.id}

mode={match.params.mode} />;

Dessa parametrar kommer från mönstret /campaigns/:id?/:mode? som beskriver två paramet-rar som valbara (därav frågetecknet).

Om id skulle vara tomt (undefined) så visas istället en lista. Ett id är oftast ett heltal men vår implementation stödjer även strängar för att kunna skapa länkar som /campaigns/new för att skapa nya kampanjer.

5.2. Gemensamma erfarenheter

Tillståndslagring

För att få till ett bra dataflöde i modulen används biblioteket Redux.

5.2

Gemensamma erfarenheter

Något som upptäcktes under början av utvecklingen var att det gick bättre att arbeta när hela teamet befann sig på samma fysiska plats än när alla arbetade på var sitt håll. Det upplevdes att det var svårt att få saker gjorda och det tog lång tid om något behövde diskuteras. Vid mer gemensamt arbete var det lätt att diskutera saker och rådfråga varandra vilket ledde till ett mycket effektivare arbete och att utvecklingen gick betydligt snabbare än tidigare. En stor erfarenhet som kommit upp under utvecklingen är hur viktigt det är med en stabil utvecklingsmiljö som fungerar som den ska. Detta märktes framförallt inom delgruppen som utvecklade mobilapplikationen. Under utvecklingen har gruppen haft problem med både Xamarin och Xamarin Test Recorder. Dessa problem har varit av olika allvarlighetsgrader, från små problem som att ett projekt inte laddas in och Visual Studio måste startas om, till mycket större problem som att flera utvecklingsdatorer behövde installeras om på grund av att en uppdatering till Xamarin skadat operativsystemet. De stora problemen har inte inträffat ofta, men de har ändå kostat mycket tid, framförallt då Xamarin och Visual Studio tar relativt lång tid att installera på nytt. De mindre problemen har inte tagit alls lika lång tid för varje fel, men totalt har det självklart kostat tid och skapat irritation.

En annan erfarenhet som dykt upp är hur lätt dokumentation och planering kan bli rö-rigt och förvirrande. Detta märktes tydligt i den delade Google Drive mapp som användes i projektet. Inga tydliga riktlinjer fanns för hur strukturen skulle se ut, vilket gjorde att det inte fanns en unison hantering av mappsystemet. I början av projektet när det inte hade hunnit bli så många filer upplevdes lagringen av dokumenten fungera bra, och det var inte svårt att hitta det dokument som söktes. Men allt eftersom projektet framskred och fler dokument tillkom blev det mer och mer rörigt. Det gjorde även att det kunde ligga kvar gamla filer som inte var aktuella längre. Detta hade kunnat lösas genom att sätta upp riktlinjer för hur systemet skulle hanteras, eller tydligare ange vem som ansvarade för att allt var uppdaterat och i god ordning. Att det lätt blir rörigt märktes också i gruppens Trello-bräden, framförallt under iteration 2. Många kort blev aldrig korrekt flyttade, och det var sällan de personer som arbetade på en aktivitet var taggade i aktivitetens kort. Detta förbättrades under senare ite-rationer då det blev en punkt på veckomötenas dagordning att gå igenom alla Trello-bräden. Gruppen har också fått erfarenhet av hur svårt det är att bryta upp utvecklingen i akti-viteter och delmål, samt hur svårt det är att tidsuppskatta dessa. Många av de aktiakti-viteter och delmål som togs fram tidigt i projektet genom brainstorming togs senare bort eller ändrades på grund av olika förutsättningar som förändrats, men även för att gruppens förståelse för ramverken och systemet i sig utvecklats under projektets gång.

Eftersom systemet består av tre delsystem som kommunicerar med varandra skrevs ett kommunikationsdokument vid ett möte för att bestämma vad som behöver skickas och hur informationen som skickas ska formateras. Mötet i sig var en erfarenhet då det hjälpte till att fånga upp eventuella oklarheter kring kommunikationen och ledde även till att alla fick en bättre insikt i systemet. Dokumentet gav sedan ett bra stöd genom projektet när delar som krävde kommunikation implementerades.

Den tidiga tilldelningen av roller och ansvarsområden var en bra erfarenhet. Rolltilldel-ning var en obligatorisk del av kursen men effekten av tilldelRolltilldel-ningen var positiv och gav