Linköpings universitetSE–581 83 Linköping

013-28 10 00 , www.liu.se

Linköpings universitet | Institutionen för datavetenskapExamensarbete på grundnivå, 15hp | Datateknik

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

Kunderbjudande i molnetProjektarbete för Byggvarulistan AB

Mattias EvaldssonFredrik GrahnLenny JohanssonSimon KarlssonAlexander SääfOscar ThunbergRichard Wigren

Handledare : Carl BrageExaminator : Kristian Sandahl

http://www.liu.se

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 årfrå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 enstakakopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och förundervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva dettatillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. Föratt 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 iden omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sättsamt 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 elleregenart. För ytterligare information om Linköping University Electronic Press se förlagetshemsida 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 toread, to download, or to print out single copies for his/hers own use and to use it unchangedfor non-commercial research and educational purpose. Subsequent transfers of copyrightcannot 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 measuresto assure authenticity, security and accessibility. According to intellectual property law theauthor has the right to be mentioned when his/her work is accessed as described above andto be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of documentintegrity, please refer to its www home page: http://www.ep.liu.se/.

c© Mattias EvaldssonFredrik GrahnLenny JohanssonSimon KarlssonAlexander SääfOscar ThunbergRichard Wigren

http://www.ep.liu.se/http://www.ep.liu.se/

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 dettabehandlas erfarenheter från projektet, vilket stöd man kan få genom att skapa och följa uppen 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 sparasina 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 hanteringav kvitton. Via detta system skulle det även gå att erbjuda cashbacks och kampanjer tillanvändaren. Under utvecklingen användes Slack för kommunikation och en systemanatomitogs fram och användes. Utvecklingen delades upp i fyra iterationer och baserades på agilaarbetsmetoder.

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änstenbestår av ett webb-API som har utvecklats med webbramverket ASP.NET och en databas somimplementerades med ORM-ramverket Entity framework core. Webbgränssnittet utveck-lades i JavaScript och biblioteket React. Dessa tre delar samverkar och ger en användaremöjlighet att genom applikationen hitta och utnyttja erbjudanden från Byggvarulistan och enadministratö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 äreffektivare att arbeta tillsammans inom teamet än att arbeta individuellt samt att valet avutvecklingsmiljö 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 Slackunderlättade kommunikationen väsentligt både generellt för hela gruppen och för de olikautvecklingsteamen.

iii

Författarens tack

Tack till Byggvarulistan AB som har bidragit med ett spännandeprojekt. Ett stort tack också till Carl Brage som har agerathandledare för projektgruppen.

iv

Innehållsförteckning

Sammanfattning iii

Författarens tack iv

Innehållsförteckning v

Ordlista viii

Lista av figurer x

Lista av tabeller xi

1 Introduktion 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Bakgrund 3

3 Teori 43.1 Utvecklingsverktyg och metoder . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 Hela projektet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 Mobilapplikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4 Molntjänsten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.5 Webbgränssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Metod 104.1 Tilldelning av ansvarsområden . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 Utbildning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3 Kanban med Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.4 Kommunikation med Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.5 Systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.6 Iterationer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.7 Gemensamma erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.8 Slack som kommunikationsverktyg . . . . . . . . . . . . . . . . . . . . . . . . . . 144.9 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Resultat 165.1 Systembeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.2 Gemensamma erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.3 Kommunikation med Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.4 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.5 Översikt över individuella bidrag . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

v

6 Diskussion 266.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.3 Användning av systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.4 Slack som kommunikationsverktyg . . . . . . . . . . . . . . . . . . . . . . . . . . 276.5 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7 Slutsats 307.1 Hur kan produkten implementeras så att man skapar värde för kunden? . . . . 307.2 Vilka erfarenheter kan dokumenteras från projektet Kunderbjudande i molnet

som kan vara intressanta för framtida projekt? . . . . . . . . . . . . . . . . . . . 307.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 317.4 Vilken effekt har verktyget Slack på kommunikation inom gruppen? . . . . . . 31

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

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

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

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

E Kanban med Trello i kandidatprojekt av Mattias Evaldsson 60E.1 Introduktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60E.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60E.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

E.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61E.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63E.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63E.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

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

G Tidsbudgetering och estimering inom projektet av Richard Wigren 72G.1 Introduktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72G.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72G.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73G.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74G.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76G.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76G.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

H Bilagor 79H.1 Enkätsvar - kodgranskning med GitHub pull request . . . . . . . . . . . . . . . 80H.2 Enkätsvar - Kanban med Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82H.3 Enkät: Kommunikation med Slack . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Referenser 86

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 fokuspå prisjämförelse inom gör-det-själv marknaden.

Cashback Ett återbäringsprogram som innebär att varuhus ger en procentsats av kostnadenfö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 grenensom 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 programsom 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 texttill text i en form som en dator kan hantera.

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

Sammanfogning Betyder i samband med GitHub att två grenar kombineras till en gren.

viii

SDK Software Development Kit, en uppsättning utvecklingsverktyg för att underlättautvecklingen 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 ändrardokumentet 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. knapparoch textfält.

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

URL Uniform Resource Locator, en sträng av tecken som identifierar en resurs på internetså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.

Xamarin En plattform för utveckling av mobilapplikationer till flera plattformar.

Lista av figurer

3.1 Exempel på en systemanatomi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5.1 Mobilapplikationens systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 Molntjänstens systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.3 Webbgränssnittets systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

C.1 Det delade projektets struktur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

x

Lista av tabeller

5.1 Roller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

A.1 Uppgiftsgenomförande (Totalt 4 användare) . . . . . . . . . . . . . . . . . . . . . . 35A.2 Automatiserade tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

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

C.1 Android-specifika filer med kod skrivna i C#. . . . . . . . . . . . . . . . . . . . . . . 48C.2 Android-specifika resursfiler skrivna i XML. . . . . . . . . . . . . . . . . . . . . . . 49C.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. . . . . . . . . . . . 68F.2 Lista över hur aktiviteterna kategoriserades. . . . . . . . . . . . . . . . . . . . . . . 69F.3 Tidsåtgång till respektive område . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70F.4 Beräknad tidsbesparing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

G.1 Statistik över reell tid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76G.2 Uteslutna aktiviteter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

H.1 Fråga 1: Hur ofta har du tittat till Kanban-brädet? . . . . . . . . . . . . . . . . . . . 82H.2 Fråga 2: Hur ofta har du ändrat i Kanban-brädet? . . . . . . . . . . . . . . . . . . . 82H.3 Fråga 3: Hur ofta har du kollat till de andra modulernas Kanban-bräden? . . . . . 82H.4 Fråga 4: Märkte du någon skillnad i hur du använde Kanban-brädet över projek-

tets gång? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82H.5 Fråga 5: Hur bra tyckte du att Trello som verktyg fungerade att bedriva Kanban

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

negativt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83H.9 Fråga 1: Hur nöjd är du med Slack som kommunikationsverktyg? . . . . . . . . . . 84H.10 Fråga 2: Upplever du att det varit lätt att få kontakt med de gruppmedlemmar du

behöver kontakta? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84H.11 Fråga 3: Upplever du att det varit lätt att hitta information som tagits upp i Slack

(webadresser, lösenord, etc.)? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84H.12 Fråga 4: Upplever du att Slack på något vis har stört ditt arbete? . . . . . . . . . . . 84H.13 Fråga 5: Om ja, hur? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

xi

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änsningar.

1.1 Motivation

I projektet Kunderbjudande i molnet har ett system utvecklats åt Byggvarulistan AB. Systemethar 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 genomatt låta användarna ladda upp bilder på sina kvitton. När kvittot mottagits och behandlatsbetalas 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 iReact. I mobilapplikationen kan användarna se aktiva erbjudanden, ladda upp kvitton ochse sina tidigare uppladdade kvitton. För att autentisera användare används inloggning viaFacebook med hjälp av Facebooks SDK. Molntjänsten låter mobilapplikationen hämta deerbjudanden som finns, och tar dessutom emot och lagrar de kvitton som användaren tarbild på med mobilapplikationen. Administratörgränssnittet kan användas av Byggvarulistansadministratörer för att hantera erbjudanden, användare och kvitton. Molntjänsten fungerarsom 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 varen blandning av traditionell mjukvaruutveckling enligt vattenfallsmodellen och agila meto-der som iterativ utveckling, iterativ utvärdering av arbetssättet och regelbundna möten medhela gruppen. I utvecklingen användes verktyg som Trello, Slack och GitHub.

1

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 ihopkunskap 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 skaparvärde för kunden?

2. Vilka erfarenheter kan dokumenteras från projektet Kunderbjudande i molnet som kanvara 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ällningarsom Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? framförallt besvarasutifrån vilket stöd det gav i just detta sammanhang.

2

2 Bakgrund

Det här avsnittet ger en kort bakgrund till kunden och motiverar varför kunden vill utvecklaprodukten 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 materialoch 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 kostnadenför inhandlat material till Byggvarulistan för de kunder som kommit till varuhusen genomByggvarulistan. Byggvarulistan delar sedan återbäringen med sina kunder för att de använ-der deras tjänst. Cashback har länge funnits i matvarubutiker och har på senare tid blivitmer och mer populärt i samband med handel över internet, men byggvarumarknaden liggerefter. Kampanjerna som ska ingå i produkten är kampanjer som leverantörer av verktyg ochbyggmaterial ger ut till Byggvarulistan. Byggvarulistans kunder ska kunna ta del av dessakampanjer 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 detingen liknande tjänst för byggmaterial, därför ämnar Byggvarulistan tidigt etablera sig i denmarknaden.

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

3

3 Teori

Det här kapitlet beskriver de verktyg, arbetsmetoder och ramverk som har använts underprojektets 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 sakersom ä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 ettprojekt. 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 iutvecklingsprocessen 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 omKanban å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örstörre och mer komplexa projekt [2]. Tre viktiga begrepp för Scrum är transparens, inspektionoch anpassning. Transparens syftar på att viktiga delar av utvecklingsprocessen ska varasynliga för de som är med och påverkar resultatet av processen. Med inspektion menas attinspektioner ska ske ofta, men inte så ofta att de förhindrar en effektiv arbetsgång. Under eninspektion kan det beslutas att en förändring måste ske för att resultatet av processen ska

4

3.1. Utvecklingsverktyg och metoder

bli tillfredsställande. I så fall justeras processen så fort som möjligt för att undvika vidareproblem. 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 utvecklingenförstår sig på hur Scrum fungerar.

Det mest kännetecknande för Scrum är sprinten som är en tidsbaserad utvecklingsperiodpå 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 avarbetet 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 riskeraatt målet med sprinten inte uppnås. Omfattningen av arbetet kan däremot ändras genomfö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änstervia Microsoft Azure.

5

3.1. Utvecklingsverktyg och metoder

3.1.6 Microsoft Azure

Azure är en samling molntjänster med månadskostnader som Microsoft förser utvecklaremed [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 attversionshantera källkod vid mjukvaruutveckling [5]. En av kärnorna i Git är att effektivtkunna skapa och sammanfoga grenar. Arbetsflödet består vanligtvis av att utvecklingsgrenarskapas 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 klarapå en gren och grenen är stabil så sammanfogas den med huvudgrenen. Vid tillägg av nyafunktioner 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 omGitHub pull requests.

3.1.9 Postman

Postman är ett program som kan användas för att testa webb-API:er. Med Postman skickasolika typer av HTTP-förfrågningar till en server och sedan visas svaret på valfritt format i ettGUI [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 ensamling 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-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 dessakategorier kan aktiviteter läggas in som beskriver en arbetsuppgift.

6

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 teknikersom 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]. Kommunikationen sker genom att en klient skickar en förfrågan tillen 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 somsä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åganoch faller i en av fem olika kategorier. Är det den tresiffriga kombinationen 1xx förmedlardet 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]. Kakanskapas av servern som sedan tilldelar den till klienten som sparar den lokalt. Kakan användssedan 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ålleti 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örmä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 WindowsPhone. 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 elleren emulator [15]. Dessa tester kan sedan köras automatiskt för att säkerställa att sekvensenfortfarande ger samma resultat. Se bilaga A för mer om Xamarin Test Recorder.

7

3.4. Molntjänsten

3.3.3 PCL Storage

Portable Class Libraries (PCL) Storage är ett multiplattform-API till Xamarin som möjliggöratt 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 iAndroid- och iOS-applikationer [17]. En av de funktioner som detta möjliggör är inloggningvia Facebook. Det låter användare identifiera sig med sitt Facebook-konto vilket gör att deinte 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 applikationen kommuniceramed 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 utvecklingav 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åndatahantering 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 attdata 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 vetahur andra lager än de som de är direkt ihopkopplade med beter sig. Detta medför attimplementation 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 äroptimerat 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ördet 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 Corestödjer flera olika databasleverantörer, bland annat Microsoft SQL Server, MySQL och SQLite[22].

8

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 ochdatameddelanden till olika plattformar [23].

3.4.6 OneSignal

OneSignal är en push-notifikationstjänst som använder FCM och ger utvecklare ett enkeltverktyg att skicka notifikationer till flera olika plattformar [24]. OneSignal erbjuder SDK:erfö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å derashemsida.

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 skickadata 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 inteladdar om all data på sidan utan använder laddning i bakgrunden för att byta ut delar avsidan [28]. Då webbläsare byggdes för att ladda om sidor på nytt så används med fördelHTML5 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 varamedveten om att det är en SPA-sida, detta då laddningar alltid ska hämta en och samma filoavsett URL.

3.5.5 Redux

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

9

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öraen 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örkritisk länk sattes en person till med på gränssnittet med delat ansvar mellan webbgränssnittoch 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 modulerna spriddes utbildningen genom diskussioner ochmini-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örjanav 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 ettKanban-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

10

4.4. Kommunikation med Slack

bara skulle vara inbegripen på max en aktiv lapp åt gången. I början på tredje iterationenomformaterades brädet, så att varje modul hade ett enskilt bräde istället för att alla modulerfanns med på samma bräde. I den tredje iterationen infördes också en veckovis uppföljningav Kanban-brädet. Gruppen samlades och diskuterade om brädet hade använts korrekt samtvad 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 teamet. Utöver detta användes engenerell 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 organiserautvecklandet 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 tidigbild över systemet. Den användes senare vid framtagningen av aktiviteter eftersom det varlä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 veckorlå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ärverktygen till utvecklingsfasen hade bestämts lades också tid på utbildning i dessa. Allt dettai syfte att förbereda inför utvecklingsfasen av projektet.

Dokumenten som skapades under iteration 1 togs fram genom både enskilt arbete ochunder 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 undermöten så att samtliga medlemmar var överens om vad som skrevs. Samtliga dokumentgranskades 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 ochtestplan. De dokument som skapades var:

• Kravspecifikation. Tidigt i projektets skede hölls ett kundmöte med en representant frånByggvarulistan. 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ådedokument och själva produkten som tas fram ska vara av hög kvalitet.

11

4.6. Iterationer

• Systemanatomi. Denna framställdes under ett gruppmöte och beskriver vad som ärnö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 mallfö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äradelar: mobilapplikation, molntjänst, och webbgränssnitt. Beslut togs även om hur dessa delarskulle utvecklas. Mobilapplikationen skulle framställas med verktyget Xamarin. Molntjäns-ten skrivas i C# i programutvecklingsmiljön Visual Studio och webbgränssnittet utvecklasmed JavaScript-biblioteket React. Projektmedlemmarna valde sedan vilken del de ville varamed 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 sindel.

4.6.2 Iteration 2

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

• Testplan. Testledaren hade huvudansvaret för att framställa denna. Testplanen beskri-ver hur testningen går till i projektet. Här specificeras vilka testramverk som ska an-vändas för de diverse olika modulerna. Det framgår även vilka delar av varje modulsom det ska finnas strukturerade test för, samt när dessa ska göras. Eftersom de olikamodulerna 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 kandidatprojektetpåbörjades den tidigt, redan i iteration två. De tidigare rubrikerna i dokumentet kundeskrivas redan här, och skisser till individuella bidrag till rapporten fanns med. Meddetta underliggande utkast var det enkelt att i kommande iterationer succesivt fortsättaskriva 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 huvudsakligadokumentationen 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 iterationoch 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 attdet mesta av huvudfunktionaliteten implementerades så återstod fortfarande några problemsom var viktiga att fixa för att applikationen skulle kunna användas enligt specifikationer.

12

4.6. Iterationer

Under iterationen skedde mycket av utvecklingen tillsammans där eventuella problemeller designbeslut kunde diskuteras direkt. Detta var för att kontra den något långsammautvecklingen 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 idetta skede. Dessa tester hade dock under denna iteration blivit definierade men på grund avsvårigheter att installera Xamarin Test Recorder på våra utvecklingsdatorer blev testningenförsenad till nästa iteration.

Molntjänsten

I iteration 3 utfördes majoriteten av arbetet med molntjänsten. Alla olika HTTP-anrop tillAPI:et utökades och färdigställdes. API:et fick nu funktionalitet så att användare kunde görafyra 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. Funktionalitetfö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 kvittonfö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 medhjälp av Facebooks API genom att en användare erhåller ett användartoken i applikationsom denne sedan skickar med till molntjänsten för att logga in. För administratörer användsistället webbgränssnittet där de skickar med användarnamn och lösenord som verifieras motdatabasen. Autentisering sker med hjälp av HTTP-kakor och auktorisering sker med sammacookie som innehåller information om klientens rättigheter. De tre behörighetsnivåerna somimplementerades är användare, administratör och root.

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

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 ladesdärefter på att korrigera fel och rätta till buggar som upptäcktes i molntjänstens programvaraunder 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 ensom 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 kunnaintegrationstesta funktioner som var under utveckling i webbgränssnittet mot ett fungerandeAPI.

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

13

4.7. Gemensamma erfarenheter

Då målet var att utveckla modulen som en SPA behövdes en metod för att kunna växlavad 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. Dettaunderlättade även debug-processen då webbgränssnitts-teamet snabbt kan testa lösningaroch 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åsakerfanns kvar att fixa. Iterationen bestod till stor del av dokumentskrivande och testning för attförse kunden med en stabil produkt.

Mobilapplikation

Det som återstod att fixa efter den tredje iterationen var att fixa så att kakor och annaninformation 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 cookieoch återhämta all information som behövs.

Utöver att implementera det som nämns ovan så var ett huvudsakligt mål med dennaiteration att testa applikationen och se till att den är stabil för överlämning. Testningenutfö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 verifieringav att molntjänsten uppfyller de krav som ställts på den. Testning gjordes dels med Postmangenom att göra anrop till molntjänstens API och kontrollera data som returnerades. Ävenintegrationstester 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 togmed 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 tillhela gruppen med frågor om hur de upplevt att Slack fungerat och om de var nöjda medverktyget. Denna enkät skickades ut i slutet av projektet för att låta gruppmedlemmarnaanvändarna använda Slack så länge som möjligt innan de lämnade sina svar.

14

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ärderingkring hållbar utveckling. Målet med denna utvärdering var att få en förståelse om systemetspåverkan i ett större perspektiv. I projektets senare skede (Iteration 4) hölls ett seminariumdär temat var att ta fram krav för systemet som tog hållbar utveckling i åtanke. Dessa kravjä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 kringhållbar utveckling och mjukvara som baserades på den modell som presenteras i ”FramingSustainability as a Property of Software Quality” [31]. Modellen delar upp hållbar utvecklingi 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 positivteller 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 sedanmål fram för att förbättra systemets hållbarhet.

15

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 äventeamets 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örvärde av systemet.

5.1.1 Mobilapplikation

Mobilapplikationen är utvecklad i Xamarin och består av ett Android-projekt och ett delatprojekt. 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 detdelade projektet. Applikationen låter användare se aktiva kampanjer och cashbacks, utnyttjadem genom att ladda upp kvitton samt se status för sina uppladdade kvitton. Användare kanockså ladda upp kvitton som inte är kopplade till ett erbjudande (kampanj eller cashback) föratt 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 idet 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 olikaplattformar. Det som framförallt har delats är kommunikation med molntjänsten och lagringav data. När dessa funktioner behövs kallar Android-projektet på funktioner i det deladeprojektet som sedan tar över.

16

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överden information som alltid ges tillgång till (namn, användar-id, etc.) kräver applikationentillgång till att läsa av användarens e-postadress. När användaren loggats in med Facebookfå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ärdet token som mottogs vid Facebookinloggningen skickas med. Med hjälp av Facebooks APIkan molntjänsten verifiera att det token de fick är giltigt och även få veta användar-id för denanvändare som loggat in. När applikationen får ett svar från molntjänsten undersöks svaretsstatuskod, och om det var ett lyckat anrop tas användaren vidare in i applikationen. Omanropet inte lyckades visas ett felmeddelande för användaren och sedan loggas användarenut 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

17

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 medhjä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 data till en viss adress inom molntjänsten. Exempelvis vid asynkron uppladdning avett 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 ochhttp://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 meden cookie i sitt svar. Denna måste lagras i applikationen för att skickas med i varje anrop tillmolntjä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 verifierasmot 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 attsparas 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 skapassparas de samtidigt till kvittolistan i applikationen och till filsystemet. Till filsystemet sparaskvitto-objektet i JSON-format sist i en fil där alla kvitto-objekt ligger sparade. Dessa laddassedan 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 tamärkbar tid. För att undvika väntetid för användaren hämtas därför inte bilderna på sammagå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ändarenbehöver vänta någon märkbar tid. Cashbacks har precis som kampanjer en knapp för attladda upp ett kvitto, men de har även en knapp för att öppna varuhusets hemsida i mobilenswebbläsare. Detta görs med en speciell länk som gör att kunden får cashback på köp somgörs online. Detta sköter byggvaruhusets hemsida och Byggvarulistan, mobilapplikationenbehöver bara öppna den länk som laddats ner tillsammans med cashbacken.

18

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. Syftetmed molntjänsten är att ta emot, lagra och skicka information om kvitton och erbjudanden tillapplikationen och webbgränssnittet. Molntjänsten använder OCR för att extrahera text frånbilder 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änstenkö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 somloggar in genom webbgränssnittet autentiseras mot användaruppgifter som finns lagrade idatabasen. 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 hartre olika roller som motsvarar användarnas accessnivåer 5.1.

19

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ämtaerbjudanden 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-anrop kan användareav 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ämtaoch granska kvitton och användare. Genom webbgränssnittet kan även administratörer medroträttigheter lägga till och ta bort administratörer.

Databas

Databasen implementerades med ORM ramverket Entity Framework Core (EF Core) ochanvänder sig av databasleverantören Microsoft SQL server. Beslutet att använda EF Core fördatabashantering togs för att underlätta implementationen av databasen och hanteringen avdatabasaccesser. EF Core och SQL server är välanpassat till ASP.NET Core vilket motiveradebeslutet 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äreftergenereras 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 somvä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 filsystemetoch spara sökvägar till bilderna i databasen istället. Det första alternativet valdes eftersomdet kändes enklare att hantera, framförallt vid migrationer av molntjänsten, än det senarealternativet. För att optimera disk I/O togs beslutet att lagra bilder i egna bord och kartläggadem 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++.

20

5.1. Systembeskrivning

Till detta API har sedan en wrapper skrivits sådan att API:et går att använda med ASP.NETCore, 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 granskadeav en administratör. OneSignal använder Firebase Cloud Messaging för att skicka notifika-tioner till mobilapplikationer. Första gången en användare av applikationen loggar in regi-streras användarens mobilenhet med OneSignal. För att skicka notifikationer till registreradeenheterna gör molntjänsten API-anrop till OneSignal. API-anropen innehåller ett meddelan-de som ska skickas och de enheter som ska ta emot meddelandet. OneSignal skickar däreftermeddelandet vidare till angivna enheter. OneSignal och Firebase Cloud Messaging valdes attanvä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 avmolntjä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öruppgift 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 datakodas 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öratt göra alla nätverksanrop. För att detta ska vara möjligt behöver anropet vara flexibelt ochinte 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 vissafrågor så är data även relevant. Detta är den data som skickas från klienten till servern. I vårtfall ä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 funktionersom körs efter att nätverksförfrågan avslutats. På detta sätt skickas meddelandet iväg sombeskriver om man är inloggad eller hanterar den omedelbara förändringen vid granskningav 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.

21

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 sedanom något speciellt läge ska visas för den. Standard (tomt argument) är visning men vissatyper kan editera eller granska resursen. Skickas inget id med så visas en lista av resurstypenistället.

Exempelvis, visning utav kampanjer tar emot kampanj-id och läge (mode).

return ;

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årimplementation stödjer även strängar för att kunna skapa länkar som /campaigns/new för attskapa nya kampanjer.

22

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 helateamet befann sig på samma fysiska plats än när alla arbetade på var sitt håll. Det upplevdesatt det var svårt att få saker gjorda och det tog lång tid om något behövde diskuteras. Vidmer gemensamt arbete var det lätt att diskutera saker och rådfråga varandra vilket ledde tillett 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 stabilutvecklingsmiljö som fungerar som den ska. Detta märktes framförallt inom delgruppen somutvecklade mobilapplikationen. Under utvecklingen har gruppen haft problem med bådeXamarin 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, tillmycket större problem som att flera utvecklingsdatorer behövde installeras om på grundav att en uppdatering till Xamarin skadat operativsystemet. De stora problemen har inteinträffat ofta, men de har ändå kostat mycket tid, framförallt då Xamarin och Visual Studiotar relativt lång tid att installera på nytt. De mindre problemen har inte tagit alls lika lång tidfö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 iprojektet. Inga tydliga riktlinjer fanns för hur strukturen skulle se ut, vilket gjorde att det intefanns en unison hantering av mappsystemet. I början av projektet när det inte hade hunnitbli så många filer upplevdes lagringen av dokumenten fungera bra, och det var inte svårtatt hitta det dokument som söktes. Men allt eftersom projektet framskred och fler dokumenttillkom blev det mer och mer rörigt. Det gjorde även att det kunde ligga kvar gamla filersom inte var aktuella längre. Detta hade kunnat lösas genom att sätta upp riktlinjer för hursystemet skulle hanteras, eller tydligare ange vem som ansvarade för att allt var uppdateratoch i god ordning. Att det lätt blir rörigt märktes också i gruppens Trello-bräden, framföralltunder iteration 2. Många kort blev aldrig korrekt flyttade, och det var sällan de personer somarbetade 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 aktiviteter ochdelmål som togs fram tidigt i projektet genom brainstorming togs senare bort eller ändradespå grund av olika förutsättningar som förändrats, men även för att gruppens förståelse förramverken och systemet i sig utvecklats under projektets gång.

Eftersom systemet består av tre delsystem som kommunicerar med varandra skrevs ettkommunikationsdokument vid ett möte för att bestämma vad som behöver skickas och hurinformationen som skickas ska formateras. Mötet i sig var en erfarenhet då det hjälpte till attfånga upp eventuella oklarheter kring kommunikationen och ledde även till att alla fick enbättre insikt i systemet. Dokumentet gav sedan ett bra stöd genom projektet när delar somkrä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 tilldelningen var positiv och gav

23

5.3. Kommunikation med Slack

struktur. Eftersom alla hade en tilldelad roll och egna ansvarsområden så blev det ingakonflikter om vem som skulle göra vad.

5.3 Kommunikation med Slack

Enkäten som gruppen svarade på gällande om Slack visar att hela gruppen var nöjd medatt använda Slack som kommunikationsverktyg (se bilaga H.3). Gruppmedlemmarna tyckteatt det var lätt att få tag i de personer de behövde kontakta och dessutom att det var enkeltatt hitta information som tagits upp i Slack, tack vare att meddelanden kunde ”nålas fast” ien chatt. Endast en gruppmedlem tyckte att Slack stört i arbetet, något som berodde på attdet blev väldigt mycket meddelanden. Användaren tyckte att detta förbättrades när gruppenbörjade använda direktmeddelanden när inte hela gruppen behövde ta del av informationen,något som beslutades under en iterationsutvärdering.

5.4 Arbetet i ett vidare sammanhang

Under det seminarium som gruppen höll internt med fokus på hållbar utveckling användesden modell som beskrivits tidigare för att resonera kring systemets påverkan på miljön ochsamhället. Ett antal samband hittades, t.ex. att byggvaruhusens användande av systemet föratt marknadsföra sig kan minska mängden reklamblad som behöver tryckas och därigenomminska användningen av papper. Det samband som gruppen upplevde att det fanns mestmöjlighet att påverka är sambandet mellan miljön, energianvändning och dataöverföring. Jumer data som skickas, desto mer energi krävs, vilket i sin tur kan skada miljön (beroendepå energikälla). De krav som gruppen kom fram till under seminariet för att hantera dettasamband är:

• Bilder som skickas ska vara under en viss storlek

• Bilder ska lagras lokalt efter att de hämtats så att de inte behöver hämtas igen

5.5 Översikt över individuella bidrag

Här presenteras en översikt över de individuella bidragen till rapporten.

5.5.1 Xamarin Test Recorder, ett alternativ till användartester? av Alexander Sääf

Rapporten beskriver effekter av användning av Xamarin Test Recorder och jämför dessa medanvändartester.

5.5.2 Lättviktig kodgranskning med GitHub pull request av Lenny Johansson

Rapporten beskriver metoden som nämns i rubriken, utvärderar den med förbrukad tid iåtanke och gruppmedlemmarnas inställning till metoden.

5.5.3 Utveckling av mobilapplikation till flera plattformar i Xamarin av FredrikGrahn

Rapporten undersöker och utvärderar fördelar och nackdelar med verktyget Xamarin. Rap-porten undersöker även hur mycket kod som går att dela med dessa verktyg och för vilkatyper av applikationer som lämpar sig för utveckling med dessa verktyg.

24

5.5. Översikt över individuella bidrag

5.5.4 Kvalitetsplanens roll i programutveckling av Simon Karlsson

Rapporten beskriver hur en kvalitetsplan är tänkt att användas och hur den använts i dettaprojekt. Rapporten försöker även utvärdera effekterna av att använda en kvalitetsplan ochkvalitetsförsäkrande åtgärder.

5.5.5 Kanban med Trello i kandidatprojekt av Mattias Evaldsson

Rapporten undersöker hur metoden Kanban kan användas tillsammans med Trello i ett kan-didatprojekt.

5.5.6 Reacts koddelning mellan webb och mobilappar av Oscar Thunberg

Rapporten undersöker hur projektet eventuellt kunde förbättrats av koddelning mellanwebbgränssnitt och mobilapplikationen.

5.5.7 Tidsbudgetering och estimering inom projektet av Richard Wigren

Rapporten beskriver och utvärderar tidsestimeringen som utförts i projektet.

25

6 Diskussion

6.1 Resultat

Produkten uppfyller alla grundläggande krav och bör därmed ha ett värde för kunden.Dock saknas viss funktionalitet som kunden specificerade i den ursprungliga projektbe-skrivningen, som t.ex. OCR-skanning av kvitton. OCR skulle användas för att snabbt läsaut information från kvitton för att automatiskt kunna godkänna eller neka aktivering averbjudanden för kunden. Problemet med OCR:en är att den inte har kunnat integreras medmolntjänsten när molntjänstens program körs på Microsoft Azure. Produkten kan trots det-ta ändå användas som det var tänkt men nu med manuell granskning och godkännandeav kvitton. Därmed har den förlorat viss grad av automation men inte funktionalitet. Vitror också att för att OCR:en skulle fungerat som kunden tänkte skulle det krävas mycketförbehandling av kvitto-bilderna och uppträning av OCR-motorn. Detta är komplext ochtidskrävande. Därför har tid inte funnits att utföra detta i projekt utan att offra väsentligfunktionalitet för det övriga systemet. Det överlämnas till kunden att potentiellt vidareut-veckla.

En lärdom som kan dras från ovanstående problem är att i framtiden bör vi mer utför-ligt undersöka olika alternativ av ramverk, språk och liknande. Detta för att se vilka delarsom lätt kan integreras med redan existerande programvara. På så sätt kan fokus därmedläggas på att implementera funktionalitet som är viktigt för kunden, utan att spendera enmassa tid på att integrera.

6.2 Metod

Ett verktyg som orsakat en hel del problem är Xamarin, som redan nämns i resultatet. Pro-blemen har lett till att mycket tid som kunde spenderats på utveckling har spenderats påkonfigurering av utvecklingsmiljön. En lärdom som dragits från detta är att det kan vara enbra investering att spendera lite extra tid på att jämföra utvecklingsmiljöer och verktyg i bör-jan av ett projekt. På så sätt låser man inte fast sig i en miljö eller verktyg för tidigt i projektetsskede. En potentiell förbättring i just detta fall är att använda React Native istället för Xama-rin och på så sätt ha möjligheten att dela vissa delar av koden mellan webbgränssnittet ochmobilapplikation. Det hade sparat en hel del tid genom att inte skriva samma funktionalitet

26

6.3. Användning av systemanatomi

på två olika sätt i två olika språk. Som diskuteras i bilaga C så finns ett annat verktyg från Xa-marin vid namn Xamarin.Forms som också hade kunnat användas, vilket förmodligen hadegivit en applikation med betydligt mer portabilitet.

6.3 Användning av systemanatomi

Som sagt så togs en systemanatomi över systemet fram tidigt under den första iterationen,vilket hjälpte oss mycket för att få en överblick över systemets funktionalitet. Att hela teametsatte sig ned och diskuterade vilken funktionalitet som bör finnas med i produkten och hurdenna funktionalitet hänger ihop var mycket hjälpsamt för att öka teamets förståelse för hurprodukten var tänkt att fungera. När systemanatomin väl var framtagen var det väldigt lättatt skapa faktiska aktiviteter att arbeta med utgående från systemanatomin. En fördel meddetta är också att aktiviteters beroenden till varandra automatiskt följer med från systemana-tomin.

Vid skrivandet av systemets arkitekturbeskrivning var systemanatomin ett bra underlagatt utgå från för att beskriva systemets funktionalitet. Ofta beskrivs övergripande funktio-nalitet och moduler med enkla UML-diagram, utgående från en systemanatomi fås mycketav samma information som vid användandet av dessa diagram. Skillnaden blir att iställetför kommunikationsriktningar så fås beroenden mellan moduler. En fördel med en systema-natomi är också att den kan innefatta både hårdvara och mjukvarumoduler som systemetinnehåller.

6.4 Slack som kommunikationsverktyg

Gruppens enkätsvar pekar på att alla medlemmar varit mycket nöjda med Slack som kom-munikationsverktyg. Att ha ett bra kommunikationsverktyg är mycket viktigt i ett projektsom detta där gruppen ofta inte sitter på samma fysiska plats och arbetar. En viktig aspektär att man måste kunna snabbt få tag i de personer som man behöver diskutera saker med.Slacks möjlighet att skicka meddelanden till individuella personer och funktioner för att näm-na personer i en chatt verkar ha fungerat bra, då gruppen upplevde att det var lätt att få tagi de personer de sökt. Att gruppen upplevt att verktyget inte hindrat deras arbete är ocksåmycket viktigt, då det är lätt hänt att man prioriterar bort att hålla sig uppdaterad med vadsom sägs om det stör för mycket. Om bara det som är relevant för just den personen visaskommer personen lättare kunna hålla koll på diskussionerna och informationen som delas.

6.5 Arbetet i ett vidare sammanhang

Eftersom hållbarhet inte togs under särskilt beaktande vid projektets uppstart är det svårt atti efterhand införliva ett sådant tänk utan att omförhandla kraven på projektet med kund. Detär däremot intressant att se vad för krav som hade kunnat ställas så att projektet fått medhållbarhetsaspekten. De krav som framförallt hittades gällde energiförbrukning kopplat tilldatabehandling.

6.5.1 Minska bildstorlek

I fallet med att begränsa storleken på bilder som skickas identifierades ett par metoder avgruppen. Komprimering, förlustfri eller ej, bildbehandling samt OCR i mobilapplikationen.Dessa metoder medför dock olika nackdelar. Alla metoderna kräver förstås i sig en viss energii processortid för att användas, men denna uppskattas vara mindre än den som är förloradför att kontinuerligt skicka onödigt stora bilder.

27

6.5. Arbetet i ett vidare sammanhang

Ej förlustfri komprimering av bilder

I fallet för komprimering som ej är förlustfri blir det en konflikt med OCR-funktionaliteteni molntjänsten. För att OCR:en ska kunna läsa av kvittona vill man ha bilderna i så skarpupplösning som möjligt. Därmed är det inte passande att data tappas vid komprimeringen,och ej förlustfri komprimering är alltså inte ett alternativ.

Förlustfri komprimering

När det gäller förlustfri komprimering blir det inga konflikter med OCR:en, bilderna går attåterställa till det ursprungliga formatet. Det finns dock en gräns för hur mycket man kankomprimera data och fortfarande hålla komprimeringen förlustfri. Det är bättre än den ejoptimerade metod som används för tillfället, och skulle vara ett möjligt alternativ. Det härär dessutom något som man hade kunnat implementera utan att det behöver finnas krav fördet.

Bildbehandling

Det tredje alternativet är att behandla bilden innan den skickas. Detta går att göra på flerasätt, men det rimliga i projektets sammanhang vore att behandla bilden i två steg. Det förs-ta är att klippa bort kanter i bilden, allt som inte innehåller kvittotext är onödigt. På så sättkan man i de flesta fall direkt minska bildstorleken drastiskt. Man kan därefter utnyttja detfaktum att det räcker med två färger för att beskriva bilder på kvitton, svart och vitt. Att re-ducera bilden till svart och vitt kallas ”binarization”. Det innebär i princip att man för varjepixel i bilden väljer den färg av svart och vitt som den är närmast, och ändrar den till den fär-gen. Därefter går det att använda simpla komprimeringsalgoritmer för att åter igen drastisktminska filstorleken. Dessa två steg måste dessutom ändå göras i molntjänsten för att OCR:enska kunna läsa bilden. Därmed medför denna metod ingen extra energiförbrukning till skill-nad från de andra metoderna. Den stora skillnaden blir att man får utföra dessa åtgärder påbilderna i mobilapplikationen istället för i molntjänsten. Det medför två saker: mer beräk-ningar i applikationen, vilket kan innebära en långsammare applikation