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 hade givit 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 teamet satte sig ned och diskuterade vilken funktionalitet som bör finnas med i produkten och hur denna funktionalitet hänger ihop var mycket hjälpsamt för att öka teamets förståelse för hur produkten var tänkt att fungera. När systemanatomin väl var framtagen var det väldigt lätt att skapa faktiska aktiviteter att arbeta med utgående från systemanatomin. En fördel med detta är också att aktiviteters beroenden till varandra automatiskt följer med från systemana- tomin.
Vid skrivandet av systemets arkitekturbeskrivning var systemanatomin ett bra underlag att 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 mycket av samma information som vid användandet av dessa diagram. Skillnaden blir att istället fö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 systemet innehå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 projekt som 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å tag i 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 vad som sägs om det stör för mycket. Om bara det som är relevant för just den personen visas kommer 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 att i 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 med hållbarhetsaspekten. De krav som framförallt hittades gällde energiförbrukning kopplat till databehandling.
6.5.1
Minska bildstorlek
I fallet med att begränsa storleken på bilder som skickas identifierades ett par metoder av gruppen. 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 energi i processortid för att användas, men denna uppskattas vara mindre än den som är förlorad för att kontinuerligt skicka onödigt stora bilder.
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-funktionaliteten i molntjänsten. För att OCR:en ska kunna läsa av kvittona vill man ha bilderna i så skarp upplö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 kan komprimera data och fortfarande hålla komprimeringen förlustfri. Det är bättre än den ej optimerade 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ör det.
Bildbehandling
Det tredje alternativet är att behandla bilden innan den skickas. Detta går att göra på flera sä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ätt kan man i de flesta fall direkt minska bildstorleken drastiskt. Man kan därefter utnyttja det faktum 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 varje pixel 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 drastiskt minska filstorleken. Dessa två steg måste dessutom ändå göras i molntjänsten för att OCR:en ska 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, samt att de bilder som lagras i applikationen blir svartvita, kantbeskurna versioner av de ursprungliga bilder- na. Beräkningarna i applikationen skulle förmodligen gå att dölja för användaren, så att de inte blev något större problem. Med lagringsformatet av bilder skulle man dock behöva föra en dialog med Byggvarulistan AB om vad de har för krav på den lokala lagringen av bilder. Eventuellt skulle det inte vara attraktivt för användare till applikationen att ha en lagring av bilder som är så pass behandlade, och i så fall skulle det antagligen inte vara hållbart. Men om man hade vetat om detta i projektets uppstart hade det varit lättare att hålla en dialog med Byggvarulistan om kraven.
OCR i mobilapplikationen
Ett eventuellt steg man skulle kunna ta vidare efter bildbehandlingen nämnd ovan, vore att ha även OCR:en i applikationen. På så sätt skulle man kunna skicka endast text-strängar som data, vilket ännu en gång skulle minska datastorleken. Detta blir dock än en gång i utbyte mot hur prydligt data lagras i applikationen. Med det här steget så skulle det bara lagras textsträngar i applikationen, vilket skulle göra kvittona ännu mer otillgängliga för an- vändaren. Man skulle kunna behålla information om strukturen i kvittot, så att det går att representera på ett liknande sätt som det var på bilden, men mycket kommer ändå att skilja sig från originalet. Det blir även en stor skillnad i datastorlek för applikationen att medfö- ra OCR-funktionalitet, något man också skulle behöva ta i beaktande i en diskussion med Byggvarulistan.
6.5. Arbetet i ett vidare sammanhang
6.5.2
Lagra bilder lokalt
En annan metod för att minska den datamängd som behöver skickas är att helt enkelt skicka bilderna färre gånger. Detta kan åstadkommas genom att lagra bilder lokalt både i webb- gränssnittet och i applikationen. Då räcker det istället att i första hand fråga om det kommit in några nya bilder, och om det inte gjort det behöver man inte hämta något alls. I webbgräns- snittets fall skulle det antagligen inte begränsa datatrafiken i någon större mängd, eftersom det där rör sig om att se många olika bilder någon enstaka gång. I applikationen skulle det däremot kunna medföra en större vinst, då det är ett fåtal bilder som kan behöva laddas upp och framförallt ner vid ett flertal tillfällen. Detta får dock vägas mot att det tar upp plats på de lokala enheterna. Eftersom bilder tagna med moderna mobilkameror kan ta ganska myc- ket plats är det rimligt att anta att bara ett visst antal bilder vill lagras lokalt, t.ex. bakåt i tiden till ett visst datum. Ännu en gång blir det en avvägning av dataöverföring mot datalag- ring lokalt. Eftersom det inte finns med någonting i kravspecifikationen om detta ämne finns det inga riktlinjer om vilket implementationssätt som bäst uppfyller både Byggvarulistans och användares önskningar. Antagligen är detta heller inte kunskap som Byggvarulistan för tillfället har, utan en förundersökning skulle behöva genomföras.
7
Slutsats
Vi anser att rapporten väl beskriver systemet vi utvecklat och de metoder, verktyg och tekni- ker som använts under projektets gång. Dessa ämnen behandlas främst i avsnitten 4 Metod och 5 Resultat. Val av metoder, verktyg och tekniker utvärderas främst i avsnitten 5 Resultat och 6 Diskussion.
7.1
Hur kan produkten implementeras så att man skapar värde för
kunden?
Produkten som implementerats består av tre moduler: en mobilapplikation, en molntjänst, och ett webbgränssnitt. Mobilapplikationen används av beställarens kunder där de kan få information om nya erbjudanden och ladda upp kvitton till molntjänsten för att få pengar tillbaka med cashbacks. Molntjänsten hanterar kommunikation och lagrar data i en databas. Webbgränssnittet tillåter administratörer hos beställaren att godkänna kunders kvitton och lägga till eller ta bort erbjudanden. Alla modulernas implementionsdetaljer beskrivs under rubriken 5.1 Systembeskrivning i resultat-delen. Produkten ger beställaren en prototyp som de kan använda för att utvärdera om idén är attraktiv för deras kunder.