-
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