Visuell programmeringsplattform för IoT-produkter

Linköpings universitet SE–581 83 Linköping

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

2021 | LIU-IDA/LITH-EX-G--21/021--SE

Visuell programmeringsplattform

för IoT-produkter

Playground Web

–

a visual programming platform for IoT products

Yen Dinh

Jesper Fasth

Filip Johansson

Svante Martinsson

Miriam Rosén

Alfred Sundstedt

Carl Södersten

Axel Wretman

Handledare : Christoffer Holm Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum 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 kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ 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 sammanhang som är kränkande för upphovsman-nens litterä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 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/. © Yen Dinh Jesper Fasth Filip Johansson Svante Martinsson Miriam Rosén Alfred Sundstedt Carl Södersten Axel Wretman

Sammanfattning

Denna rapport behandlar arbetet som en kandidatgrupp, bestående av åtta civilingen-jörsstudenter inom data- och mjukvaruteknik vid Linköpings universitet, utförde under våren 2021. Arbetet gjordes som en del av kursen Kandidatprojekt i programvaruutveckling, med kurskod TDDD96, där kandidatgruppen utvecklade en webbapplikation åt företa-get Neue Labs. Webbapplikationen baserades på Neue Labs mobilapplikation Playground, och utvecklades med hjälp av JavaScript-biblioteken React och Redux. Applikationen är en plattform för visuell programmering av IoT produkter, där programmen tar formen av flö-desgrafer. Rapporten beskriver arbetsprocessen och redogör för den slutgiltiga produkten. Projektet har bedrivits helt på distans enligt en något modifierad Scrum-metodik. Några av de viktigaste lärdomarna som gruppen tar med sig rörde utbildning, kommunikation och testning. Dessutom innehåller rapporten åtta individuella bidrag, som är skrivna av kandidatgruppens medlemmar.

Författarnas tack

Kandidatgruppen vill rikta ett stort tack till Neue Labs, då företaget har gjort det möjligt för gruppen att arbeta med projektet, tillhandahållit det materiel som krävts, gett gruppen ut-rymme för egna förslag och bemött gruppen med en positiv inställning. Ett särskilt tack till Fredrik Wanhainen och Emil Wallin, som har funnits där vid frågor och funderingar. Kandi-datgruppen skulle även vilja tacka gruppens handledare Christoffer Holm, som alltid kom-mit med bra svar på gruppens frågor och lett gruppen i rätt riktning under projektets gång. Dessutom skulle kandidatgruppen vilja tacka kursens examinator Kristian Sandahl för för-beredande undervisning inför projektet.

Innehåll

2.2 Liknande lösningar . . . 3

2.3 Gruppens tidigare erfarenheter . . . 4

3 Teori 5 3.1 Projektmodeller . . . 5

3.2 Arkitekturmönstret Flux och biblioteket Redux . . . 6

3.3 AWS AppSync . . . 6

3.4 Utvecklingsspråk . . . 6

3.5 Bibliotek & ramverk . . . 7

3.6 Testverktyg . . . 7

4 Metod 9 4.1 Projektorganisation . . . 9

4.2 Utvecklingsmetod . . . 10

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

4.4 Metod för att utvärdera prestanda . . . 13

5 Resultat 14 5.1 Systembeskrivning . . . 14

5.2 Värde för kunden . . . 18

5.4 Processbeskrivning . . . 20

5.5 Gemensamma erfarenheter . . . 23

5.6 Översikt över individuella bidrag . . . 24

6 Diskussion 27 6.1 Resultat . . . 27

6.2 Metod . . . 28

6.3 Arbetet i ett vidare sammanhang . . . 30

7 Slutsatser 33 A Scrum i jämförelse med andra projektmodeller - Yen Dinh 35 A.1 Introduktion . . . 35 A.2 Teori . . . 35 A.3 Metod . . . 37 A.4 Resultat . . . 38 A.5 Diskussion . . . 39 A.6 Slutsatser . . . 40

B Hur webbläsaren blev skapad och hur den påverkar webbapplikationer -Jesper Fasth 41 B.1 Introduktion . . . 41 B.2 Teori . . . 41 B.3 Metod . . . 43 B.4 Resultat . . . 44 B.5 Diskussion . . . 46 B.6 Slutsatser . . . 47

C Testdriven utveckling eller test last utveckling som testningsmetod för utveck-ling av mjukvaruprojekt - Filip Johansson 49 C.1 Introduktion . . . 49 C.2 Teori . . . 49 C.3 Metod . . . 50 C.4 Resultat . . . 52 C.5 Diskussion . . . 53 C.6 Slutsatser . . . 54

D Säkerhetsrisker vid användning av “internet of things” - Svante Martinsson 55 D.1 Introduktion . . . 55 D.2 Teori . . . 55 D.3 Metod . . . 57 D.4 Resultat . . . 57 D.5 Diskussion . . . 58 D.6 Slutsatser . . . 60

E Informationstäthet i visuella programmeringsverktyg - Miriam Rosén 61 E.1 Introduktion . . . 61 E.2 Teori . . . 61 E.3 Metod . . . 62 E.4 Resultat . . . 63 E.5 Diskussion . . . 65 E.6 Slutsatser . . . 67

F Webbapplikation eller mobilapplikation för dagens mjukvarumarknad -Alfred Sundstedt 68 F.1 Introduktion . . . 68 F.2 Teori . . . 69 F.3 Metod . . . 71 F.4 Resultat . . . 73 F.5 Diskussion . . . 79 F.6 Slutsatser . . . 81

G Ökad användning av Internet of Things ur ett hållbarhetsperspektiv -Carl Södersten 82 G.1 Introduktion . . . 82

G.2 Bakgrund och Teori . . . 82

G.3 Metod . . . 84

G.4 Resultat . . . 85

G.5 Diskussion . . . 87

G.6 Slutsatser . . . 88

H Jämförelse av populära webbramverk för nybörjare - Axel Wretman 89 H.1 Introduktion . . . 89 H.2 Teori . . . 89 H.3 Metod . . . 92 H.4 Resultat . . . 94 H.5 Diskussion . . . 97 H.6 Slutsatser . . . 98 Litteratur 99

Figurer

3.1 Ett diagram för informationsflödet i en Flux-applikation. . . 6

4.1 Skillnaden på merge och rebase . . . 12

5.1 Inloggningssidan . . . 15

5.2 Flows-sidan . . . 15

5.3 Editor-sidan . . . 16

5.4 Ett flow med patches . . . 16

5.5 Inställningar för en patch av typen “iOS Notification” . . . 17

5.6 Redigering inuti en grupp-patch . . . 18

5.7 Layout genererad av webbapplikationen . . . 18

5.8 Systemanatomi . . . 19

5.9 Grafer som visar gruppens svar på enkätens obligatoriska frågor under samarbe-tet med TDDE46. . . 21

5.10 Filhierarkin för systemets källkod. . . 22

A.1 Ett spiralmodellsdiagram . . . 37

B.1 En referensarkitektur till webbläsare. . . 42

B.2 En vy av webbläsarnas historia från 1990 till 2003. . . 46

C.1 Utvecklingsflöde för TDD. . . 51

C.2 Utvecklingsflöde för TLD. . . 51

D.1 DDOS-attack, Bild av: Nasanbuyn . . . 56

D.2 MITM-attack . . . 56

E.1 Fisheye-filter applicerat på bilden i figur E.4 . . . 64

E.2 Redigeringsytan när man navigerat sig in i två lager av grupp-patcher. . . 65

E.3 Redigeringsytan i Playground web på zoom-nivå 25% . Ungefär halva tillgängliga redigeringsytan är synlig och täcks av 84 patcher. . . 66

E.4 Ett mer verklighetstroget användarfall av redigeringsytan i Playground web, zoom-nivå 50%. . . 66

F.1 Digram för enkätens deltagare. . . 74

F.2 Diagram för tjänster där webbapplikationer helst föredras. . . 75

F.3 Diagram för tjänster där mobilapplikationer helst föredras. . . 76

F.4 Diagram för tjänster där ingen applikationstyp helst föredras. . . 77

F.5 Två diagram för visuella programmeringsverktyg. . . 78

G.1 SusAD-diagram mall . . . 84

Tabeller

B.1 Tabell över populära webbläsare och vilka motorer de använder. . . 43 E.1 Maximal informationsdensitet för varje zoom-nivå. . . 65

Ordlista

Appsync Servertjäst från AWS för att tillhandahålla GraphQL API:er. s. 2, 6, 17 Automat Hårdvaruenhet som kan konfigureras med hjälp av Playground. s. 3

Backlogg Lista på funktioner som ska implementeras eller aktiviteter som ska utföras. s. 5, 29

Create React App Projekt utvecklat av Facebook som gör det enkelt att sätta upp nya React-webbapplikationer med ett enda kommando. s. 8

End-to-end Testningsmetod som innebär att testa applikationens hela flöde av användning för att validera integriteten. s. 13

Flow Lättare applikationer med funktioner och gränssnitt som kan skapas genom Playground. s. 14

Flux Arkitekturmönster för webbapplikationer. s. 2, 6, 19, 24, 34 Git Verktyg för versionshantering. s. 11

GitLab Tjänst för dela och lagra Git-repon. s. xi, 11, 12, 29 GraphQL Databasspråk som är utvecklat av Facebook. s. 6, 17

Grupp-patch Patch som möjliggör nästling av patcher. Fungerar lite som en katalog. s. 14 iOS Operativsystem för mobila enheter utvecklat av företaget Apple. s. 1, 3, 33

JavaScript Programmeringsspråk för webbutveckling. s. 2, 6, 7, 24, 27, 33 Jest Ramverk till JavaScript som underhålls av Facebook. s. 7, 13

Jira Verktyg för projektplanering. s. 10, 11, 21, 29

Microsoft Teams Mjukvaruplattform för gruppkommunikation. s. 11, 13

Neue Labs Företag som skapar produkter inom IoT, kunden till projektet. s. 1, 3, 10, 21, 23, 24, 30, 31, 34, 88

Node-RED Nodbaserat programmeringsverktyg. s. 3 Node.js Serverplattform med öppen källkod. s. 3

OpenJS Foundation Organisation som förvaltar och förespråkar JavaScript projekt med öp-pen källkod. s. 3

Overleaf Online-verktyg för att skriva LaTeX-dokument. s. 12

Patch Kopplingsbar, ibland modifierbar, modul fylld med funktionalitet och egenskaper. s. 14

Pipeline Kedja av processer. I detta projekt består processerna av kontroller av koden som finns på GitLab. s. 12

Playground Mobilapplikation från Neue labs. s. 2, 3

Playground Web Webbversion av Playground, produkten som utvecklades i detta projekt. s. 2, 4, 25, 30, 33, 34, 65

PostCSS Verktyg för att automatiskt generera CSS utifrån JavaScript. s. 7, 27 React Testing Library Testverktyg till JavaScript. s. 7, 8, 13

ReactJS JavaScript-bibliotek för att skapa interaktiva webbapplikationer. s. 2, 6–8, 13, 19, 24, 27, 33, 34

Redux JavaScript-bibliotek för att hantera tillstånd i webbapplikationer. s. 2, 6, 7, 13, 19, 24, 27, 33, 34

Scrum Projektmodell som bygger på ett iterativt arbetssätt. s. 5, 10, 11, 13, 20, 21, 24, 29, 33 Slack Mjukvaruplattform för gruppkommunikation. s. 24

Förkortningar

API Application Programming Interface. Specifikation på tillgängliga funktioner för inter-aktion med en modul eller enhet. s. 6, 8, 31

AWS Amazon Web Services. Tjänster för exempelvis server- och databasunderhåll. s. 2, 4, 6, 17, 31

CD Continuous Development. Utvecklingsmetod som innehär att utveckling sker kontinu-erligt i många små iterationer. s. 12

CI Continuous Integration. Utvecklingsmetod som innebär att ändringar integreras i den existerande kodbasen kontinuerligt. s. 12

CSS Cascading Style Sheets. Utveckingsspråk som används för att definiera utseende på webbsidor. s. 7, 27

DiVA Digitala Vetenskapliga Arkivet. Svensk databas för publicerade vetenskapliga upp-satser och avhandlingar. s. 13, 30

DOM Document Object Model. En modell för att tolka HTML som en trädstruktur. s. 7, 19, 20, 34

GUI Graphical User Interface. Grafiskt användargränssnitt, den del av produkten som an-vändaren ser och interagerar med. s. 28

HTML Hypertext Markup Language. Utvecklingsspråk som används för att definiera inne-hållet på webbsidor. s. 7, 27

IoT Internet of Things. Saker, utöver datorer och telefoner, som är uppkopplade mot inter-net och varandra. s. 1, 3, 18, 25, 30

SUS System Usability Scale. Mått på användbarhet av system. Värdet baseras på ett antal enkätfrågor. s. 8, 23, 30

UI User Interface. Användargränssnitt. s. 10 UX User Experience. Användarupplevelse. s. 10

1

Introduktion

Detta kapitel beskriver syftet och ger en motivering till utvecklingen av produkten som grup-pen har tagit fram i detta projekt, samt behandlar de avgränsningar som påverkat resultatet av produkten. I denna del finns även frågeställningarna som behandlas i rapporten.

1.1

Motivering

Internet of Things (IoT), är ett begrepp som beskriver att vardagliga enheter, som exempel-vis tvättmaskiner, tandborstar och kylskåp, allt mer börjar kopplas upp mot internet. Detta möjliggör att enheter kan fjärrstyras och samla data som sedan kan läsas av över internet.

Neue Labs är ett svenskt startupbolag inom IoT som förändrar hur man bygger uppkopp-lade produkter. Detta leder till ett nytt ekosystem som möjliggör snabbare och billigare fram-tagning av prototyper samt utveckling av skräddarsydda smarta anslutna lösningar. För att en användare snabbt ska kunna göra detta har Neue Labs en visuell programmeringslösning där man kopplar ihop noder som alla har olika fördefinerande funktioner. Dessa konfigureras för att sedan skapa fast programvara (eng.firmware), samt applikationer för sin uppkopplade hårdvara.

Problemet idag är att Neue Labs produkt endast finns tillgängligt för iOS-produkter och utvecklingen av större nodnätverk är icke-ergonomisk. Att göra produkten tillgänglig på en hemsida skulle därför underlätta detta och också göra det enklare för användarna att få en bättre överblick av sitt arbete. Det skulle också göra produkten mer tillgängligt för fler an-vändare.

1.2

Syfte

Projektet utfördes på beställning av Neue Labs som idag har en produkt som endast fungerar på iOS-produkter. Målet med detta projekt var att göra denna produkt tillgänglig på en ny plattform, webben, för att underlätta utvecklingen av större nodnätverk.

Projektet bestod av en utvecklingsprocess där design och implementation baserades på de krav som projektgruppen fått av kunden. I projektet skulle även denna kandidatrapport skrivas där frågeställningarna som finns i kapitel 1.3 behandlas.

1.3. Frågeställning

1.3

Frågeställning

Följande frågeställningar har undersökts under projektets gång.

1. Hur kan systemet Playground Web implementeras så att man skapar värde för kunden? 2. Vilka erfarenheter kan dokumenteras från ett småskaligt programvaruprojekt som kan

vara intressanta för framtida projekt?

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

4. Hur påverkar ReactJS tillsammans med Redux och arkitekturmönstret Flux en webbap-plikations prestanda?

1.4

Avgränsningar

Detta projekt syftade till att göra kundens produkt, Playground, tillgänglig på en ny plattform: webben. Kunden hade därför krav på att den nya produkten skulle vara kompatibel med deras existerande system, både i utseende, arkitektur och funktionalitet. För att produkten skulle vara arkitekturmässigt kompatibel med kundens system anpassades produkten för att användas tillsammans med servertjänsten AWS Appsync.

Kunden hade även krav på att produkten skulle byggas med välkända och väldokumen-terade verktyg för att underlätta vidareutveckling, därför valdes de väletablerade JavaScript-biblioteken ReactJS och Redux.

Fokus för projektet var att skapa en plattform för datorer och webbapplikationen anpas-sades därför ej för mobila webbläsare.

1.5

Kontext

Detta projekt är utfört i samband med att projektgruppen läst kursen TDDD96 Kandidatpro-jekt i mjukvaruutveckling. I kurskraven ingick bland annat att varje proKandidatpro-jektmedlem skulle bidra med 400 arbetstimmar och ha ett eget ansvarsområde i gruppen.

Det fanns även krav på att dokument som till exempel projektplan, kvalitetsplan, och arkitekturdokument skulle produceras. Även en kandidatrapport på svenska skulle skrivas, där de tre första frågeställningarna i rapporten var obligatoriska för kursen, den fjärde valdes av projektgruppen.

Start och slutdatum för projektet var även definierat efter kursens längd, med start den 18 januari och slut den 19 maj 2021.

2

Bakgrund

I detta kapitel ges en kort bakgrund till projektets kund och deras behov samt vilka liknande lösningar som redan finns på marknaden. Här behandlas även projektgruppens bakgrund och tidigare erfarenheter.

2.1

Kundens bakgrund och syfte

Kunden Neue Labs i sin nuvarande form och inriktning startade 2020, men bygger på en tek-nikplattform som togs fram 2015 och utvecklades fram till och med 2019. Den tidigare platt-formen hade ett fokus på modebranschen, men idag har bolaget ett fokus på IoT-produkter åt industrin.

Företaget har skapat en plattform bestående av två produkter: hårdvaruenheten Auto-mat och mobilapplikationen Playground. Plattformen ska, snabbt och billigt, kunna ta fram testbara prototyper för ny hårdvara genom att koppla upp befintlig hårdvara till mobilappli-kationen.

Målet med plattformen är att skapa ett verktyg som inte kräver att användaren har en teknisk bakgrund, utan istället tillåter utvecklingen att vara flexibel och enkel att förstå. Det uppnås genom att visuellt representera komponenter samt dess medföljande funktionalitet i ett nodbaserat gränssnitt, i form av en endimensionell lista.

Plattformen finns i nuläget endast tillgänglig för mobila iOS-enheter och är i listformat, vilket gör den icke-ergonomisk, något som företaget vill ändra på. Kunden vill utveckla en webbversion av applikationen för att utöka tillgängligheten samt för att göra plattformen mer ergonomisk för sina användare. Kunden har därför gjort en beställning för detta till pro-jektgruppen.

2.2

Liknande lösningar

Den största konkurrerande lösningen som finns är Node-RED som är ett flödesbaserat pro-grammeringsverktyg ursprungligen utvecklat av IBM’s Emerging Technology Services, men är numera del av OpenJS Foundation. Node-RED programmet körs i en webbläsare och är byggt på Node.js. En användare kan då använda drag-och-släpp i webbläsaren för att skapa program bestående av olika noder som finns i programmet där varje nod har en funktion.

2.3. Gruppens tidigare erfarenheter

Detta program kan sedan köras på en mängd olika hårdvaror såsom Raspberry Pi, Arduino eller i molnet via Amazon Web Services. [39]

Den största skillnaden mellan Node-RED och Playground Web är att Node-RED kräver att användaren själv hittar en lösning för att köra programmet. Det kan göras genom att starta en lokal server på enheten man befinner sig på eller genom att använda sig av en molntjänst. Det krävs på så sätt en relativt hög nivå av teknisk datorkunskap för att kunna använda sig av plattformen.

2.3

Gruppens tidigare erfarenheter

Samtliga medlemmar i gruppen har minst tre års erfarenhet från antingen civilingenjörspro-grammet i mjukvaruteknik eller civilingenjörsprocivilingenjörspro-grammet i datateknik. De som läser mjuk-varuteknik har tidigare projekterfarenhet från kursen TDDD92 (Artificiell intelligens - pro-jekt) och de som läser datateknik har tidigare projekterfarenhet från kursen TSEA29 (Kon-struktion med mikrodatorer, projektkurs). Alla medlemmar har även läst kursen TDDC93 (Programvaruutvecklingsmetodik, teori) där de fått lära sig teorin bakom olika delar av ett mjukvaruprojekt. Ett par medlemmar från gruppen har även tidigare professionell erfarenhet av mjukvaruutveckling från deltids- och sommarjobb.

Gruppen har även, från tidigare erfarenhet, lärt sig att kontinuerlig tidrapportering är viktigt då det ger en bra överblick över hur arbetet för varje individ går. Detta är viktigt då hela gruppen kan hjälpas åt så att alla kan lägga ner ungefär lika mycket tid under hela projektets gång.

Gruppen har även lärt sig att kommunikation är viktigt. Dålig kommunikation kan leda till att gruppmedlemmar inte vet hur projektet ligger till med olika mål och vad andra grupp-medlemmar håller på med. Det kan även leda till att endast vissa personer vet hur delar av det utvecklade systemet fungerar vilket gör felsökning svårt.

En annan lärdom från tidigare erfarenhet är att det är viktigt att fråga om hjälp när pro-blem uppstår. Det kan ta mycket onödig tid om man inte ber någon annan om hjälp och endast försöker lösa alla problem själv.

3

Teori

I detta kapitel behandlas teori som är relevant för projektet, relaterat till projektmodeller, arkitekturmönster och utvecklingsverktyg.

3.1

Projektmodeller

För att uppnå effektiva projektresultat i större projekt är det bra att använda sig av en pro-jektmodell. De bidrar till att ett projekt styrs på ett specifikt sätt. [116]

3.1.1

Scrum

I ett projekt som utnyttjar Scrum finns det tre distinkta roller: en produktägare, ett utveck-lingsteam och en Scrummästare. Produktägaren bär ansvaret för en produkt-backlogg som ska vara till hjälp för utvecklingsteamet att maximera värdet av gruppens arbete och därmed även produkten. Utvecklingsteamet är självorganiserande vilket innebär att beslut angåen-de vem som ska göra vad och hur är något som gruppen tillsammans bestämmer. Den sista rollen är Scrummästaren. Personen som har denna roll har som ansvar att säkerhetsställa att Scrum förstås och efterlevs och gör detta genom att vägleda utvecklingsteamet. Scrummäs-taren håller även i gruppens sprintmöten. [128]

Sprintmöten är en viktig del i Scrum och brukar hållas när en sprint avslutas och en ny börjar. En sprint är en fastställd arbetsperiod på högst en månad. Att ha en sprint som sträcker sig under en längre period minskar chansen för uppnå förutsägbarheten som kan komma med att använda sig av Scrum. En längre sprintperiod ökar dessutom risken för att tiden som lagts på arbetet har varit i onödan [128]. Kortare sprintar kan anses vara mindre bra när mål för sprintarna förblir densamma och inte tillräckligt mycket arbete hinner göras för att uppnå målen.

Under sprintmötet går teamet igenom det som varit bra och mindre bra med den tidigare sprinten och anledningarna till varför sprinten gick som det gjorde. Efter att en utvärdering av sprinten gjorts, bestämmer teamet nya mål och aktiviteter för den kommande sprinten som sätts in i en sprint-backlogg. Dessa mål och aktiviteter bestäms utifrån produkt-backloggen som produktägaren har ansvar över. Utöver sprintmöten, har teamet dagliga Scrummöten på högst 15 min där gruppen berättar vad som gjorts det tidigare dygnet, vad som ska göras det kommande dygnet och om de stött på några problem [128].

3.2. Arkitekturmönstret Flux och biblioteket Redux

3.2

Arkitekturmönstret Flux och biblioteket Redux

Flux är ett arkitektursmönster som utvecklades av Facebook och används för att utveckla storskaliga webbbapplikationer som körs på klientsidan. Flux gör webbbapplikationer mer förutsägbara och skalbara genom att skicka information i ett enkelriktat flöde och sparar all tillståndsinformation i ett objekt.

Flux-mönstret består av fyra delar: vyer, lager, handlingar och avsändare. Vyer (eng. vi-ews) är komponenter som användaren kan interagera med. Lager (eng. stores) kan ses som en variabel som hela applikationen har tillgång till. Handlingar (eng. actions) är funktioner som uppdaterar någon specifik del av lagret. Avsändare (eng. dispatcher) ser till att alla lager får informationen som skickas via en handling.

Flödet i Flux går på så sätt i en cirkel: när en användare interagerar med en vy skickas en handling med information till alla lager via en avsändare. När lagren sedan blir uppda-terade sänds en signal till vyerna som då kan uppdatera sig själva med ny information från lagren [35]. Figur 3.1 illustrerar informationsflödet i en Flux-applikation. Facebook designa-de Flux med ReactJS-komponenter i åtanke och ett av designa-de mest populära metodesigna-derna för att implementera Flux är med Redux [57, 140].

Redux är ett JavaScript-bibliotek med öppen källkod som har ett API som tillåter utveck-laren att snabbt och enkelt implementera delarna som behövs för en Flux applikation. [140]

Avsändare (Dispatcher) Handling (Action) Vy (View) Lager (Store)

Figur 3.1: Ett diagram för informationsflödet i en Flux-applikation.

3.3

AWS AppSync

Appsync är en tjänst från Amazon Web Services (AWS) för att tillhandahålla GraphQL API:er. Tjänsten gör att utvecklare lätt kan koppla ihop många enheter som samlar in och/eller visar upp gemensam data, utan att behöva implementera egen serverhantering. Serverkommuni-kationen sker med databasspråket GraphQL som låter användaren själv välja vilka data som ska hämtas och på vilket format. Det går även att prenumerera på data så att uppdateringar sker kontinuerligt. [3]

För att koppla upp sig mot databasen krävs autentisering, vilket kan göras med en nyc-kel eller med hjälp av andra AWS-tjänster, om mer avancerad hantering av åtkomstnivåer behövs. [3]

3.4

Utvecklingsspråk

3.5. Bibliotek & ramverk

3.4.1

HTML

Hypertext Markup Language (HTML) är ett märkspråk som används för att representera alla vi-suella element på en hemsida. Det är vad alla moderna och mest populära webbläsare tolkar för att visa en grafisk representation av sidan. [147]

3.4.2

CSS

Cascading Style Sheets (CSS) är ett språk som används för att beskriva grafiska attribut. Det gäller allt ifrån färger till textstilar och appliceras oftast på HTML-element. [143]

3.4.3

JavaScript

JavaScript är ett ECMAScript-baserat högnivåspråk med stöd för flera programmeringspara-digm. Det är ett konventionellt programmeringsspråk som används för att beskriva logiska beteenden som skall utföras på en hemsida genom att interagera med hemsidans DOM. Detta kan vara beteenden i samband med användarinteraktion, men också helt oberoende händel-ser eller kontinuerliga beteenden. [31]

3.5

Bibliotek & ramverk

Följande bibliotek och ramverk har använts i projektet. Utöver de som nämns i detta kapitel har även Redux använts. Detta beskrivs i kapitel 3.2.

3.5.1

React

ReactJS är ett ramverk utvecklat och uppehållet av Facebook. Det använder sig av JavaScript och innehåller verktyg i formen av en myriad av funktioner som kan användas för att gene-rera allt som ingår i en hemsida. [62]

Där webbbutveckling oftast ses som att ha en annorlunda struktur från andra typer av program så ger React möjligheten att utveckla webbsidor på ett mer konventionellt sätt ge-nom att skriva största delen av all kod i endast JavaScript.

3.5.2

PostCSS

Även om ReactJS ger möjligheten att generera alla delar av hemsidans kod, är det ofta inte en önskad struktur att ha, då koden kan bli svårläst och svårhanterlig. Därför används ofta CSS fortfarande vid sidan av React. För hjälp med detta finns PostCSS som är ett JavaScript-bibliotek som huvudsakligen består av en kodtolk. Den tillåter användningen av komplexa strukturer som inte existerar i CSS i samband med vanlig CSS. Denna kombination av kod kan sedan tas in av tolken och översättas till endast CSS som webbläsaren kan förstå.[32]

3.6

Testverktyg

För att underlätta skapandet av automatiska tester har Jest och React Testing Library använts.

3.6.1

Jest

Jest är ett ramverk till JavaScript som underhålls av Facebook som designades för att förenkla testning av stora webbapplikationer. Jest kräver mycket lite konfiguration för att sätta upp vilket minskar tröskeln att komma igång med testningen. [36]

3.6. Testverktyg

3.6.2

React testing library

React Testing Library är ett testverktyg till JavaScript specifikt för ReactJS som utökar det grundläggande JavaScript Testing-biblioteket genom att lägga till ett API som fungerar med React-komponenter. Detta bibliotek kommer förinställt om man startar projekt genom Create React App. [29]

3.6.3

System Usability Scale

System Usability Scale (SUS) är ett snabbt och enkelt verktyg för att mäta användavänlighet. Användare av systemet ombeds besvara på specifika enkätfrågor med påståenden på en skala ett till fem. Där ett står för att personen inte alls håller med påståendet och fem står för att personen håller med till fullo. Följande frågor används:

1. Jag kan tänkta mig använda systemet igen 2. Jag tycker att systemet är onödigt komplext 3. Jag tycker att systemet är enkelt att använda

4. Jag tror att jag hade behövt teknisk support för att fortsätta kunna använda systemet i framtiden

5. Jag tycker att systemets delar är väl integrerade

6. Jag tycker att systemet innehåller för många ologiska delar

7. Jag kan tänka mig att andra personer skulle kunna lära sig att använda detta systemet snabbt

8. Jag tycker att systemet är besvärligt att använda 9. Jag kände mig bekväm när jag använde systemet

10. Jag behövde lära mig många saker innan jag kunde använda systemet Varje svarsvärde sätts sedan in i följande ekvation:

• Varje udda numrerat svar subtraheras med ett.

• Varje jämnt numrerat svar multipliceras med minus ett och adderas med fem. • Avslutningsvis summeras alla nya värden och multipliceras med 2,5.

Resultatet blir en skala från 1 till 100 som visar hur användarvänligt ett system är. Minst 68 poäng anses vara över genomsnittet och indikera att användarvänligheten för systemet är bra. [142]

4

Metod

I detta kapitel beskrivs hur arbetet med projektet utfördes. Här behandlas: hur gruppen var organiserad, hur mjukvaran utvecklades, hur gruppen arbetade för att fånga erfarenheter, samt hur systemets prestanda utvärderades.

4.1

Projektorganisation

Projektet genomfördes i en grupp om 8 personer, där alla hade en specifik roll med tillhörande ansvarsområden. Inför rolltilldelningen fick samtliga teammedlemmar värdera hur gärna de ville ha en roll på en tregradig skala och efter gemensam diskussion blev resultatet följande:

• Teamledare - Yen Dinh

Teamledaren hade som ansvar att leda arbetet och se till att de processer som bestämts i gruppen följdes. Personen representerade gruppen utåt och hade kontakt med hand-ledare samt examinator. I fall där det behövdes hade teamhand-ledaren sista ordet.

• Analysansvarig - Alfred Sundstedt

Analysansvarig var den person som hade mest kontakt med kunden samt hade som ansvar att ta reda på kundens verkliga behov och dokumentera projektets krav. • Arkitekt - Jesper Fasth

Arkitekten hade som ansvar att ta fram en stabil arkitektur och göra övergripande tek-nikval. Rollen hade som ansvar att dokumentera arkitekturen och hade sista ordet i teknikfrågor.

• Utvecklingsledare - Axel Wretman

Utvecklingsledaren ansvarade för den detaljerade designen av produkten och fattade beslut om utvecklingsmiljön. Rollen ledde och fördelade utvecklingsarbetet till resten av gruppen.

• Testledare - Filip Johansson

Testledaren beslutade systemets status genom att testa kvalitetskraven tillsammans med kvalitetssamordaren. Rollen ansvarade för att testplan och testrapport skrevs.

4.2. Utvecklingsmetod

• Kvalitetssamordnare - Carl Södersten

Kvalitetssamordnaren såg till att kvaliteten av arbetet höll måttet och budgeterade för detta. Kvalitetssamordaren hade även ansvar för att en kvalitetsplan skrevs.

• Dokumentansvarig - Miriam Rosén

Dokumentansvarig tog fram dokumentmallar och logotyp för gruppen. Rollen ansva-rade för att samtliga dokument blev klara i tid för deadlines. Med detta jobbade de mycket med kvalitetssamordare och konfigurationsansvarig.

• Konfigurationsansvarig - Svante Martinsson

Konfigurationsansvarig bestämde vilka arbetsprodukter som skulle versionhanteras och bestämde vilka produkter som ingick i en utgåva. Rollen valde och underhöll där-för verktygen som användes där-för version- och konfigurationshantering och såg till att de användes på rätt sätt.

4.2

Utvecklingsmetod

I detta kapitel beskrivs det hur utvecklingen av produkten skett. I medföljande delkapitel behandlas: kravinsamling, planering, arbetssätt, utbildning, versionshantering och testning.

4.2.1

Kravinsamling

För att samla in krav hade projektgruppen inledningsvis ett möte med Neue Labs. På det mötet höll Neue Labs en översiktlig presentation om uppdraget, där den tänkta produkten beskrevs. Därefter hölls ett kravmöte, som fokuserade mer på att hitta företagets verkliga behov och på att sätta upp krav för produkten. De identifierade kraven infördes i en kravspe-cifikation och innefattade mestadels funktionella krav. Sedan genomfördes ett möte kopplat till UX och UI, som genererade några icke-funktionella krav. När de icke-funktionella kra-ven var införda i kravspecifikationen, kompletterades den med ytterligare några krav som kandidatgruppen ansåg som viktiga. Därefter granskades alla kraven i kravspecifikationen av gruppmedlemmar som ej deltagit i skrivandet av kravspecifikationen samt handledare. Slutligen konverterades kraven till uppgifter i Jira. När projektet sedan gick emot sitt slut och Jira uppgifterna blev färre hade projektgruppen ett till möte där kravspecifikationen diskute-rades. Med erfarenheterna som projektgruppen samlat kring utvecklingen upptäcktes några funktionella krav och icke-funktionella krav som inte längre var relevanta till produkten. Des-sa krav ströks och projektgruppen Des-samt Neue Labs godkände den nya kravspecifikationen.

4.2.2

Planering

Projektet utfördes enligt Scrum och planering gjordes därför iterativt. Detta projekt utfördes med en sprintlängd på en vecka och varje måndag hölls ett sprintmöte där den tidigare sprin-ten utvärderades samt nästa sprint planerades.

Sprintplaneringen bestod i att fastställa några övergripande mål för veckan samt identifi-era aktiviteter som behövde utföras för att målen skulle uppfyllas. Aktiviteterna lades sedan in som ärenden i Jira och flyttades till “Att göra”-kolumnen för innevarande sprint. Under veckan kunde sedan teammedlemmarna välja vilken uppgift de ville ta sig an genom att tilldela den till sig själv i Jira.

För att identifiera lämpliga mål för veckan togs de milstolpar och beslutspunkter som definierats i projektplanen i beaktning. De aktiviteter som togs fram stämdes av mot krav-specifikationen för att säkerställa att rätt saker utvecklades.

Utifrån milstolparna i projektplanen definierades fyra faser för projektet, där varje fas motsvarade en iteration av vidareutveckling av produktprototypen. Produkten genomgick tre prototypstadier innan slutgiltig leverans och längden på varje fas vara ungefär tre veckor.

4.2. Utvecklingsmetod

4.2.3

Arbetssätt

Gruppen valde flera olika verktyg för att kommunicera inom och utanför gruppen. Ett av dessa var Microsoft Teams, en applikation som har chatt- och videofunktioner [91]. Detta var också en plats där gruppen förvarade inofficiella dokument som endast berörde gruppen eller handledaren, såsom mötesdokument. I Teams valde gruppen att ha två kanaler, allmänt och utveckling. I utvecklingskanalen ställdes frågor som hade med kodutvecklingen att göra och i den allmänna kanalen skrevs allt annat som berörde hela gruppen, såsom meddelanden om att de inte kunde närvara vid ett möte. Det var även i denna kanal som gruppen höll sina möten, som exempelvis de dagliga Scrum-mötena.

Då hela utbildningen skedde på distans, arbetade gruppen på distans under hela pro-jektets gång. Utvecklingen av produkten skedde i första hand i par, där någon tog en av de uppgifter som fanns att göra i Jira och arbetade med någon annan i gruppen som ville vara med. När paret var klar med uppgiften de valt, granskades den av antingen gruppens ut-vecklingsledare eller gruppens konfigurationsansvariga. De lade då in kommentarer i koden om nödvändigt och markerade committen som granskad när det var klart. Kodgransknings-processen fungerade på samma sätt även när programmeringen inte gjordes i par.

Med hjälp av verktyget Jira kunde gruppen få en övergripande bild på hur de låg till varje vecka för att förhindra risken för restarbete. Om arbete återstod i slutet av veckan var målet att utföra det arbetet så tidigt som möjligt den nästkommande veckan. Såg det ut att bli en för stor mängd restarbete togs detta upp på ett gruppmöte för att diskutera lösningar.

4.2.4

Utbildning

Projektet använde sig av flera olika verktyg, språk och tekniker som de flesta projektmedlem-mar inte haft någon erfarenhet med sedan tidigare. Därmed behövde gruppmedlemprojektmedlem-marna utbilda sig inom olika områden, innan utvecklingen av produkten kunde börja. Varje grupp-medlem fick själv välja på vilket sätt som utbildningen skulle gå till samt när detta skedde. Det kunde till exempel vara genom läsning, videoklipp eller genomförandet av utbildande uppgifter. Utöver dessa individuellt inriktade metoder skedde även utbildning i grupper, genom att mer erfarna gruppmedlemmar utbildade andra eller att medlemmar tillsammans bekantade sig med verktyget.

De områden som gruppmedlemmarna utbildade sig inom var till en början taget utifrån vad kunden hade rekommenderat. Senare skapade utvecklingsledaren ett dokument kallat Utvecklingsresurser, som sammanfattade utbildningsområden mer konkret, utifrån de verk-tyg, språk, ramverk med mera, som gruppen hade bestämt skulle användas. I dokumentet fanns även rekommenderade utbildningssidor länkade för varje område.

Därtill skapade konfigurationsansvarig ett dokument kallat Git-Process, som innehöll en utbildande guide i hur gruppmedlemmar skulle följa standarden för projektets versionshan-tering.

4.2.5

Versionshantering

Gruppen använde sig av Git för att versionshantera progamkod. Sättet gruppen arbetade med versionshantering skulle kunna jämföras med Gitflow [9]. Gruppen utvecklade dock en egen version av detta som huvudsakligen använder sig av två grenar, master och dev. Eftersom gruppen använde sig av Jira kunde den som ville utveckla en ny funktion, ta ett kort (ett kort är den visuella formen av en uppgift) i Jira och flytta det till “in progress”. När personen gjort detta skulle en lokal gren skapas, som utgår från dev-grenen, för denna funktion. Grenen skulle då som namn ha aktivtetens id, som kunde ses på kortet i Jira.

Personen skulle sedan arbeta på denna gren lokalt. Aktivitetsgrenarna pushades inte till GitLab, med undantag för ett fåtal gånger då halvfärdiga aktiviteter skulle lämnas över mellan gruppmedlemmar. När personen kände sig färdig för att integrera sin funktion med dev-grenen skulle personen uppdatera sin lokala version av dev-dev-grenen och sedan använda sig

4.2. Utvecklingsmetod

av Git-kommandot ”Git rebase” för att få dev-grenens ändringar till sin aktivitesgren. När personen sedan fixat eventuella konflikter kunde personen använda sig av ”Git merge” för att flytta ändringarna till dev-grenen.

Denna metod ledde till att Git-historiken blev helt linjär, vilket var fördelaktigt då den blev lättare att följa och förstå. Ett exempel på skillnaden mellan kommandona git rebase och git merge kan ses på bild 4.1.

Figur 4.1: Skillnaden på merge och rebase

Mastergrenen är den gren där gruppen endast hade fungerande och stabila versioner av produkten. Detta var speciellt användbart när en demonstration av produkten skulle visas upp för kunden då gruppen kunde vara någorlunda säkra på att de alltid hade något att demonstrera.

Gruppen använde sig av GitLab för att lagra projektets kodbas. Gruppen använde sig även av GitLabs CI/CD-verktyg för att bygga en pipeline som kördes varje gång någon pushade kod till kodförrådet(eng. repository). Denna pipeline testade att bygga projektet, körde auto-matiska tester och kollade att koden följde den stilstandard som gruppen valt.

Dokument har valts att inte versionshanteras med Git utan de versionshanterats på ett mer manuellt sätt. Med hjälp av tjänsten Overleaf skrevs dokumenten tillsammans och när gruppen kände att det var en färdig version gjordes en kopia av den som också sparades.

4.2.6

Testning

Metodiken för testningen som utfördes kan delas upp i tre delar: enhetstester, integrations-tester, och acceptanstester.

Enhetstester

Enhetstester utfördes kontinuerligt under utvecklingsfasen och skrevs av personen som arbe-tat med utvecklingen av den aktuella funktionaliteten. Utvecklaren ansvarade själv för exakt vad som testades.

Integrationstester

Integrationstester utfördes i samband med att en funktionalitet integrerades med resterande kodbas, mer specifikt i samband med en merge till dev-grenen (Se Versionshantering). Då

4.3. Metod för att fånga erfarenheter

testade utvecklaren att den nya funktionaliteten, som klarat sina enhetstester, inte förstör-de någon annan funktionalitet. Integrationstester har i syfte att testa interaktion med annan existerande funktionalitet och då integrationen med sagd funktionalitet.

Detta gjordes på automatisk väg med testfiler som simulerade en användares interaktio-ner med applikationen. Testfilerna hade en förutbestämd kedja av funktionsanrop som mot-svarade relevanta användarval till funktionerna som skulle testas. Syftet med detta var att se till att den nya funktion som lades till inte ändrade slutresultatet när andra funktioner blev inblandade.

I de automatiska testerna användes React Testing Library för att simulera användarinterak-tion med applikaanvändarinterak-tionen. För att simulera funkanvändarinterak-tioner som interagerade med databasen, eller som på annat sätt föll utanför ramarna för vad det aktuella testet skulle testa, användes Jest. Acceptanstester

Acceptanstester utfördes som manuella end-to-end tester. Detta handlade om att testa att ap-plikationen uppfyllde kraven för aktuell prototypiteration och se till att apap-plikationen gav rätt resultat till de inmatningar som gavs. Detta utfördes alltså genom så kallad black-box testing där testaren inte bryr sig om vad som specifikt händer i koden, utan endast att ap-plikationen ger de resultat som efterfrågas i en viss situation med specifika parametrar. För att göra acceptanstester skrev projektgruppen en lista med instruktioner för manuella test. Acceptanstesterna baserades på kravspecifikationen och innehöll alla tester som behöver ge-nomföras för att verifiera att applikationen uppfyllde alla krav.

4.3

Metod för att fånga erfarenheter

Insamling av erfarenheter skedde framförallt under varje sprintplaneringsmöte. Mötet inled-des alltid med en reflektion av förra sprinten. Genom att gruppmedlemmar presenterade po-sitiva och negativa erfarenheter under förra sprinten kunde gruppen ta lärdom av varandra samt diskutera åtgärder vid behov. Under sprintplaneringsmötet samlades även erfarenheter genom att alla svarade på en anonym enkät om förra sprinten.

Utöver sprintplaneringsmöten kunde erfarenheter delas under gruppmöten, dagliga Sc-rum-möten, via Microsoft Teams-meddelanden eller under konversationer mellan gruppmed-lemmar.

4.4

Metod för att utvärdera prestanda

För att utvärdera systemets prestanda med avseende på biblioteken (ReactJS och Redux) ut-fördes en litteraturstudie.

Litteraturstudien syftade till att undersöka de teoretiska för- och nackdelarna med projek-tets val av bibliotek samt arktiekturmönster. För att hitta källmaterial till studien användes sökmotorn Google Scholar med söksträngarna: “react redux performance” samt “react java-script performance”. Efter att ha läst titlarna på de 20 första resultaten för vardera sökning, samt abstract för 3 respektive 4 av dem, valdes 2 artiklar ut.

I sökmotorn Google användes söksträngen ”performance increase frameworks javascript” där rubrikerna och rubrikens adress lästes för de första 10 resultaten av 215 miljoner. Utifrån dessa valdes en ut på grund av att webbadressen var till en rapport från databasen DiVA och för att rubriken var relevant till studien. Anledningen till varför rubrikens adress lästes var för att få källor av god kvalité från hemsidor där vanliga användare inte kan ändra innehållet.

5

Resultat

I detta kapitel presenteras projektets resultat. Här beskrivs systemet som utvecklades, hur arbetsprocesser utvecklats, samt vilka erfarenheter som gruppen tar med sig från projektet. Kapitlet avslutas sedan med en översikt över de individuella delar som projektets medlem-mar bidragit med.

5.1

Systembeskrivning

Systemet som utvecklats är en webbapplikation för enklare visuell programmering. I detta kapitel beskrivs applikationens funktionalitet och utseende.

5.1.1

Begrepp

Två begrepp som är centrala i systembeskrivningen är flow och patch. Här ges därför en något mer utförlig förklaring av dessa begrepp än den som finns i ordlistan.

Flow

Ett flow är det program man programmerar, i applikationen, och visualiseras som en flödes-graf med patcher och kopplingar.

Patch

En patch kan liknas vid en funktion inom matematik eller programmering. En patch kan ha in- och/eller utgångar. Det är alltså inte nödvändigt att en patch har både in- och utgångar men minst en av dessa måste finnas för att den ska ha någon form av effekt.

Patcher används för att bygga ett flow, där de representerar noderna i flödesgrafen som kopplas ihop för att skapa logik.

Utöver vanliga patcher finns några speciella typer. För att förstå förklaringen av applika-tionen nedan så är det viktigt att förstå vad en grupp-patch är. En grupp-patch fungerar som en egenskapad patch och kan redigeras precis som ett flow.

5.1. Systembeskrivning

5.1.2

Applikation

Den webbapplikation som utvecklats består huvudsakligen av tre olika sidor: inloggning, flows och editor.

Inloggningssidan är simpel och har ingen annan funktionalitet utöver inloggningen. Figur 5.1 visar dess utseende.

Figur 5.1: Inloggningssidan

På flows-sidan visas porträtt för alla de flows som den inloggade användaren har tillgäng-liga i den valda arbetsytan. Vilken arbetsyta som ska visas kan väljas på Neue Labs webbsida, och är ett sätt att gruppera sina flows på. På denna sida finns möjlighet att redigera eller änd-ra inställningar på flows. Det går även att dupliceänd-ra, ta bort eller skapa nya flows. På bild 5.2 syns det ikoner på porträttet med namn “My flow 1” eftersom musmarkören befann sig över det porträttet när bilden togs. Den nedre vänstra ikonen används för att duplicera och den nedre högra används för att ta bort en patch. Kugghjulet används för att visa inställningarna och pennan i mitten används för att gå in i “editor”-vyn.

Figur 5.2: Flows-sidan

Pennan i mitten av ett flow är en knapp som öppnar editor-vyn för just det flowet, denna vy visas på bild 5.3. I detta fall redigeras flowet “My flow 1” vilket syns uppe i högra hörnet.

5.1. Systembeskrivning

Den högra menyn, “Patch list”, är en lista med tillgängliga patcher som kan dras eller klickas in i arbetsytan. Patcherna i patch-listan är grupperade i olika kategorier, vilket syns på bild 5.3.

Denna vy används för att redigera ett flow, lägga till nya patcher, redigera patcher och koppla ihop patcher. Ett exempel på ett flow med patcher kan ses på bild 5.4 där arbetsytan är utzoomad och sidomenyerna är indragna för att se mer av arbetsytan.

Figur 5.3: Editor-sidan

5.1. Systembeskrivning

På varje enskild patch finns det en kugghjulsikon som används för att komma åt den patchens inställningar. Vad som finns i inställningarna kan variera mellan olika patch-typer. Ett exempel på en inställningsmeny kan ses på bild 5.5.

Figur 5.5: Inställningar för en patch av typen “iOS Notification”

In- och utgångar kan även läggas till och tas bort på varje patch. För att lägga till en in- eller utgång klickar man på “Add value”-texten som syns på alla patcher. Vilka in- och utgångar som finns tillgängliga beror på patch-typ. Det finns även två speciella patch-typer: “Group patch” och “Design page”, där man kan byta namn på tillagda in- och utgångar.

En in- eller utgång markeras genom att användaren klickar på den. När in- eller utgång-en väl är markerad kan användarutgång-en radera dutgång-en gutgång-enom att klicka på delete eller backspace-tangenten.

Den vänstra menyn som syns på bild 5.3 används vid redigering inuti en grupp-patch för att veta på vilket djup som redigeringen sker på. Exempel på hur det kan se ut vid redigering inuti en grupp-patch kan ses på bild 5.6.

Om ytterligare en grupp-patch läggs till i detta exempel och redigeringen utfördes inuti den patchen, hade även den synts i den vänstra menyn under “Min grupp-patch”. Detta ger användaren en tydlig överblick av sitt arbete och det blir tydligt var redigeringen sker i relation till toppnivån av flowet.

Alla de ändringar som görs på patcher i arbetsytan synkroniseras med Neue Labs backend kontinuerligt. Ändringar som utförs i webbapplikationen behöver alltså inte sparas manuellt av användaren för att de ska bli tillgängliga i iOS-applikationen.

Det går även att enkelt gå över från mobilapplikationen till webbapplikationen med redan existerande flows som är utvecklade i mobilapplikationen. Webbapplikationen generar en temporär layout för flows som aldrig öppnats i webbapplikationen förr, exempel på layout som generats automatiskt visas i bild 5.7.

5.1.3

Synkronisering med iOS-applikationen

Applikationen använder sig av AWS Appsync (se 3.3) för att vara synkroniserad med iOS-applikationen. Som nämnts tidigare så synkroniseras alla ändringar som sker på editor-sidan kontinuerligt genom att applikationen skickar GraphQL-frågor efter varje ändring. Detta in-nebär att det enda som behövs för att ändringarna från webbapplikationen ska synas är att iOS-applikationen laddas om.

5.2. Värde för kunden

Figur 5.6: Redigering inuti en grupp-patch

Figur 5.7: Layout genererad av webbapplikationen

5.1.4

Systemanatomi

Systemanatomin, figur 5.8, beskriver hur olika delar av projektet hänger ihop. Den användes främst i ett tidigt stadie av projektet för att skapa en översikt över systemet som skulle ut-vecklas. Med hjälp av den lades en grundläggande plan på i vilken ordning de olika delarna skulle utvecklas. Senare under projektets gång blev dock kravspecifikationen underlag för mer detaljerad planering.

5.2

Värde för kunden

Värdet kunden får från detta projekt är en ny plattform för programmering av deras IoT-enheter. Innan fanns endast en iOS-applikation. Kunden ansåg att det var omständigt att använda applikationen för att göra stora flows och att det fanns ett värde i att kunna göra det i en 2D-vy istället, i form av en webbapplikation.

5.3. Utvärdering av produkten

Figur 5.8: Systemanatomi

5.3

Utvärdering av produkten

Följande avsnitt beskriver hur väl produkten uppfyller kraven samt hur produkten kan ut-värderas på andra sätt.

5.3.1

Krav

Kravspecifikationens bestod av totalt 85 krav, varav 82 krav hade prioritet 1 och 3 krav hade prioritet 2. Kraven verifierades genom acceptanstest, där 82 prioritet 1 krav och 1 prioritet 2 krav var uppfyllda 2021-05-24. [69].

5.3.2

Systemets prestanda

I detta projekt har biblioteken ReactJS och Redux med arkitekturmönstret Flux använts. I detta kapitel redovisas resultatet av litteraturstudien som genomfördes för att utvärdera systemets prestanda, såsom svarstid eller DOM-manipulering med avseende på de bibliotek som an-vänts.

I Performance, Modularity and Usability, a Comparison of JavaScript Frameworks [110] testar Ockelberg och Olsson olika ramverk och mäter prestandan för dessa genom olika uppgifter. Två sätt som författarna mätte prestandan på var bland annat genom hur snabbt ramverket kunde hantera DOM-manipulering och minnesallokering. Uppgifterna kunde då vara att ska-pa, uppdatera, radera eller flytta på data för att se hur det påverkade prestandan. Ett annat sätt de kollade på detta var genom att titta på hur långt tid det tog att starta upp den färdiga applikationen. Tiderna för alla dessa tester mättes med hjälp av Google Chromes utvecklar-verktyg och efter varje test gavs poäng ut baserat på resultaten. Testerna utfördes på en Single Page Application som författarna skapat.

De ramverk som författarna i Performance, Modularity and Usability jämförde mellan var Angular, ReactJS och Vue. Vid skapande av element i DOM:en var ramverket Vue snabbast, men med liten marginal. Författarna förklarar att denna marginal kunde bero på inkonse-kventa tester och deras slutsats är att när det kommer till skapande av element är valet av ramverk oväsentligt [110]. Vid uppdatering och radering av element presterade Angular bäst och Vue sämst i båda testerna. Detta ledde även till att Angular ansågs vara bäst och Vue sämst översiktligt när det gällde DOM-manipulering.

När det kom till minnesallokering hade alla tre ramverken liknande tider. Angular hante-rade större arrays snabbare, men mindre arrays långsammare och React gjorde det motsatta. Författarna gav de tre ramverken samma poäng då skillnaden var liten och de tre ramverken antagligen allokerade minne på liknande sätt. [110]

5.4. Processbeskrivning

Den största skillnaden i ramverken kan ses på starttiden av applikationen. Projektet som använde sig av React hade störst byggstorlek, men snabbast starttid i jämförelse med de and-ra and-ramverken. Detta var något som förvånade författarna som trodde att byggstorleken skulle påverka starttiden och därmed prestandan [110]. Denna skillnad bidrog till att React ansågs vara det bästa ramverket när det kommer till prestanda, skriver författarna [110].

I JavaScript DOM-Manipulation Performance får Persson istället att Vue och React har lik-nande starttid och att Angular har längst starttid [115]. Författaren kommer också fram till att React är ramverket som är bäst på DOM-manipulering då det har bäst resultat i tre av de fyra tester som utfördes. Angular har liknande resultat som React och Vue är lite långsammare än båda dessa två med längst tid i tre av fyra test.

I rapporten Ramverk vs Vanilla JavaScript [50] kommer författaren fram till att ramverken Vue och React har likvärdig prestanda, genom att mäta på liknande sätt som Ockelberg och Olsson gör. Gustafsson väljer dock att fortsätta sin studie med hjälp av Vue, då hans applika-tion var av mindre skala, eftersom hans litteraturstudie antydde att React var bättre för större applikationer.

5.4

Processbeskrivning

Vid samarbetet med kursen TDDE46 bestämde kvalitetssamordaren och testledaren att pro-cessen Scrum skulle ligga i fokus under projektet. Samarbetet resulterade även i att ett antal kvalitetskrav bestämdes.

5.4.1

Scrum

Genom användningen av Scrum har gruppen fått en bättre överblick av hela arbetet och vad som behövt göras när. De dagliga Scrummötena har sett till att varje gruppmedlem alltid har haft något att göra. Det förhindrar även att gruppmedlemmar kör fast då kommunikationen vid morgonmöten försäkrar att de som behöver hjälp får det.

Mätning av processen

För att mäta utvecklingen av processen Scrum genomfördes en anonym enkät under varje sprint-planeringsmöte. Genom att samla in gruppens åsikter och tankar så kunde vi se hur bra processen fungerade och se om det behövdes göras några förbättringar. Enkäten bestod av följande frågor, där fråga 1,3,4,5 var obligatoriska:

1. Hade förra sprinten tydliga mål? 1-5 2. Varför var målen tydliga/otydliga?

3. Hur upplevde du att gruppen följde planeringen? 1-5 4. Hur upplevde du arbetets svårighet förra sprinten? 1-5 5. Hur roligt var arbetet i förra sprinten? 1-5

6. Vad fungerade bra under förra sprinten?

7. Vad fungerade mindre bra under förra sprinten?

8. Vilka var de största hindren för att nå förra sprintens mål? 9. Vad kan förbättras till nästa sprint?

Efter att samtliga gruppmedlemmar fyllt i enkäten var det kvalitetssamordnarens uppgift att bestämma om det behövdes ett gruppmöte för att diskutera hur gruppen kunde åtgärda problemen som enkätsvaren belyste.

5.4. Processbeskrivning

Processförbättring

Till en början var alla relativt ovana vid att använda Scrum samtidigt som gruppen inte kän-de varandra så bra. Detta bidrog till att processen inte fungerakän-de utmärkt. Gruppen hakän-de inte heller en bra kännedom om verktyget Jira eller hur det skulle användas på bästa sätt. Allt eftersom gruppen blev mer bekant med Scrum och fick en bättre gemenskap fungerade processen bättre.

Inledningsvis var Teamledaren Scrummästare då det kändes naturligt att den som är teamledare även tar den rollen i Scrumprocessen. När utvecklingen väl kom igång bestämde gruppen att det var mer passande att ha utvecklingsledaren som Scrummästare.

Utifrån de genomförda enkäterna belystes framförallt att gruppens användning av Jira kunde förbättras. Därmed så fokuserades processförbättringen på hur Jira användes som en del av Scrum. Resultatet från enkätens obligatoriska frågor 5.9 visar inte en tydlig förbätt-ring. Förbättringen av Jira kom främst utifrån textsvaren som “Vad kan förbättras till nästa sprint?”. Inledningsvis var gruppen mindre bra på att lägga till nya ärenden i Jira. Något som förbättrades avsevärt under senare delen av projektet. Tidigt i projektet kunde uppgifter påbörjas utan att det fanns ett ärende i Jira. Vilket i de värsta fall ledde till att två personer jobbade på samma uppgift samtidigt. Detta kunde även ske då gruppen missade att se över ärenden som redan fanns i Jira. Gruppen hade även en tendens att lägga till nya ärenden utan detaljerad beskrivning av uppgiften eller förklaring av problemet. Genom att i senare delen av projektet till exempel rapportera in buggar med tydliga videoklipp som visade problemet, blev ärendehanteringen mycket mer effektiv.

Figur 5.9: Grafer som visar gruppens svar på enkätens obligatoriska frågor under samarbetet med TDDE46.

5.4.2

Kvalitetskrav

Då projektet behövde inkludera mätbara kvalitetsmål bestämdes ett antal kvalitetskrav uti-från bestämda kvalitetsfaktorer. Kvalitetssamordaren tillsammans med testledaren valde att kvalitetsfaktorerna användbarhet och korrekthet skulle ligga i fokus. Därefter adderades un-derhållsmässighet som ett fokus efter förfrågan från kunden. Nedan följer varje kvalitetsfak-tor, dess relaterade kvalitetskrav samt hur kraven mättes.

Funktionalitet

Funktionalitetskravet handlade om att uppfylla kunden Neue Labs krav på systemets funk-tionalitet. Kravet var följande:

5.4. Processbeskrivning

Kravet verifierades genom projektets acceptanstest [69]. Underhållbarhet

Kravet på underhållbarhet berörde möjligheten till förståelse och vidareutveckling av syste-met. Kraven var följande:

• Alla funktionselement i systemet ska ha det modifierade LCOM4-värdet lika med 1. • Systemets källkodsfiller ska ha ett kommentarindex inom intervallet 1 och 1,5.

Lack of Cohesion of Method v.4 (LCOM4) är ett sätt att mäta sammandragning i ett system [111]. Ökad sammandragning i ett system gör det lättare att underhålla och vidareutveckla ett system. Varje funktionselement blir tilldelad ett värde beroende på hur många komponenter som är kopplade till kodobjektet. Där ett värde lika med 1 betyder att funktionselementet ingår i systemets sammahängande träd. Kravet verifierades utifrån acceptanstest [69].

Enligt 5.10 går det att se systemets kompetentträd. Vilket visar att alla komponenter är en del av ett sammanhängande träd.

Figur 5.10: Filhierarkin för systemets källkod.

Kommentarindex är ett värde skapat internt för att mäta hur väl systemet är dokumen-terat, vilket förenklar förståelseprocessen av systemet. Genom att antalet kommentarer i en

5.5. Gemensamma erfarenheter

fil divideras med antalet funktioner i filen fås en kvot som kallas kommentarindex. Kravet verifierades genom att gå igenom och säkerhetställa att alla funktioner hade en tillhörande kommentar. Kommentarindexet för hela systemet låg på 1,04. Utifrån 141 kommentarer divi-derat med 136 funktioner.

Användbarhet

Användbarhetskraven berörde möjligheten för användare att använda systemet. Kraven var följande:

• Systemet ska uppnå ett System Usability Scale resultat på minst 68.

• Systemet ska fungera på följande webbläsare: Google Chrome version 88.0.4324.182, Microsoft Edge version 88.0.705.74, Mozilla Firefox version 85.0.2 och Apple Safari ver-sion 14.0.

För att säkerhetställa att systemet är lätt att förstå och att använda, bestämdes det att använd-barheten skulle mätas utifrån skalan SUS, se 3.6.3 för en förklaring.

Kravet verifierades genom att sju ingenjörsstudenter i åldrarna 20 till 24 år använde syste-met i cirka tio minuter och sedan svarade på SUS-enkätfrågorna. Innan personerna började använda systemet fick de en kort bakgrund till projektet, kunden Neue Labs och systemet. Re-sultaten varierade från ett SUS-värde på 70 till 90. Med ett medelvärde på 76,8 och en median på 77,5.

Då användare högst troligen kan komma att använda systemet på olika webbläsare inför-des även krav på att systemet ska fungera på olika webbläsare. Kravet verifierainför-des genom att gruppen utförde acceptanstester för samtliga webbläsare listade i kravet. Det ska även tilläggas att webbläsarna Google Chrome, Microsoft Edge samt Mozilla Firefox även använ-des kontinuerligt av projektgruppen under utvecklingen. Det fanns alltid minst en utvecklare som hade en av de listade webbläsarna som föredragen användningsplattform för systemet.

5.5

Gemensamma erfarenheter

Följande avsnitt beskriver några av de erfarenheter som gruppen har samlat på sig under projektets gång.

5.5.1

Utbildning

Det märktes tidigt att gruppen låg på olika kunskapsnivåer inom webbutveckling. Om alla hade haft goda kunskaper sedan innan hade troligtvis utvecklingen fungerat bättre från bör-jan. Istället fick flera gruppmedlemmar spendera mycket tid på utbildning innan personerna kunde komma igång med utveckling. Skillnaden i kunskaper gjorde dock att gruppmedlem-mar med mer erfarenhet kunde hjälpa till med utbildningen för de andra.

En erfarenhet som flera projektmedlemmar fick under utbildningsfasen var att det var viktigt att blanda teori och praktik. Att enbart läsa dokumentation upplevdes inte speciellt givande, då informationen lätt glömdes bort när man inte fått använda den i praktiken. Den mest uppskattade metoden var att använda guider där praktiska övningsuppgifter var cen-trala och teori förklarades i samband med uppgifterna.

5.5.2

Kundrelation

Tidigt i projektet visade det sig att kunden endast var tillgänglig en gång i veckan under ett schemalagt kundmöte. Det gjorde att det kunde ta lång tid att få svar på frågor, särskilt i början av projektet då nya frågor var frekventa. Genom att påpeka vikten av en mer frekvent

5.6. Översikt över individuella bidrag

kommunikation kunde vi få till fler kundmöten och starta en bättre dialog via en ny chattka-nal i programmet Slack. Gruppen hade önskat en tätare kommunikation med kunden redan från startet av projektet då kommunikation med kunden var som viktigast.

5.5.3

Distansarbete

Hela projektet har skett på distans. Trots att hela gruppen tidigare hade jobbat med distanslä-ge i andra kurser under nästan ett år, så var det fortfarande en utmaning att få allt att fundistanslä-gera perfekt på distans. Särskilt vad gäller att lära känna varandra. En lösning var att ha flera tillfällen för teambuilding.

Gruppen har varje morgon haft ett så kallat “stand-up”-möte vilket har bidragit till att alla har känt att de har en bra inblick i arbetet. Det har även gjort det lätt att inte fastna då man var dag får en chans att ställa frågor till hela gruppen.

Utvecklingen skedde med en blandning av parprogrammering och programmering en-skilt. Gruppen valde att inte tvinga någon till att parprogrammera utan det var upp till varje medlem att själva välja vad som passade dem. Detta fungerade bra och inga problem upp-märksammades.

5.5.4

Tekniska lärdomar

Då utvecklingen i projektet använde sig av JavaScript med biblioteken ReactJS och Redux har gruppen lärt sig mycket om dessa. I framtiden, om ytterligare webbprogrammering skulle ske, är dessa bibliotek något som gruppen skulle kunna tänka sig att fortsätta använda. Därtill så har gruppmedlemmar fått lärdomar inom arkitekturmönstret Flux.

5.6

Översikt över individuella bidrag

Under projektets gång har samtliga gruppmedlemmar skrivit ett individuellt bidrag till rap-porten. I detta kapitel ges en kort översikt över de ämnen som gruppen fördjupat sig i.

5.6.1

Scrum i jämförelse med andra projektmodeller - Yen Dinh

Med hjälp av en litteraturstudie jämfördes Scrum, som valdes att användas i detta kandidat-projekt, gentemot andra projektmodeller för att avgöra om den är mest lämpad för ett projekt av denna skala. Detta genomfördes genom att svara på vilka för- och nackdelar det finns med de valda modellerna, där de sedan ställdes upp mot Scrums för- och nackdelar. Utifrån detta tas ett resultat fram om vilken typ av modell som är mest passande för ett projekt av samma skala som ett kandidatprojekt.

5.6.2

Hur webbläsaren blev skapad och hur den påverkar webbapplikationer

-Jesper Fasth

Då Neue Labs tidigare har utvecklat en iOS-applikation och detta projekt går ut på att utveckla en liknade webbapplikation som körs på fyra utvalda webbläsare är det relevant att se vil-ka skillnader det finns mellan webbläsarna och deras arkitektur, varför är det så, och vilken inverkan de har på webbapplikationer. För att svara på dessa frågor utfördes en litteratur-studie där frågorna “Vilka skillnader finns mellan dagens webbläsare?”, “Varför ser dagens webbläsare ut som de gör?”, och “Vilka krav sätter en webbläsares arkitektur på webbappli-kationer?” utvärderades.