Utveckling av komplett system för rapportering och granskning av avfallsdata

2021 | LIU-IDA/LITH-EX-G--2021/023--SE

Utveckling av komplett system för

rapportering och granskning av

avfallsdata

Development of a complete system for reporting and reviewing

waste data

Henrik Larsson Edström

Moltas Enåkander

Mirna Ghazzawi

Simon Hermansson

Albin Holmkvist

Anton Nylund

Gustav Stappe Renner

Robin Simonsson

Handledare : Anders Märak Leffler Examinator : Kristian Sandahl

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 circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

©

Henrik Larsson Edström Moltas Enåkander Mirna Ghazzawi Simon Hermansson Albin Holmkvist Anton Nylund Gustav Stappe Renner Robin Simonsson

Rapporten behandlar utvecklingen av ett system som möjliggör för rapportering och granskning av avfallsdata. Systemet består av en mobilapplikation och en webbapplika-tion som utvecklats med React Native respektive React, en databas som utvecklats med MySQL och en back-end bestående av tjänster som erbjuds av Amazon Web Services. I AWS används tjänster som tillåter hantering av mobilapplikation, webbapplikation, da-tabas och användare. Systemet utvecklades av åtta studenter vid Tekniska högskolan vid Linköpings universitet på uppdrag av det australiensiska företaget EcCell.

Projektet resulterade i framtagningen av produkten Trace the Waste med nästan alla önska-de funktionaliteter. I rapporten diskuteras även vad som haönska-de kunnat göras annorlunda i utvecklingen med hjälp av andra verktyg. Rapporten drar slutsatser om bland annat varför produkten ger värde för kunden och hur den agila arbetsmetoden Scrum påverkat studen-ternas arbete under distansläge.

Varje student har också skrivit ett individuellt bidrag där olika områden relaterade till pro-jektet utreds. Bidragen finns i slutet av rapporten.

Sammanfattning iii Författarens tack iv Innehåll v Figurer viii Tabeller ix Ordlista xii 1 Introduktion 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställningar . . . 2 1.4 Avgränsningar . . . 2 1.5 Kontext . . . 2 2 Bakgrund 3 2.1 Kundens bakgrund och syfte . . . 3

2.2 Gruppens tidigare erfarenheter . . . 3

3 Teori 5 3.1 Översikt över tekniker . . . 5

3.2 Amazon-tjänster . . . 6

3.3 Verktyg för processarbete . . . 8

4 Metod 10 4.1 Utvecklingsmetod . . . 10

4.2 Metod för att fånga erfarenheter . . . 13

4.3 Prototyper . . . 15

5 Resultat 18 5.1 Systembeskrivning . . . 18

5.2 Processbeskrivning . . . 33

5.3 Gemensamma erfarenheter . . . 35

5.4 Översikt över individuella bidrag . . . 36

6 Diskussion 38 6.1 Resultat . . . 38

B Datormoln, distansutbildning och den digitala klyftan - Moltas Enåkander 60 B.1 Introduktion . . . 60 B.2 Bakgrund . . . 61 B.3 Teori . . . 61 B.4 Metod . . . 63 B.5 Resultat . . . 63 B.6 Diskussion . . . 65 B.7 Slutsatser . . . 65

C Kvinnliga civilingenjörsstudenters upplevelser i projektteam - Mirna Ghazzawi 67 C.1 Introduktion . . . 67 C.2 Bakgrund . . . 67 C.3 Teori . . . 68 C.4 Metod . . . 68 C.5 Resultat . . . 70 C.6 Diskussion . . . 73 C.7 Slutsatser . . . 74

D En jämförelse av FaaS-system - Simon Hermansson 76 D.1 Introduktion . . . 76 D.2 Bakgrund . . . 77 D.3 Teori . . . 77 D.4 Metod . . . 78 D.5 Resultat . . . 78 D.6 Diskussion . . . 83 D.7 Slutsatser . . . 84

E Utveckling av ett användarvänligt system - Albin Holmkvist 86 E.1 Introduktion . . . 86 E.2 Bakgrund . . . 87 E.3 Teori . . . 88 E.4 Metod . . . 91 E.5 Resultat . . . 91 E.6 Diskussion . . . 93 E.7 Slutsatser . . . 95

F.3 Teori . . . 97

F.4 Metod . . . 99

F.5 Resultat . . . 99

F.6 Diskussion . . . 101

F.7 Slutsatser . . . 102

G Kategorisering av coronapandemins negativa effekter på grupparbete ute i ar-betslivet Gustav Renner 104 G.1 Introduktion . . . 104 G.2 Bakgrund . . . 105 G.3 Teori . . . 105 G.4 Metod . . . 106 G.5 Resultat . . . 106 G.6 Diskussion . . . 108 G.7 Slutsatser . . . 109

H En jämförelse mellan olika databashanteringssystem - Robin Simonsson 111 H.1 Introduktion . . . 111 H.2 Bakgrund . . . 112 H.3 Teori . . . 112 H.4 Metod . . . 116 H.5 Resultat . . . 118 H.6 Diskussion . . . 118 H.7 Slutsatser . . . 120 Litteratur 121

5.8 Hemskärm för granskare. . . 26 5.9 Webbapplikationen – ”Show companies"”-skärmen. . . 26 5.10 Webbapplikationen – ”Show companies”-skärmen där ett företag har valts i listan

till vänster. . . 27 5.11 ”Show companies”-skärmen – Ett valt företags uppgifter kan redigeras i rutan till

höger. . . 27 5.12 ”Show companies”-skärmen – Ett nytt företags uppgifter kan skrivas in i rutan till

höger. . . 28 5.13 ”Show personnel”-skärmen – Ett valt företags personalkonton visas i listan till

vänster och information för ett valt konto visas till höger. . . 28 5.14 ”Show personnel”-skärmen – Lägga till ett nytt konto. . . 29 5.15 ”Show tables”-skärmen – Tabellen filtreras baserat på vad användaren skrivit in i

sökfältet för ”Username”-kolumnen. . . 29 5.16 ”Show tables”-skärmen – Användaren har dubbelklickat på en rad så att

innehål-let i rapporten visas. . . 30 5.17 ”Show tables”-skärmen – Vissa fält, exempelvis ”Change ID”, kan inte redigeras. . 30 5.18 ”Show tables”-skärmen – skapandet av en ny avfallsrapport. . . 31 5.19 EER-diagram för databasen. . . 32 5.20 Relationsschema för databasen. . . 32 6.1 Sustainability Analysis Diagram, som beskriver kedjan av påverkan för Trace the

Waste. . . 45 D.1 Världskarta över tillgänglighetsregioner för de tre FaaS-systemen. . . 78 E.1 Bearbetningsfasen utformad efter design med människan i centrum enligt

ISO-9241-210. . . 90 E.2 Detaljeringsfasen utformad efter design med människan i centrum enligt

ISO-9241-210. . . 91 H.1 Visualisering av JOIN-funktionaliteten. . . 113

5.1 Generella krav på mobilapplikationen, taget från projektets kravspecifikation. . . . 19 D.1 Kall- och varmstartstider för en JavaScript-funktion i AWS Lambda och i Azure

Functions. . . 80 D.2 Skillnader mellan kall- och varmstartstider för Java och JavaScript i AWS Lambda. 82 D.3 Kall- och varmstartstider för Go, Java, Python och Node.js i AWS Lambda. . . 83 F.1 Jakob Nielsens tio tumregler för gränssnittsdesign. . . 98 F.2 Rekommendationer för utveckling av ett gränssnitt avsett för äldre generationer. . 101 H.1 Tabellen visar exekveringstiden i millisekunder. . . 118

Back-end– Programmeringskod som ligger på serversidan, kopplar samman databas och front-end.

Branch – En gren i versionshanteringssystemet där källkod förvaras när ny funktionali-tet ska implementeras.

CD – Akronym för Continuous Delivery vilket innefattar processen av att snabbt leverera ny och uppdaterad mjukvara.

CI – Akronym för Continuous Integration vilket är en process för att utföra automatisera-de tester på ett system.

Commit– Tillägg av den lokala kodversionen i ett Git-repository.

CSS – Akronym för Cascading Style Sheets. Ett språk som man kan skapa stilmallar för hemsidor med, där stilmallen exempelvis kan ange hemsidans bakgrundsfärg eller typsnitt.

EcCell– Namnet på kundföretaget.

EER-diagram – Akronym för Enhanced entity-relationship. Det är en visualisering för hur relationerna i en databas ser ut.

Eslint– Statiskt analyseringsverktyg för att varna utvecklare om standarder ej följs.

Figma – En vektorgrafikredigerare som används för att ta fram prototyper av gränssnitt för digitala applikationer.

Front-end – Det användargränssnitt som användaren ser och interagerar med genom ex-empelvis en webbläsare eller en mobilapplikation.

Google Docs– Molntjänst som möjliggör gemensam redigering av dokument.

Google Drive– Molntjänst för att skapa och dela filer.

Git– Ett versionshanteringssystem för källkod.

GitLab– En webbapplikation som möjliggör för förvaring av git-projekt i molnet.

Git-repository – Mappen .git/ inuti ett projekt som noterar ändringar i projektet och som därmed ger upphov till en historik för projektet.

Granskare – En person som är anställd av EcCell med uppgiften att granska företags avfallsrapporter.

HTML – Akronym för HyperText Markup Language. Ett språk som används för att struk-turera innehåll på hemsidor.

HTTP – Akronym för Hypertext Transfer Protocol. Ett protokoll som ger möjlighet för en webbläsare och en webbserver att kommunicera.

JavaScript – Ett dynamiskt programmeringsspråk som främst används vid webbutveck-ling.

Jest – Ett ramverk för testning utvecklat för att skriva tester i JavaScript, kan användas för både React och React Native.

LA_{TEX – Ett typsättningssystem för skrivande av dokument.}

Merge– En operation i Git för att sammanfoga delar av ett git-projekt.

Molnfunktion – Molnfunktioner (eng. cloud functions) är funktioner som kan exekveras på hårdvara som en molnleverantör tillhandahåller. Den kod som finns i dessa molnfunktio-ner ska alltså alltid finnas tillgänglig att anropas på i molnet.

MySQL– En databashanterare för hantering av data i databasen.

Node.js – En öppen-källkodsplattform för att exekvera program skrivna i programme-ringsspråket JavaScript.

Push – kommando för att ladda upp ändringar i ett lokalt repository till ett Git-repository lagrat på en fjärrserver.

Pull – Git-Kommando för att ladda ner data från ett Git-repository lagrat på en fjärrser-ver till ett lokalt Git-repository.

React – Ett JavaScript-bibliotek som används för att utveckla gränssnitt till webbapplika-tioner.

inom programmet och kan utvecklas och underhållas separat.

Trace the Waste– Produkten och projektets namn.

Token – Ett unikt objekt som fås efter autentisering. En token innehåller information om den autentiserade användaren och dess rättigheter till vissa operationer.

UX – Akronym för User experience. Begreppet innefattar användarens upplevelse av en produkt.

Rapporten beskriver ett projektarbete som utfördes under första halvan av 2021 av studenter vid Linköpings universitet. Projektgruppen bestod av åtta personer där hälften av gruppen studerar civilingenjörsprogrammet i datateknik och där andra hälften studerar civilingen-jörsprogrammet i mjukvaruteknik.

Rapporten är strukturerad på följande sätt. Den börjar med en bakgrund till projektet, vilket följs av teori och de metoder som använts under projektet. Därefter presenteras grup-pens resultat och slutsatser med en diskussionsdel däremellan. Sista delen i rapporten består av gruppmedlemmarnas individuella utredningar som handlar om ämnen relaterade till projektet.

1.1

Motivering

Projektet gick ut på att utveckla produkten Trace the Waste, vilket är ett system för att skapa och administrera avfallsrapporter. Detta verktyg ska underlätta för projektgruppens kund, EcCell. Deras uppgift är att granska återvinningsanläggningars avfallsrapporter och att ba-serat på denna data, utfärda miljörapporter som byggföretag kan granska när de väljer en återvinningsanläggning för deras avfall.

Majoriteten av de återvinningscentraler som samarbetar med projektgruppens kund hante-rar idag rapporteringen av avfall med hjälp av papper och penna, där sorteringen av olika material skrivs ned som procentandelar. Kunden anser att detta arbetssätt är ineffektivt och förlegat.

1.2

Syfte

Trace the Waste består av en mobilapplikation, en webbapplikation och en tillhörande data-bas. Produkten möjliggör för kunden att kunna följa alla steg av avfallshanteringen i syfte att verifiera att all information stämmer.

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

4. Hur påverkar det agila arbetssättet Scrum projektgruppens arbete, när arbetet sker på distans?

1.4

Avgränsningar

En begränsning för projektgruppen var att varje gruppmedlem hade 400 timmar var att använda till projektet.

Eftersom produkten som utvecklats skapats från grunden, har kompatibilitet med något tidigare system ej behövt behandlats. Dock har det funnits en prototyp från vilken projekt-gruppen har kunnat utgå ifrån. Prototypen var en demonstration över hur systemet skulle fungera och innefattade en mobilapplikation, en webbapplikation och en databas. Kunden klargjorde tidigt att avsikten med projektet var att använda det i produktion. Därför ville kunden att projektgruppen skulle prioritera utveckling av de basfunktioner som krävdes för att produkten skulle fungera. Ytterligare, mindre viktig funktionalitet skulle endast implementeras i mån av tid.

1.5

Kontext

Arbetet utfördes inom ramen för kursen TDDD96 – Kandidatprojekt i programvaruutveckling. Vissa krav i kravspecifikationen är krav som finns där i enlighet med krav från kursen. Kur-sen specificerar exempelvis att det ska finnas tre mätbara kvalitetskrav, att det ska lämnas in dokument vid specifika datum, samt att arbetet tar slut när kursen tar slut i maj. Alla dead-lines samt antal timmar per person är fasta och de är viktiga för examinationen av kursen. Seminarier är också ett krav från kursen, där alla gruppmedlemmar ska närvara.

Detta kapitel går igenom den bakgrund som ligger till grund för idén till projektet från kun-dens sida, samt projektgruppens relevanta erfarenheter före genomförandet av projektet.

2.1

Kundens bakgrund och syfte

Kunden är en avfallskontrollant vars huvudsakliga arbetsuppgift är att kontrollera att sorte-ring av avfall sker på ett korrekt sätt, med hjälp av granskning och summesorte-ring av avfallsdata. Kunden har intresse av att spåra materialet och intyga hur stor andel som återvinns hos en återvinningsanläggning. För tillfället rapporteras avfallssorteringen genom pappersrappor-ter, något som ur kundens synvinkel försämrar företagens arbete då de fysiska rapporterna kan försvinna samt leda till mer arbete när månads- eller årssammanfattningar ska samman-ställas.

Kundens mål med projektets produkt var möjligheten att kunna utföra granskning och att kunna generera sammanfattningar av hanteringen av allt avfall digitalt. Detta mål skulle möjliggöras genom att personal vid återvinningsanläggningar skulle få förmågan att skapa avfallsrapporter med hjälp av en mobilapplikation. Dessa rapporter skulle sedan sparas i en databas. Webbapplikationen skulle kunna läsa data från denna databas och med hjälp av denna skapa sammanfattningar av avfallshanteringen.

2.2

Gruppens tidigare erfarenheter

Projektmedlemmarna bestod av åtta studenter som alla läst fem terminer vid Linköpings universitet. Fyra av dessa studerar civilingenjörsprogrammet i datateknik och de resteran-de fyra sturesteran-derar civilingenjörsprogrammet i mjukvaruteknik. Medlemmarna haresteran-de tidigare erfarenheter av programmeringsrelaterade projektarbeten, dock inte till den grad som det-ta projekt innefatdet-tade. Mjukvaruteknikstudenterna hade tidigare erfarenhet av utveckling av databaser och mobilapplikationer, då detta ingick i andra kurser. Datateknikstudenterna läs-te även en UX-kurs parallellt med detta projekt, vilket kom till nytta vid gränssnittdesign för

I detta kapitel beskrivs den teoretiska bakgrunden för de tekniker, tjänster och processer som projektgruppen har använt under projektet.

3.1

Översikt över tekniker

I detta avsnitt beskrivs den teoretiska bakgrunden för de tekniker som projektgruppen har använt under projektet.

3.1.1

JavaScript

JavaScript är ett interpreterat programmeringsspråk som använts som underliggande pro-grammeringsspråk i produktens webbapplikation, mobilapplikation och back-end. Språket används även ofta i samband med HTML och CSS, där JavaScript tillåter utvecklarna att exempelvis dynamiskt exekvera kod som respons till händelser som bland annat knapp-tryck. [161]

3.1.2

React

React är ett ramverk till JavaScript som ursprungligen utvecklades av Facebook för att un-derlätta deras front-end-utveckling. React är komponentbaserat, vilket innebär att gränssnitt byggs upp med kod som kallas för komponenter. Det är med React som produktens webbap-plikation har byggts upp. [64, 120]

3.1.3

React Native

React Native är ett ramverk till JavaScript som möjliggör för utveckling av applikationer till både Android och iOS. Det är baserat på React, men istället för att fokusera på front-end i webbläsaren är målet istället mobila plattformar. React Native har använts i produktens mobilapplikation, som fungerar för både Android och iOS. [163]

MySQL är en databashanterare (eng. Database Management System, DBMS), som möjliggör för hantering av relationsdatabaser. En relationsdatabas är organiserad genom så kallade re-lationer, som också kan kallas för tabeller. Raderna i en relation kan sägas bestå av instanser av dessa tabeller. SQL är det underliggande standardiserade språket som används för mani-pulation av databasen. [101, 4, 110]

3.1.7

REST API

Ett API, eller Application Programming Interface, är en samling regler och protokoll som de-finierar hur enheter och applikationer kan kommunicera med varandra. Ett REST API är ett API som följer REST:s principer. REST, eller representational state transfer är en samling design-principer för API:er. För att en API ska följa REST:s designdesign-principer ska servrar och klienter vara oberoende, alla förfrågningar efter en resurs ska se likadana ut och ska följa HTTP-standarden med operationerna ”POST”, ”GET”, ”PUT” och ”DELETE”. REST API:s får inte ha tillstånd vilket innebär att en förfrågan måste innehålla all information som krävs för att kunna behandla den. [49, 71]

3.1.8

Three-tier architecture

”Three-tier architecture” är en mjukvaruarkitektur som delar upp mjukvaran i tre olika ni-våer. Dessa nivåer består av presentationsnivån, applikationsnivån och datanivån. Presen-tationsnivån består av det som användaren interagerar med, det vill säga användargräns-snittet. Syftet med presentationsnivån är att visa och ta emot information ifrån användaren. Applikationsnivån är den nivå som behandlar data som kommer från presentationsnivån el-ler behandlar data som finns i datanivån. Datanivån ansvarar för att lagra informationen som applikationsnivån behandlar, ofta kan detta ske i form av en databas. [50]

3.1.9

L

_TEX

LaTeX är ett typsättningssystem som innehåller funktioner för skapande av teknisk och ve-tenskaplig dokumentation. [72]

3.2

Amazon-tjänster

I detta avsnitt beskrivs den teoretiska bakgrunden för de tjänster som projektgruppen har använt under projektet.

3.2.1

AWS Amplify

AWS Amplify är en tjänst som projektgruppen använt för att göra webbapplikationen till-gänglig över nätet. AWS Amplify tillhandahåller även mindre tjänster som underlättar för kommunikation mellan de båda applikationerna och Amazon API Gateway. [15]

3.2.2

AWS Lambda

AWS Lambda är en serverlös beräkningstjänst som möjliggör för exekvering av kod i molnet i form av så kallade molnfunktioner (eng. cloud functions). Dessa molnfunktioner kan skri-vas i flera olika språk, däribland exempelvis Python, Ruby och Node.js. Molnfunktionerna placeras i AWS Lambda och kan sedan aktiveras av anrop från andra tjänster inom AWS. I projektgruppens fall har Node.js använts. Molnfunktionerna kan bland annat anropas från Amazon API Gateway och kan i sin tur även kommunicera med både Amazon RDS och Amazon Cognito. [159]

3.2.3

Amazon Cognito

Amazon Cognito är en tjänst som möjliggör för användarhantering. Denna tjänst sköter bland annat lagring av användaruppgifter, autentisering vid inloggning och auktorisation baserat på användargrupp då användare försöker kalla på molnfunktioner. I projektgruppens pro-dukt är användarkatalogen uppdelad i tre grupper, personal, företag och granskare, där des-sa tre användargrupper är behöriga till att använda olika molnfunktioner inom AWS Lamb-da. [154]

3.2.4

Amazon API Gateway

Amazon API Gateway är en tjänst som möjliggör för upprättandet av ett REST API. Det-ta REST API går att koppla ihop med AWS Lambda, vilket möjliggör för användare i både mobilapplikationen och webbapplikationen att kalla på molnfunktioner. [153]

3.2.5

Amazon RDS

Amazon Relational Database Service är en tjänst som tillåter användare att lagra relationsda-tabaser i molnet. Eftersom Amazon RDS är en molntjänst kommer användare kunna komma åt informationen som finns lagrad i databasen från flera olika enheter och från flera olika platser så länge som de är uppkopplade mot ett nätverk. Amazon RDS erbjuder möjligheter för användare att skala sina applikationer. Är en användare i behov av mer lagringsutrymme kan tjänsten allokera mer lagring för databasen. [26, 155]

3.2.6

Amazon S3

Amazon S3 är en webbaserad molntjänst för fillagring. Amazon S3 erbjuder skalbarhet för användare då de endast behöver betala för det serverutrymme som de faktiskt använder. Ett vanligt användningsområde för S3 är lagring av mediafiler som bilder, videor och musik. I projektgruppens fall har Amazon S3 använts för lagring av bilder. Lagringen av filer sker i en så kallad bucket. [156, 30]

3.2.7

Amazon VPC

Amazon Virtual Private Cloud tillåter användare att skapa ett isolerat privat nätverk i Ama-zons moln där användare kan spara undan resurser. En användare kan sedan definiera ett

ett arbetslag, även kallat scrumteam, och ett antal definierade roller. Det finns också aktiviteter, artefakter och regler. Alla delar har ett specifikt syfte och är viktiga för att nå en framgångsrik användning av Scrum.

Scrumteamet består av en scrummästare, en produktägare och ett utvecklingsteam. Scrum-mästaren ansvarar för att projektmedlemmarna förstår Scrum och att Scrum efterlevs i arbetet. Produktägaren ansvarar för att maximera produktens värde och utvecklingsteamets värde, och utvecklingsteamet är ansvariga för att utföra själva arbetet.

Kärnan i att arbeta med Scrum är sprinten, en tidsbegränsad period på en månad eller kortare. Efter en sprint ska ett nytt användbart produktinkrement tagits fram, detta produk-tinkrement ska potentiellt vara redo att levereras till kund. Efter en sprint tagit slut påbörjas en ny sprint. Inför varje sprint ansvarar scrummästaren för att ett planeringsmöte äger rum. På detta möte planeras den kommande sprinten där bland annat ett mål för sprinten tas fram. Detta mål ska ge vägledning för utvecklingsteamet om vad som ska uppnås och imple-menteras under sprinten.

Under pågående sprint hålls varje dag ett kort scrummöte som pågår under maximalt 15 minuter. Där ska medlemmar i utvecklingsteamet kort förklara vad de gjort föregående dag, vad de ska göra under kommande dag och om de upplever att några problem finns som kan leda till att sprintmålet inte kan uppnås. I slutet av en sprint sker en granskning där produktägaren kan förklara för intressenter om vad som uppnåtts under sprinten. Ut-vecklingsteamet får möjlighet att diskutera vad som gått bra och mindre bra under sprinten. Därefter kan en sprintåterblick ske där scrumteamet får möjlighet att granska sig själva och komma fram till en plan om hur de förbättrar arbetet inför kommande sprints.

Till en sprint tillhör också artefakter som en produktbacklogg och en sprintbacklogg. Pro-duktbackloggen är en ordnad lista över funktionalitet som kan behövas för slutprodukten. Listan är ordnad efter prioritet där viktigast funktionalitet finns högst upp i listan. I sprint-backloggen finns en eller flera poster från produktsprint-backloggen som utvecklingsteamet ska utveckla under en sprint. [8, 78]

3.3.3

GitLab

GitLab är en plattform som erbjuder versionshantering med hjälp av Git i molnet. Förutom denna tjänst finns det även andra tjänster tillgängliga i GitLab som kan underlätta utveck-lingsprocessen [160]. Projektgruppen har använt GitLab för versionshantering, men också för automatisk testning och för hantering av ”Boards” som kan användas till produktbacklogg och sprintbacklogg vilket används inom Scrum-metodiken.

3.3.4

Parprogrammering

Parprogrammering är en agil metod för programvaruutveckling där två utvecklare arbetar gemensamt med samma uppgift. De två personerna i paret har varsin roll, där den ena skri-ver koden och den andra granskar koden medan den skrivs. Personerna kan och förväntas byta roller vid jämna mellanrum. Det finns flera olika fördelar med parprogrammering. Agi-le Alliance [7] menar att den kod som skrivs förväntas bli bättre när ett par arbetar med den eftersom paret kan diskutera lösningar och lättare hitta misstag i koden som är svårare för en ensam person att upptäcka. De menar också att en mer erfaren programmerare kan överföra sina kunskaper till den mindre erfarna programmeraren i paret. En möjlig nackdel med parprogrammering är att det fungerar sämre om inte båda personerna i paret är aktiva, fokuserade på uppgiften och delaktiga i diskussioner. [7, 29]

3.3.5

Eslint

Eslint är ett statiskt analyseringsverktyg som ger varningar om kodstandarder ej följs. Ge-nom integrationer med utvecklingsmiljön kan programmeraren få varningar i realtid sam-tidigt som koden skrivs. Eslint kan även konfigureras om utvecklarna önskar att modifiera kodstandarden efter egna önskemål.

produkten.

4.1.1

Projektroller

Under utvecklingen av produkten har varje gruppmedlem haft en egen roll och därmed varit direkt ansvarig för en egen del av projektet. Dessa roller redovisas och beskrivs här.

Teamledare

Teamledaren är ansvarig för att projektets mål uppfylls och att de processer och metoder som specificerats för projektet används. Teamledaren representerar även gruppen utåt. Albin Holmkvist var gruppens teamledare.

Analysansvarig

Den analysansvarige är ansvarig för kontakt och informationsutbyte med kund. Denna per-son är därmed även ansvarig för att kundens verkliga behov formuleras som krav, som grup-pen sedan kan arbeta för att realisera. Henrik Larsson Edström var grupgrup-pens analysansvari-ge.

Arkitekt

Arkitekten är ansvarig för att en övergripande arkitektur tas fram. Denna arkitektur beskriver systemet både övergripande och på detaljnivå. Alla gruppmedlemmar kan sedan utgå ifrån denna arkitektur vid utvecklingen av produkten. Simon Hermansson var gruppens arkitekt.

Utvecklingsledare

Utvecklingsledarens primära ansvar är att leda och fördela utvecklingsarbetet. Den är även ansvarig för den detaljerade designen och för fastställande av de utvecklingsmiljöer som an-vänds. Det är även utvecklingsledarens ansvar att arkitekturen realiseras. Robin Simonsson vad gruppens utvecklingsledare.

Testledare

Testledaren är ansvarig för testning av systemet. Denna person ska skriva en testplan som beskriver hur testningen ska genomföras och på vilka nivåer. Flera testrapporter ska också skrivas. Dessa liknar en statusrapport som redogör för testningens status. Gruppens testle-dare var Gustav Stappe Renner.

Kvalitetssamordnare

Kvalitetsarbete, det vill säga arbete som utförs i mål om att säkerställa systemets kvalitet, är något som alla medlemmar varit ansvariga för till viss mån. Det var däremot kvalitetssam-ordnaren som var huvudansvarig för detta område. Kvalitetssamkvalitetssam-ordnaren ansvarade även för att ta fram en kvalitetsplan, ett dokument som redovisar för vilka kvalitetskrav som sy-stemet ska uppnå. Anton Nylund var gruppens kvalitetssamordnare.

Dokumentansvarig

Den dokumentansvarige är ansvarig för att alla dokument följer de standarder som doku-mentmallarna anger samt säkerställer att dokumenten levereras till deras respektive leve-ransdagar. Mirna Ghazzawi var gruppens dokumentansvarige.

Konfigurationsansvarig

Den konfigurationsansvarige säkerställer att relevanta projektfiler versionshanteras, samt an-svarar för de verktyg som versionshanteringen utförs med. Därtill skapas ett ansvar till att dessa verktyg används på korrekt sätt. Denna person samarbetar mycket med utvecklings-ledaren samt den dokumentansvarige för att komma fram till vilka arbetsprodukter som är nödvändiga att versionshanteras. Konfigurationsansvarig för gruppen var Moltas Enåkan-der.

4.1.2

Scrum

Scrum har använts vid utvecklingen av produkten. Gruppens teamledare Albin Holmkvist antog rollen som scrummästare. Gruppens analysansvarige, Henrik Larsson Edström antog rollen som produktägare, då produktägarens ansvarsområden sammanfaller med många av de områden som den analysansvarige ansvarar för. Gruppen har haft dagliga scrummöten, med avbrott endast under tentaperioden i mars. I början av projektet lade gruppmedlemmar-na till uppgifter till produktens backlogg. Dengruppmedlemmar-na backlogg uppdaterades även kontinuerligt, då nya idéer om vad som krävdes av produkten definierades. Sprints har varit två veckor långa, där gruppen vid starten för varje sprint har planerat in vilka uppgifter som ska vara färdigställda vid sprintens slut. Dessa uppgifter finns från början i produktens backlogg, och tas vid planeringsmöten in i sprintens backlogg. Vid behov kunde sprintens backlogg ändras under sprinten. Efter varje sprint har en utvärdering av sprinten skett där gruppen diskuterat vad som gått bra och mindre bra, samt vad som kunde göras bättre till nästkommande sprint.

då den ansetts varit potentiellt färdigställd, utsett en utomstående gruppmedlem att granska artefakten. Under granskningen har granskaren kommenterat alternativt ändrat artefakten, varefter slutgiltiga ändringar har genomförts av upphovsmakarna. Därefter har artefakten ansetts färdigställd.

För att enkelt se till att projektgruppens kodstandard följs har verktyget Eslint integre-rats med utvecklingsmiljön. Verktyget hjälper programmeraren att upptäcka om skriven kod inte följer gruppens kodstandard genom att i dessa fall visa varningar i utvecklingsmiljön.

4.1.5

GitLab

Under projektarbetet versionshanterades all källkod via GitLab. Koden delades upp baserat på vilken del av den färdiga produkten den avsåg, det vill säga antingen webbapplikation, mobilapplikation, back-end eller databas, med hjälp av så kallade grenar (eng. branches). Där-till fanns en gren för den slutgiltiga koden, en huvudgren, där kod från de andra grenarna integrerats. Kod relaterad till en viss del började alltid utvecklas på en egen gren, tills dess att denna kod ansågs godtagbar för att sammanfogas med huvudgrenen.

GitLab användes för att fastställa förestående aktiviteter och milstolpar. Där kunde hela gruppen se vad som arbetades på vid ett visst tillfälle, vad som avslutats och vad som ännu inte hade genomförts.

4.1.6

Testning

Testning på flera olika nivåer var planerat att utföras på systemet i syfte att säkerställa de krav som specificerades i kravspecifikationen. Dessa nivåer innefattade enhetstestning, in-tegrationstestning, systemtestning samt acceptanstestning.

Enhetstesterna för projektet skrevs i ramverket Jest. Detta ramverk valdes eftersom det är lätt att använda, samt för att det fungerar mycket bra för program skrivna i JavaScript. I detta projekt innefattar det mobilapplikationen, webbapplikationen samt funktioner i back-end som hanterar både användarhantering och hämtning, radering samt modifikation av data i databasen.

Continous integration var planerad att genomföras genom GitLabs egna CI/CD-verktyg, där standardiserade enhets- och integrationstester skrevs. Detta gjordes i mål om att säkerställa att utvecklarens kod uppfyllde vissa krav innan den skickades upp till projektets GitLab. System- samt användbarhetstester var planerade att utföras när majoriteten av systemets funktionaliteter var implementerade. Systemtesterna var så kallade End-to-End tester som

testar vissa utvalda faktorer för hela systemet, dessa innefattade vissa prestanda- samt funktionalitetskrav. Vid användbarhetstestningen blev testpersonerna tilldelade en upp-gift att utföra i applikationen och därefter besvarade dessa personer på tio frågor enligt SUS-mätningen.

4.2

Metod för att fånga erfarenheter

I detta avsnitt redovisas erfarenheter från projektet i enlighet med frågeställning 2 i Avsnitt 1.3.

4.2.1

Möten

För insamling av erfarenheter under projektarbetet användes ett flertal metoder. Möte med handledare hölls varje vecka där handledaren kunde kontrollera att inga större problem upp-stått. Utöver handledarmöten hade gruppen ett eget veckomöte. Dessutom hade gruppen dagliga scrummöten som beskrivs i Avsnitt 4.1.2.

För varje vecka skapades ett dokument som beskrev varje agenda som mötena skulle ha. Varje möte hade en tillhörande punklista där det kortfattat stod vad som skulle diskuteras under respektive möte.

4.2.2

Erfarenhetssamling

Den mest frekvent använda metoden för dokumentation var veckorapporter som skrevs varje vecka, de innefattade vad gruppen gjort den gångna veckan, planen för den kommande vec-kan och potentiella risker. Dessa rapporter skrevs tillsammans av gruppen på veckomöten. Tidrapportering användes för att dokumentera individernas spenderade timmar. Tidrappor-teringsdokumentet utformades i Excel med individuella flikar där spenderade timmar fördes in. Dokumentet använde sig sedan av formler för att sammanställa tid spenderad varje vecka och total tid spenderad på projektet, vilket gav en tydlig översikt.

4.2.3

Dokument

Projektgruppen dokumenterade arbetsinsatser och förhållningssätt i ett gemensamt grupp-kontrakt. Tidsrapportering skedde kontinuerligt veckovis i ett Excel-dokument. En veckorap-port skrevs även varje vecka. De mer formella dokument som skapades var projektplanen, kravspecifikationen, kvalitetsplanen, arkitekturdokumentet, testplanen, testrapporterna och en användarmanual. En sammanfattning av innehållet i respektive dokument redovisas här.

Gruppkontrakt

I gruppkontraktet finns information om vilken ambitionsnivå gruppen har inför projektet. Den specificerar även hur gruppen ska hantera problem och återkoppling inom gruppen samt anger regler angående hur gruppmöten ska fungera och dokumenteras. Den innehåller även information om vilka krav gruppmedlemmarna har på varandra, samt information om konsekvenserna då en individ inte följer de förväntade kraven.

Tidsrapporter

Detta Excel-dokument innehåller information om hur många timmar varje gruppmedlem har arbetat med respektive aktivitet varje vecka. Det finns också en sammanställning över inrapporterad tid under enskilda veckor och en sammanställning över det totala antalet

in-Kundens projektbeskrivning och krav dokumenterades i kravspecifikationen. Detta doku-ment användes som en grund för att ta fram varje krav för respektive plattform. Kraven uppdaterades med tiden, och varje krav bestod av en beskrivning, en prioritet och om kravet var funktionellt eller icke-funktionellt.

Kvalitetsplan

Kvalitetsplanen innehåller information om hur olika metoder ska appliceras för att produk-tens kvalitet ska uppnå högsta möjliga nivå. Det finns bland annat information om kod-granskning, parprogrammering och standarderna för dokument och kod. Här beskrivs för-bättringar projektgruppen har gjort för de metoder som har använts. Det finns även en be-skrivning av processen i fokus och hur den dokumenteras.

Arkitekturdokument

Arkitekturdokumentet innehåller en beskrivning av den övergripande arkitektur som an-vänts av produkten. Dokumentet fastställer och beskriver även de val av tekniker och ram-verk som utgör implementationen av produkten och motivering till varför dessa valts.

Testplan

Testplanen specificerar hur testningen ska genomföras i projektet. Detta innefattar även vilka standarder som kommer antas, samt vilka verktyg och tekniker som gruppen ska använda sig av.

Testrapport

Testrapporten innehåller en summering för testningens status vid rapportens skrivande. Fle-ra instanser av detta dokument ska skrivas under projektets gång i mån om att redogöFle-ra för testningens och produktens status.

Användarmanual

Användarmanualen specificerar hur produktens kund ska använda sig av produkten på ett korrekt sätt. Den innehåller även information till utvecklare som eventuellt kommer vidare-utveckla produkten om hur den är uppbyggd, vilka teknologier och programmeringsspråk som använts, samt vilken funktionalitet som återstår att implementera.

4.3

Prototyper

Prototyper för mobilapplikationen och webbapplikationen utvecklades i syfte om att ha en referensram gällande hur dessa delar av systemet skulle se ut och hur skärmar skulle vara ihopkopplade. Utvecklingen av respektive gränssnitt utfördes med dessa prototyper i åtanke.

4.3.1

Prototyp till mobilapplikation

Utvecklingen av mobilapplikationen påbörjades genom skapandet av en prototyp över de skärmar som applikationen skulle innehålla. Med en prototyp blev det tydligt vilken infor-mation varje skärm behövde innehålla och hur skärmarna skulle sitta ihop. I Figur 4.1 redo-visas skärmarna, flödet mellan skärmarna och även fälten i varje skärm, där information ska matas in av användaren. Verktyget Figma användes för att utveckla den grafiska prototypen.

Figur 4.1: Gränssnittsflöde över prototypen till mobilapplikationen.

4.3.2

Prototyp till webbapplikation

Innan utvecklingen av webbapplikationen påbörjades skapades en prototyp av webbappli-kationen. Prototypen innehåller olika vyer för hur applikationen skulle kunna se ut för fö-retagsadministratörer anställda vid återvinningsanläggningar och för granskare anställda av EcCell, se Figur 4.2 och Figur 4.3 för representationer av dessa prototyper.

ta arbetsprocessen för rapportörer och att samtidigt underlätta kundens års- och månadssam-manställningar. Funktionaliteten som implementerats är uppladdning av avfallsrapporter till en databas via antingen en mobilapplikation eller en webbapplikation. Webbapplikationen har mer administrativ funktionalitet som bland annat ger kunden möjlighet att granska den data som finns i databasen. Webbapplikationen tillåter även för användarhantering.

5.1.1

Systemanatomi

I början av projektet skapade projektgruppen gemensamt en systemanatomi som visas i Figur 5.1. Denna anatomi gav gruppen en enkel överblick över vilken funktionalitet systemet skulle erbjuda och hur systemet skulle vara uppdelat mellan olika gränssnitt och roller.

5.1.2

Mobilapplikation

Utveckling av mobilapplikationen har resulterat i en nästintill färdig applikation. Applika-tionen har ännu inte släppts och används för tillfället inte av rapportörer. Det som beskrivs nedan är dess funktioner och deras tänkta användning hos avfallsrapportörer.

Mobilapplikationen är den del av systemet som primärt kommer att användas av av-fallsrapportörer i deras dagliga arbete. Rapportörerna loggar in i applikationen med sitt egna personalkonto och skapar en rapport för en viss last när den lastas av och sorteras vid återvinningsanläggningen. Denna rapport innefattar en bild på ett kvitto kopplat till lasten, en bild på lasten som transporterats, och till sist en approximativ procentuppdelning över vilka material som lasten bestod av.

Figur 5.1: Systemanatomi för produkten.

Mobilapplikationen består av skärmar som vägleder rapportören genom processen att skapa en rapport. Den gör detta enkelt med hjälp av kontroller och instruktioner som garanterar att rapporterna har korrekt data. Mobilapplikationen kommunicerar med databasen för att ladda upp och permanent lagra rapporter genom AWS. Mobilapplikationen fungerar för både Android och iOS vilket uppfyller krav 3.1.1-2 i projektets kravspecifikation, se Tabell 5.1.

Krav-nr

Version Kravtext

Prioritets-nivå

Kravtyp

3.1.1 2 Mobilapplikationen ska kunna köras på smartphones med kamera, som an-vänder operativsystemet Android 5.0 (API 21) eller nyare med en skärmstor-lek på minst 320 ˆ 500 px.

Prio 1 Kundkrav och utvecklarkrav, Icke-funktionellt.

3.1.2 2 Mobilapplikationen ska kunna köras på smartphones med kamera, som an-vänder operativsystemet iOS 11.0 eller nyare med en skärmstorlek på minst 320 ˆ 500 px.

Prio 1 Kundkrav och utvecklarkrav, Icke-funktionellt.

användningsfallen i applikationen samtidigt som varje skärms funktionalitet beskrivs.

Figur 5.2: Flödesbeskrivning för skapande och uppladdning av en avfallsrapport.

5.1.2.2 Uppladdning av rapport

För att ladda upp en rapport följer användaren flödet som visas i Figur 5.2, där användaren först loggar in i applikationen med sitt användarnamn och lösenord. Därefter väljer använ-daren knappen med alternativet ”New report”, och efter det presenteras skärmen som kallas ”Load”. Till rapporten ska två bilder bifogas, en på avfallet och en på kvittot till invägningen av lasten. Informationsfälten fylls i och användaren går vidare genom att trycka på knappen ”Submit”. Då kommer användaren till materialskärmen där uppskattningen av material fylls i. Sedan laddar användaren upp rapporten genom att trycka på knappen ”Submit”. Då visas en bekräftelse på att rapporten blivit uppladdad. Nedan beskrivs stegen i detalj.

5.1.2.3 Inloggningskärmen

Skärmen ”Login” har som uppgift att verifiera användare så att endast behöriga kommer åt systemet. Detta görs genom att skicka en förfrågan till back-end med användaruppgifter-na som matas in i fältet ”Useranvändaruppgifter-name” och ”Password”. Dessa uppgifter kontrolleras sedan i Amazon Cognito som verifierar att användarnamnet med givet lösenord existerar, och om detta är fallet skickas en respons på förfrågan innehållande en token samt en bekräftelse på att förfrågan gick igenom. ”Login”-skärmen utför även en kontroll som kontrollerar att båda fälten är ifyllda innan en förfrågan skickas. Om något fält är tomt kommer ett meddelande visas på skärmen där användaren blir ombedd att fylla i fälten, se Figur 5.3. När korrekta inloggningsuppgifter har fyllts i och användaren har tryckt på ”Login” så visas nästa skärm.

Figur 5.3: Varning som uppkommer när ett fält lämnats tomt vid inloggning.

5.1.2.4 Hemskärmen

Skärmen ”Home” är applikationens hemskärm som visas efter att användaren har loggat in, se Figur 5.2. Skärmen ger användaren två alternativ, att antingen påbörja en ny rapport genom att klicka på knappen ”New Report” eller att se historiskt uppladdade rapporter med knappen ”History”.

När knappen ”New report” klickas på tas användaren till skärmen ”Load”. I bakgrunden skapar applikationen en tom rapport med informationsfält som fylls i de efterkommande skärmarna.

När knappen ”History” klickas på skickar applikationen en förfrågan till databasen om rapporteringshistorik för den inloggade användaren. Sedan tas användaren vidare till skär-men ”History” där inskickade rapporter visas upp.

5.1.2.5 Lastskärmen

Skärmen ”Load” är till för att användaren ska fylla i information om lasten som transpor-terats. Det innefattar: bild på lasten, bild på kvittot, datum, byggarbetsplats, invägnings-nummer, vikt, containerstorlek som i applikationen motsvarar: ”Date”, ”Site”, ”Docket No.”, ”Weight” och ”Bin size”. Fälten som behöver fyllas i kräver olika typer av data och därför används flera olika inmatningsmetoder. Skärmen och fälten som behöver fyllas i visas i Figur 5.4. Överst finns två knappar för att bifoga bilder i rapporten ”Docket reciept” och ”Waste”. Då de trycks ned öppnas skärmen ”Camera” där rapportören kan ta en bild med kameran på telefonen. Vid tagen bild visas skärmen ”Save” där alternativet att behålla bilden eller ta en ny finns. Då save trycks på sparas bilden och en liten version visas upp ”Load” skärmen. Samma process upprepas för att bifoga bild på kvittot.

Första fältet med datum är förifyllt med dagens datum då rapporter oftast handlar om dagens datum. Vid behov går det att manuellt ändra datumet med tangentbordet direkt i textfältet, det går även att välja knappen ”Date Picker” som öppnar en kalender där önskat

ned på skärmen. När knappen klickats ned gör applikationen en kontroll att alla fält är ifyllda innan den går vidare till nästa skärm. Om någon information saknas kommer det upp en ruta som ber användaren att fylla i eventuella tomma fält. När all information är ifylld och ”Next”-knappen är nedtryckt går applikationen vidare till materialskärmen.

5.1.2.6 Materialskärmen

Skärmen ”Material” i Figur 5.2 används för att mata in uppskattningen av procent. Det som visas på skärmen är en lista över alla material som företaget har lagt till i databasen. Denna information hämtas från databasen med en förfrågning när skärmen ska laddas in. På så sätt visas bara material som är relevanta för användaren.

Procentsatserna fylls i med plus- och minusknapparna i varje rad. Procentsatserna är visuellt uppskattade vilket ger en viss osäkerhet i värdena. På grund av detta har applikationen en upplösning med steg av fem procent. Varje klick på plusknappen lägger till 5 procent och minusknappen tar bort 5 procent. Med denna inmatning slipper användaren använda ett tangentbord för att mata in data.

För att säkerställa att de inmatade värdena är giltiga utförs en kontroll. Alla inmatade värden summeras och summan visas högst upp på skärmen under företagets logga, se skär-men ”Material” i Figur 5.2. Med summeringen vet användaren hur många procent som är kvar att fylla i för att nå 100 procent. När summan är lika med 100 procent ändras texten i knappen på botten till ”Submit”, vilket tillåter rapporten att skickas in, se Figur 5.5. Ett tryck på ”Submit”-knappen laddar upp rapporten till databasen och visar användaren en skärm som bekräftar att rapporten är uppladdad. Om något fel skulle ske vid uppladdningen av rapporten visas istället en skärm som informerar användaren om detta.

5.1.2.7 Redigering av uppladdad rapport

Redigering av en uppladdad rapport sker genom att följa flödet som visas i Figur 5.6, där användaren först loggar in. Efter inloggning visas hemskärmen, på hemskärmen klickas knappen ”History” på och då visas en lista över alla rapporter som användaren laddat upp. Användaren väljer en rapport i listan genom att att trycka på den. Då visas en överblick över rapporten med både byggarbetsplatsdata och materialuppskattning. För att redigera rappor-ten klickas knappen ”Edit” ned, och då tas användaren vidare till en skärm där ifylld data redigeras på samma sätt som rapporten skapades första gången. Byggarbetsplatsdata samt anledning för redigering fylls i på första skärmen och på nästa skärm fylls materialprocenten i. När användaren fyllt i båda och klickat på knappen ”Submit” visas en bekräftelse på att rapporten är redigerad.

Figur 5.4: Lastskärmens metoder för ifyllnad av information.

Redigering av en uppladdad rapport delar flera skärmar med skapandet av en rapport, därför beskrivs endast de nya skärmarna i detalj nedan.

5.1.2.8 Historikskärmen

Historikskärmen, ”History”, i Figur 5.6, består av en skrollbar lista som innehåller alla tidi-gare rapporter som användaren har laddat upp. När skärmen laddas in skickas en förfrågan till databasen som begär den inloggade användarens uppladdade rapporter. Varje rapport blir ett eget föremål i listan som går att trycka på för att bli vidareskickad till en överblick av rapporten. Då en rapport klickas på i listan byter bakgrunden färg för att visa att trycket registrerats.

Figur 5.5: Stegvis ifyllnad av procentenheter visar skärmens tillstånd vid olika procent.

Figur 5.6: Flödet mellan applikationens skärmar för att redigera en uppladdad rapport.

5.1.2.9 Överblicksskärmen

Överblicksskärmen benämnd ”Overview” i Figur 5.6, ger en sammanfattning över all inrap-porterad data. Skärmen går endast att läsa, inget går att redigera. För att redigera trycks knappen ”Edit” ned vilket öppnar upp rapportens fönster för byggarbetsplatsdata och mate-rialuppskattning där alla parametrar kan ändras.

5.1.2.10 Värde hos kunden

Mobilapplikationen skapar värde för kunden genom att tillåta avfallsrapporter att laddas upp digitalt. Ett problem som kunden uttryckte var att rapporter i pappersform frekvent tappas bort, med applikationen finns alla rapporter samlade på ett ställe och behöver inte lämnas in fysiskt. Ett starkt önskemål som kunden formulerade var att applikationen ska vara lätt att använda då inte alla rapportörer har teknikvana. En applikation som är enkel att tolka och använda i deras vardagliga arbete skapar värde då rapportörerna kan fokusera på annat. Rapporteringen sker från varierande miljö som inte alltid är optimal för mobilskärmar, trots det ska applikationen gå att lita på. Därför är applikationen utformad för att vara lättanvänd, med stora knappar och med stor text. Ett krav kunden hade var att rapporterna behövde innehålla viss information. Detta uppfylles genom att applikationen har kontroller för att verifiera att nödvändig data är ifylld innan en uppladdning av rapporten kunde göras.

5.1.3

Webbapplikation

Webbapplikationen är den del av systemet som granskare och företagsadministratörer använ-der sig av i sitt arbete. I webbapplikationen finns det en överblick över inrapporterad data, avfallsrapportörer och återvinningsanläggningar. Det finns två typer av konton till webbap-plikationen, en kontotyp avsedd för företagsadministratörer bundna till en viss återvinnings-anläggning och en kontotyp avsedd för granskare som är anställda hos EcCell, som kan se data från och administrera alla återvinningsanläggningar i webbapplikationen.

5.1.3.1 Inloggningskärmen

Inloggningsskärmen som syns i Figur 5.7 kan användas av både EcCell och företagsadminist-ratörer. Fälten ”Email Address” och ”Password” ska vara ifyllda med korrekt användardata för att kunna logga in till webbapplikationen.

Figur 5.7: Webbapplikationen – Inloggningsskärm.

5.1.3.2 Utloggningsknapp

Knappen ”Sign out” syns på alla skärmar efter en granskare eller en företagsadministratör har loggat in för att det ska vara enkelt att när som helst kunna logga ut från applikationen utan att behöva backa till en specifik skärm. ”Sign out”-knappen syns exempelvis i Figur 5.8.

5.1.3.3 EcCells hemskärm

Hemskärmen för EcCell visas efter att en granskare som jobbar hos EcCell har loggat in i webbapplikationen, se Figur 5.8. De två knapparna ”Show Companies” och ”Show Tables” utgör den viktigaste delen av hemskärmen.

Figur 5.8: Hemskärm för granskare.

5.1.3.4 ”Show Companies”-skärmen

”Show Companies”-skärmen innehåller både en företagsvy och en personalkontovy.

Företagslistan

När en granskare hos EcCell klickar på ”Show Companies”-knappen som finns i menyn på hemskärmen så får den en ny skärm som syns i Figur 5.9. Där finns en skrollbar lista, benämnd ”Companies”, med alla befintliga företagsnamn. Alla företagsnamn i listan är klickbara. Granskare kan klicka på ett företagsnamn för att se mer detaljerad information, ”Company Information”, om företaget i en informationsruta med fälten som syns till höger i Figur 5.10. Dessa fält kan redigeras genom att klicka på knappen ”Edit”, se Figur 5.11. Om en granskare väljer att inte ändra någonting kan den klicka på ”Cancel” för att avbryta och om den istället vill spara ändringen ska knappen ”Save” klickas på och då uppdateras företagsinformationen som syns på skärmen. Knappen ”Add new company” är till för att lägga till nya företag i listan. När en granskare klickar på knappen får den en ”Company Information”-ruta till höger, se Figur 5.12, där fält kan fyllas i för att lägga till ett nytt före-tag. Knapparna ”Cancel” och ”Save” finns också med då, med samma funktionalitet som beskrevs innan.

Figur 5.10: Webbapplikationen – ”Show companies”-skärmen där ett företag har valts i listan till vänster.

Figur 5.11: ”Show companies”-skärmen – Ett valt företags uppgifter kan redigeras i rutan till höger.

Figur 5.12: ”Show companies”-skärmen – Ett nytt företags uppgifter kan skrivas in i rutan till höger.

Personalkonto-listan

När en granskare klickar på ”Show Personnel” för ett specifikt företag kommer en lista med all personal länkat till företaget att visas upp. Även här kan information om ett visst personalkonto visas genom att klicka på detta konto, se Figur 5.13. Och på samma sätt som i företagslistan kan man här redigera det som valts i listan till vänster. En extra funktionalitet här är att när granskaren klickar på ”Add new account” kommer den att få två alternativ enligt Figur 5.14. Varje personalkonto har olika informationsfält som kan visas och redigeras.

Figur 5.13: ”Show personnel”-skärmen – Ett valt företags personalkonton visas i listan till vänster och information för ett valt konto visas till höger.

Figur 5.14: ”Show personnel”-skärmen – Lägga till ett nytt konto.

5.1.3.5 ”Show Tables”-skärmen

Den här skärmen visar en tabell, där varje rad representerar en avfallsrapport. Avfallsrap-porter är sorterade efter datum, och en granskare kan filtrera tabellen baserat på namn eller det den skriver in i sökfälten enligt Figur 5.15. För att visa mer detaljerad information för en specifik avfallsrapport behöver granskaren dubbelklicka på en rad i tabellen. Rapporten kommer att visas enligt Figur 5.16. Med knapparna ”Edit” och ”Delete” kan avfallsrapporten redigeras och tas bort. Vissa fält får ej redigeras, se 5.17. Med knappen ”Back” kan granskaren gå tillbaka till tabellvyn. Med knappen ”Add new report” kan granskaren skapa nya rappor-ter, se Figur 5.18. Avslutningsvis ger knappen ”Download data in Excel format” möjligheten att ladda ner tabellens innehåll i en Excel-fil.

Figur 5.15: ”Show tables”-skärmen – Tabellen filtreras baserat på vad användaren skrivit in i sökfältet för ”Username”-kolumnen.

Figur 5.16: ”Show tables”-skärmen – Användaren har dubbelklickat på en rad så att innehål-let i rapporten visas.

Figur 5.18: ”Show tables”-skärmen – skapandet av en ny avfallsrapport.

5.1.3.6 Värde hos kunden

Webbapplikationen skapar värde för kunden genom att den möjliggör för granskare från EcCell att ha en god överblick över vilka återvinningsanläggningar som är anslutna till pro-dukten, samt information relaterad till dem. Det kan sägas vara en syntes av ett antal krav som kunden hade i början av projektet. Kunden önskade även att det skulle vara möjligt att skapa nya konton för återvinningsanläggningar och dess personal vilket webbapplikationen också möjliggör. Vidare var ett krav att en användare av webbapplikationen ska kunna se data från databasen, samt redigera den, något som är möjligt för granskare då det kommer till information om företags- och personalkonton samt avfallsrapporter. Granskare kan även skapa nya avfallsrapporter, vilket är funktionalitet som kunden också ville ha.

5.1.4

Databas

En viktig del för att systemet ska uppfylla kundens krav är att det finns en databas som kan spara olika typer av data. Det är i databasen som data om bland annat avfallsrapporter och återvinningsanläggningar sparas. Databasen är en MySQL-databas som finns tillgänglig genom Amazons molntjänst Amazon RDS (se Avsnitt 3.2.5). För att möjliggöra implementa-tionen av databasen, och för att detta skulle kunna genomföras på ett korrekt sätt, skapades ett EER-diagram. Detta diagram ger en beskrivning av hur entiteterna, eller objekten i da-tabasen förhåller sig till varandra. Entiteterna är de fyrkantiga objekten i diagrammet som visas i Figur 5.19.

Utifrån diagrammet i Figur 5.19 skapades sedan ett relationsschema som återfinns i Figur 5.20, som beskriver hur olika tabeller i databasen är relaterade till varandra. Databasen kun-de därefter med hjälp av relationsschemat implementeras i MySQL.

För att förhindra att vem som helst kan komma åt databasen har den placerats i en VPC med hjälp av Amazon VPC (se Avsnitt 3.2.7), vilket innebär att endast en definierad grupp användare har åtkomst till databasen.

Figur 5.19: EER-diagram för databasen.

Figur 5.20: Relationsschema för databasen.

5.1.5

Bildlagring

Lagringen av bilderna som hör ihop med en rapport sker i Amazon S3 och det som sparas undan i databasen när en rapport skapas är namnet på bilderna. Med hjälp av namnen på bilderna kan de sedan hämtas från S3. För varje rapport skapas en mapp i S3 där mappen döps till rapportens identifierare. I mappen sparas sedan de bilder som hör ihop med rap-porten. Bilderna följer formatet ”load_YYYY-MM-DD_HH:MM:SS.type” om det är en bild på

lasten och ”receipt_YYYY-MM-DD_HH:MM:SS.type” om det är en bild på kvittot. ”YYYY-MM-DD” är det datum som rapporten skapades, ”HH:MM:SS” anger tiden som rapporten skapades och ”type” anger filformatet för bilden.

Den bucket som bilderna sparas i är placerad i samma Amazon VPC som databasen för att förhindra att obehöriga har åtkomst till bilderna.

5.1.6

Användarhantering

Användarhantering sker med hjälp av Amazon Cognito. I Amazon Cognito finns det en användarkatalog som är uppdelad i tre grupper. Dessa grupper kallas för personal, företag och granskare. Varje användartyp skapas med hjälp av en egen molnfunktion som automa-tiskt tilldelar användaren till rätt grupp. När en molnfunktion väl skapat en användare i Amazon Cognito, anropas även en annan molnfunktion, som skapar en representation av användaren i MySQL-databasen. Varje användargrupp har en egen roll, som specificerar vil-ka molnfunktioner som användarna i denna grupp har tillåtelse att anropa. Dessa rättigheter är hierarkiska, där företagskonton har alla rättigheter som personalkonton har, med addition av ytterligare rättigheter, och där granskarkonton har alla rättigheter som företagskonton har, med addition av ännu ytterligare rättigheter.

I webbapplikationen och i mobilapplikationen kan användare fylla i inloggningsfält, som skickar upp information till Amazon Cognito som i sin tur autentiserar användaruppgifter-na. När en användare autentiserats kan den anropa funktioner i det REST API som finns i Amazon API Gateway (se Avsnitt 3.2.4). Dessa funktioner är dock begränsade efter an-vändargrupper, och vid ett anrop auktoriseras användaren genom att användarens grupp kontrolleras efter korrekta rättigheter.

5.1.7

Molnfunktioner

Molnfunktioner har skapats för två ändamål. Det första ändamålet har varit att möjliggöra för skapandet av användare i Amazon Cognito, och det andra ändåmålet har varit möjlighe-ten att kommunicera med databasen. Molnfunktionerna är skrivna i Node.js och placerade i AWS Lambda (se Avsnitt 3.2.2). När en molnfunktion anropas skickas ett svar i JSON-format bestående av två fält, ”statusCode” och ”body”. I Förteckning 1 syns ett illustrativt exempel på ett svar från en funktion som hämtar alla rapporter som är skapade av en specifik använ-dare hos ett specifikt företag. Statuskod 200 innebär att data kunde hämtas från databasen utan problem. Inuti ”body” finns den data som databasen returnerade. När data skickas som argument till molnfunktionerna från antingen mobilapplikationen eller webbapplikationen är den också strukturerad i JSON-format. Molnfunktioner som kommunicerar med databa-sen som beskrivs i Avsnitt 5.1.4 är inlagda i samma VPC-grupp som denna.

5.1.8

REST API

I Amazon API Gateway (se Avsnitt 3.2.4) har det skapats ett REST API som tillåter användare i både webbapplikationen och i mobilapplikationen att anropa funktioner som är kopplade till molnfunktioner i AWS Lambda med hjälp av HTTP-anrop. Detta API använder sig av vad Amazon kallar för en AWS_IAM-auktoriserare, som kontrollerar att användarens roll är auktoriserad att anropa en molnfunktion.

"waste_load": "5884692/load_2021-05-18_12:06:00.jpg", "reason_for_change": "",

"ABN": 123,

"address": "Australian Waste Facility Address" }

] }

Förteckning 1: Exempel på svar från en molnfunktion.

dagen och vad den planerar att arbeta med under den resterande dagen. Enligt Scrums riktlinjer arbetade gruppen i kortare sprints, där varje sprint var två veckor lång. Gruppen hade en backlog där alla uppgifter som skulle behöva utföras för att realisera produkten fanns. Till varje sprint flyttades ett antal av dessa uppgifter som skulle utföras till en separat backlog just för sprinten. Efter varje sprint hölls en utvärdering där gruppen diskuterade vad som gått bra under den gångna sprinten och vad som kunde göras bättre under nästa sprint. En enkät sammanställdes för att mäta påverkan av förbättringarna mellan varje sprint. En mätning över hur många av aktiviteterna som avslutades och över hur många som förblev oavslutade sammanställdes även. Detta tyckte projektgruppen ökade produktiviteten då det hjälpte gruppen att få en bättre överblick av vad som tog för mycket respektive för lite tid. Projektgruppen upplevde även att det blev lättare att planera nästkommande iterationer. Processen förbättrades efter varje sprint med hjälp av sprintåterblickar där vi diskutera-de vad som har gått bra och dåligt, idéer till nästa sprint samt diskutera-de åtgärdiskutera-der som kommer att genomföras. Enkäten som skickades ut till alla gruppmedlemmar gav gruppen möjlig-heten att utvärdera dessa möjliga förbättringar som tagits upp i föregående sprintåterblick. Gruppen blev även bättre på att vikta uppgifter, vilket gjorde det lättare att planera vad som var rimligt att hinna med under den kommande sprinten. Enkäten visade på att fler gruppmedlemmar upplevde att de hann med de uppgifter som var planerade för de senare sprintarna. Enkäten visade även att gruppmedlemmarna upplevde att sprintarna var bättre planerade ju längre in i projektet gruppen kom.

För att kunna följa det agila arbetssätt som Scrum förespråkar krävdes verktyg som möj-liggjorde för gruppmedlemmarna att kommunicera med varandra, trots att arbetet skedde på distans. De verktyg som gruppen använde var Microsoft Teams och Facebook Messenger, något som gruppen upplevde skapade förutsättningar för bra, kontinuerlig kommunikation.

5.2.1

Samarbete med coaching-grupp

Projektgruppens kvalitetssamordnare tillsammans med en gruppmedlem deltog i ett samar-bete med en coaching-grupp som över totalt fyra tillfällen gav hjälp och återkoppling gällan-de kvalitetskrav och processen i fokus, som i gällan-detta fall var Scrum. Med hjälp av gällan-dessa tillfällen valdes projektgruppens tre kvalitetskrav, användbarhet, tillgänglighet och underhållbarhet.

5.3

Gemensamma erfarenheter

Detta avsnitt kommer beskriva ett antal erfarenheter som projektgruppen fått och som grupp-medlemmarna kan ta med sig till framtiden när de ska arbeta med nya projekt.

5.3.1

Kundkontakt

Samtliga gruppmedlemmar hade tidigare erfarenhet av att arbeta med större projekt i en grupp med flera medlemmar, men inte på samma skala som detta projekt innebar, med all funktionalitet och dokumentation som krävdes. Med detta projekt är det även första gången som gruppmedlemmarna arbetat mot en riktig kund som är beroende av att produkten som tas fram i projektet uppnår en god kvalitet. Projektgruppen försökte öka möjligheterna till att uppfylla kundens behov och krav genom att ha en kontinuerlig kommunikation med kunden under projektets gång. Gruppen insåg att regelbundna möten skulle leda till att kundens förväntningar kontinuerligt skulle närma sig det som projektgruppen ansett varit genomförbart. Detta skulle i sin tur minska risken för oförutsedda ändringar som potentiellt sett annars skulle kunna medföra en stor och kostsam påverkan för projektet.

En annan viktig erfarenhet är också vikten av att vara tydlig med kunden om vad grup-pen anser vara rimligt att uppnå inom de timmar som är avsedda för ett projekt. Det är annars lätt hänt att gruppen får alldeles för många förväntningar från kunden som inte kom-mer hinnas med. Till exempel har det hänt att kunden trodde att gruppen ville ha kontakt med en extern part, på grund av att den kundansvarige inte gav ett tydligt ja eller nej på denna förfrågan.

5.3.2

Scrum

Varje gruppmedlem hade läst en kurs i programutvecklingsmetodik. Konceptet Scrum var därför inget nytt. Däremot hade ingen i gruppen tidigare erfarenhet av att faktiskt använda sig av metoden. Gruppen valde att ha korta dagliga möten på morgonen vilket var en bra erfarenhet då gruppmedlemmarna tillsammans lyckades skapa en daglig rutin i distanslä-get. På mötena redovisade gruppmedlemmarna planen för den resterande dagen och för vad individen gjorde föregående dag och ifall något problem uppstått. Många av gruppmedlem-marna fick en känsla av att de blev tvungna till att faktiskt göra det man avsatt sig att göra till följd av dessa möten. Detta tyckte projektgruppen var en mycket positiv effekt av arbets-metoden.

5.3.3

Dokumentation och versionshantering

Dokument tyckte projektgruppen underlättade arbetet med produkten. Majoriteten av do-kumenten har skrivits i Google Docs vilket fungerat mestadels bra. Det som fungerat mindre bra i Google Docs har varit hantering av referenser. Kandidatrapporten skrevs i LA_{TEX vilket} har varit en ny positiv upplevelse för många i gruppen och som kommer att fortsättas att användas av gruppmedlemmar i framtiden.

förståelse gällande testning och varför olika nivåer av testning behövs för att säkerställa olika typer av krav hos produkten.

5.3.5

AWS

I projektet har ekosystemet AWS använts i stor utsträckning. Det har krävt en stor mängd efterforskning i hur det systemet fungerar för att kunna implementera projektets alla delar. Det har varit viktigt för varje gruppmedlem att ha en god förståelse för hur AWS fungerar ef-tersom den mjukvara som gruppen utvecklat ska kunna fungera tillsammans med de tjänster som AWS erbjuder. Inför framtiden har gruppmedlemmarna inget emot att arbeta med AWS igen, men gruppmedlemmarna provar gärna på nya system om tillfälle ges.

5.4

Översikt över individuella bidrag

Detta avsnitt ger en kort introduktion till de individuella bidrag som skrivits av projektmed-lemmarna.

5.4.1

Blockkedje-teknologi inom avfallshantering

Blockkedje-teknologi är mestadels känd för sin tillämpning inom kryptovalutor, men det finns även andra tillämpningsområden för blockkedje-teknologi. Hur blockkedje-teknologi kan användas inom datalagring och avfallshantering samt vad det har för effekt på datalag-ringens säkerhet undersöks i det individuella bidraget i bilaga A av Henrik Larsson Edström.

5.4.2

Datormoln, distansutbildning och den digitala klyftan

Projektet Trace the Waste genomfördes helt på distans och under det senaste året har flera län-der i världen behövt anpassa sin utbildning på grund av coronapandemin. Skolor, lärare och elever har behövt ställa om till en utbildning som sker på distans. Vilken roll har datormoln spelat för distansutbildning? Vilken roll för den digitala klyftan spelar distansutbildning? Detta är något som undersöks i det individuella bidraget i bilaga B av Moltas Enåkander.

5.4.3

Kvinnliga civilingenjörsstudenters upplevelser i projektteam

Många projektteam på datautbildningar på Linköpings universitet består av få kvinnor och dessa projekt är en viktigt del av utbildningen. En av de här projekten är projektet som rap-porten baseras på. Vilka upplevelser har kvinnor i dessa projektteam och hur påverkar detta samarbetet i projektteamet? Detta kommer att undersökas i bilaga C av Mirna Ghazzawi.