Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik
2020 | LIU-IDA/LITH-EX-G--20/057--SE
Hawkeye
–
En titt in i framtidens räddningstjänstutrustning
Hawkeye
–
A peek into the future of emergency services
Bence Nagy
Björn Birath
Edvin Bergström
Erik Ahlroth
Jakob Sjöqvist
Jonathan Hjort
Payam Tavakoli
Philip Gunnarsson
Handledare : Viktor Blidh 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/. © Bence Nagy Björn Birath Edvin Bergström Erik Ahlroth Jakob Sjöqvist Jonathan Hjort Payam Tavakoli Philip Gunnarsson
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 skapa ett 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 att strömma video och sensordata till den bakre ledningen samt erbjuda en mixed reality-vy fö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 vid Institutionen för Datavetenskap på Linköpings universitet. Rapporten beskriver hur Haw-keye har framställts och de metoder som har tillämpats av projektgruppen, exempelvis Scrum. I slutet av rapporten presenteras de individuella bidrag som gruppmedlemmarna har skrivit och som är relaterade till Hawkeye-projektet.
Författarens tack
Gruppen vill tacka Kristian Sandahl och kursledningen för en välplanerad kurs som givit gruppen förutsättningarna för att kunna utföra detta projekt. Gruppen vill även rikta ett extra tack till gruppens handledare Viktor Blidh som har varit väldigt hjälpsam och bidragit med värdefulla tips.
Vidare vill gruppen tacka Magnus Bång som var kunden till projektet. Magnus har varit väldigt tillmötesgående och gjort sitt yttersta för att bidra med de materiell som gruppen behövt under projektets gång. Vid tekniska frågor har även Daniel Westberg, som arbetar i Bångs team, bistått med mycket hjälp och handledning vilket gruppen vill tacka honom för.
Innehåll
Figurer vii Tabeller viii Definitioner ix 1 Introduktion 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställningar . . . 1 1.4 Avgränsningar . . . 2 2 Bakgrund 3 2.1 Kunden . . . 3 2.2 Uppgift . . . 3 2.3 Kundens system . . . 4 2.4 Tidigare erfarenheter . . . 4 3 Teori 5 3.1 Räddningsinsatser idag . . . 5 3.2 Mixed reality . . . 5 3.3 HoloLens 2 . . . 6 3.4 WebRTC . . . 6 3.5 Programmeringsspråk . . . 73.6 Verktyg och program . . . 7
4 Metod 12 4.1 Utvecklingsmetod . . . 12
4.2 Organisation . . . 16
4.3 Metod för att fånga erfarenheter . . . 18
5 Resultat 19 5.1 Systembeskrivning . . . 19
5.2 Process i fokus: Scrum . . . 29
5.3 Gemensamma erfarenheter . . . 29
5.4 Framtida projekt . . . 31
5.5 Värde för kunden . . . 31
5.6 Översikt över individuella bidrag . . . 32
6 Diskussion 33 6.1 Metod . . . 33
7 Slutsatser 42
7.1 Hur kan Hawkeye implementeras så att det skapar värde för kunden? . . . 42
7.2 Vilka erfarenheter kan dokumenteras från kandidatprojektet som kan vara in-tressanta för framtida projekt? . . . 42
7.3 Vilket stöd kan fås genom att skapa och följa upp en systemanatomi? . . . 42
7.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 44 A.1 Inledning . . . 44 A.2 Bakgrund . . . 45 A.3 Teori . . . 45 A.4 Metod . . . 46 A.5 Resultat . . . 47 A.6 Diskussion . . . 48 A.7 Slutsatser . . . 48
B Jämförelse av Git-arbetsflöden av Björn Birath 50 B.1 Inledning . . . 50 B.2 Bakgrund . . . 51 B.3 Teori . . . 51 B.4 Metod . . . 53 B.5 Resultat . . . 53 B.6 Diskussion . . . 55 B.7 Slutsatser . . . 56
C Jämförelse av HLS och WebRTC för direktströmning av Edvin Bergström 57 C.1 Inledning . . . 57 C.2 Bakgrund . . . 58 C.3 Teori . . . 58 C.4 Metod . . . 59 C.5 Resultat . . . 59 C.6 Diskussion . . . 63 C.7 Slutsatser . . . 64
D Undersökning kring hur Scrum påverkar effektiviteten i en grupp av Erik Ahlroth 65 D.1 Inledning . . . 65 D.2 Bakgrund . . . 65 D.3 Teori . . . 66 D.4 Metod . . . 67 D.5 Resultat . . . 67 D.6 Diskussion . . . 69 D.7 Slutsatser . . . 69
E Problem och alternativ till lösenordsautentisering av Jakob Sjöqvist 71 E.1 Inledning . . . 71 E.2 Bakgrund . . . 72 E.3 Teori . . . 72 E.4 Metod . . . 73 E.5 Resultat . . . 74 E.6 Diskussion . . . 76 E.7 Slutsatser . . . 77
F Mjukvarutestning i små projekt av Jonathan Hjort 79 F.1 Inledning . . . 79 F.2 Bakgrund . . . 79 F.3 Teori . . . 80 F.4 Metod . . . 82 F.5 Resultat . . . 82 F.6 Diskussion . . . 84 F.7 Slutsatser . . . 84
G Olika kravhanteringstekniker i mindre mjukvaruprojekt av Payam Tavakoli 86 G.1 Inledning . . . 86 G.2 Bakgrund . . . 87 G.3 Teori . . . 87 G.4 Metod . . . 90 G.5 Resultat . . . 90 G.6 Diskussion . . . 93 G.7 Slutsatser . . . 94
H GDPR och Hawkeye av Philip Gunnarsson 95 H.1 Inledning . . . 95 H.2 Bakgrund . . . 95 H.3 Teori . . . 96 H.4 Metod . . . 97 H.5 Resultat . . . 98 H.6 Diskussion . . . 98 H.7 Slutsatser . . . 99 Litteratur 101
Figurer
3.1 Webbserver i NiFi. . . 9
3.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 . . . 21
5.3 Hjälmens vägvisningsläge samt undermenyerna . . . 22
5.4 Hjälmens informationsläge samt undermenyerna . . . 22
5.5 Hjälmens chattruta . . . 23
5.6 Kommunikationsöversikt . . . 25
5.7 UML-sekvensdiagram för signaleringsprocessen . . . 26
5.8 Dashboardens användargränssnitt utan videoanslutning . . . 27
5.9 Dashboardens användargränssnitt med videoanslutning . . . 28
5.10 Dashboardens användargränssnitt med chattruta . . . 28
5.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ått motsvarar redan befintliga system och grönt de som behövde skapas. . . 36
6.2 Systemanatomi . . . 37
6.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. . . 52
B.2 Exempel på hur en rebase kan se ut. . . 52
B.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 . . . 60
C.2 En bild över en WebRTC kommunikation utan en TURN server. Siffrorna visar i vilken ordning som kommunikationen sker. . . 61
C.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] . . . . 88
G.2 Graf över svar på fråga 1 . . . 91
G.3 Graf över svar på fråga 2 . . . 91
G.4 Graf över svar på fråga 3 . . . 92
G.5 Graf över svar på fråga 4 . . . 92
Tabeller
3.1 Upplägg av Test First Programming . . . 10
4.1 Gruppens upplägg på Kanbanbrädet . . . 13
4.2 Upplägg på Kodgranskning . . . 15
4.3 Dokument som ska produceras . . . 16
4.4 Rollfördelning . . . 16
5.1 NiFi:s funktionalitet mot databasen . . . 24
5.2 Exempel på websocketmeddelanden . . . 25
D.1 Redovisar hur aktiviteter klarades av inom tidsramen av en sprintperiod . . . 68
D.2 Redovisar hur ofta påståenden kring aktiviteter stämmer . . . 68
D.3 Redovisar hur ofta Scrum användes och hur bra det fungerade . . . 68
G.1 Exempel på kravlista . . . 89
G.2 Frågorna i frågeformuläret . . . 90
Definitioner
• Hawkeye: Projektets namn.
• Hjälmen: Avser delsystemet som består av den trådlösa användarenheten, som bland annat 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äddningsstasitua-tionen 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 delade kalendrar.
• 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 vetenskapliga dokument.
• Overleaf: En webbaserad LaTeX-redigerare.
• IoT: Akronym för Internet of Things och motsvarar en enhet som är uppkopplad mot internet 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 till Mixed 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.
• Open-source: En term för att beskriva program vars källkod är släppt med en licens som 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 eller annan data.
• Versionshanteringssystem: Ett program eller system som kan utföra versionshantering på 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, utan någon mellanhand, som exempelvis en server.
1
Introduktion
I detta kapitel introduceras och presenteras projektet, dess syfte, centrala frågeställningar och avgrä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 innan insatsen kan börja. Att ha all information i bakhuvudet under insatsen sätter personalen i en stressad 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 mjukvara fö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 kommunikation med 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 en tillhörande Dashboard. Prototypens syfte är att agera som konceptbevis för ett system som syftar till att underlätta arbetet för räddningstjänstpersonal under räddningsinsatser. Syftet med rapporten är att ge insikt i hur kandidatprojektet har utförts, vad det har resulterat i och vilka 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 intressanta för framtida projekt?
1.4. Avgränsningar
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?
1.4
Avgränsningar
Projektet hade en begränsad tidsbudget på 380 timmar per gruppmedlem, vilket innebar en total tidsbudget på 3040 timmar. Tidsbudgeten inkluderade utvecklingstid, tid för dokumen-tation, möten, utbildning och en individuell utredning.
2
Bakgrund
I detta kapitel kommer kunden, uppgiften, kundens nuvarande system och projektgruppens tidigare erfarenheter av att arbeta i projekt att beskrivas.
2.1
Kunden
Kunden för kandidatprojektet var forskningsgruppen Ubiquitous Computing and Analytics Group vid Institutionen för Datavetenskap på Linköpings universitet. Forskningsgruppens syfte är att bedriva forskning inom IT-området för att hantera katastrofer och olyckor med fokus 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. Den framstä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ämre befäl och bakre ledning samt att underlätta för främre ledning att hitta och få information om nyckelobjekt. 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älm med integrerad HoloLens 2. Kundens önskemål var att projektgruppen skulle utveckla ett mixed reality-gränssnitt för främre befäl. Detta gränssnitt skulle ha funktionalitet för att visa information om nyckelobjekt och visa riktningen till dessa. Detta var möjligt eftersom denna typ 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 till den bakre ledningen. För att den bakre ledningen enkelt skulle kunna ta del av videoström-men från Hjälvideoström-men skulle ett webbaserat användargränssnitt utvecklas. Detta användargräns-snitt benämns som Dashboarden. Dashboarden skulle även kunna visa sensordata som har skickats 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
2.3. Kundens system
Hjälmen också skulle lagras i en databas. Det utvecklade systemet skulle agera som prototyp och 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 sysy-stem 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 data som möjligt för att kunden på egen hand vid ett senare tillfälle skulle kunna använda datan som underlag för AI:n.
2.4
Tidigare erfarenheter
Samtliga gruppmedlemmar hade tidigare ingått i en projektgrupp där syftet har varit att utveckla 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 under de föregående fem terminerna och eventuella hobbyprojekt eller jobb. Under utbildningen hade även samtliga gruppmedlemmar läst en kurs inom programutvecklingsmetodik.
Då kursen TDDD92 innefattade ett mindre formellt projekt varierade erfarenheterna av att arbeta enligt en projektmodell eller arbetsmetod. De gruppmedlemmar som läst kursen TSEA29 hade erfarenhet av att jobba enligt projektmodellen LIPS. Erfarenheter från tidigare projektarbeten bidrog till att gruppen planerade mer realistiska mål.
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ätta arbetet 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 under en räddningsinsats som en utmaning då chefen både måste ha mycket erfarenhet och goda kunskaper.
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 skillnader mellan 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å utryckningsfordon samt radiokommunikation med räddningspersonal på plats. Med hjälp av informationen kan bakre ledning koordinera och assistera räddningspersonalen på plats, exempelvis genom att skicka 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 den verkliga världen och en digital värld. Mixed reality skapar en värld där användaren kan
intera-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 och augmented 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 visualisera en 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 vid tidpunkten 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ö av funktioner, se Microsofts webbsida för fullständiga specifikationer [3]. Några av de centrala funktionerna 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ör att 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 denna information 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 antal olika ICE-kandidater som överförs till motparten under signaleringsprocessen. Den första ICE-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 informainforma-tion om bland annat omkod-ningsformat (codec) samt video- och ljudströmmar [6].
3.4.3
STUN
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 melmel-lan två klienter inte kan etableras. Målet med en peer-to-peer-anslutning är att ändpunkterna ska kunna kommunicera direkt med varandra men på grund av vissa nätverkskonfigurationer är detta inte alltid möjligt. I dessa fall används en 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ändigtvis anvä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++ och Java [9].
3.5.2
Javascript
Javascript är ett språk som används primärt vid webbutveckling för att skapa en interaktiv frontend. 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 av projektgruppen för ökad produktivitet och effektivitet och andra mjukvaror eller verktyg anvä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 har anvä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 av testverktyget 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öd för utveckling till HoloLens 2 och är det som Microsoft rekommenderar om man vill komma igå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 webbsida byggs upp av flera komponenter som hierarkiskt tillåts interagera med varandra [16]. Genom att bygga självständiga komponenter kan komponenter återanvändas på flera olika ställen i applikationen.
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,
3.6. Verktyg och program
syntaxmarkering, refaktorisering och möjligheten att installera tilläggsprogram för utökad funktionalitet.
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 en Dockerfile. En Dockerfile är en fil som beskriver vilken mjukvara som ska finnas i containern samt andra konfigurationsparametrar, exempelvis vilka portar på den underliggande servern som 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 man exempelvis definiera olika containers beroenden till varandra och på så sätt se till att dessa startas 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är att 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 provisioprivatperso-nera servrar efter behov och betala för dem 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 in videoströmmar och kan integreras i andra applikationer genom att erbjuda ett fullfjädrat API-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 exempelvis trä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 hantera dataflöden mellan system. NiFi har ett webbaserat gränssnitt där så kallade processorer och flö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 som skickas 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.
3.6. Verktyg och program
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 av rummets 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 av automatiserade 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 är distribuerat innebär att alla utvecklare på ett projekt har en kopia av alla projektets filer och alla ändringar av dessa filer. Detta betyder att ingen central server krävs och att nästan alla operationer som Git utför görs lokalt. Den mapp som versionshistoriken sparas i kallas ett repository, 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, autoauto-matiska leveranser samt merge requests. Vidare har GitLab ä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 ändringar gjorda på en gren i ett projekt med en annan gren. Liknande verktyg i andra plattformar kallas ibland pull request. I en merge request kan andra utvecklare i projektet se vilka ändringar som har gjorts och lämna åsikter och kommentarer om de tycker att något borde ändras. När alla är överens godkänns merge requesten och integreringen genomförs [28].
3.6. Verktyg och program
3.6.14
Clockify
Clockify är ett webbaserat verktyg för att rapportera tid. I Clockify kan en arbetsyta skapas som flera personer kan rapportera tid i. För arbetsytan kan kategorier för arbetspass skapas vilket ger möjligheten att få en överblick över vilka aktiviteter som upptagit mest tid. Clockify har 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 aktiviteterna blir genomförda.
Inför varje sprint hålls ett sprintplaneringsmöte. Under detta möte flyttas aktiviteter som ska göras från produktbackloggen till sprintbackloggen. En produktbacklogg är en samling aktiviteter som behöver genomföras för att produkten ska bli klar. De aktiviteter som flyttas förtydligas och vid behov delas upp till flera mindre aktiviteter [29]. I slutet av en sprint hålls ett sprintåterblicksmöte där föregående sprint utvärderas. I Scrum ingår även dagliga Scrummöten där gruppen diskuterar vad de har gjort under dagen, vad de ska göra nästa dag 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 under utveckling. Test First Programming går att beskriva i fem steg, vilka går att se i Tabell 3.1. Dessa steg repeteras under utveckling av mjukvaran [31].
Tabell 3.1: Upplägg av Test First Programming
# Del Beskrivning
1 Skriv tester Innan en ny funktion implementeras skrivs tester som definierar funktionens begränsningar och funktionalitet. Testerna kan baseras på kravspecifikationen, milstolpar och aktiviteter som är uppsatta fö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 kod har 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ögsta prioritet, fokus ligger på att den ska fungera.
4 Kör tester Testerna körs igen på koden som har skrivits. Om alla testerna går igenom är utvecklaren försäkrad om att det som implementerats fungerar 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är istället.
3.6. Verktyg och program
systemanatomin upp i olika lager beroende på var funktionaliteterna ligger. Dessa lager är: Service, Användargränssnitt, Serverfunktioner, Kommunikation och Hårdvara. Med dessa grunder för en systemanatomi kan ett team också själv bestämma hur deras systemanatomi ska se ut och ha skillnader från det generella utseendet [32]. Ett exempel på en mer generell systemanatomi 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 skapa fö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 vad som krävs för att få allting att fungera.
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 till projektet. Dessa anpassningar förklaras grundligt i detta delkapitel. Gruppmedlemmen som hade 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 denna process 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öka fö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-kagruppmedlemmar-nal istället för att träffas. Målet med frågorgruppmedlemmar-na var att medlemmarna skulle ge korta men tydliga svar för att berätta om hur arbetet har gått och 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?
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 var framfö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 diskuterakomman-des och planerakomman-des. Mötet behandlakomman-de följankomman-de 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 Beskrivning
1 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 en femma 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.
4.1. Utvecklingsmetod
• 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 med mö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. Detta lä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 en tidrapport 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 en kodstandard. 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 arbetat med C# och Javascript. Den C#-kod som skrevs följde Microsofts C# kodstandard [33] medan Javascript-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 att fö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 vara leveransklar. Detta gjordes genom att köra tester och genomföra en kodgranskning på all kod som 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 till funktionen gjordes på grenen och när utvecklarna ansåg att utvecklingen var färdig gjorde de en git-push av grenen till GitLab, vilket innebär att ändringarna till koden överförs till GitLab 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 en annan gruppmedlem kontrollera ändringarna. Om gruppmedlemmen godkände denna mer-ge request applicerades ändringarna på huvudgrenen.
4.1. Utvecklingsmetod
annan gruppmedlem som inte arbetat med koden. På mötet gick utvecklarna igenom hur ko-den fungerar, vad syftet med koko-den var och vad koko-den har för betydelse senare. Utvecklare och granskare kontrollerade att kodstandarden följdes, att koden var väldokumenterad samt diskuterade 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 Beskrivning
1 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 och fö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 kapitel 4.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 Studio Code [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 2 eller 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 även fö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].
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 detta var primärt att MySQL och Ignite har mycket snarlika gränssnitt vilket innebar att kunden efter leverans med enkla ingrepp kunde migrera den MySQL-databas som projektgruppen tagit fram till Apache Ignite. Av denna anledning har projektgruppen inte interagerat med Apache 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 skrevs kan 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ålgrupp
Projektplan Beskrivning av projektet Projektgrupp Kravspecifikation Beskrivning och prioritering av
kra-ven
Projektgrupp, beställare Kvalitetsplan Arbetssätt för att hålla hög standard
för projektet
Projektgrupp Systemanatomi Beskrivning av systemets
konstruk-tion
Projektgrupp, beställare Arkitekturdokument Beskrivning av systemets arkitektur Projektgrupp, beställare Testplan Beskrivning av hur tester ska utföras Projektgrupp
Tidsredovisning Visar spenderade timmar per person Projektgrupp
Kandidatarbete 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 Namn
Teamledare Bence Nagy
Analysansvarig Payam Tavakoli Kvalitetssamordnare Philip Gunnarsson Konfigurationsansvarig Björn Birath
Arkitekt Erik Ahlroth
Dokumentansvarig Jakob Sjöqvist Utvecklingsledare Edvin Bergström
4.2. Organisation
4.2.1
Teamledare
Teamledaren hade det övergripande ansvaret för att projektarbetet gick framåt och att målen uppfylldes. 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 av projektgruppen 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ördes av alla gruppmedlemmar, att en kvalitetsplan skrevs och att erfarenheter plockades upp och togs med till senare delar av projektet.
4.2.4
Konfigurationsansvarig
Konfigurationsansvarig hade ansvaret för vilka arbetsprodukter som skulle versionshanteras och som skulle ingå i en leverans. Rollen innefattade även att välja och underhålla verktygen som användes för version- och konfigurationshantering samt ansvara för att dessa verktyg användes på rätt sätt. Konfigurationsansvarig hade också ansvar för att utbilda resten av projektgruppen 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 hade det huvudsakliga ansvaret för att läsa på och leta kunskap för att slutligen kunna presentera en 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 arkitekten dela 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ämnaframställ-des in i tid. Om revidering efterfrågaframställ-des av handledare, kursansvarig eller kund var det fortsatt dokumentansvarig som såg till att önskade korrigeringar utfördes och att det uppdaterade dokumentet skickades in till alla parter inom den överenskomna eller givna tidsramen.
Dokumentansvarig skulle även kontrollera att samtliga dokument som lämnades in var granskade av någon gruppmedlem och följde eventuella formateringsriktlinjer. Vidare hade dokumentansvarig ä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 att det skulle vara smidigt att exempelvis kontrollera vilka krav som var överenskomna och på så sätt undvika missförstånd.
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ördelade utvecklingsarbetet. Rollen innefattade också att ta beslut om utvecklingsmiljöer. I samband med 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 av testledaren efter att en sprint utfördes och beslut om systemets status gjordes huvudsakligen av 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 kapitel beskrivs de huvudsakliga metoderna som tillämpades för att projektgruppens medlemmar skulle 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 varje gruppmedlem möjlighet att skriva ner problem de hade för tillfället och dela dem med resten av gruppen. Om några problem var stora kunde dessa tas upp på nästkommande veckomöte alternativt 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 uppmuntrades gruppmedlemmen till att hålla i en workshop för övriga gruppmedlemmar. Det hölls flera workshops, bland annat för Unity, Docker, testning och Git. Vid ett tillfälle hölls en workshop av kunden för att projektgruppen skulle få insikt i hur kunden arbetade med de befintliga systemen.
4.3.3
Sprintåterblicksmöte
Sprintåterblicksmöten användes i samband med Scrum för att fånga erfarenheter om hur arbetet 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 var mycket effektivt för att direkt kunna applicera det gruppen gjorde bra från förra sprinten eller 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åg gruppen till att alltid ha en sekreterare. Det blev då enkelt för gruppen att gå tillbaka och titta vad som faktiskt sades och även om en gruppmedlem var frånvarande kunde denne ta del av mötet till viss mån. Därmed fångades erfarenheter som gruppen kom fram till på möten effektivt, eftersom alla gruppmedlemmar kunde ta del av anteckningarna när som helst via Google Drive.
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 har funktionalitet för att visa information om IoT-objekt med hjälp av mixed reality samt strömma videodata till Dashboarden. Hjälmens videoström visas på en webbaserad Dashboard. För att kunna 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.
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.
5.1. Systembeskrivning
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äl på 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älmens funktioner.
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å eller pekas mot med ett finger. I menyn finns det fem olika knappar med funktionalitet för att visa chattruta, gömma IoT-objekten, starta vägvisning till ett IoT-objekt, visa information om ett IoT-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 undermeny där typen av IoT-objekt kan väljas. Därefter öppnas ytterligare en undermeny som visar alla IoT-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 i IoT-objektets riktning.
I det andra fallet då informationsvisning initierades visas en textruta bredvid menyn där IoT-objektets information visas. Denna information kan även ses ovanför varje IoT-objekt och kan blir större om användaren försöker läsa texten inom nio meter från IoT-objektet, i Figur 5.4 visas informationsvisningen. För att avsluta information- eller vägvisning behöver användaren avmarkera respektive menyknapp.
5.1. Systembeskrivning
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 NiFi får Hjälmen ett JSON-objekt som innehåller koordinater (latitud och longitud), namn, typ, id samt informationstext. Koordinaterna översätts till positioner relativt Hjälmen med hjälp av haversine-formeln (beräknar avstånd mellan två latitud- och longitudkoordinater [36]). Från objektets 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 chattrutan kan flyttas runt genom att användaren tar tag i den, flyttar den och därefter släpper den. För att stänga chattrutan behöver användaren avmarkera chattrutan i menyn. Figur 5.5 visar hur chatten ser ut. Om chattrutan är gömd när ett meddelande anländer informeras användaren genom att notifikationssiffran på chattknappen ökas.
5.1. Systembeskrivning
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ån Dashboarden 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 det fullständiga systemet, används två huvudsakliga bakomliggande komponenter, en Apache NiFi-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 lagringsvolymer fö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 all kommunikation med databasen genom NiFi. För att det ska vara möjligt att hämta och spara data i databasen utvecklades ett NiFi-flöde som kunde ta emot HTTP-anrop. Totalt har NiFi funktionalitet 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
5.1. Systembeskrivning
anrop till NiFi på adressen <BASEURL>/<tabellnamn>. Där tabellnamnet motsvarar den da-tabastabell som ska användas. I Tabell 5.1 nämns skillnaderna mellan olika typer av anrop till NiFi.
Tabell 5.1: NiFi:s funktionalitet mot databasen Operation HTTP Metod Dataformatering
Hämta data GET Ingen
Lägga in data POST JSON
Uppdatera data PUT JSON
Ta bort data DELETE JSON
Om anropet har typen GET skickas data tillbaka till klienten i JSON-format. Däremot om anropet ä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 databastabellen inte finns returneras 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 enligt kunden. Databasen används i huvudsak för att lagra information om IoT-objekt som deras position, 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ömma samma 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 detDet-ta används en Kurento Media Server. Videon strömmas då från avsändaren till Kurento Media Server, som sedan strömmar den vidare till alla mottagare. Därmed är bandbreddskravet på avsändaren lika 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 Cloud Platform. Att komma igång med Coturn innefattade endast enstaka steg bestående av att stä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 denna anslutning 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.
han-5.1. Systembeskrivning
är markerad som avsändare anger ett id som inte är knuten till en befintlig session, skapas en ny session med det id:t. Efter att en session har skapats kan mottagare ansluta sig genom att ange det id:t.
För att signaleringssevern ska kunna kommunicera med klienterna och Kurento Media Servern (KMS) används websockets, detta kan ses i Figur 5.6. Kommunikationen mellan kli-enterna och signaleringsservern baseras på ett egendefinierat protokoll. Varje meddelande i protokollet 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. Datan som skickas mellan klienter kan exempelvis vara textmeddelanden. Exempel på meddelan-den visas i Tabell 5.2.
Tabell 5.2: Exempel på websocketmeddelanden
Typ Data
init Sessions ID samt roll (avsändare/mottagare)
sdpOffer SDP-erbjudande med information om mediaparametrar iceCandidate ICE-kandidat med ansluntingsparametrar
dataMessage 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 av Kurento-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. En beskrivning av signaleringsprocessen i sin helhet visas i Figur 5.7.
5.1. Systembeskrivning
Figur 5.7: UML-sekvensdiagram för signaleringsprocessen
Signaleringsservern agerar också HTTPS-server och tillhandahåller således de statiska filer som tillsammans utgör Dashboarden.
5.1. Systembeskrivning
5.1.4
Dashboarden
Dashboarden är ett webbaserat användargränssnitt utvecklad i React och används för att visa en 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, exempelvis knappar. 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 en chattruta. 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 som genereras för varje videoström av Hjälmen. Genom att ange en textsträng för en videoström och 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.6 och 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.
5.1. Systembeskrivning
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 kan meddelanden skrivas och skickas till både Hjälmen och andra Dashboarder som är ansluten till samma session. I Figur 5.10 visas denna chatt.
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 plan och har under tiden gjort kontinuerliga förbättringar med hjälp av coacherna från kursen TDDE46 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 Google Drive, 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. Detta var något som gruppen valde att inte implementera utan istället valde att genomföra mindre fö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 inte uppfyllde 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örgjor-des.
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 utvecklingsmetoderna under projektet.
