hawkeyeliu.diva-portal.org/smash/get/diva2:1450968/fulltext01.pdfsammanfattning denna rapport...

Linköpings universitetSE–581 83 Linköping013-28 10 00 , www.liu.se

Linköpings universitet | Institutionen för datavetenskapExamensarbete på grundnivå, 15hp | Datateknik

2020 | LIU-IDA/LITH-EX-G--20/057--SE

Hawkeye– En titt in i framtidens räddningstjänstutrustningHawkeye– A peek into the future of emergency services

Bence NagyBjörn BirathEdvin BergströmErik AhlrothJakob SjöqvistJonathan HjortPayam TavakoliPhilip Gunnarsson

Handledare : Viktor BlidhExaminator : Kristian Sandahl

http://www.liu.se

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 forskning 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 upphovsmannensmedgivande. För att garantera äktheten, säkerheten ochtillgä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 somgod 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 hemsidahttp://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for aperiod 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-commercialresearch 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 publisherhas taken technical and administrative measures to assure authenticity, security and accessibility.According to intellectual property law the author has the right to bementionedwhen his/her workis 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/.

©

Bence NagyBjörn BirathEdvin BergströmErik AhlrothJakob SjöqvistJonathan HjortPayam TavakoliPhilip Gunnarsson

http://www.ep.liu.se/http://www.ep.liu.se/

Sammanfattning

Denna rapport beskriver kandidatprojektet Hawkeye. Projektet har utförts av åtta studen-ter inom kursen TDDD96 vid Linköpings Universitet. Projektet har handlat om att skapaett stöd till framtidens räddningstjänst med hjälp av en Microsoft HoloLens 2 som är äm-nad att användas av främre befäl. Huvudfunktionerna för Hawkeye var bland annat attströmma video och sensordata till den bakre ledningen samt erbjuda en mixed reality-vyför att visa information om verktyg och patienter ämnad för den för den främre ledningen.Projektets beställare var forskningsgruppen Ubiquitous Computing and Analytics Group vidInstitutionen för Datavetenskap på Linköpings universitet. Rapporten beskriver hur Haw-keye har framställts och de metoder som har tillämpats av projektgruppen, exempelvisScrum. I slutet av rapporten presenteras de individuella bidrag som gruppmedlemmarnahar skrivit och som är relaterade till Hawkeye-projektet.

ii

Författarens tack

Gruppen vill tacka Kristian Sandahl och kursledningen för en välplanerad kurs som givitgruppen förutsättningarna för att kunna utföra detta projekt. Gruppen vill även rikta ett extratack till gruppens handledare Viktor Blidh som har varit väldigt hjälpsam och bidragit medvärdefulla tips.

Vidare vill gruppen tacka Magnus Bång som var kunden till projektet. Magnus har varitväldigt tillmötesgående och gjort sitt yttersta för att bidra med de materiell som gruppenbehövt under projektets gång. Vid tekniska frågor har även Daniel Westberg, som arbetar iBångs team, bistått med mycket hjälp och handledning vilket gruppen vill tacka honom för.

iii

Innehåll

Figurer vii

Tabeller viii

Definitioner ix

1 Introduktion 11.1 Motivering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Bakgrund 32.1 Kunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Uppgift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Kundens system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 Tidigare erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Teori 53.1 Räddningsinsatser idag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Mixed reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 HoloLens 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.4 WebRTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.5 Programmeringsspråk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.6 Verktyg och program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Metod 124.1 Utvecklingsmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3 Metod för att fånga erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Resultat 195.1 Systembeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 Process i fokus: Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 Gemensamma erfarenheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.4 Framtida projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.5 Värde för kunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.6 Översikt över individuella bidrag . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Diskussion 336.1 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

iv

7 Slutsatser 427.1 Hur kan Hawkeye implementeras så att det skapar värde för kunden? . . . . . 427.2 Vilka erfarenheter kan dokumenteras från kandidatprojektet som kan vara in-

tressanta för framtida projekt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.3 Vilket stöd kan fås genom att skapa och följa upp en systemanatomi? . . . . . . 427.4 Hur kan modern teknologi i form av en Microsoft HoloLens användas för att

underlätta räddningstjänstens arbete under räddningsinsatser? . . . . . . . . . 43

A Jämförelse av utvecklingsprocessen och användningsområdena för spelmotorer-na Unity Engine och Unreal Engine av Bence Nagy 44A.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46A.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48A.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

B Jämförelse av Git-arbetsflöden av Björn Birath 50B.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50B.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51B.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51B.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55B.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

C Jämförelse av HLS och WebRTC för direktströmning av Edvin Bergström 57C.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57C.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58C.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58C.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59C.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59C.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63C.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

D Undersökning kring hur Scrum påverkar effektiviteten i en grupp av Erik Ahlroth 65D.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65D.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65D.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66D.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67D.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67D.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69D.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

E Problem och alternativ till lösenordsautentisering av Jakob Sjöqvist 71E.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71E.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72E.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72E.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73E.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74E.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76E.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

v

F Mjukvarutestning i små projekt av Jonathan Hjort 79F.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79F.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79F.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80F.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82F.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82F.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84F.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

G Olika kravhanteringstekniker i mindre mjukvaruprojekt av Payam Tavakoli 86G.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86G.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87G.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87G.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90G.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90G.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93G.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

H GDPR och Hawkeye av Philip Gunnarsson 95H.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95H.2 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95H.3 Teori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96H.4 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97H.5 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98H.6 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98H.7 Slutsatser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Litteratur 101

vi

Figurer

3.1 Webbserver i NiFi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Ett exempel på en systemanatomi och dess olika lager för en bankomat. . . . . . . 11

5.1 Översikt över ingående delsystem. Röda pilar representerar WebRTC-anslutningar, blåa websocket-anslutningar och svart HTTP, eller andra anslutningar. 20

5.2 Hjälmens meny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.3 Hjälmens vägvisningsläge samt undermenyerna . . . . . . . . . . . . . . . . . . . . 225.4 Hjälmens informationsläge samt undermenyerna . . . . . . . . . . . . . . . . . . . 225.5 Hjälmens chattruta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.6 Kommunikationsöversikt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.7 UML-sekvensdiagram för signaleringsprocessen . . . . . . . . . . . . . . . . . . . . 265.8 Dashboardens användargränssnitt utan videoanslutning . . . . . . . . . . . . . . . 275.9 Dashboardens användargränssnitt med videoanslutning . . . . . . . . . . . . . . . 285.10 Dashboardens användargränssnitt med chattruta . . . . . . . . . . . . . . . . . . . . 285.11 Översikt av resultaten från sprintåterblicksenkäten . . . . . . . . . . . . . . . . . . 29

6.1 Tidig översikt över alla delsystem och hur de förväntades kommunicera. Blåttmotsvarar redan befintliga system och grönt de som behövde skapas. . . . . . . . . 36

6.2 Systemanatomi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.3 Djupare översikt av alla delsystem och hur de kommunicerar. Blått motsvarar de

redan befintliga delsystemen, grönt de som gruppen skulle utveckla och rött kom-munikationsmetod. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.4 Översikt av alla delsystem och hur de kommunicerar. Blått motsvarar redan be-fintliga system, grönt de som behöver skapas och rött kommunikationsmetod. . . 38

B.1 Exempel på en merge. Cirklarna representerar commits. . . . . . . . . . . . . . . . . 52B.2 Exempel på hur en rebase kan se ut. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52B.3 Hur en (a) release och (b) hotfix gren kan se ut. . . . . . . . . . . . . . . . . . . . . . . 55

C.1 Ett UML sekvensdiagram över början av en HLS session . . . . . . . . . . . . . . . 60C.2 En bild över en WebRTC kommunikation utan en TURN server. Siffrorna visar i

vilken ordning som kommunikationen sker. . . . . . . . . . . . . . . . . . . . . . . . 61C.3 En bild över en WebRTC kommunikation med en TURN server. Siffrorna visar i

vilken ordning som kommunikationen sker. . . . . . . . . . . . . . . . . . . . . . . . 62

G.1 Exempel på ett Use Case Diagram [use-case-ex] . . . . . . . . . . . . . . . . . . . . 88G.2 Graf över svar på fråga 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91G.3 Graf över svar på fråga 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91G.4 Graf över svar på fråga 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92G.5 Graf över svar på fråga 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92G.6 Graf över svar på fråga 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

vii

Tabeller

3.1 Upplägg av Test First Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1 Gruppens upplägg på Kanbanbrädet . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Upplägg på Kodgranskning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3 Dokument som ska produceras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4 Rollfördelning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1 NiFi:s funktionalitet mot databasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 Exempel på websocketmeddelanden . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

D.1 Redovisar hur aktiviteter klarades av inom tidsramen av en sprintperiod . . . . . . 68D.2 Redovisar hur ofta påståenden kring aktiviteter stämmer . . . . . . . . . . . . . . . 68D.3 Redovisar hur ofta Scrum användes och hur bra det fungerade . . . . . . . . . . . . 68

G.1 Exempel på kravlista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89G.2 Frågorna i frågeformuläret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

H.1 Sökhistorik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

viii

Definitioner

• Hawkeye: Projektets namn.

• Hjälmen: Avser delsystemet som består av den trådlösa användarenheten, som blandannat innehåller en Microsoft HoloLens 2.

• Ignite: En databas som kunden redan besitter, den använder Apache Ignite.

• Dashboard: Avser delsystemet som är en webbapplikation med visualisering av video-ström och annan data från Hjälm och IoT-objekt. Används av bakre ledning.

• Bakre ledning: Refererar till personal som använder Dashboarden och övervakar situa-tionen från räddningsstationen eller annan fysisk plats.

• Främre befäl: Ledningspersonal som är på plats under en räddningsinsats.

• Google Calendar: En webbaserad kalendertjänst som har möjligheten att skapa deladekalendrar.

• Google Drive: En molntjänst för att skapa och dela filer, exempelvis textdokument, kal-kylark och presentationer.

• LaTeX: Ett typsättningssystem som används för att skapa tekniska och vetenskapligadokument.

• Overleaf: En webbaserad LaTeX-redigerare.

• IoT: Akronym för Internet of Things och motsvarar en enhet som är uppkopplad motinternet varifrån den kan hanteras och administreras.

• IoT-objekt: En IoT-sensorpuck som finns placerad på bland annat verktyg eller patien-ter. Skickar information till databasen om objektets plats och eventuell annan informa-tion.

• Latens: Den tid det tar för data att transporteras mellan två klienter.

• Mixed Reality: Sammanflätning av en virtuell värld och den verkliga världen. Använ-daren ser virtuella hologram som den även kan interagera med.

• Microsoft HoloLens: Ett Mixed Reality Headset utvecklat av Microsoft.

• Mixed Reality Toolkit: Ett verktyg utvecklat av Microsoft för att förenkla utveckling tillMixed Reality plattformar i Unity.

• MixedReality-WebRTC: Ett verktyg utvecklat av Microsoft som gör det möjligt att inte-grera WebRTC i Mixed Reality program.

• Node.js: En plattform för att med hjälp av JavaScript exekvera program på en server.

• JSON: Ett textbaserat format som används för att utbyta data.

ix

• Open-source: En term för att beskriva program vars källkod är släppt med en licenssom tillåter allmänheten att använda, studera och möjligtvis modifiera koden.

• Versionshantering: Ett sätt att spåra och jämföra ändringar som gjorts på en kodbas ellerannan data.

• Versionshanteringssystem: Ett program eller system som kan utföra versionshanteringpå given data.

• WebSocket: Ett kommunikationsprotokoll och kanal som tillåter full-duplex-kommunikation över en TCP-anslutning.

• Peer-to-peer: En datornätverksarkitektur där klienter kan kommunicera direkt, utannågon mellanhand, som exempelvis en server.

x

1 Introduktion

I detta kapitel introduceras och presenteras projektet, dess syfte, centrala frågeställningar ochavgränsningar.

1.1 Motivering

När en räddningsinsats ska utföras av räddningstjänstpersonal ställs de inför en tuff situa-tion. Det finns en hel del information de behöver ta del av för att få en bra lägesbild innaninsatsen kan börja. Att ha all information i bakhuvudet under insatsen sätter personalen i enstressad situation. Det är här projektet Hawkeye kommer in i bilden.

På uppdrag av forskningsgruppen Ubiquitous Computing and Analytics Group vid Institu-tionen för Datavetenskap på Linköpings universitet, har projektgruppen utvecklat mjukvaraför en hjälm och benämns som Hjälmen. Hjälmen ger med hjälp av Mixed Reality räddnings-tjänsten information om föremål på platsen. Hjälmen upprätthåller även kommunikationmed bakre ledning genom en videoström som skickas till ett webbaserat användargränssnitt.Användargränssnittet har även utvecklats som en del av detta projekt och kallas Dashboard.

1.2 Syfte

Syftet med projektet var att utveckla en prototyp bestående av mjukvara för en hjälm och entillhörande Dashboard. Prototypens syfte är att agera som konceptbevis för ett system somsyftar till att underlätta arbetet för räddningstjänstpersonal under räddningsinsatser. Syftetmed rapporten är att ge insikt i hur kandidatprojektet har utförts, vad det har resulterat i ochvilka erfarenheter projektgruppen har fått under projektets gång.

1.3 Frågeställningar

1. Hur kan Hawkeye implementeras så att det skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från kandidatprojektet som kan vara intressantaför framtida projekt?

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

1

1.4. Avgränsningar

4. Hur kan modern teknologi i form av en Microsoft HoloLens användas för att underlättaräddningstjänstens arbete under räddningsinsatser?

1.4 Avgränsningar

Projektet hade en begränsad tidsbudget på 380 timmar per gruppmedlem, vilket innebar entotal tidsbudget på 3040 timmar. Tidsbudgeten inkluderade utvecklingstid, tid för dokumen-tation, möten, utbildning och en individuell utredning.

2

2 Bakgrund

I detta kapitel kommer kunden, uppgiften, kundens nuvarande system och projektgruppenstidigare erfarenheter av att arbeta i projekt att beskrivas.

2.1 Kunden

Kunden för kandidatprojektet var forskningsgruppen Ubiquitous Computing and AnalyticsGroup vid Institutionen för Datavetenskap på Linköpings universitet. Forskningsgruppenssyfte är att bedriva forskning inom IT-området för att hantera katastrofer och olyckor medfokus på räddningstjänst och ambulanssjukvård. Projektgruppens kontaktperson och bestäl-lare var Magnus Bång.

Målet med den framställda prototypen var att den skulle agera som konceptbevis. Denframställda prototypen var inte ämnad att användas av räddningstjänsten men baserat påprototypens duglighet var det tänkbart att forskningsgruppen skulle kunna komma att åter-använda delar av systemet eller hela systemet för att vidareutveckla detta.

2.2 Uppgift

Uppgiften som gruppen fick av kunden var att förbättra kommunikationen mellan främrebefäl och bakre ledning samt att underlätta för främre ledning att hitta och få information omnyckelobjekt. Ett nyckelobjekt är ett objekt av särskilt värde för räddningstjänsten, exempel-vis patienter och verktyg. Detta skulle utföras genom att utveckla programvara till en hjälmmed integrerad HoloLens 2. Kundens önskemål var att projektgruppen skulle utveckla ettmixed reality-gränssnitt för främre befäl. Detta gränssnitt skulle ha funktionalitet för att visainformation om nyckelobjekt och visa riktningen till dessa. Detta var möjligt eftersom dennatyp av föremål var försedda med IoT-sensorer.

Kunden efterfrågade också funktionalitet för att kunna strömma video från Hjälmen tillden bakre ledningen. För att den bakre ledningen enkelt skulle kunna ta del av videoström-men från Hjälmen skulle ett webbaserat användargränssnitt utvecklas. Detta användargräns-snitt benämns som Dashboarden. Dashboarden skulle även kunna visa sensordata som harskickats från Hjälmen samt ha stöd för att kunna skicka textmeddelanden till Hjälmen. Över-gripande för hela projektet var att kunden önskade att all information som skickades från

3

2.3. Kundens system

Hjälmen också skulle lagras i en databas. Det utvecklade systemet skulle agera som prototypoch ha möjlighet för vidareutveckling.

2.3 Kundens system

Då kunden sedan tidigare drev ett forskningsprojekt inom detta område fanns ett antal sy-stem som var av intresse för detta projekt. Dessa system var:

• en Apache Ignite-databas,

• IoT-objekt som rapporterar sina aktuella värden till Ignite,

• en kartapplikation där IoT-objekten finns markerade och

• en AI.

Gällande kundens AI var projektgruppens uppgift enbart att spara undan så mycket datasom möjligt för att kunden på egen hand vid ett senare tillfälle skulle kunna använda datansom underlag för AI:n.

2.4 Tidigare erfarenheter

Samtliga gruppmedlemmar hade tidigare ingått i en projektgrupp där syftet har varit attutveckla antingen bara mjukvara eller både mjuk- och hårdvara. Dessa erfarenheter kom pri-märt från kursen TSEA29 (Konstruktion med mikrodatorer) eller TDDD92 (AI-projekt). Vi-dare hade samtliga gruppmedlemmar god programmeringsvana från kurser som lästs underde föregående fem terminerna och eventuella hobbyprojekt eller jobb. Under utbildningenhade även samtliga gruppmedlemmar läst en kurs inom programutvecklingsmetodik.

Då kursen TDDD92 innefattade ett mindre formellt projekt varierade erfarenheterna avatt arbeta enligt en projektmodell eller arbetsmetod. De gruppmedlemmar som läst kursenTSEA29 hade erfarenhet av att jobba enligt projektmodellen LIPS. Erfarenheter från tidigareprojektarbeten bidrog till att gruppen planerade mer realistiska mål.

4

3 Teori

I det här kapitlet beskrivs relevant teori kopplad till frågeställningarna och projektet överlag.Vidare beskrivs även relevant teori gällande val av verktyg och metoder för att underlättaarbetet för gruppen.

3.1 Räddningsinsatser idag

I detta kapitel beskrivs målgruppen för vår prototyp och hur de arbetar idag.

3.1.1 Främre befäl

Främre befäl vid en räddningsinsats är den person som leder och organiserar arbetet påolycksplatsen. Tanken med Hawkeye var att främre befäl skulle använda Hjälmen.

I boken Taktik, ledning och ledarskap beskrivs att många, snabba och viktiga beslut mås-te fattas under en räddningsinsats [1]. Vidare beskriver författarna också chefsrollen underen räddningsinsats som en utmaning då chefen både måste ha mycket erfarenhet och godakunskaper.

3.1.2 Bakre ledning

Bakre ledning vid en räddningsinsats består idag ofta av personal från SOS-alarm [2]. De an-svarar för att leda och organisera räddningsinsatsen. Det förekommer emellertid skillnadermellan olika regioner vilket innebär att det inte alltid finns en central som leder alla rädd-ningsinsatser.

Informationsflödet till bakre ledning idag består av GPS-position på utryckningsfordonsamt radiokommunikation med räddningspersonal på plats. Med hjälp av informationen kanbakre ledning koordinera och assistera räddningspersonalen på plats, exempelvis genom attskicka mer personal eller ta fram ritningar över byggnader för att kunna hitta brandposter.

3.2 Mixed reality

Mixed reality som på svenska översätts till blandad verklighet är en sammanflätning av denverkliga världen och en digital värld. Mixed reality skapar en värld där användaren kan intera-

5

3.3. HoloLens 2

gera med både verkliga och datoranimerade objekt och objekten kan interagera med varand-ra.

Mixed reality ska inte förväxlas med augmented reality. Skillnaden mellan mixed reality ochaugmented reality är att augmented reality kan visualisera objekt i verkligheten men att använ-daren inte kan interagera med objekten. Ett exempel är att augmented reality kan visualiseraen låda på ett bord medan mixed reality möjliggör att både visualisera objektet och låta använ-daren ta upp lådan och öppna den.

Mixed reality är en relativt ny och outforskad teknik. Microsoft HoloLens 2 kunde vidtidpunkten för projektet ej köpas av privatpersoner eller företag.

3.3 HoloLens 2

HoloLens 2 är ett mixed reality headset tillverkat av Microsoft. HoloLens 2 har en uppsjö avfunktioner, se Microsofts webbsida för fullständiga specifikationer [3]. Några av de centralafunktionerna hos HoloLens 2 är:

• blickspårning (2 IR-kameror),

• kamera (8-MP, 1080p, 30Hz video),

• röststyrning samt

• handspårning.

3.4 WebRTC

WebRTC är ett webbaserat ramverk för realtidskommunikation över internet via ett peer-to-peer protokoll. Det har stöd för överföring av video, ljud och annan godtycklig data. WebRTCär numera en webbstandard som erbjuder ett API som kan användas av webbutvecklare föratt enkelt implementera tekniken [4].

För att etablera en peer-to-peer-anslutning mellan WebRTC-klienterna behöver en signa-leringsprocess utföras. Under denna process delas information om möjliga anslutningskon-figurationer mellan klienterna via en signaleringsserver. När klienterna har mottagit dennainformation bestäms den bästa anslutningsvägen och en peer-to-peer-anslutning upprättas.

3.4.1 ICE-kandidater

En Internet Connectivity Establishment (ICE)-kandidat är ett förslag på en kommunikations-väg mellan två klienter [5]. Under normala förhållanden genererar respektive klient ett antalolika ICE-kandidater som överförs till motparten under signaleringsprocessen. Den förstaICE-kandidaten som skickas representerar den bästa anslutningsvägen till klienten som ge-nererade kandidaten.

3.4.2 SDP-erbjudande

Ett Session Description Protocol (SDP) erbjudande är ett meddelande som innehåller informa-tion om datan som ska överföras. Protokollet innehåller information om bland annat omkod-ningsformat (codec) samt video- och ljudströmmar [6].

3.4.3 STUN

Session Traversal Utilities for NAT (STUN) är ett protokoll som används för att bestämma enklients externa IP-adress och port [7]. Informationen används för att upprätta en peer-to-peer-anslutning.

6

3.5. Programmeringsspråk

3.4.4 TURN

Traversal Using Relay NAT (TURN) är ett protokoll som tillåter vidarebefordring av data mel-lan klienter när en direktanslutning mellan två klienter inte kan etableras. Målet med en peer-to-peer-anslutning är att ändpunkterna ska kunna kommunicera direkt med varandra menpå grund av vissa nätverkskonfigurationer är detta inte alltid möjligt. I dessa fall användsen TURN-server som mellanhand. En TURN-server innehåller även all funktionalitet som in-går i STUN-protokollet, vilket innebär att en TURN-server per definition inte nödvändigtvisanvänds för att vidarebefordra data mellan klienter [8].

3.5 Programmeringsspråk

I detta kapitel beskrivs de olika programmeringsspråk som användes under projektets gång.

3.5.1 C#

C# (C-sharp) är ett programmeringsspråk utvecklat av Microsoft i samband med ramverket.NET. Det är ett objektorienterat språk som har likheter med andra språk som C/C++ ochJava [9].

3.5.2 Javascript

Javascript är ett språk som används primärt vid webbutveckling för att skapa en interaktivfrontend. Det stödjer flera olika programmeringsparadigm som objektorienterade och funk-tionella stilar [10].

3.6 Verktyg och program

I projektet användes en uppsättning mjukvaror. Vissa mjukvaror användes på initiativ avprojektgruppen för ökad produktivitet och effektivitet och andra mjukvaror eller verktyganvändes baserat på önskemål från projektets kund.

3.6.1 Unity

Unity är en spelmotor utvecklad av Unity Technologies som har en stor användarbas och haranvänts för att utveckla stora spel som Hearthstone [11] och Pokémon Go [12]. Unity stöd-jer programmeringsspråket C# för skriptning och har inbyggt stöd för testning med hjälp avtestverktyget NUnit. Unity har ingen inbyggd kodredigerare men har stöd för många tredje-partsredigerare så som Visual Studio Code och Visual Studio [13]. Unity har också starkt stödför utveckling till HoloLens 2 och är det som Microsoft rekommenderar om man vill kommaigång snabbt med utvecklingen till sin HoloLens 2 [14].

3.6.2 React

React är ett open-source bibliotek till JavaScript utvecklat av Facebook för att bygga använ-darvänliga webbgränssnitt [15]. React är komponentbaserat vilket innebär att en webbsidabyggs upp av flera komponenter som hierarkiskt tillåts interagera med varandra [16]. Genomatt bygga självständiga komponenter kan komponenter återanvändas på flera olika ställen iapplikationen.

3.6.3 Visual Studio Code

Enligt Visual Studio Codes startsida [17] är Visual Studio Code en open-source textredigera-re utvecklad av Microsoft. Den har stöd för utvecklingsverktyg för exempelvis felsökning,

7

3.6. Verktyg och program

syntaxmarkering, refaktorisering och möjligheten att installera tilläggsprogram för utökadfunktionalitet.

3.6.4 Docker

Docker är en virtualiseringsmjukvara som möjliggör att köra tjänster i så kallade containers[18]. En container kan liknas med en avskalad virtuell server innehållandes precis den mjuk-vara som krävs för att huvudapplikationen ska kunna köras. En container beskrivs av enDockerfile. En Dockerfile är en fil som beskriver vilken mjukvara som ska finnas i containernsamt andra konfigurationsparametrar, exempelvis vilka portar på den underliggande servernsom ska svara mot containerns lokala portar.

Som en utökning av Docker finns verktyget Docker Compose som används för att orkest-rera flera containers på ett smidigt sätt [19]. Genom att använda Docker Compose kan manexempelvis definiera olika containers beroenden till varandra och på så sätt se till att dessastartas i rätt ordning. Vidare har Docker Compose enkla kommandon för att starta och stop-pa samtliga containers samtidigt istället för att behöva göra detta för respektive container.

3.6.5 Google Cloud Platform

Google Cloud Platform (GCP) är en tjänst för Infrastructure-as-a-Service (Iaas), detta innebäratt de erbjuder tillgång till infrastruktur som en tjänst [20]. Detta möjliggör att privatperso-ner och företag kan hyra infrastruktur och provisionera servrar efter behov och betala fördem resurser som allokeras. Att hyra infrastruktur gör att användare inte behöver köpa in,konfigurera eller underhålla infrastruktur och användare kan således fokusera på sin kärn-verksamhet.

3.6.6 MySQL

MySQL är ett open-source system för att hantera relationsdatabaser. Det används för att desig-na, utveckla och administrera databaser.

3.6.7 Kurento

Kurento Media Server (KMS) är en open-source mjukvara som har funktionalitet för att han-tera WebRTC-kommunikation [21]. Vidare erbjuder även KMS funktionalitet för att spela invideoströmmar och kan integreras i andra applikationer genom att erbjuda ett fullfjädratAPI-gränssnitt som applikationer kan kommunicera med över websockets.

3.6.8 Apache Ignite

Apache Ignite är en open-source distribuerad databas. Utöver att enbart agera databas haräven Ignite funktionalitet för att processa data vilket kan vara användbart för att exempelvisträna neurala nätverk [22].

3.6.9 Apache NiFi

Apache NiFi är enligt dess dokumentation [23] ett program som är utvecklat för att hanteradataflöden mellan system. NiFi har ett webbaserat gränssnitt där så kallade processorer ochflöden mellan dessa processorer enkelt kan skapas. En processor är en komponent som han-terar data och syftar alltså inte till en fysisk processor. Varje processor skapar en flowfil somskickas vidare i flödet. Flowfilen innehåller resultatet och metadata från den förra processorn.I Figur 3.1 visas en bild över en enkel webbserver implementerad i NiFi.

8


Figur 3.1: Webbserver i NiFi.

3.6.10 Slack

Slack, förkortning av ”Searchable Log of All Conversation and Knowledge” [24], är en chatt-applikation som riktar sig till projektgrupper och företag. Idén är att varje projekt eller fö-retag har ett eget rum, detta rum består av ett antal textkanaler som vissa eller samtliga avrummets deltagare har tillgång till. Det ger möjligheten att strukturera och sortera konver-sationer. Slack har även stöd för att programmatiskt skicka påminnelser och andra typer avautomatiserade meddelanden.

3.6.11 Git

Git är ett gratis distribuerat versionshanteringssystem för källkod utvecklat av Linus Tor-valds [25]. Git är idag mycket populärt och är det vanligaste versionshanteringssystemet[26]. Det används av många stora företag som Google, Microsoft och Facebook. Att Git ärdistribuerat innebär att alla utvecklare på ett projekt har en kopia av alla projektets filer ochalla ändringar av dessa filer. Detta betyder att ingen central server krävs och att nästan allaoperationer som Git utför görs lokalt. Den mapp som versionshistoriken sparas i kallas ettrepository, eller repo [25].

3.6.12 GitLab

GitLab är en plattform för att hysa källkod som versionshanteras med Git. GitLab har ocksåen rad verktyg och funktioner som kan användas vid utveckling. Några av dessa är auto-matisk testning och byggning av kod, automatiska leveranser samt merge requests. Vidare harGitLab även funktionalitet för Kanbanboards [27].

3.6.13 Merge request

Merge request är ett verktyg i GitLab som utvecklare använder när de vill integrera ändringargjorda på en gren i ett projekt med en annan gren. Liknande verktyg i andra plattformarkallas ibland pull request. I en merge request kan andra utvecklare i projektet se vilka ändringarsom har gjorts och lämna åsikter och kommentarer om de tycker att något borde ändras. Näralla är överens godkänns merge requesten och integreringen genomförs [28].

9


3.6.14 Clockify

Clockify är ett webbaserat verktyg för att rapportera tid. I Clockify kan en arbetsyta skapassom flera personer kan rapportera tid i. För arbetsytan kan kategorier för arbetspass skapasvilket ger möjligheten att få en överblick över vilka aktiviteter som upptagit mest tid. Clockifyhar stöd för att exportera tidrapporteringsdata till diverse format, exempelvis Excel.

3.6.15 Scrum

Scrum är ett utvecklingsramverk där utvecklingen delas upp i sprintar. En sprint är en be-stämd tidsperiod. Längden på tidsperioden varierar och kan vara allt från veckor till måna-der. Under en sprint genomförs aktiviteter som finns i sprintbackloggen, vilken är en priori-terad lista med aktiviteter som ska genomföras samt vem som har ansvar för att aktiviteternablir genomförda.

Inför varje sprint hålls ett sprintplaneringsmöte. Under detta möte flyttas aktiviteter somska göras från produktbackloggen till sprintbackloggen. En produktbacklogg är en samlingaktiviteter som behöver genomföras för att produkten ska bli klar. De aktiviteter som flyttasförtydligas och vid behov delas upp till flera mindre aktiviteter [29]. I slutet av en sprinthålls ett sprintåterblicksmöte där föregående sprint utvärderas. I Scrum ingår även dagligaScrummöten där gruppen diskuterar vad de har gjort under dagen, vad de ska göra nästadag och om de har stött på några problem [30].

3.6.16 Test First Programming

Test First Programming (även Test Driven Development, TDD) är en mjukvaruutvecklingspro-cess. Det är en process som är till för att hjälpa utvecklarna hitta defekter i mjukvaran underutveckling. Test First Programming går att beskriva i fem steg, vilka går att se i Tabell 3.1. Dessasteg repeteras under utveckling av mjukvaran [31].

Tabell 3.1: Upplägg av Test First Programming

# Del Beskrivning1 Skriv tester Innan en ny funktion implementeras skrivs tester som definierar

funktionens begränsningar och funktionalitet. Testerna kan baseraspå kravspecifikationen, milstolpar och aktiviteter som är uppsattaför sprinten.

2 Kör tester Testerna körs (minst) en gång innan koden för funktionen imple-menteras. Detta görs för att försäkra sig om att testerna som skrivsär fungerande, och till exempel inte går igenom utan att någon kodhar skrivits.

3 Skriv koden Kod skrivs för funktionen så att den går igenom testerna. Att ko-den är välskriven i det här stadiet av utvecklingen är inte av högstaprioritet, fokus ligger på att den ska fungera.

4 Kör tester Testerna körs igen på koden som har skrivits. Om alla testerna gårigenom är utvecklaren försäkrad om att det som implementeratsfungerar för de testfall som finns.

5 Revidera koden Allt eftersom koden växer måste den revideras för att hålla hög kva-litet. Eftersom fokus inte låg på välskriven kod i steg 3 ligger det häristället.

3.6.17 Systemanatomi

En systemanatomi är en typ av graf som skapas för att visa en översikt av ett systems funk-tionalitet. Det generella utseendet av en systemanatomi är olika rutor för funktionaliteteroch subfunktionaliteter samt pilar som visar vad en funktionalitet byggs på. Med detta sätts

10


systemanatomin upp i olika lager beroende på var funktionaliteterna ligger. Dessa lager är:Service, Användargränssnitt, Serverfunktioner, Kommunikation och Hårdvara. Med dessagrunder för en systemanatomi kan ett team också själv bestämma hur deras systemanatomiska se ut och ha skillnader från det generella utseendet [32]. Ett exempel på en mer generellsystemanatomi och dess lager kan ses i Figur 3.2.

Figur 3.2: Ett exempel på en systemanatomi och dess olika lager för en bankomat [32].

Till skillnad från översikter som skapas för att kunna visas upp för externa parter och skapaförståelse där är systemanatomin till för utvecklarna av systemet. Genom att tidigt i ett pro-jekt skapa en systemanatomi kan ett team tillsammans enas kring funktionaliteter och vadsom krävs för att få allting att fungera.

11

4 Metod

I detta kapitel beskrivs hur arbetet har fungerat under utvecklingen av Hawkeye. Detta in-kluderar utvecklingsmetoderna som har använts och hur erfarenheter har fångats.

4.1 Utvecklingsmetod

Flera utvecklingsmetoder har tillämpats under projektet. I detta kapitel beskrivs dessa meto-der samt hur gruppen har tillämpat dessa.

4.1.1 Process i fokus: Scrum

Under projektet tillämpade gruppen Scrum som arbetsmetod med vissa anpassningar tillprojektet. Dessa anpassningar förklaras grundligt i detta delkapitel. Gruppmedlemmen somhade det generella ansvaret för Scrumprocessen och Scrumrelaterade möten var utvecklings-ledaren och antog därmed rollen som Scrummästare.

Scrum var även gruppens process i fokus vilket innebar att gruppen analyserade dennaprocess extra med hjälp av coacher från kursen TDDE46. Att processen var mer i fokus inne-bar mer dokumentation, analys av förbättringsmöjligheter samt utförande av mätningar påprocessen. Bakgrunden till att just Scrum valdes var att gruppen från start hade dokumente-rat processen noggrant. Vidare ansåg gruppen att det fanns många fördelar med att försökaförbättra Scrum ytterligare.

4.1.1.1 Dagligt Scrummöte

Gruppen gjorde en egen variant av dagliga Scrummöten som innebar att gruppmedlemmar-na svarade på frågor varje dag via en Slack-kanal istället för att träffas. Målet med frågornavar att medlemmarna skulle ge korta men tydliga svar för att berätta om hur arbetet har gåttoch hur medlemmen har planerat att fortsätta. Följande tre frågor ställdes i Slack-kanalen.

• Vad har jag gjort i dag?

• Vad ska jag göra i morgon?

• Har jag stött på något problem?

12

4.1. Utvecklingsmetod

4.1.1.2 Sprintåterblicksmöte

I slutet av varje sprint hölls ett möte för att sammanfatta och utvärdera sprinten. Det varframförallt tre frågor som diskuterades:

• Vad gick bra under sprinten?

• Vad kunde ha gått bättre?

• Vad kan förbättras till nästa sprint?

4.1.1.3 Sprintplaneringsmöte

I början av varje sprint hölls ett sprintplaneringsmöte där det som skulle göras den komman-de veckan diskuterades och planerades. Mötet behandlade följande frågor:

• Är det något kvar från förra sprinten?

– Är det fortfarande aktuellt?

– Behöver det brytas upp?

• Vad är målet med sprinten? Vad ska bli klart?

• Vilka aktiviteter behöver genomföras?

• Finns det någon aktivitet som är beroende av någon annan?

• Vem vill göra vad?

4.1.1.4 Sprintbacklogg och produktbacklogg

Både sprintbackloggen och produktbackloggen fanns sammanställd på ett Kanbanbräde,dess struktur visas i Tabell 4.1. Själva Kanbanbrädet fanns i GitLab och där skrevs varje akti-vitet ner som en issue.

Tabell 4.1: Gruppens upplägg på Kanbanbrädet

# Kolumn Beskrivning1 Produktbacklogg Aktiviteter som behöver genomföras för att få en färdig pro-

dukt.2 Sprintbacklogg Alla aktiviteter som ska genomföras den nuvarande sprinten.3 Pågående aktiviteter De aktiviteter som någon jobbar på.4 Avslutade aktiviteter Aktiviteter som anses vara klara för granskning av andra

gruppmedlemmar.5 Slutförda aktiviteter. Klara och granskade aktiviteter.

4.1.1.5 Sprintåterblicksenkät

Som en del av process i fokus skulle mätningar utföras på Scrum. Mätningarna gjordes ge-nom att projektmedlemmarna fick svara på en enkät i samband med sprintåterblicksmötet.I enkäten fanns det sex påståenden som skulle värderas på en skala från ett till fem där enfemma betydde att man höll med om vad påståendet sa och en etta betydde det motsatta.Påståendena som skulle värderas var:

• Jag känner att jag hann med allt som jag planerade för den här sprinten.

• Jag känner att aktiviteterna var väl planerade denna sprint.

13


• Jag känner att aktiviteterna var relevanta gentemot sprintens mål.

• Uppgifterna jag hade denna sprint var tydliga.

• Mina uppgifter denna vecka var väldigt komplexa.

• Uppgiften som jag gjorde var inte beroende av något annat som inte var klart.

4.1.2 Veckomöte

Veckomötet var ett administrativt möte som hölls varje måndag under projektet. Syftet medmötet var att diskutera kring och planera de delar av arbetet som inte var utvecklingsrelate-rade. Hela gruppen närvarade under mötet.

4.1.3 Tidrapportering

Samtliga projektdeltagare har rapporterat all tid de arbetat med projektet i Clockify. Dettalät projektdeltagarna få en översikt på hur mycket tid man lagt ner på projektet, både påindividnivå och gruppnivå. I slutet av varje vecka exporterades datan till ett kalkylark där entidrapport för den veckan sammanställdes.

4.1.4 Kalender

En gemensam kalender för projektet skapades i Google Calendar. Kalendern innehöll gemen-samma aktiviteter för gruppen, exempelvis veckomöten, handledarmöten och inlämningar.

4.1.5 Programmeringspraxis

För att det skulle vara enkelt för projektgruppen att läsa och förstå koden följer all kod enkodstandard. Utöver kodstandarden finns dokumentation för all kod, vilket kan hjälpa läsa-ren att få bättre kontext om vad koden gör och varför. Under projektet har gruppen arbetatmed C# och Javascript. Den C#-kod som skrevs följde Microsofts C# kodstandard [33] medanJavascript-koden följde Airbnb:s standard [34].

4.1.6 Versionshantering

För att försäkra att alla ändringar som gjordes till projektets källkod är spårbara och för attförenkla utvecklingen användes Git.

GitLab användes som ett centralt repository, vilket är en samlingsplats för alla versions-hanterade resurser. Det huvudsakliga fokuset var att huvudgrenen, master, alltid skulle varaleveransklar. Detta gjordes genom att köra tester och genomföra en kodgranskning på all kodsom skulle integreras in i huvudgrenen.

Processen som användes för att skapa och integrera en ny funktion började med att ut-vecklaren skapade en ny lokal gren, en så kallad feature branch. All utveckling relaterad tillfunktionen gjordes på grenen och när utvecklarna ansåg att utvecklingen var färdig gjordede en git-push av grenen till GitLab, vilket innebär att ändringarna till koden överförs tillGitLab där förändringarna versionhanteras. För att integrera ändringarna till huvudgrenenöppnade kodförfattaren en merge request. Efter att en merge request har öppnats, behövde enannan gruppmedlem kontrollera ändringarna. Om gruppmedlemmen godkände denna mer-ge request applicerades ändringarna på huvudgrenen.

4.1.7 Kodgranskning

Kodgranskning gjordes vid varje merge request. Vid varje granskning genomfördes ett mötedär koden, tester och dokument som har skapats presenterades av utvecklaren för minst en

14


annan gruppmedlem som inte arbetat med koden. På mötet gick utvecklarna igenom hur ko-den fungerar, vad syftet med koden var och vad koden har för betydelse senare. Utvecklareoch granskare kontrollerade att kodstandarden följdes, att koden var väldokumenterad samtdiskuterade möjliga problem relaterade till koden. Den mall som användes för kodgransk-ning är beskriven i Tabell 4.2.

Tabell 4.2: Upplägg på Kodgranskning

# Granskningsdel Beskrivning1 Formalia Val av sekreterare som dokumenterar kodgransk-

ningen.2 Kodbakgrund Varför har koden skapats? Vilken Issue i Kanban-

boarden?3 Genomgång av tester Vad har testats? Vad kommer testas? Något som inte

testas?4 Genomgång av kod Följer koden kodstandard? Hanteras felaktig inda-

ta?5 Genomgång av dokumentation Följer dokumentationen överenskommen standard?

Finns det några tvetydigheter?

4.1.8 Systemanatomi

För att gruppen skulle få en förståelse för hur produkten kommer fungera skapades en sys-temanatomi. Systemanatomin användes för att förtydliga viktiga punkter i utvecklingen ochför att se till att ingen kritisk del glömdes bort.

4.1.9 Utvecklingsprogram

För att underlätta arbetet med den uppsatta programmeringspraxisen, som beskrivs i kapitel4.1.5 och framförallt för att göra kodskrivande bekvämare användes flera utvecklingspro-gram. Dessa gav stöd i kodskrivandet motsvarande refaktoriseringshjälp, felsökning, struk-turering, testning, med mera. De program som användes var Unity [13] och Visual StudioCode [17].

4.1.9.1 Unity

Större delen av utveckling till Hjälmen gjordes i Unity. Bland annat användes många funk-tioner för HoloLens 2 som Unity erbjuder via verktyget Mixed Reality Toolkit, exempelvis ka-meramanipulering anpassad för Mixed Reality samt blick- och handspårning. Det gav ocksågruppen möjligheten att testa dessa funktioner direkt i Unity istället för på en HoloLens 2eller i en HoloLens 2 emulator, vilket förkortade utvecklingstiden. Både Mixed Reality använ-dargränssnittet och strömmningsfunktionaliteten byggdes i Unity. För att utveckla strömm-ningsfunktionaliteten användes verktyget MixedReality-WebRTC. För testning användes Uni-tys egna testverktyg och NUnit.

4.1.9.2 Visual Studio Code

Visual Studio Code användes för kodredigering i alla delar av projektet. Det användes ävenför felsökning på Dashboarden och Hjälmen. För Dashboarden användes den inbyggda fel-sökningsfunktionen och för Hjälmen användes tillägsprogrammet Debugger for Unity [35].

15

4.2. Organisation

4.1.10 Apache Ignite

Kunden hade sedan tidigare en Apache Ignite-databas men för att förenkla för projektgrup-pen önskade kunden att utvecklingen gjordes mot en MySQL-databas. Bakgrunden till dettavar primärt att MySQL och Ignite har mycket snarlika gränssnitt vilket innebar att kundenefter leverans med enkla ingrepp kunde migrera den MySQL-databas som projektgruppentagit fram till Apache Ignite. Av denna anledning har projektgruppen inte interagerat medApache Ignite utan uteslutande använt MySQL.

4.1.11 Dokumentation

Under projektets gång skrevs ett antal olika dokument. Vilka dessa var och varför de skrevskan ses i Tabell 4.3. Majoriteten av de dokument som skrevs var till för att hjälpa projektgrup-pen att utföra projektet. Alla dokument som listas i Tabell 4.3, med undantag för tidsredovis-ningen, skrevs i LaTeX med LaTeX redigeraren Overleaf.

Tabell 4.3: Dokument som ska produceras

Dokument Syfte MålgruppProjektplan Beskrivning av projektet ProjektgruppKravspecifikation Beskrivning och prioritering av kra-

venProjektgrupp, beställare

Kvalitetsplan Arbetssätt för att hålla hög standardför projektet

Projektgrupp

Systemanatomi Beskrivning av systemets konstruk-tion

Projektgrupp, beställare

Arkitekturdokument Beskrivning av systemets arkitektur Projektgrupp, beställareTestplan Beskrivning av hur tester ska utföras ProjektgruppTidsredovisning Visar spenderade timmar per person ProjektgruppKandidatarbete Slutgiltig rapport Kursledning, allmänheten

Förutom dokumenten i Tabell 4.3 skrevs också många mindre dokument, exempelvis oppo-neringstexter och presentationer. För dessa dokument användes Google Drive.

4.2 Organisation

För att effektivisera grupparbetet och tydliggöra ansvarsområden tilldelades varje grupp-medlem en roll. Tilldelningen av roller presenteras i Tabell 4.4.

Tabell 4.4: Rollfördelning

Roll NamnTeamledare Bence NagyAnalysansvarig Payam TavakoliKvalitetssamordnare Philip GunnarssonKonfigurationsansvarig Björn BirathArkitekt Erik AhlrothDokumentansvarig Jakob SjöqvistUtvecklingsledare Edvin BergströmTestledare Jonathan Hjort

16

4.2. Organisation

4.2.1 Teamledare

Teamledaren hade det övergripande ansvaret för att projektarbetet gick framåt och att målenuppfylldes. Teamledaren ansvarade även för kontakten med kursledningen och represente-rade teamet utåt. Rollen innebar även bokning av lokaler och utskick av kallelse till resten avprojektgruppen inför möten. Teamledaren skulle se till att överenskomna processer följdes,att en projektplan skrevs och hade det sista ordet om det behövdes.

4.2.2 Analysansvarig

Analysansvarig var huvudsakligen ansvarig för att hålla kontakt med kunden. Detta innefat-tade att kommunicera kundens kommentarer och önskemål till projektmedlemmarna, över-sätta kundens tankar om sin produkt till konkreta krav samt se till att kunden hölls uppdate-rad med status för projektet. Analysansvarig hade även huvudansvar över att en kravspeci-fikation skapades, hölls uppdaterad och följdes upp under utvecklingen av produkten.

4.2.3 Kvalitetssamordnare

Kvalitetssamordnaren hade ansvar för att gruppen var säker på att produkten som fram-ställdes höll hög kvalitet. Praktiskt innebar detta att kontrollera att kvalitetsarbete utfördesav alla gruppmedlemmar, att en kvalitetsplan skrevs och att erfarenheter plockades upp ochtogs med till senare delar av projektet.

4.2.4 Konfigurationsansvarig

Konfigurationsansvarig hade ansvaret för vilka arbetsprodukter som skulle versionshanterasoch som skulle ingå i en leverans. Rollen innefattade även att välja och underhålla verktygensom användes för version- och konfigurationshantering samt ansvara för att dessa verktyganvändes på rätt sätt. Konfigurationsansvarig hade också ansvar för att utbilda resten avprojektgruppen hur de valda verktygen skulle användas.

4.2.5 Arkitekt

Arkitekten hade ansvar för att utveckla en systemarkitektur som uppfyllde de krav som ställ-des på produkten. Vid oklarheter gällande systemets arkitektur var det arkitekten som hadedet huvudsakliga ansvaret för att läsa på och leta kunskap för att slutligen kunna presenteraen lösning på problemet. Arkitekten skulle också under utvecklingsprocessen se över syste-mets arkitektur och uppdatera densamma vid förändringar i krav. Vidare skulle arkitektendela och diskutera den framarbetade arkitekturen med resterande del av projektgruppen.Detta gjordes för att hitta potentiella problem eller förbättringsmöjligheter i ett tidigt skede.

4.2.6 Dokumentansvarig

Dokumentansvarig hade det huvudsakliga ansvaret för att nödvändiga dokument framställ-des och lämnades in i tid. Om revidering efterfrågades av handledare, kursansvarig ellerkund var det fortsatt dokumentansvarig som såg till att önskade korrigeringar utfördes ochatt det uppdaterade dokumentet skickades in till alla parter inom den överenskomna ellergivna tidsramen.

Dokumentansvarig skulle även kontrollera att samtliga dokument som lämnades in vargranskade av någon gruppmedlem och följde eventuella formateringsriktlinjer. Vidare hadedokumentansvarig även ett ansvar för att det fanns en tydlig dokumentstruktur och att do-kumenten var lättillgängliga för resterande gruppmedlemmar. Bakgrunden till detta var attdet skulle vara smidigt att exempelvis kontrollera vilka krav som var överenskomna och påså sätt undvika missförstånd.

17

4.3. Metod för att fånga erfarenheter

4.2.7 Utvecklingsledare

Utvecklingsledaren ansvarade för den detaljerade designen, ledde och vid behov fördeladeutvecklingsarbetet. Rollen innefattade också att ta beslut om utvecklingsmiljöer. I sambandmed Scrum tog utvecklingsledaren rollen som Scrummästare.

4.2.8 Testledare

Testledaren ansvarade för att systemet testades både under utveckling och som helhet. Test-planen skrevs av testledaren för att formalisera hur systemet testades. Testrapporter skrevs avtestledaren efter att en sprint utfördes och beslut om systemets status gjordes huvudsakligenav testledaren. Tillsammans med kvalitetssamordnaren testades även systemets kvalitet.

4.3 Metod för att fånga erfarenheter

En del av arbetet handlade om att få erfarenhet och att lära sig på vägen. I detta kapitelbeskrivs de huvudsakliga metoderna som tillämpades för att projektgruppens medlemmarskulle samla erfarenheter både från varandra och externa parter.

4.3.1 Dagligt Scrummöte

Då Scrum tillämpades hölls även dagliga Scrummöten. På ett dagligt Scrummöte hade varjegruppmedlem möjlighet att skriva ner problem de hade för tillfället och dela dem med restenav gruppen. Om några problem var stora kunde dessa tas upp på nästkommande veckomötealternativt kunde gruppmedlemmen be om hjälp direkt.

4.3.2 Workshops

Om någon gruppmedlem kände sig erfaren med något verktyg eller teknik uppmuntradesgruppmedlemmen till att hålla i en workshop för övriga gruppmedlemmar. Det hölls fleraworkshops, bland annat för Unity, Docker, testning och Git. Vid ett tillfälle hölls en workshopav kunden för att projektgruppen skulle få insikt i hur kunden arbetade med de befintligasystemen.

4.3.3 Sprintåterblicksmöte

Sprintåterblicksmöten användes i samband med Scrum för att fånga erfarenheter om hurarbetet hade gått föregående vecka, detta beskrivs i detalj i kapitel 4.1.1.2. Under sprintåter-blicksmöten kunde gruppen reflektera över varför en sprint gick bra eller dåligt. Detta varmycket effektivt för att direkt kunna applicera det gruppen gjorde bra från förra sprinteneller justera det som gick mindre bra, inför kommande sprintar.

4.3.4 Dokumentation av möten

För att inte glömma bort vad som diskuterades under både interna och externa möten såggruppen till att alltid ha en sekreterare. Det blev då enkelt för gruppen att gå tillbaka och tittavad som faktiskt sades och även om en gruppmedlem var frånvarande kunde denne ta delav mötet till viss mån. Därmed fångades erfarenheter som gruppen kom fram till på möteneffektivt, eftersom alla gruppmedlemmar kunde ta del av anteckningarna när som helst viaGoogle Drive.

18

5 Resultat

I detta kapitel presenteras projektets resultat. Resultatet uppnåddes genom att tillämpa me-toderna som finns beskrivna i Kapitel 4.

5.1 Systembeskrivning

I detta delkapitel beskrivs det system som gruppen producerade. Kapitlet inleds med enöversikt av systemet vilket följs av en beskrivning av respektive delsystem.

5.1.1 Översikt

Systemet består av tre huvudsakliga komponenter: en HoloLens 2, ett webbaserat användar-gränssnitt och en server. Dessa kallas Hjälmen, Dashboarden respektive servern. Hjälmen harfunktionalitet för att visa information om IoT-objekt med hjälp av mixed reality samt strömmavideodata till Dashboarden. Hjälmens videoström visas på en webbaserad Dashboard. För attkunna upprätta en anslutning mellan Dashboard och Hjälm används en server. En översiktöver delsystemen och hur de interagerar med varandra illustreras i Figur 5.1.

19

5.1. Systembeskrivning

Figur 5.1: Översikt över ingående delsystem. Röda pilar representerar WebRTC-anslutningar,blåa websocket-anslutningar och svart HTTP, eller andra anslutningar.

20


5.1.2 Hjälmen

Hjälmens hårdvara består av en Microsoft HoloLens 2. Den utgör gränssnittet för främre befälpå plats genom Mixed Reality. Hjälmen används för att få information om IoT-objekt, vägvis-ning, visa textmeddelanden samt strömma en video. I detta delkapitel beskrivs Hjälmensfunktioner.

5.1.2.1 Meny

Alla Hjälmens funktioner styrs från en meny. Denna meny kan tas fram genom att använ-daren rotera sin hand och därefter kan knappar interageras med genom att tryckas på ellerpekas mot med ett finger. I menyn finns det fem olika knappar med funktionalitet för att visachattruta, gömma IoT-objekten, starta vägvisning till ett IoT-objekt, visa information om ettIoT-objekt samt att stänga menyn. Denna meny och dess knappar kan ses i Figur 5.2.

Figur 5.2: Hjälmens meny

5.1.2.2 Informations- och vägvisning

När en användare initierar information- eller vägvisning från menyn öppnas en undermenydär typen av IoT-objekt kan väljas. Därefter öppnas ytterligare en undermeny som visar allaIoT-objekt som tillhör någon av de valda typerna. Om det är vägvisning som initierats såkommer alla andra IoT-objekt att gömmas och en pil som pekar i IoT-objektets riktning visas,detta kan ses Figur 5.3. Vägvisningspilen uppdateras kontinuerligt så att den alltid pekar iIoT-objektets riktning.

I det andra fallet då informationsvisning initierades visas en textruta bredvid menyn därIoT-objektets information visas. Denna information kan även ses ovanför varje IoT-objektoch kan blir större om användaren försöker läsa texten inom nio meter från IoT-objektet, iFigur 5.4 visas informationsvisningen. För att avsluta information- eller vägvisning behöveranvändaren avmarkera respektive menyknapp.

21


Figur 5.3: Hjälmens vägvisningsläge samt undermenyerna

Figur 5.4: Hjälmens informationsläge samt undermenyerna

Informationen för respektive objekt hämtas via NiFi med hjälp av ett HTTP-anrop. Från NiFifår Hjälmen ett JSON-objekt som innehåller koordinater (latitud och longitud), namn, typ, idsamt informationstext. Koordinaterna översätts till positioner relativt Hjälmen med hjälp avhaversine-formeln (beräknar avstånd mellan två latitud- och longitudkoordinater [36]). Frånobjektets beräknade position skapas en motsvarighet i den virtuella världen.

5.1.2.3 Chatt

När användaren öppnar chatten visas en chattruta med textmeddelanden. Denna chattrutankan flyttas runt genom att användaren tar tag i den, flyttar den och därefter släpper den. Föratt stänga chattrutan behöver användaren avmarkera chattrutan i menyn. Figur 5.5 visar hurchatten ser ut. Om chattrutan är gömd när ett meddelande anländer informeras användarengenom att notifikationssiffran på chattknappen ökas.

22


Figur 5.5: Hjälmens chattruta

Överst i chattrutan visas session id, vilket används för att ansluta till videoströmmen. Var-je meddelande har strukturen av författare : meddelande. Meddelanden skickas frånDashboarden till Hjälmen via signaleringsservern med websockets.

5.1.2.4 Videoström

När Hjälmen startas initieras en anslutning till servern för att skicka en videoström från Hjäl-mens framåtriktade kamera automatiskt. Processen att ansluta till servern består av att upp-rätta en websocket-anslutning till signaleringsservern och en peer-to-peer-anslutning till KMS.Signaleringsprocessen beskrivs i detalj i Kapitel 5.1.3.6.

5.1.3 Server

För att Hjälmen och Dashboarden ska kunna interagera med varandra och användarna av detfullständiga systemet, används två huvudsakliga bakomliggande komponenter, en ApacheNiFi-server och en Node.js-server (signaleringsserver). På servern körs även en Kurento Me-dia Server, Coturn samt MySQL.

5.1.3.1 Docker

För att skapa en tydlig separation av de individuella tjänsterna inom projektets backend an-vänds Docker. Varje tjänst enkapsuleras i sin egen container. Dessa tjänster inkluderar NiFi,MySQL-databasen, Kurento Media Server, TURN-servern och signaleringsservern.

För att orkestrera dessa containers och etablera gemensamma nätverk och lagringsvolymerför dem används Docker Compose.

För att göra backend-tjänsterna lättillgängliga under utvecklingens gång huserar tjänster-nas containers på en virtuell server på Google Cloud Platform.

5.1.3.2 Apache NiFi

Enligt önskemål från projektets beställare skulle så mycket som möjligt av den fullständi-ga applikationens dataflöde mellan olika delsystem ske via NiFi. För att uppnå detta går allkommunikation med databasen genom NiFi. För att det ska vara möjligt att hämta och sparadata i databasen utvecklades ett NiFi-flöde som kunde ta emot HTTP-anrop. Totalt har NiFifunktionalitet för fyra olika typer av databasoperationer vilket innefattar att hämta data, läg-ga in data, uppdatera data, och ta bort data. För att utföra en sådan operation utförs ett HTTP

23


anrop till NiFi på adressen /. Där tabellnamnet motsvarar den da-tabastabell som ska användas. I Tabell 5.1 nämns skillnaderna mellan olika typer av anrop tillNiFi.

Tabell 5.1: NiFi:s funktionalitet mot databasen

Operation HTTP Metod DataformateringHämta data GET IngenLägga in data POST JSONUppdatera data PUT JSONTa bort data DELETE JSON

Om anropet har typen GET skickas data tillbaka till klienten i JSON-format. Däremot omanropet är i POST, PUT eller DELETE behöver också datan som ska modifieras att vara påJSON-format i HTTP-anropet. Om databasanropet lyckas returneras HTTP-statuskoden 200.NiFi-flödet innefattar även viss felhantering. Om datan är felformaterad eller databastabelleninte finns returneras HTTP-statuskoden 400. Om ett internt fel inträffar returneras HTTP-statuskoden 500.

5.1.3.3 MySQL

Projektets beställare hade sedan tidigare använt en Apache Ignite-databas för att lagra in-formation från IoT-objekt. För att begränsa projektets komplexitet bestämdes att en MySQL-databas skulle användas istället, då MySQL och Ignite har mycket snarlika gränssnitt enligtkunden. Databasen används i huvudsak för att lagra information om IoT-objekt som derasposition, namn och eventuell annan information.

5.1.3.4 Kurento Media Server

Enligt önskemål från projektets beställare skulle videoströmmen ha stöd för så kallade one-to-many relationer, det vill säga att flera Dashboards skulle kunna ta emot samma videoström.Vanligtvis med WebRTC innebär detta att avsändaren till videoströmmen måste strömmasamma video till ett antal mottagare via direktanslutningar till respektive mottagare. Det-ta ställer höga krav på bandbredd på avsändarens sida. För att undvika detta används enKurento Media Server. Videon strömmas då från avsändaren till Kurento Media Server, somsedan strömmar den vidare till alla mottagare. Därmed är bandbreddskravet på avsändarenlika stort oavsett antal mottagare.

Kurento Media Server har stöd för att spela in videoströmmar och används även för detta.

5.1.3.5 TURN-server

Som TURN-server användes mjukvaran Coturn som körs i en egen container på Google CloudPlatform. Att komma igång med Coturn innefattade endast enstaka steg bestående av attställa in nödvändiga konfigurationsparametrar.

5.1.3.6 Signaleringsserver

För att klienter skulle kunna skicka- eller ta emot en videoström behövde en anslutning mel-lan respektive klient och Kurento Media Servern (KMS) upprättas. I led att upprätta dennaanslutning krävs en signaleringsserver som kan förmedla anslutningsparametrar för respek-tive klient till KMS och vice versa. Denna signaleringsserver implementerades i Node.js.

Signaleringsservern har stöd för flera samtidiga sessioner vilket innebär att den kan han-tera videoströmmar från flera Hjälmar. Den bakomliggande strukturen består av sessioneroch klienter. Där en session är ett rum med en avsändare och ett godtyckligt antal mottagare.Klienter ansluter sig till en session genom att ange ett id i form av en sträng. Om en klient som

24


är markerad som avsändare anger ett id som inte är knuten till en befintlig session, skapas enny session med det id:t. Efter att en session har skapats kan mottagare ansluta sig genom attange det id:t.

För att signaleringssevern ska kunna kommunicera med klienterna och Kurento MediaServern (KMS) används websockets, detta kan ses i Figur 5.6. Kommunikationen mellan kli-enterna och signaleringsservern baseras på ett egendefinierat protokoll. Varje meddelande iprotokollet består av två delar, en typ- och en datadel.

Figur 5.6: Kommunikationsöversikt

Websocketanslutningarna används också för att möjliggöra datautbyte mellan klienter. Datansom skickas mellan klienter kan exempelvis vara textmeddelanden. Exempel på meddelan-den visas i Tabell 5.2.

Tabell 5.2: Exempel på websocketmeddelanden

Typ Datainit Sessions ID samt roll (avsändare/mottagare)sdpOffer SDP-erbjudande med information om mediaparametrariceCandidate ICE-kandidat med ansluntingsparametrardataMessage Meddelande i form av text eller data

Kommunikationen med KMS sker enligt Kurentos egna protokoll. Meddelanden som skic-kas till KMS handlar till stor del om att ge instruktioner om skapandet och hanteringen avKurento-specifika resurser. Exempel på instruktioner som skickas är att koppla ihop två kli-enter, starta inspelning samt skapa det underliggande videoobjektet för videoströmmen. Enbeskrivning av signaleringsprocessen i sin helhet visas i Figur 5.7.

25


Figur 5.7: UML-sekvensdiagram för signaleringsprocessen

Signaleringsservern agerar också HTTPS-server och tillhandahåller således de statiska filersom tillsammans utgör Dashboarden.

26


5.1.4 Dashboarden

Dashboarden är ett webbaserat användargränssnitt utvecklad i React och används för att visaen videoström och skicka meddelanden.

Användargränssnittet för Dashboarden utgörs i grunden av open-source mallen Paperba-se [37]. Inga förändringar av mallen gjordes utöver att rensa bort demoelement, exempelvisknappar. Gränssnittet består av två huvudkomponenter, en meny och en arbetsyta. De vik-tigaste elementen för arbetsytan består av ett textfält, två knappar, en videoruta, samt enchattruta. Gränssnittet i sin helhet visas i Figur 5.8.

Figur 5.8: Dashboardens användargränssnitt utan videoanslutning

5.1.4.1 Videoström

Textfältet används för att låta användaren ange ett session ID, vilket är en unik sträng somgenereras för varje videoström av Hjälmen. Genom att ange en textsträng för en videoströmoch klicka på Connect skapas en anslutning till KMS och den strömmade videon börjar vi-sas i videorutan, se Figur 5.9. Detaljerna kring anslutningsprocessen beskrivs i kapitel 5.1.3.6och illustreras i Figur 5.6. Om videoströmmen avslutas av Hjälmen eller om Dashboard-användaren klickar på Disconnect slutar videoströmmen att visas.

27


Figur 5.9: Dashboardens användargränssnitt med videoanslutning

5.1.4.2 Chattruta

I nedre högra hörnet finns en chattruta som kan öppnas genom att klickas på. Väl öppnad kanmeddelanden skrivas och skickas till både Hjälmen och andra Dashboarder som är anslutentill samma session. I Figur 5.10 visas denna chatt.

Figur 5.10: Dashboardens användargränssnitt med chattruta

28

5.2. Process i fokus: Scrum

5.2 Process i fokus: Scrum

Överlag har det gått bra med process i fokus och Scrum. Gruppen har dokumenterat enligt planoch har under tiden gjort kontinuerliga förbättringar med hjälp av coacherna från kursenTDDE46 eller baserat på egna förbättringsförslag.

5.2.1 Dokumentation av process

Dokumentationen som gjordes var sprintåterblicksdokument, sprintplaneringsdokument,sprintåterblicksenkäten och dagliga Scrummöten i Slack. Vidare dokumenterades alla aktivi-teter i GitLabs kanbanbräde. Gruppen hade alltid tillgång till all dokumentation via GoogleDrive, Slack eller GitLab.

5.2.2 Förbättring av process

Ett krav på projektgruppen var att analysera samt genomföra förbättringar på processen.Gruppen fick förslag från TDDE46-coacherna att införa tidsestimering av aktiviteter. Dettavar något som gruppen valde att inte implementera utan istället valde att genomföra mindreförbättringar. Ett exempel på detta var införandet av SMART:a (Specifika, Mätbara, Accepte-rade, Realistiska och Tidsbundna) aktiviteter och mål. Till en början fanns det mål som inteuppfyllde dessa krav.

5.2.3 Beskrivning av mätningar

I Figur 5.11 ses genomsnittliga resultatet från samtliga sprintåterblicksenkäter. Gruppen gjor-de ej enkäten mer än fem gånger trots att mer än fem sprintar genomfördes.

Figur 5.11: Översikt av resultaten från sprintåterblicksenkäten

5.3 Gemensamma erfarenheter

I detta kapitel beskrivs gruppens erfarenheter av att använda de olika utvecklingsmetodernaunder projektet.

29

5.3. Gemensamma erfarenheter

5.3.1 Arbetsmetod

I detta delkapitel beskrivs erfarenheter från de arbetsmetoder som projektgruppen tillämpa-de.

5.3.1.1 Scrum

Gruppens erfarenhet av Scrum är att det var en mycket effektiv metod. Vidare tycker mångagruppmedlemmar att sprintar som höll sig inom en vecka fungerade bra. Gruppens Scrum-process blev bättre och bättre under processens gång, till exempel blev mötesprotokollen bätt-re ifyllda och aktiviteterna blev bättre avgränsade och mer specifika. Gruppen lyckades välmed att genomföra möjliga förbättringar som diskuterades under sprintåterblicksmöten.

5.3.1.2 Parprogrammering

De gemensamma erfarenheterna gruppen fick av parprogrammering är mycket positiva. Deaktiviteter som genomfördes med hjälp av parprogrammering genomfördes bättre och snab-bare. Parprogrammering gjorde också att medlemmarna kände sig mer motiverade att göraett bra arbete.

5.3.1.3 Distansarbete

Andra delen av vårterminen 2020 gick Linköpings Universitet in i distansläge på grund avden då rådande Coronapandemin. Detta medförde att arbetet med projektet behövdes struk-tureras om. Alla möten gjordes om till digitala möten och projektgruppen fick använda digi-tala verktyg för att samarbeta. Gruppens erfarenhet av att jobba i distansläge är överraskandepositiv. Majoriteten av gruppen anser att denna övergång fungerade bra och att det inte varett större hinder i utvecklingen. En mindre del av gruppen tycker däremot att distansarbetetförsvårade utvecklingen och var problematiskt.

5.3.1.4 Workshops och kodgranskningar

Då alla i gruppen inte kunde delta i utvecklingen av projektets alla delar användes workshopsoch kodgranskning för att dela information och kunskap inom gruppen. Totalt genomfördesfem workshops inom gruppen. Gruppmedlemmarna anser att dessa gav alla medlemmar enövergripande förståelse inom de flesta delarna av projektet och de verktyg som användes.Gruppen genomförde åtta kodgranskningar, varav fem följde det bestämda formatet. Allagranskningar gjordes på kod relaterad till Hjälmen och gav bra kunskapsspridning inomden arbetsgruppen och resulterade i att mer kod följde kodstandarden och att två defekterhittades.

5.3.2 Versionshantering

Det Git-arbetsflöde som gruppen använde och som finns beskrivet i kapitel 4.1.6, har tillstörre delen följts under hela projektet. Målet som gruppen hade satt upp, att alltid ha grenenmaster felfri, uppnåddes nästan. Orsaken till de flesta fallen där master hade fel var hur NiFi-programmet lagrades. Det sparades i en binär fil som Git inte hanterade särskilt bra och omNiFi kördes samtidigt som en gruppmedlem la till ändringarna som har gjorts i denna fil tillen commit hände det ofta att filen förstördes.

Feature branches användes enligt planen, grenarna hölls till större delen separerade ochkonflikter mellan olika grenar uppstod sällan. Vissa grenar var väldigt långlivade, iblandöver flera sprintar. Även merge requests användes som planerat och kombinerades med kod-granskningen i senare delen av utvecklingen.

Ett fåtal gånger gjordes ändringar direkt på master för att fixa mindre buggar eller fel somhade missats. Eftersom dessa ändringar oftast bara rörde några få rader ansågs detta vara

30

5.4. Framtida projekt

okej, även om det inte följde arbetsflödet. Bakgrunden till detta var att det inte tycktes varavärt den tid det skulle tagit att följa processen i dessa fall.

5.3.3 Tekniska erfarenheter

Under projektets gång har gruppen använt många nya tekniker och verktyg som få grupp-medlemmar tidigare hade arbetat med. Gruppen har också haft möjlighet att utveckla sinkunskap inom verktyg och tekniker de tidigare använt, exempelvis Git och JavaScript. Någ-ra av de områden som gruppmedlemmar har fått ny kunskap inom är utveckling i Unity,WebRTC och React.

5.3.4 Systemanatomi

Tidigt i projektet, efter att ha skrivit en kravspecifikation arbetade gruppen fram en systema-natomi, se Figur 6.2. Systemanatomin gav gruppen en översikt över systemets funktioner ocharkitekturmässiga krav.

Systemanatomins rutor i högsta nivån representerar systemets interaktioner med använ-dare av Dashboarden eller Hjälmen. Därefter utökades dessa funktioner genom lägre nivåermed rutor som motsvarar vad som krävs för att dessa funktioner ska fungera. I och med attkraven och därmed arkitekturen förändrades, blev vissa delar av systemanatomin överflödi-ga. Ett exempel på detta var att kartinformationen uteblev men kvarstår i systemanatomin.De grundläggande funktioner som beskrivs i systemanatomin för respektive delsystem im-plementerades i den slutgiltiga prototypen.

5.4 Framtida projekt

Då arbetsmetoderna och de olika tekniker som har använts i detta projekt har varit nya er-farenheter för många i projektgruppen kommer medlemmarna att ta med sig många av demför framtida projekt.

Det främsta gruppen kommer ta med sig till framtiden är arbetsmetoderna som utnytt-jades under projektet. Scrum kommer fortsätta att användas av många medlemmar på olikasätt. Även metoder för att dela kunskap med andra medlemmar kommer utnyttjas i framti-den, exempelvis workshops.

En annan erfarenhet som gruppen kommer ta med sig är att kunna uppskatta hur storansträngning som krävs för att bli klar med olika uppgifter. Detta är något som gruppen blevbättre på under projektets gång genom att använda Scrum.

5.5 Värde för kunden

Målet med projektet var att skapa en mjukvara till Hjälmen och Dashboarden som kan un-derlätta arbetet för räddningstjänsten under en räddningsinsats. Gruppen skapade ett systemsom kan agera som konceptbevis för kundens slutgiltiga mål. Det system som gruppen pro-ducerade kan användas som en testprototyp av kunden gentemot slutanvändare, vilket kanresultera i värdefull feedback för prototypens vidareutveckling.

Kunden hade även flera befintliga system som gruppens prototyp var tänkt att integrerasmot. Detta medförde att många av designkraven som har specificerats gjordes i konsultationmed kunden. Främsta anledningen till detta var att det skulle vara enkelt för gruppen attintegrera prototypen mot kundens system eller att det skulle vara enkelt för kunden att inte-grera gruppens prototyp vid ett senare tillfälle. Prototypen som gruppen skapade uppfyllerockså många av de krav som kunden benämnde som viktiga.

31

5.6. Översikt över individuella bidrag

5.6 Översikt över individuella bidrag

I detta delkapitel presenteras de individuella bidragen.

5.6.1 Jämförelse av utvecklingsprocessen och användningsområdena förspelmotorerna Unity Engine och Unreal Engine av Bence Nagy

I denna rapport undersöks skillnaderna i utvecklingsprocessen och användningsområdenamellan spelmotorerna Unreal Engine och Unity Engine.

5.6.2 Jämförelse av Git-arbetsflöden av Björn Birath

I denna rapport undersöks vilka populära Git-arbetsflöden som finns och vilka arbetsflödensom passar till vilka typer av projekt. I rapporten diskuteras även hur de olika arbetsflödenakan integreras med kontinuerlig integrering och leverans.

5.6.3 Jämförelse av HLS och WebRTC för direktströmning av Edvin Bergström

I rapporten beskrivs hur HLS och WebRTC fungerar, vilka egenskaper de har och hur deraslatens uppstår. HLS och WebRTC för- och nackdelar diskuteras samt till vilka användnings-områden teknikerna passar.

5.6.4 Undersökning kring hur Scrum påverkar effektiviteten i en grupp av ErikAhlroth

En granskning av hur effektivt vi och andra liknande grupper tillämpade Scrum. Avklaradeaktiviteter, koordinering och sprintperioder ligger i fokus.

5.6.5 Problem och alternativ till lösenordsautentisering av Jakob Sjöqvist

I denna rapport kommer lösenordsautentisering att beskrivas och utvärderas för att hitta dessbrister. Vidare kommer också alternativa autentiseringsmetoder att beskrivas.

5.6.6 Mjukvarutestning i små projekt av Jonathan Hjort

Denna rapport undersöker vad för hinder som kan uppstå när en projektgrupp försökertillämpa agil testning. Rapporten undersöker också hur dessa hinder går att undvika ellerhur de går att göra lindrigare.

5.6.7 Olika kravhanteringstekniker i ett mindre mjukvaruprojekt av PayamTavakoli

I rapporten granskas processen av att framställa krav tillsammans med kunden i projektetsom varit och hur en sådan process kan förbättras.

5.6.8 GDPR och Hawkeye av Philip Gunnarsson

I rapporten undersöks vad GDPR säger om videoinsamling. Vilka tillstånd som behövs föratt få spela in video och vad projektgruppen behöver tänka på när projektgruppens prototypsamlar in annan data på olycksplatser. Texten behandlar även huruvida GDPR är tillräckligtför att skydda individers personliga data för detta projektet.

32

6 Diskussion

I detta kapitel diskuteras projektets metod och resultat. Dessutom kommer projektet ävenanalyseras ur ett vidare perspektiv med fokus på sociala, miljömässiga och etiska aspekter.

6.1 Metod

I detta delkapitel utvärderas de arbetssätt som projektgruppen tillämpade under projektet.

6.1.1 Utvecklingsmetod

I början av projektet delades gruppen upp, en del jobbade på Dashboarden och en del påHjälmen. När det senare uppenbarade sig att serverdelen tog mycket tid delades Dashboard-gruppen upp i två delar. Detta gav en bra uppdelning både vad gäller ansvar och kunskaps-spridning inom gruppen. Det lät gruppmedlemmarna fokusera mer på en enstaka del, sam-tidigt som de kunde förlita sig på att de andra delarna också slutfördes. Genom att arbetapå detta sätt reducerades kraven på varje gruppmedlems förståelse för systemet som hel-het. En nackdel var dock att när en gruppmedlem bytte grupp för att balansera arbetsbördanblev det en större tröskel, då kunskapsspridningen mellan grupperna var mer begränsad.Interaktionen mellan olika delsystem var protokollbaserad, vilket gav en tydlig struktur påhur informationen skulle skickas, utan några större krav på djupare förståelse av de andradelsystemen.

I kapitel 6.1.1.1 - 6.1.1.3 diskuteras de metoder som användes.

6.1.1.1 Scrum

Den Scrumprocess som användes var givande för gruppens utvecklingsprocess. Enligt grup-pen gav sprintplaneringsmötet en välstrukturerad och bra planering. Mötena bytte ibland fo-kus från planering till att istället diskutera hur de planerade aktiviteterna skulle genomföras.Gruppen tyckte att detta förbättrade aktiviteterna då innehåll tydligare kunde definieras. Detsprintåterblicksmöte som hölls varje vecka gav gruppen ett bra tillfälle att diskutera förbätt-ringsmöjligheter i utvecklingsprocessen. Gruppens genomförande av dagliga Scrummötenvar mer eller mindre givande. Under perioder med mycket utveckling gav det en bra inblicki de olika gruppernas framsteg. Personers och gruppers problem lyftes snabbt fram på ett

33

6.1. Metod

naturligt sätt, i och med frågan ”var har du för problem idag?”. Under perioder med mindreutveckling och mer dokumentation tyckte många gruppmedlemmar att det var mindre vik-tigt och därav mindre givande. Under dessa perioder var svaren ofta ospecifika vilket kan havarit orsaken till att vissa gruppmedlemmar upplevde det dagliga Scrummötet som mindregivande.

6.1.1.2 Versionshantering

Versionshanteringen gick bra, en faktor som bidrog var att projektet var uppdelat i många oli-ka delar och tillägg av nya funktioner påverkade oftast bara ett delsystem. Gruppen kundedärför jobba på flera grenar parallel

hawkeyeliu.diva-portal.org/smash/get/diva2:1450968/fulltext01.pdfsammanfattning denna rapport...

Documents