Linköpings universitet SE–581 83 Linköping
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik
2016 | LIU-IDA/LITH-EX-G--16/049--SE
Ett system för att detektera
kundbeteende i
självplocks-lager: As Long As It Scales
A system for detecting customer behaviour in open product
stocks: As Long As It Scales
Andreas Enström
Joakim Ericsson
John Eriksson
Josef Fagerström
Olle Nilsson
Per Olin
Michael Sörsäter
Hampus Viken
Handledare : Anton Sundblad Examinator : Kristian Sandahl
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c Andreas Enström Joakim Ericsson John Eriksson Josef Fagerström Olle Nilsson Per Olin Michael Sörsäter Hampus Viken
PROJEKTIDENTITET
Grupp PUM-4, VT2016 Linköpings tekniska högskolaNamn Roll E-post
Andreas Enström Arkitekt andreas.enstrom@live.se Joakim Ericsson Utvecklingsledare joakim.s.ericsson@gmail.com John Eriksson Dokumentansvarig johneriksson94@gmail.com Josef Fagerström Konfigurationsansvarig josef.g.fagerstrom@gmail.com Olle Nilsson Kvalitetssamordnare nilssonn94@gmail.com
Per Olin Testledare perolin94@gmail.com
Michael Sörsäter Teamledare michael.sorsater@gmail.com Hampus Viken Analysansvarig hampus.viken@gmail.com
Kund:Valtech
Kontaktperson:Erik Kurin, 070 - 165 35 04, erik.kurin@valtech.se
Kursansvarig:Kristian Sandahl, 013 - 28 19 57, kristian.sandahl@liu.se
Sammanfattning
Denna rapport beskriver systemet ALAIS (As Long As It Scales) och hur det har utvecklats. ALAIS byggdes i samband med ett kandidatarbete i programvaru-utveckling vid Linköpings universitet åt företaget Valtech. Syftet med systemet är att demonstrera att det går att utföra automatiserad A/B-testning genom att placera skålar med godis på olika vågar och se hur positionen, samt eventuella märkningar, som ekologisk, påverkar konsumtionen. Det färdiga systemet är up-pdelat i tre moduler, en som sköter kommunikationen med vågarna, en som utför beräkningar och kommunicerar med en databas, och en som består av ett grafiskt gränssnitt som användaren interagerar med. De tre modulerna kommunicerar med varandra över ett nätverk. Rapporten avslutas med individuella erfarenheter från alla gruppmedlemmar.
Innehållsförteckning
Sammanfattning iv Innehållsförteckning v Figurförteckning viii Tabellförteckning 1 1 Inledning 2 1.1 Syfte . . . 2 1.2 Frågeställning . . . 2 1.3 Beställare . . . 3 1.4 Begrepp . . . 4 1.5 Avgränsningar . . . 4 2 Bakgrund 5 3 Teori 6 3.1 Websocket . . . 6 3.2 Node.js . . . 6 3.3 Trello . . . 7 3.4 Slack . . . 7 3.5 SEMAT . . . 7 3.6 A/B-testning . . . 7 3.7 Black-box testing . . . 7 3.8 White-box testing . . . 7 4 Metod 8 4.1 Utbildning . . . 9 4.2 Utveckling . . . 9 4.3 Testning . . . 10 5 Resultat 11 5.1 Systembeskrivning . . . 11 5.2 Erfarenheter . . . 155.3 SEMAT Kernel ALPHA:s . . . 17
6 Diskussion 18 7 Slutsatser 20 A Projektets arkitektur av Andreas Enström 22 A.1 Inledning . . . 22
A.3 Frågeställning . . . 22 A.4 Avgränsningar . . . 22 A.5 Bakgrund . . . 23 A.6 Teori . . . 23 A.7 Metod . . . 23 A.8 Resultat . . . 24 A.9 Diskussion . . . 25 A.10 Slutsatser . . . 25
B Arbetsfördelning, organisation och enhetlig mjukvara av Joakim Ericsson 27 B.1 Inledning . . . 27 B.2 Syfte . . . 27 B.3 Frågeställning . . . 28 B.4 Bakgrund . . . 28 B.5 Teori . . . 28 B.6 Metod . . . 28 B.7 Resultat . . . 29 B.8 Diskussion . . . 29 B.9 Slutsatser . . . 30
C Samarbete vid dokumentskrivning i projekt och rollen som dokumentansvarig av John Eriksson 31 C.1 Inledning . . . 31 C.2 Syfte . . . 31 C.3 Frågeställning . . . 31 C.4 Bakgrund . . . 32 C.5 Teori . . . 32 C.6 Metod . . . 32 C.7 Resultat . . . 33 C.8 Diskussion . . . 33 C.9 Slutsatser . . . 35
D Värdet av standardiserad versionshantering och rollen konfigurationsansvarig av Josef Fagerström 36 D.1 Inledning . . . 36 D.2 Syfte . . . 36 D.3 Frågeställning . . . 36 D.4 Bakgrund . . . 37 D.5 Teori . . . 37 D.6 Metod . . . 38 D.7 Resultat . . . 38 D.8 Diskussion . . . 39 D.9 Slutsatser . . . 40
E Metoder och verktyg för ett högkvalitativt mjukvaruprojekt av Olle Nilsson 41 E.1 Inledning . . . 41 E.2 Syfte . . . 41 E.3 Frågeställning . . . 41 E.4 Bakgrund . . . 42 E.5 Teori . . . 42 E.6 Metod . . . 42 E.7 Resultat . . . 43 E.8 Diskussion . . . 44
E.9 Slutsatser . . . 44
F Testning i ett mjukvaruprojekt och dess påverkan av Per Olin 46 F.1 Inledning . . . 46 F.2 Syfte . . . 46 F.3 Frågeställning . . . 46 F.4 Bakgrund . . . 46 F.5 Teori . . . 47 F.6 Metod . . . 47 F.7 Resultat . . . 48 F.8 Diskussion . . . 48 F.9 Slutsatser . . . 49
G Teamledarens roll och verktyg inom projektledning av Michael Sörsäter 50 G.1 Inledning . . . 50 G.2 Syfte . . . 50 G.3 Frågeställning . . . 50 G.4 Bakgrund . . . 51 G.5 Teori . . . 51 G.6 Metod . . . 52 G.7 Resultat . . . 52 G.8 Diskussion . . . 52 G.9 Slutsatser . . . 53
H Rollen som analysansvarig och hur denne utför god kravhantering samt kund-kontakt av Hampus Viken 54 H.1 Inledning . . . 54 H.2 Syfte . . . 54 H.3 Frågeställning . . . 54 H.4 Bakgrund . . . 55 H.5 Teori . . . 55 H.6 Metod . . . 56 H.7 Resultat . . . 57 H.8 Diskussion . . . 58 H.9 Slutsatser . . . 58 Referenser 59
Figurförteckning
5.1 Översiktlig struktur . . . 11 5.2 Sensorenhet . . . 12 5.3 Backend . . . 13 5.4 Startsida . . . 14 5.5 Redigeringsflik . . . 15 C.1 Frontend . . . 35Tabellförteckning
1
Inledning
Den här rapporten behandlar utvecklingen av systemet ALAIS (As Long As It Scales), som är ett verktyg för att genomföra tester på hur placering och märkning av produkter påverkar deras åtgång. För att göra detta använder systemet ett antal vågar. Dessa kopplas mot en databas som bearbetar deras mätdata. Mätdatan presenteras sedan grafiskt på en interaktiv hemsidan. Den färdiga produkten ska användas i en mässmonter av företaget Valtech.
1.1
Syfte
Detta dokument har till syfte att sammanställa de erfarenheter som gruppen har skaffat sig under projektets gång. Syftet med systemet som utvecklades är att bistå som ett “proof of concept” för ett system som kan utföra automatiserade A/B-tester på produktmärkning och placering.
1.2
Frågeställning
• Kan systemet byggas och ge värde till kund?
Med värde menas här att kunden ska kunna vidareutveckla systemet samt att de kan använda det för sitt avsedda syfte.
• Hur ska systemet struktureras för att det ska vara modulärt?
Med modulärt menas här att systemets moduler ska ha väldefinierade kommunika-tionsgränssnitt och vara oberoende av varandra så att de är lätta att byta ut och köra på olika hårdvaruenheter.
• Hur ska systemet utformas för att det ska verka i realtid?
Med realtid menas här att systemet ger återkoppling till användaren kontinuerligt och tillräckligt snabbt för att upplevas som responsivt. Det finns alltså en tidsmässig gräns i värsta fallet.
• Vilka erfarenheter kan dokumenteras från projektet som kan vara intressanta för
1.3. Beställare
• Vilket stöd kan man få genom att använda och följa upp SEMAT Kernel ALPHA:s?
1.3
Beställare
Beställare av systemet är det privata företaget Valtech som är ett konsultbolag med kontor i Stockholm. De jobbar inom IT och e-handel.
1.4. Begrepp
1.4
Begrepp
• Frontend: Det grafiska gränssnittet och tillhörande script. • Backend: En central serverenhet som styr dataflödet mellan
Sensorenheten, databasen och Frontend.
• Sensorenhet: Samlingsnamn för vågarna och det gränssnitt de använder för att kom-municera med Backend.
• Exekveringsmiljö: (Eng. Runtime Environment) Ett system som specificerar hur in-struktionerna i ett program exekveras.
• NUC: (Next Unit of Computing) Liten persondator tillverkad av Intel. • RTC: Real-time communication. Realtidskommunikation.
• Proof of concept: En prototyp vars syfte är att visa att en viss idé kan förverkligas.
1.5
Avgränsningar
Projektet avgränsas av att gruppens medlemmar måste lägga ner 400 ˘ 40 timmar arbetstid vardera.
2
Bakgrund
Projektet är ett kandidatarbete utfört av åtta personer. Initiativtagare och beställare av pro-jektet är företaget Valtech som arbetar inom e-handel. En fördel med e-butiker är att det finns tillgång till realtidsinformation om kundernas handlingsbeteende. Valtech är intresserade av hur detta kan appliceras på handel i fysiska butiker. Det är ett outforskat område så det finns därför inte någon etablerad marknad att jämföra produkten mot.
Vid början av kursen ställde gruppen upp en lista med de fem mest intressanta projekten. På denna lista var detta projekt först. Vi i gruppen tyckte det verkade spännande på grund av dess innovativa och experimentella natur. Dessutom var en bidragande faktor att ett system skulle byggas från grunden.
Alla i projektgruppen har tidigare under utbildningen arbetat i liknande projekt. Detta är dock det hittills största i omfattning. Nytt i det här projektet var även att det som produceras ska levereras till en extern kund utanför universitetet. Vad gäller de programmeringsspråk och tekniker som använts för att utveckla systemet hade gruppen varierande erfarenheter sedan tidigare. På grund av det har utbildning varit nödvändig genom hela projektet, i syn-nerhet under dess tidiga skede.
3
Teori
I det här avsnittet förklaras den teori som behövs för att förstå resten av rapporten.
3.1
Websocket
En av de viktigaste faktorerna att ta hänsyn till när man ska bygga ett realtidssystem med webbkommunikation är nätverksprestandan. I synnerhet responstid är viktigt, eftersom en för lång sådan gör att systemet inte längre verkar i realtid. Ett sätt att minska responstiden är att minimera mängden data som skickas mellan server och klient. Ett sätt att uppnå detta är att använda protokollet Websocket, istället för det mer konventionella protokollet HTTP. Websocket är precis som HTTP baserat på protokollet TCP, med den stora skillnaden att Web-socket inte behöver lika mycket extra information som HTTP för att skicka datan. En annan stor skillnad mellan Websocket och HTTP är att Websocket inte är “request”-baserat, vilket betyder att en klient inte behöver be servern om data. Istället räcker det med att en klient har anslutit för att den ska få all data som servern skickar ut. [1]
3.2
Node.js
Det finns ett flertal alternativ vad gäller programmeringsspråk för webbservrar. Om man inte är intresserad av att optimera beräkningar på servern och gärna ser att koden är lättskriven, så är skriptspråk ett bra alternativ. Några av de mest populära skriptspråken för webbpro-grammering är PHP, Python Web och JavaScript. Av dessa språk har JavaScript med ex-ekveringsmiljön Node.js bäst prestanda vid nätverkskommunikation, överlägset bättre än både Python och PHP, vilket gör att det är det språk som lämpar sig bäst för realtidskommu-nikation. [2]
Node.js är en exekveringsmiljö skriven i JavaScript som är utvecklad för att användas vid skapandet av skalbara internetapplikationer. Den är asynkron och eventdriven vilket gör den effektiv. [3]
3.3. Trello
3.3
Trello
Trello är ett webb-baserat verktyg som hjälper sina användare att skapa och organisera Kan-ban Boards. Ett Trello Board är uppbyggt av listor som innehåller aktiviteter. Aktiviteterna kan sedan i sig innehålla listor med vad som ska göras på varje aktivitet. [4]
3.4
Slack
Slack är det verktyg som vi har använt mest för kommunikation inom gruppen och med kunden under projektets gång. Slack finns både som webbverktyg och som app till mobilen. I Slack skapar man antingen öppna kanaler för hela teamet eller privata, dit man bjuder in de som ska vara behöriga att se vad som skrivs i kanalen. Det finns också flera verktyg till Slack som man kan installera för att utöka funktionaliteten. Vi har använt verktyg som har tillåtit oss att skapa påminnelser och få notiser när ändringar har skett i vårt Git repository. [5]
3.5
SEMAT
SEMAT (Software Engineering Method And Theory) är ett initiativ till att omforma progra-mutveckling till en rigorös process. Vi har använt oss av ett verktyg som innefattas av SE-MAT kallat “ALPHA State Cards” (Abstract-Level Progress Health Attribute) under projek-tets gång. Varje ALPHA tillhör ett delområde som finns i ett mjukvaruprojekt och represen-terar ett steg som ska uppfyllas i det delområdet. De är till för att hålla koll på projektets status och för att hjälpa gruppen planera vad som ska göras i vilken iteration av projektet. [6]
3.6
A/B-testning
A/B-testning är en metod för att undersöka vilket av två eller fler alternativ som är det bästa. Det går ut på att låta testpersoner utsättas för snarlika situationer där endast den del som ska testas skiljer situationerna åt. För att resultatet inte ska bli felaktigt är det viktigt att personerna som alternativen testas på inte vet om att de utsätts för ett test. [7]
3.7
Black-box testing
“Black-box testing” är en metod för att undersöka sambandet mellan indata och utdata utan att bry sig om de interna mekanismerna.
3.8
White-box testing
“White-box testing” är en metod för att undersöka systemets interna funktionalitet. Genom att se till att varje funktion, uttryck och villkor har testats för alla möjliga utkomster kan man eliminera buggar och kod som inte behövs.
4
Metod
För att strukturera projektarbetet har ett antal agila metoder använts. Arbetstiden har delats upp i fyra stycken cirka tre veckor långa iterationer. För varje iteration har ett antal mål definierats med hjälp av SEMAT ALPHA State Cards. Dessa ALPHA:s representerar ett antal generella milstolpar för mjukvaruprojekt. Genom att planera vilka av dessa milstolpar som ska vara klara i vilken iteration, får man en översiktlig plan över hur projektet bör fortskrida. [8]
Under projektets gång har vi samlat in ett stort antal erfarenheter, främst genom att diskutera problem och frågor som dykt upp. Under arbetets gång är det viktigt att försöka identifiera erfarenheter, både för att lättare kunna ta till sig dem, men även för att kunna dokumentera dem. Erfarenheter är viktiga både för individen men är även en viktig resurs för hela projek-tgruppen.
Under den första iterationen, även kallad förstudien, skissades en övergripande projekt-planering upp med hjälp av ALPHA State Cards. Under förstudien skrevs även en kravspeci-fikation, en kvalitetsplan och en projektplan. Det finns tre anledningar till detta. För det första att gruppen och beställaren ska vara överens om vilka krav som ställs på produkten. För det andra att gruppen är överens om vilka metoder och standarder som ska följas för att säker-ställa produktens kvalitet. För det tredje att det ska finnas en tydligt definierad plan för vilka steg som finns och när de ska vara klara.
Under förstudien tilldelades även roller till alla projektmedlemmar. De roller som de-lades ut var teamledare, dokumentansvarig, analysansvarig, kvalitetssamordnare, konfigu-rationsansvarig, utvecklingsledare, testansvarig och arkitekt. Varje roll ansvarar för ett antal aspekter av projektarbetet. Det innebär att man i största möjliga mån ska förbereda och leda det arbete som rör dessa aspekter. För flera roller inkluderar detta att man har det yttersta ansvaret för ett eller flera dokument. Exempelvis ansvarar testansvarige för testplanen. De övriga tre iterationerna var utvecklingsiterationer och refereras till som iteration ett, två och tre. I iteration ett utvecklades den första prototypen och demonstrerades för kunden trots att den inte uppfyllde alla krav. I iteration två vidareutvecklades prototypen från iteration ett med målet att den skulle uppfylla högprioritetskrav och vara en nästan fungerande produkt.
4.1. Utbildning
I iteration tre vidareutvecklades prototypen från iteration två till den grad att kunden kan an-vända produkten för sitt syfte. Arbetet i iteration ett och två bestod mest av implementation av nya funktioner. I iteration tre bestod arbetet mestadels av att fixa buggar och till viss del av att förbättra redan existerande funktioner.
4.1
Utbildning
All utbildning under projektets gång har skett internt i gruppen. Vi har inte haft några formella undervisningstillfällen. Utbildningen har istället skett kontinuerligt under projek-tets gång, till stor del genom egenutbildning med hjälp av internet. I de fall som en mindre fråga har kunnat besvaras av någon annan gruppmedlem har gruppmedlemmar som behövt hjälp frågat medlemmar som varit mer kunniga inom det området. Detta har varit möjligt tack vare att stora delar av gruppen har arbetat på samma plats samtidigt.
4.2
Utveckling
Majoriteten av koden är skriven i JavaScript i exekveringsmiljön Node.js. Det största un-dantaget är databasen som är definierad i språket SQL med databashanteraren MySQL. Vi hade ett flertal faktorer i åtanke när vi skulle välja programmeringsspråk, huvudsakligen beräknings- och nätverksprestanda eftersom tanken är att systemet ska verka i realtid. Efter en kort utredning beslutade vi dock att den mängd data som behandlas av Backend sannolikt inte är tillräckligt stor för att beräkningsprestandan ska vara ett problem. Fokus lades då på de olika skriptspråk som finns för webbprogrammering. I synnerhet jämfördes Python med ramverket Flask, PHP och JavaScript med Node.js. Av dessa visade sig JavaScript i Node.js vara bäst lämpat för realtidskommunikation över internet. Möjligheten att i och med detta val kunna skriva i stort sett hela kodbasen i samma språk var den avgörande faktorn som till slut ledde till att vi valde JavaScript. Valet att använda JavaScript med Node.js gjorde det möjligt för oss att använda biblioteket socket.io för realtidskommunikation. Detta är förde-laktigt då socket.io använder protokollet Websocket för nätverkskommunikation, istället för HTTP. Websocket lämpar sig bättre för realtidskommunikation än HTTP, eftersom att HTTP kräver att klienten ska efterfråga ny data.
För att varje gruppmedlem skulle kunna arbeta så effektivt som möjligt valde vi att inte knyta oss till någon specifik utvecklingsmiljö. Det har varit helt upp till var och en att välja vad man föredrar. För att ändå hålla en enhetlig stil på koden har verktyget ESLint använts. ESLint konfigureras enligt en förutbestämd standard och rapporterar sedan om kod som inte följer standarden. Vissa i gruppen valde att köra sin kod genom ESLint manuellt, andra valde att låta ESLint kontinuerligt övervaka det de skrev. Den standard vi har använt under projektet är framtagen av företaget Airbnb. [9]
Under projektet använde vi oss av versionshanteringssystemet Git tillsammans med GitHub, som är en tjänst som tillhandahåller gratis lagring av de versionshanterade filerna. Det gjorde att alla i projektgruppen kunde komma åt koden när som helst. GitHub har även ett system för att hantera “issues” som vi använde i viss utsträckning för att rapportera buggar. När en gruppmedlemm upptäckte en bug som av någon anledning inte kunde eller behövde fixas omgående, skapades en issue på GitHub. En issue är i grund och botten bara en kommentar som beskriver ett problem. Andra personer som har tillgång till koden på GitHub kan sedan svara på kommentaren eller markera problemet som löst, i vilket fall issue:n i fråga markeras som avklarad.
Den dokumentation som tagits fram under projektet använder typsättnings-systemet LaTeX. Med hjälp av en mall har alla dokument fått ett enhetligt utseende. Även dokumenten har versionshanterats med Git.
4.3. Testning
För att strukturera utvecklingsarbetet har vi använt oss av Kanban. Kärnan i Kanban är ett så kallat “Kanban Board”. Ett Kanban Board består av tre kolumner, benämnda “To do”, “Do-ing” och “Done”. När en funktion som vi ville ha i slutprodukten identifierades, lades den till under “To do”. När någon började arbeta med en funktion lades den personens signatur till funktionen och samtidigt flyttades den från “To do” till “Doing”. När den sedan blev klar flyttades den till “Done”. Detta bidrog till att parallellisera och organisera arbetet så att alla visste vem som jobbade med vad. Tjänsten Trello har använts för att skapa Kanban Boards för de tre iterationerna. Trello har utöver den grundläggande Kanban-funktionaliteten stöd för att till exempel kommentera och färgmärka kort.
De två Google-tjänsterna Drive och Calendar har använts för att lagra filer respektive schemalägga möten. I Google Drive finns det också möjlighet att skapa textdokument och kalkylark som vi utnyttjat för att bland annat kartlägga nerlagd tid för varje gruppmedlem. För att kunna kommunicera med varandra inom gruppen när vi inte befunnit oss på samma plats, har chattjänsten Slack använts. Slack använder sig av ett kanalsystem för uppdelning av ämnen. Detta har gett oss möjlighet att även använda Slack för enklare kommunikation med kunden.
Skype har använts för mer utförliga avstämningar med kunden. Med hjälp av både mikrofon och webbkamera har vi även kunnat utföra mindre demonstrationer av systemet utan att behöva vara på plats hos kunden.
4.3
Testning
Systemets olika enheter har testats separat genom enhetstester och ihop med varandra i sys-temtester. Vid projektets början planerade vi även att genomföra integrationstester, men detta gjordes aldrig då de olika modulerna färdigställdes så snabbt att systemtester kunde påbörjas nästan direkt. Syftet med testerna är att se om systemet uppfyller de krav som är beskrivna i kravspecifikationen. Målet med dessa krav är att få ett stabilt och säkert system. Nedan beskrivs de testprocesser som planerades att användas i början av projektet.
Enhetstester är tester som sker på varje enhet i systemet för att se till att de fungerar innan de integreras med andra enheter. Enhetstester körs i den mån det är möjligt på alla komponenter som bygger upp systemet. Processen som användes kallas White-box testing. Processen går ut på att testa allt det interna i en enhet genom att se till att alla olika logiska val som kan göras i enheten testas. Om full “branch coverage” uppnås, det vill säga att alla logiska vägval testas, har man verifierat att koden beter sig som förväntat.
Integrationstester genomförs efter alla enhetstester är klara för de enheter som ska integreras. Integrationstesterna sker efter enhetstesterna för att kunna utesluta att felet ligger i någon av delmodulernas enskilda funktioner. Slutar systemet fungera som förväntat efter integration så är det därmed lättare att lokalisera felet. Processen som var tänkt att användas kallas Top-down integration testing. Den går ut på att skapa testdata, så kallade stubs som skickas in i de enheter som ska integreras. En stub finns till för att simulera den data som enheten ska kunna hantera och därför borde enheten kunna integreras om den hanterar alla stubs som den ska.
Systemtester sker efter att alla delar av systemet har genomgått integrationstesterna och in-tegrerats till ett system. För att genomföra systemtesterna användes Black-box testing.
5
Resultat
Resultatet av vårt projekt är ett system som uppfyller de krav som specificerades i kravspeci-fikationen. Nedan följer hur det färdiga systemet är konstruerat och våra erfarenheter av projektet.
5.1
Systembeskrivning
Det kompletta systemet består av tre huvudsakliga moduler som vi har kallat för Sensoren-het, Backend och Frontend. Figur 5.1 visar en översiktlig beskrivning av modulernas struk-tur och kommunikationstopologi. Mer detaljerade beskrivningar av de enskilda modulerna återfinns under motsvarande rubrik.
Figur 5.1: Översiktlig struktur
Frontend och Backend kommunicerar över nätverk med protokollen HTTP och Websocket, beroende på vilken typ av data som skickas. Sensorenheten och Backend kommunicerar via Websocket. I vår implementation körs Backend och Sensorenheten på samma hårdvara, vilket resulterar i att endast lokal nätverkskommunikation sker mellan dessa moduler.
5.1. Systembeskrivning
Sensorenhet
Sensorenheten består av vågarna och gränssnittet till Backend. Sensorenheten läser kontin-uerligt data från vågarna, ansvarar för att kommunikationen är stabil och att mätvärdena processeras innan datan skickas vidare.
Vågarna kommunicerar med en dator via serieport eller USB, beroende på vågtyp. Sensorenheten består av en superprocess och flera subprocesser, en för varje ansluten våg, se Figur 5.2.
Figur 5.2: Sensorenhet
Superprocessens uppgift att upptäcka när en ny våg som är kompatibel med systemet ansluts och då skapa en subprocess för den. För att upptäcka anslutna vågar används moduler som är skrivna specifikt för de olika vågtyperna. Superprocessen söker regelbundet efter nya vågar. För att undvika att samma våg upptäcks flera gånger under tiden den är ansluten har superprocessen en lista med information om anslutna vågar. Superprocessen innehåller även en lista över vågar som tidigare har varit anslutna. Det gör det möjligt att upptäcka när en våg återansluts och då tilldela den samma ID som den tidigare haft.
Subprocesserna används för att läsa av vågarna och skicka avläst data vidare till Backend. När en subprocess startas använder den sig av det första argumentet till processen för att instansiera en ny vågmodul. Argumentet är ett objekt i JSON-format som innehåller infor-mation om vilken vågtyp som anslutits och data som identifierar den specifika vågen. Med informationen skapas en anslutning till vågen. Om anslutningen till vågen lyckas loggar processen in med användarnamn och lösenord genom ett REST-anrop till Backend. Vid ly-ckad inloggning returneras en “token” som används för autentisering när vågdata skickas till Backend.
För att skicka vågdata skapas en Websocket-anslutning till Backend genom vilken ett sensor-ID tas emot. Detta sensor-ID skickas till superprocessen som sparar det tillsammans med informa-tionen om den anslutna vågen. När hela kedjan av anslutningar från våg till Backend är upprättad blir vågmodul-instansen instruerad att börja reagera på viktförändringar. Vågen
5.1. Systembeskrivning
avläses kontinuerligt och datan avkodas till ett viktvärde i gram. Eftersom vikten på en våg i perioder kan förbli oförändrad skickas bara vikten om en viktförändring har skett.
Backend
Backend är den centrala modulen i systemet som kopplar ihop och kommunicerar med alla andra delar av systemet. Denna modul hanterar all logik och bearbetning av data som den tar emot från Sensorenheten och skickar vidare till Frontend. Den hanterar även all kommunika-tion med databasen, vilken den kommunicerar med genom ett API. Backend är uppdelad i fyra subprocesser, en superprocess som startar dessa, samt en databas med vilken alla sub-processer förutom en kommunicerar med. De fyra subsub-processerna kommunicerar internt med varandra genom superprocessen. Backends kommunikationstopologi beskrivs i Figur 5.3.
Figur 5.3: Backend
Backend kommunicerar med övriga moduler på två olika sätt; via HTTP och via Websocket. Backend innehåller två HTTP-servrar som körs på olika portar och har olika syften. Den ena, i Figur 5.3 benämnd “Static”, får man kontakt med först när man ansluter till Backend. Från denna skickas ett antal statiska filer som innehåller kod för att visa hemsidan och för att skapa kontakt med resten av Backend. Den andra HTTP-servern hanterar alla icke tidskri-tiska anrop från Frontend och Sensorenheten via ett REST API. Dessa anrop inkluderar all kommunikation där ingen mätdata skickas, till exempel inloggning.
Websocket används för realtidskommunikation mellan modulerna. Denna kommunikation sker genom två olika gränssnitt benämnda “Sensor RTC” och “Frontend RTC” i Figur 5.3. Sensor RTC hanterar kommunikationen mellan Sensorenheten och Backend genom att ta emot data från Sensorenheten och spara den i databasen. Frontend RTC hanterar kommu-nikationen mellan Backend och Frontend genom att hämta data från databasen och skicka den till Frontend. Fördelen med denna uppdelning är att den del som skriver till databasen separeras från den del som läser från databasen, vilket ökar säkerheten i systemet. Uppdel-ningen gäller dock inte till hundra procent då vårt system kräver att man kan manipulera vissa aspekter av databasen från Frontend.
5.1. Systembeskrivning
Databasen är definierad i SQL med hjälp av databashanteraren MySQL. SQL-databaser är uppdelade i ett antal så kallade relationer, lättast visualiserade som tabeller, i vilka all data sparas. Utöver detta kan man definiera procedurer och funktioner som utför operationer på relationerna och, i funktionernas fall, returnerar värden. ALAIS databas består av nio relationer, i vilka information om produkter, vågar, tester och mätvärden sparas. Utöver detta finns ett antal procedurer för att hämta, lägga till, ta bort och uppdatera data.
Frontend
Frontend är en hemsida som presenterar mätdata grafiskt. På Frontend kan användaren välja hur datan ska visualiseras med hjälp av olika diagram. Figur 5.4 visar hur det ser ut när en användare går in på hemsidan.
Figur 5.4: Startsida
Om användaren är inloggad som administratör kan användaren även redigera vad det står att skålarna innehåller och dess färger i graferna, genom att gå in på fliken “redigera”. Hur detta ser ut kan betraktas i Figur 5.5.
5.2. Erfarenheter
Figur 5.5: Redigeringsflik
Frontend är byggt i Bootstrap som är ett open-source ramverk för att bygga hemsidor i HTML, CSS och JavaScript. Bootstrap är kompatibelt med de senaste versionerna av web-bläsarna Google Chrome, Firefox, Internet Explorer, Opera och Safari. Bootstrap stödjer också responsiv webbutveckling, vilket innebär att hemsidor byggda i Bootstrap anpassar sig till olika skärmstorlekar. Bootstrap har tillåtit oss att bygga upp hemsidan med hjälp av flikar, vilket innebär att hela hemsidan laddas in med detsamma och byte mellan de olika sidorna går snabbt.
För att ytterligare utöka funktionaliteten använder sig Frontend av diverse bibliotek. De vik-tigaste av dessa är Data Driven Diagrams (D3), Bootstrap-table och Bootstrap-colorpicker. D3 används för att skapa interaktiva och dynamiska diagram och grafer. Bootstrap-table.js an-vänds för att skapa tabeller med funktionalitet utöver den som Bootstrap erbjuder. Bootstrap-colorpicker.js används för att skapa en klassisk färgväljare som används för att ändra färgen som hör ihop med varje produkt.
5.2
Erfarenheter
Denna sektion beskriver de erfarenheter som gruppen som helhet har samlat på sig under projektets gång. Specifikt kommer de erfarenheter tas upp som rör produktens utveckling från en teknisk synpunkt, samt de som rör den arbets- och utvecklingsmetodik som tilläm-pats under projektets gång.
5.2. Erfarenheter
Tekniska erfarenhter
I början av projektet valde vi att använda biblioteket Chart.js för att implementera grafer. Senare under projektet visade det sig att Chart.js inte hade något bra stöd för realtidsdata, vilket var något som vi behövde för systemet. Därför valde vi att vid iteration två byta från Chart.js till D3.js, som är ett JavaScript-bibliotek som har bra stöd för realtidsvisualisering. Ändringen tog i slutändan ungefär en vecka att utföra och med facit i hand skulle man ha tänkt igenom biblioteksvalet innan kodningen började.
I projektets början behövde vi hitta lämplig hårdvara. Detta tog mycket tid, då det tog lång tid att läsa igenom datablad och hitta en våg med rätt egenskaper i avseende på kommunikation, vikt, precision och kapacitet. Vi köpte totalt in fyra olika vågar för att hitta den mest lämpade vågen för projektet. De vågarna vi köpte in och jämförde var en KERN PCB-6001, en KERN PCB 6000, en DYMO M5 och en OHAUS traveler 5000. Det var bra att testa flera vågar för att se att systemet klarade av olika typer av gränssnitt, upptäcka egenskaper hos vågarna som inte är önskvärda för projektet och till sist för att testa om systemet kan hantera flera vågar. I slutändan valde vi vågen OHAUS traveler 5000, då den skickade data snabbast, vägde minst och var relativt liten och billig jämfört med de andra vågarna.
Redan från början av projektet bestämde vi oss för att använda socket.io för kommunikatio-nen mellan de olika modulerna. Vi valde att använda socket.io eftersom det gav ett intryck av att vara enkelt att använda och snabbt att komma igång med. Socket.io hade många bra kodexempel och annan hjälp på sin hemsida. Eftersom ingen i gruppen hade särskilt my-cket erfarenhet av liknande verktyg sedan tidigare så kändes det bra att använda. Det visade sig också senare i projektet att det var ett bra val eftersom arbetet med socket.io är mycket enkelt och man får mycket funktionalitet gratis, jämfört med om man till exempel skulle im-plementerat kommunikationen själv. Ett problem vi stött på med socket.io är att det ibland fungerar dåligt med Firefox, något som dock är planerat att fixas i kommande versioner av webbläsaren. [10] Det problemet har vi tagit oss runt genom att helt enkelt använda en annan webbläsare.
Metoderfarenheter
Under hela projektet har gruppen arbetat i ett projektrum tillhandahållet av Linköpings uni-versitet. Då NUC:en och vågarna har förvarats i detta rum och alla har haft tillgång till det, så har gruppen spenderat majoriteten av sin tid där. Detta har gjort att gruppen har arbe-tat nära varandra genom hela projektet, vilket har ökat sammanhållningen. Då frågor eller problem har uppstått har det alltid funnits någon ur gruppen nära till hands, vilket har ökat produktiviteten och kodens kvalitet.
Det har varit effektivt att använda verktyget Trello. Genom att dela upp arbetet i olika ak-tiviteter och tilldela dem till personer i gruppen har det både varit enkelt att fördela arbetet men även att få en översikt över arbetsflödet. Trello användes även som en Backlog, då nya krav/funktioner från kunden lades till som aktiviteter på Trello.
Under projektet har vi använt chattjänsten Slack. Fördelen med Slack är att man kan använda tillägg som kalender, påminnelser, meddelande från GitHub och liknande. Majoriteten av kommunikationen har skett via Slack och verktyget är väl lämpat för denna typ av projekt. Kundens kontaktpersoner har även de varit med i vissa av våra Slack-kanaler, vilket har underlättat kommunikationen då det är effektivare att chatta än att kommunicera via e-post. Att vår kund har haft sitt kontor i Stockholm har inte varit ett problem för kundkontakten, eftersom vi har använt oss av ett flertal kommunikationsverktyg som Slack, Skype och e-post.
5.3. SEMAT Kernel ALPHA:s
De gånger vi behövt demonstrera systemet eller träffas fysiskt har de ordnat biljetter för vår resa till och från Stockholm för att träffa dem.
Det har varit en utmaning att ta reda på vad kunden faktiskt vill ha. Efter vi valde projektet fick vi mer information från en PowerPoint-presentation som de skickade oss. Där fick vi en tydligare bild om vad de ville få ut av projektet och efter samtal med dem specificerades det ytterligare. När de hade godkänt vår kravspecifikation var det stor skillnad mot vad vi trodde från början.
5.3
SEMAT Kernel ALPHA:s
Under projektets gång har SEMAT Kernel ALPHA:s endast använts vid de obligatoriska sta-tusrapporterna samt för att lägga upp planeringen i början av projektet. Anledningen till detta är att ingen i gruppen känt något behov av att följa upp planeringen. Istället användes av gruppen definierade aktiviteter för att planera iterationerna.
6
Diskussion
Systemet som har utvecklats har ett värde för kunden eftersom det följer de krav som speci-ficerades i början av projektet. Det huvudsakliga värdet är den prototyp som utvecklats åt dem. Ytterligare har de fått ett värde i och med att de har fått en grund för att kunna utveckla liknande produkter i framtiden. Vissa restriktioner vid vidareutveckling av produkten finns dock, huvudsakligen i form av de val av bibliotek och ramverk som har gjorts. Några tekniker som används i produkten, som D3 och Websocket, kan komma att kräva mycket arbete om de ska bytas ut i framtiden.
För att göra systemet modulärt så har det delats upp i moduler som kommunicerar med varandra över ett nätverk. Detta leder till att modulerna kan placeras på olika ställen och köras på olika hårdvaruenheter. Även inom modulerna har utvecklingen skett med mod-uläritet i åtanke. Backend består till exempel av flera olika mikrotjänster som hanterar olika protokoll. Även dessa mikrotjänster skulle teoretiskt sett kunna delas upp och köras på olika hårdvaruenheter utan att det krävs större ändringar. Sensorenheten är strukturerad på ett så-dant sättatt det enkelt går att lägga till protokoll för nya vågar som ska anslutas till systemet. För att få systemet att verka i realtid gjordes ett antal teknikval. Det första valet var att an-vända Node.js som exekveringsmiljö. Vi valde JavaScript med Node.js eftersom det i förhål-lande till andra webbtekniker (exempelvis Python Web och PHP) presterar överlägset bättre i många sammanhang. Node.js är särskilt effektiv när väldigt många klienter ska hanteras. Det andra valet som gjordes var att använda socket.io med Websocket som kommunikationspro-tokoll till realtidskommunikationen. Detta gjorde kommunikationen både enkel och effektiv i jämförelse med att använda HTTP med REST-API. Det enda problemet med att använda Websocket är att Firefox ännu inte har fullt stöd för det, vilket resulterar i att data ibland inte kommer fram till mottagaren som det ska.
Genom att samla in data om kundens beteende kan många aspekter av handeln effektiviseras. Till exempel kan en butik tillhandahålla produkter som det är känt att kunderna uppskattar vilket leder till att färre varor måste slängas för att ingen köper den. Detta förutsätter dock att datan som samlats in om kundens beteende är korrekt. Skulle systemet som samlar in data om kunden fungera felaktigt förloras både pengar och resurser. Det är därför viktigt att ha
en stabilt och välfungerande system som man kan lita på. Att resurser används effektivt är bra för säljare, köpare, miljön och samhället i stort.
För att kunna förutsäga en kunds beteende behöver en hel del data samlas in och analyseras. Datainsamling är idag ett ganska kontroversiellt ämne och det är därför viktigt att spara data på ett säkert sätt. I vårt system är detta inget stort problem eftersom systemet endast sparar data om produkter, inte individer. Om systemet däremot utökas för att följa trender hos individer så behöver det struktureras om med striktiare säkerhetskrav i åtanke.
7
Slutsatser
Systemet ALAIS uppfyller de krav som kravspecifikationen specificerar. I relation till våra frågeställningar är våra slutsatser följande:
• Systemet går att bygga på ett sådant sätt att det ger värde till kund. Vi har byggt ett fungerande system som kunden kommer kunna använda och, om de väljer att göra det, vidareutveckla.
• Systemet har konstruerats i tre separata moduler som enbart kommunicerar med varan-dra via nätverk. Således är systemet modulärt i den meningen att modulerna är oberoende från varandra och att de kan köras på olika hårdvaruenheter. Ytterligare är gränssnitten mellan varje modul väldefinierade i separata mikrotänster vilket gör att modulerna med lätthet kan bytas ut så länge gränssnitten är kända.
• Genom ett antal teknikval har systemet utformats så att det verkar i realtid. Det är huvudsakligen exekveringsmiljön Node.js och protokollet Websocket som bidragit till detta.
• En mängd erfarenheter har samlats in under projektets gång. De viktigaste är följande:
– Det är viktigt att redan från början välja lämpliga mjukvarubibliotek, då det kan krävas en stor mängd arbete att byta när implementationen redan har börjat.
– Det kan krävas många försök innan man hittar hårdvara som passar.
– Ett projektrum är väldigt bra, både för produktiviteten och sammanhållningen i gruppen.
– Webbaserade verktyg som Trello, Slack och Skype kan med fördel användas för ar-betsfördelning, planering och kommunikation, både inom gruppen och med kun-den.
– Det är viktigt med en ordentlig kravspecificering innan produkten börjar imple-menteras.
Utöver de generella slutsatserna för projektet har varje gruppmedlem sammanställt en utred-ning om personliga erfarenheter från projektet. Sammanfattutred-ningar av utredutred-ningarna följer nedan:
A. Andreas Enström diskuterar och analyserar hur produktens arkitektur togs fram. B. Joakim Ericsson undersöker hur man utvecklar enhetlig mjukvara i ett projekt
bestående av flera personer, samt hur arbetet i ett projekt kan fördelas och organiseras. C. John Eriksson diskuterar hur dokumentskrivning kan parallelliseras samtidigt som en
enhetlig dokumentdesign uppnås.
D. Josef Fagerström diskuterar värdet av rollen konfigurationsansvarig samt lämpligheten hos de versionshanteringsverktyg och standarder som använts under detta projekt. E. Olle Nilsson utvärderar olika tekniker och metoder som kan användas för att
kvalitetssäkra ett projekt.
F. Per Olin diskuterar testledarens uppgift i ett projekt och de metoder som använts för att testa systemet.
G. Michael Sörsäter diskuterar vikten av att ha en teamledare och utvärderar arbetsme-toder som kan användas för att underlätta organiseringen av ett projekt.
H. Hampus Viken undersöker hur kravinsamling och kundkontakt sköts på ett bra sätt, samt hur rollen analysansvarig skiljer sig i praktiken mot teorin.
A
Projektets arkitektur av Andreas
Enström
Denna del av rapporten är skriven av Andreas Enström som haft rollen som arkitekt under projektets gång och går igenom hur arkitekturen för detta projekt togs fram.
A.1
Inledning
Min roll som arkitekt involverar analys av kravspecifikation och kundens nuvarande kom-petenser inom projektområdet. Som arkitekt måste man skaffa sig en överblick för att kunna identifiera komponenter och gränssnitt samt kunna kommunicera dessa idéer vidare. Detta för att ta fram en arkitektur som skapar värde för kunden men också är realiserbar, vilket är vad denna individuella del av rapporten kommer att behandla.
A.2
Syfte
I detta avsnitt ska det redogöras för hur en lämplig arkitektur togs fram för projektet från arkitektens perspektiv.
A.3
Frågeställning
Hur tar man fram en lämplig arkitektur för detta projekt? För att identifiera en lämplig arkitektur bör följande frågor besvaras.
• Hur kan arkitekturen skapa värde för kunden? • Hur kan arkitekturen underlätta utveckling?
A.4
Avgränsningar
En eller två personer ska kunna frakta slutprodukten till mässor där den ska kunna demon-streras, vilket innebär att den måste vara liten och lätt. Det kommer inte att redogöras för andra möjliga arkitekturer.
A.5. Bakgrund
A.5
Bakgrund
Systemet som är beställt ska jämföra produktpopularitet baserat på olika variabler, så som produktplacering eller vilken information som presenteras. Som beställare av systemet står företaget Valtech som har erfarenhet av bland annat digital strategi, e-handel, UX och webb-analys. Valtech har alltså mycket erfarenhet från mjukvara och vill med detta projekt ta klivet mot IoT - “Internet of Things” - och föra samman detta med sin nuvarande verksamhet. E-handel och A/B testning är något de har erfarenhet av sedan tidigare, denna produkt är ett sätt att få ett liknande verktyg i den fysiska handeln. Målet med projektet är att få en demon-strerbar prototyp som kommer användas i huvudsak på branschmässor.
A.6
Teori
Här följer förklaringar till använd terminologi som inte är förklarade i huvudrapporten.
UX- “user experience” - handlar om interaktion mellan människa och system. [11]
Mock-ups- tidiga prototyper av designen. De skapas för att enklare kunna visualisera slut-produkten, och på så sätt ge värdefull återkoppling tidigt. Det kan bidra till att enkelt kunna åtgärda problem tidigt, istället för att behöva göra om stora delar av produkten i ett senare skede. [12]
JSON- “JavaScript Object Notation” - är ett textbaserat, språkoberoende lättviktsformat som används för datautbyte. [13]
JWT- “JSON Web Token” - är en JSON-baserad öppen standard för att skicka fodringar mel-lan parter i en webbapplikationsmiljö. Tokens är utformade till att vara kompakta och URL-säkra. JWT används typiskt för att skicka identiteten för en autentiserad användare till en tjänst, men annan information som krävs av tjänsten kan också skickas med. Oftast är dessa tokens signerade så att tjänsten kan lita på att innehållet inte har manipulerats under trans-porten. En token kan liknas vid ett körkort med olika behörigheter, giltighetstid och ska vara svårt att förfalska. [14]
TLS- “Transport Layer Security” - är ett kryptografiskt kommunikationsprotokoll. I en web-bläsare ser man att detta används oftast genom att det i adressfältet står https i början av adressen, alltså http följt av s, där s betyder att det är en säker anslutning. [15]
Mikrotjänster- begrepp som innebär att olika komponenter i ett system kan köras oberoende av varandra och kommunicerar via väldefinierade gränssnitt. Vidare betyder detta att alla komponenterna kan köras på en maskin, spridas ut på flera maskiner i ett kluster av noder eller valfri kombination däremellan. Det gör att systemet är enkelt att skala, både upp och ner i storlek. Det kan också spridas över stora geografiska områden om så önskas. Vidare underlättar det separat utveckling och eventuell felsökning av de olika komponenterna.
A.7
Metod
Brainstorming efter kundmöte, analys av kravspecifikationen och analys av kundens kompe-tensområden ger viktig information om vad som faktiskt är målet samt hur värde kan skapas för kunden. Genom att skapa “mock-ups” blir det lättare att identifiera vilka komponenter som behövs i systemet. Utifrån dessa kan sedan olika teknologier utvärderas och därefter väljas. För att utvärdera teknologierna tas begränsningar, resurser, tid, underhållbarhet, pre-standa, skalbarhet, stabilitet, utvecklings- och vidareutecklingsmöjligheter i beaktning. För att verifiera att projektet utvecklas i rätt riktning är regelbundna avstämningar med kunden viktiga.
A.8. Resultat
Enligt informationen från kunden önskades en prototyp som skulle kunna demonstreras på mässor och visa potentialen med A/B testning vid fysisk handel. Det innebar att en skalbar prototyp var önskvärd samt att den måste fungera trots störningar som finns i typiska mäss-miljöer.
Från analysen och alla mock-ups identifierades följande huvudkomponenter för systemet:
• Sensorenhet som står för kommunikation med vågar. • Databas som håller all mätdata och beräknade värden.
• Beräkningsenhet som gör beräkningar på insamlad data och fattar logiska beslut utifrån dessa.
• Användargränssnitt.
När huvudkomponenterna identifierats evaluerades möjliga teknologival. För att bygga ett grafiskt användargränssnitt utvärderades JavaFX , Qt, Python-ramverket WxWidgets och webbteknologi. Då systemet skulle visa på skalbarhet och detaljer kring framtida maskinvara vid vidareutveckling var okänd vid projektets genomförande var det önskvärt med en så plat-tformsoberoende teknologi som möjligt. Detta sammantaget med att Valtech har kompetens inom webbutveckling medförde att en webbapplikation framfördes som förslag till Valtech, vilket de också ansåg var ett lämpligt val. Vidare valdes HTML5, CSS3 och JavaScript som språk för webbapplikationen, detta innebär att användargränssnittet fungerar på alla plat-tformar som har en modern webbläsare.
Härnäst utvärderades teknologier för “Backend” som kunde lämpa sig för kommunika-tion mot användargränssnittet. Först utvärderades Java, C++, Python, PHP, .NET och Node.js. Tidigt uteslöts .NET för att det mer eller mindre begränsar valet av plattform till en maskin med Windows. [16] De kvarvarande teknologierna utvärderades genom att göra efterforskningar om bibliotek fanns som lämpade sig för projektet. I projektet behövdes kom-munikation med vågar via USB eller seriell komkom-munikation. Vidare behövdes en webbserver för kommunikation mot användargränssnittet. Dessutom behövdes ett sätt att snabbt visu-alisera realtidsdata. Alla teknologier hade lämpliga bibliotek för detta projekt. Därefter jäm-fördes prestanda för att utesluta andra teknologier, det medförde att PHP uteslöts. [17] Från de kvarvarande kandidaterna valdes Node.js för att hålla ner antalet teknologier och därmed beroenden för projektet. Det underlättar vidareutveckling och underhåll av systemet vilket skapar värde för kunden.
Eftersom systemet använde webbteknologi fanns det inte någon anledning till att begränsa systemet till att bara fungera lokalt på en maskin. Då behövdes också ett inloggningssys-tem för att säkerställa att användaren hade de rättigheter som krävdes för att få utföra olika handlingar.
A.8
Resultat
Följande komponenter identifierades slutligen:
• Webbapplikation som grafiskt användargränsnitt.
• Statisk filserver som tillhandahåller klienten till användargränssnittet. • Inloggningssystem för att hantera olika rättigheter i systemet.
A.9. Diskussion
• "Reverse proxy" - En åtkomstpunkt för slutanvändaren som vidarebefordrar alla för-frågningar till rätt delsystem.
• Sensorenhet som står för kommunikation med vågar. • Databas som håller all mätdata och beräknade värden.
• Beräkningsenhet som gör beräkningar på insamlad data och fattar logiska beslut utifrån dessa.
• Datainsamlare för att ta emot all data från sensorenheterna. • Datautgivare för att skicka data till det grafiska gränssnittet.
Eftersom systemet skulle vara skalbart skapades varje komponent som en mikrotjänst. Som underliggande kommunikationsprotokoll för hela systemet valdes HTTP och i vissa fall utökat med TLS för säker kommunikation, Websocket för realtidsdata eller bådadera. Detta valdes för att genomgående vara så konsekvent som möjligt, vilket underlättar utveckling och underhåll.
Ovanpå detta definierades gränssnitt för kommunikation mellan komponenterna. Som dataformat användes JSON då det är enkelt att bygga ut eller ändra samt är väletablerat och har mycket stöd. Vidare behövdes ett enkelt sätt att kontrollera om en komponent har behörighet att utföra olika handlingar. För att undvika att varje förfrågan måste godkän-nas av en auktoriseringstjänst valdes JWT för att hantera detta då varje komponent själv kan verifiera att användaren är auktoriserad.
Här följer identifierade gränssnitt för kommunikation mellan de olika komponenterna:
• Gränssnitt för kommunikation med sensorenheter.
• REST API - “REpresentational State Transfer Application Programming Interface” - för inloggning och redigering av databas.
• Databasgränssnitt som definierar hur data sätts in och hämtas från databasen.
Eftersom projektet gick ut på att skapa en prototyp för vad som var möjligt var det oklart vilka plattformar systemet skulle användas på. För att fungera på allt mellan mobiltelefoner och projektorer valdes tidigt Bootstrap för att enkelt komma igång med detta. För visuell representation med grafer valdes ett färdigt bibliotek, åter igen för att spara tid.
A.9
Diskussion
Fler delar kunde ha specificerats mer detaljerat i ett tidigt skede av projektet. Till exempel specificerades inte så många komponenter för det grafiska användargränssnittet vilket med-förde att onödiga beroenden framträdde under utvecklingen. Om det funnits en tydligare komponent för datahantering i webbapplikationen kunde utvecklingen ha underlättats.
A.10
Slutsatser
Genom att analysera kravspecifikationen och kunden kan arkitekturen anpassas för att skapa så mycket värde som möjligt för kunden. Här gjordes det genom att uppfylla kravspecifika-tionen och genom att använda teknologier som kunden är väl insatt i sedan tidigare för att underlätta vidareutveckling.
A.10. Slutsatser
Arkitekturen underlättade utvecklingen av systemet genom att identifiera tydliga kompo-nenter som kunde utvecklas oberoende av varandra. Detta var speciellt viktigt då det var flera utvecklare och det inte är produktivt att vänta på andra hela tiden för att komma framåt i projektet.
Slutsatserna ovan besvarar frågan om hur en lämplig arkitektur togs fram för detta projekt. Det vill säga att det var lämpligt att uppfylla kravspecifikationen, skapa värde för kunden och underlätta utvecklingen genom tydligt definierade komponenter.
B
Arbetsfördelning, organisation
och enhetlig mjukvara av Joakim
Ericsson
Denna del av rapporten är skriven av Joakim Ericsson som har haft rollen som lingsledare under projektets gång. Jag kommer att undersöka hur enhetlig mjukvara utveck-las i ett projekt bestående av flera personer och hur arbetet i ett projekt kan fördeutveck-las och organiseras.
B.1
Inledning
Rollen som utvecklingsledare inkluderar många olika områden. Det sträcker sig från allt som att delegera och leda arbetet till att ta tekniska beslut om hur systemet ska se ut. Ansvarsom-rådet snuddar också vid testning.
I rollen som utvecklingsansvarig har jag därför gjort många olika saker. Detta är något som jag gillar och rollen passade därför mig personligen bra. Den tekniska biten som jag har lagt mest tid på i projektet är kommunikationen mellan de olika delmodulerna som används. Denna arbetsuppgift passade mig bra eftersom jag då fick en bra uppfattning om hur alla moduler fungerade och kunde vara med och välja vilka tekniker som skulle användas. Detta gjorde i sin tur att jag hade bra koll på hur systemet fungerade vilket hjälpte mig att organis-era och fördela arbetet.
B.2
Syfte
Syftet med detta avsnitt är att klargöra vad rollen som utvecklingsledare innebär. För att göra detta kommer ett antal relevanta frågeställningar redovisas och resultatet diskuteras och analyseras. Texten nedan kommer samtidigt att ta upp och diskutera erfarenheter och intres-santa upptäckter som gjorts under projektets gång. De ämnen som kommer att undersökas är hur arbetet i ett projekt organiseras effektivt och hur enhetlig och konsekvent mjukvara kan skrivas.
B.3. Frågeställning
B.3
Frågeställning
• Hur utvecklar man enhetlig och konsekvent programvara i ett större projekt?
• Vilka metoder och verktyg kan användas för att förenkla organisation och arbetsfördel-ningen i projektet?
B.4
Bakgrund
Systemet som byggts under projektet har skapats med moduläritet i åtanke. Detta betyder att det finns flera moduler i systemet som kan utvecklas relativt oberoende av varandra, vilket förenklar parallellt arbete. Vi valde i början av projektet att istället för att var och en fick ansvar för varsin modul så ansvarade man för en speciell teknik. Exempelvis så ansvarade jag för all kommunikation mellan modulerna istället för kommunikationen för endast en modul. Detta gjorde att utvecklaren fick en bättre helhetskänsla för systemet och gjorde antagligen att utvecklingen gick snabbare.
Ett av de problem som vi ställdes inför i början var hur man i ett projekt på åtta stycken personer får en enhetlig kod. Om man dessutom tar med i beräkningarna att vi alla hade begränsad erfarenhet av de programmeringsspråk som skulle användas så uppdagades ett problem. I egenskap av utvecklingsledare funderade jag mycket på hur koden skulle göras enhetlig. Det verktyg som sedan användes för att lösa detta var en så kallad “linter”. En linter är ett verktyg som ser till att en viss kodstandard följs. En passande och välkänd kodstandard valdes och konfigurerades med verktyget. Att använda en linter gör i teorin att alla tvingas att hålla samma standard och att kod utvecklad av många personer ser liknande ut.
B.5
Teori
Den linter som vi använde i projektet kallas Eslint [18] [19] . Just det verktyget valdes eftersom det stödde JavaScript och underhölls aktivt. Eslint är använt av många stora och välkända företag inom webbutvecklingsbranschen som Facebook, PayPal, Atlassian och många fler [18]. Därför kändes det som ett tryggt och väl testat verktyg. Verktyget är ett projekt med öppen källkod som också är en fördel vid val av testverktyg.
Eslint har möjligheten att följa många olika kodstandarder. Vi valde mellan flera olika stan-darder men vi valde till sist en av de kändaste och mest uppdaterade standard som vi kunde hitta kallad Airbnb [9]. Denna stilguide eller kodstandard hade stöd för samtliga av de funk-tioner som vi ville utnyttja som ECMAScript 6. Standarden var också aktivt underhållen och uppdaterad av utvecklaren. Denna standard var också utbredd och använd i många andra projekt och företag som Reddit, National Geographic med flera [9].
För att organisera och fördela arbetet i projektgruppen använde vi oss av Kanban. Kanban är en teknik som kan användas vid agila projekt. Det Kanban hjälper till med är att visualisera vad för aktiviteter som måste göras i ett projekt. En styrka med Kanban är att det går att göra väldigt enkelt och är snabbt att komma igång med [20]. Just för att visualisera Kanban board:et så använde vi oss av tjänsten Trello [4].
B.6
Metod
Genom att använda Eslint så kunde samtliga i projektet skriva enhetlig kod. Eslint kan an-vändas på flera olika sätt. Dels i terminalen och dels som ett plugin i den valda texteditorn. Det sistnämnda var det som jag personligen tyckte var det bästa och smidigaste eftersom Eslints varningar och fel direkt uppkom när koden skrevs. Många i gruppen använde bara
B.7. Resultat
Eslint från terminalen vilket också fungerar bra även om det kan bli lite svårare att hitta alla små fel. Eslint har också funktionen att automatiskt fixa små fel och denna funktion använde vi oss också utav.
Vi använde i projektet ett Kanban board för att förenkla organisationen av arbetet. Kanban board:et hade kategorierna: “To Do”, “Doing” och “Done”. När man började jobba med en aktivitet så flyttades aktiviteten ett steg och en tagg sattes på aktiviteten med namn så att samtliga projektmedlemmar enkelt kunde få en bild av vem som gjorde vad. Varje iteration hade sitt eget Kanban board som skapades i början av respektive iteration. Kanban board:et skapades med de aktiviteter som var tänkt att göras under iterationen men kunde också fyllas på under arbetets gång med nya aktiviteter som uppkommit.
För att samla in erfarenheter har jag efter varje iteration i projektet reflekterat över vad som har fungerat bra och vad som kunde ha gjorts bättre. Dessa erfarenheter har sedan används för att försöka göra nästa iteration bättre. Erfarenheterna kommer också att tas med till framtida projekt.
B.7
Resultat
Att använda Eslint resulterade i att mycket av den kod till servern som skrevs följde samma standard. Ett problem som uppstod var dock att standaren som vi valde inte kunde ap-pliceras lika lätt på JavaScript-koden som skulle köras i webbläsaren som på serverkoden. Detta berodde på att ECMAScript 6 standaren som användes till serverkoden i Node.js inte ännu stöds fullt ut av samtliga webbläsare. Detta löstes senare i iteration två genom att an-vända ett byggskript som kompilerade ner ECMAScript 6 koden ämnad för att köras i web-bläsare till lägre versioner av JavaScript. Efter att ha löst problemet för koden utvecklad för webbläsare så kunde alltså all JavaScript-kod som skrevs i projektet följa samma standard. Användningen av Eslint kunde alltså förenkla gruppens arbete att få en enhetlig och kon-sekvent kod, även om man kan argumentera för att det skulle räckt med att endast använda en kodstandard och bestämma att alla skulle följa den. Eslint förenklade dock processen att följa just denna standard.
En Kanban board hjälpte projektgruppen att organisera och fördela arbetet i gruppen. Det gjorde det enkelt att se vem som gjorde vad. När en uppgift färdigställdes kunde sedan var person för sig själv se vad som mer behöves göras och själv välja en ny uppgift att börja med istället för att någon annan var tvungen att dela ut uppgifter.
I projektets första iteration så användes inte Kanban board:et särskilt flitigt av gruppen vilket gjorde att det blev svårare att använda den på ett effektivt sätt. Under den andra iterationen användes Kanban mer effektivt redan från början och det fungerade därför mycket bättre att använda. Vi valde också att efter första iterationen dela upp så att varje iteration hade sitt eget Kanban board istället för att vi hade ett stort eftersom vi upptäckte att det blev svåröver-skådligt.
B.8
Diskussion
Resultatet av att använda Eslint gjorde att även om kod skriven av olika personer kan ha vissa karaktärsdrag så följer den fortfarande en viss standard. Mitt intryck av att använda ett sådant verktyg var initialt att det var alltför noggrant och att det skulle bli för jobbigt och svårt att följa alla dessa regler. Jag hade innan i tidigare projekt följt förutsatta kodstandarder men då inte haft ett sådant verktyg som kontrollerar att den följs. Det var därför en ny erfarenhet som jag till en början kände mig ganska negativt inställd till. Dock så blev det enklare att
B.9. Slutsatser
använda då man vant sig vid det. Den riktiga styrkan låg också senare när flera bitar av koden från flera personer skulle sammanfogas. Även om det syns att koden är skriven av flera personer så följer den en standard och har en viss enhetlighet. Jag tror att det hjälpte att ha ett sådant verktyg som nybörjare till programmeringsspråket, även om en del saker tog längre tid så gjordes de redan från början på ett korrekt sätt. När man sedan lär sig mer om ett programmeringsspråk kan man bilda sig en egen uppfattning av vad som är en bra kodstandard och kanske modifiera den för att passa bättre till sin egen smak. Dock tror jag fortfarande att det är bra att ha en gemensam och väldefinierad standard vid arbete i projekt med flera personer.
Även om resultatet av att använda en linter gör att koden får en gemensam standard så ska det inte blandas ihop med att den tar hand om buggar eller andra fel. Lintern har ingen riktig logik för att analysera om koden är rätt eller fel, även om fel ibland fångas upp eftersom de inte följer standaren. Lintern hjälper exempelvis inte till och kollar om olika datatyper blandas på konstiga sätt utan det får programmeraren hålla koll på själv. För att få denna funktionalitet skulle man behöva hitta ett kompletterande program som analyserar kodens betydelse. Dock kan Eslint ibland hjälpa till med enklare fel som att varna om att variabler och funktioner som används inte är definierade.
I en studie om att använda linter som ett verktyg för att rätta fel säger Gong m.fl. att Eslint är ett exempel på en så kallad statisk linter. Likt min egen slutsats så beskrivs det hur ett sådant verktyg lätt kan missa fel. Ett kompletterade verktyg att använda för att hitta fler fel skulle kunna vara en så kallad dynamisk linter, som beskrivs i studien. Den dynamiska linter som studeras heter Dlint och det visar sig i studien att genom att använda den som ett komplement till en traditionell statisk linter så kan många fler fel hittas [19].
Vi valde att använda oss av Kanban eftersom det är en teknik som är relativt enkel att komma igång med. Vi tyckte Kanban passade bra till detta projekt eftersom det inte kändes värt att lägga ner mycket tid på att lära sig någon mer komplex utvecklingsmetod. Det var också en teknik som jag och många andra redan hade kommit i kontakt med under tidigare projekt och visste därför innan hur det fungerade och användes. För att realisera en Kanban board använde vi oss av den webbaserade tjänsten Trello. Jag tror det var både en fördel och nackdel att använda Trello. Att ha board:et på nätet gör att alla enkelt, var man än befinner sig, kan komma åt det och se vad som behöver göras. Samtidigt tror jag att man skulle ha fått en bättre känsla för vad som skulle göras genom att istället ha använt sig av post-it lappar på en vägg. Det skulle då blivit mer tydligt för teamet då aktiviteter flyttades och slutfördes, även om nackdelen med den lösningen är att board:et blir mindre portabel.
B.9
Slutsatser
Följande slutsatser, med fokus på frågeställningarna, kunde göras från resultatet av kandi-datarbetet:
• Eslint är ett mycket effektivt sätt att skriva enhetlig och konsekvent kod i ett projekt. Genom att använda Eslint kan också en del, men inte alla fel i koden upptäckas innan den körs.
• Att använda sig av ett Kanban board är ett bra sätt att organisera ett projekt. Genom att använda metoden så visualiseras arbetet och det blir lättare att följa vad som måste göras och vilken prioritet det har. Att använda sig av ett Kanban board hjälpte också till att fördela arbetet i projektet eftersom alla projektmedlemmar enkelt kunde se vem som gjorde vad.
C
Samarbete vid
dokumentskrivning i projekt och
rollen som dokumentansvarig av
John Eriksson
Det här avsnittet är skrivet av John Eriksson som har haft rollen som dokumentansvarig i projektet.
C.1
Inledning
Under projektets gång har många dokument skrivits. Det här avsnittet undersöker hur vi har jobbat och och vilka metoder vi har använt oss av. Det behandlar också vad rollen som dokumentansvarig innebär.
I ett projekt finns en dokumentansvarig för att säkerställa att det finns mallar att följa och att de färdiga dokumenten följer dessa mallar. Den dokumentansvarige är också ansvarig för att granska dokumenten, se till att de skickas in i tid och att alla dokument håller en hög kvalitet. Eftersom majoriteten av dokumenten skrivs antingen under förstudien eller i slutet av en iteration är rollen som dokumentansvarig väldigt fri under arbetets gång, i avseendet att man inte är knuten direkt till arbete inom ett ansvarsområde och kan vara där man behövs. Detta fungerade bra eftersom vi arbetade mot en Kanban board vilket innebär en frihet i vad man arbetar med då man arbetar mot en backlog som man kan välja aktiviteter från.
C.2
Syfte
Syftet med denna utredning är att undersöka hur flera personer kan skriva dokument tillsam-mans på ett bra sätt och att behandla vilka metoder som har använts vid dokumentskrivning under projektets gång. Det är också att redogöra för vad rollen som dokumentansvarig in-nebär och för de erfarenheter som har gjorts under projektets gång. För att göra detta kommer dokumentet utgå från ett antal frågeställningar som kommer att diskuteras.
C.3
Frågeställning
• Hur kan flera personer skriva dokument parallellt på ett effektivt sätt?
