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 kommunikation. 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 utveck- 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ördelas 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