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ör
spelmotorerna Unity Engine och Unreal Engine av Bence Nagy
I denna rapport undersöks skillnaderna i utvecklingsprocessen och användningsområdena mellan 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öden som passar till vilka typer av projekt. I rapporten diskuteras även hur de olika arbetsflödena kan 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 deras latens 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 Erik
Ahlroth
En granskning av hur effektivt vi och andra liknande grupper tillämpade Scrum. Avklarade aktiviteter, 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 dess brister. 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öker tillämpa agil testning. Rapporten undersöker också hur dessa hinder går att undvika eller hur de går att göra lindrigare.
5.6.7
Olika kravhanteringstekniker i ett mindre mjukvaruprojekt av Payam
Tavakoli
I rapporten granskas processen av att framställa krav tillsammans med kunden i projektet som 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ör att få spela in video och vad projektgruppen behöver tänka på när projektgruppens prototyp samlar in annan data på olycksplatser. Texten behandlar även huruvida GDPR är tillräckligt för att skydda individers personliga data för detta projektet.
6
Diskussion
I detta kapitel diskuteras projektets metod och resultat. Dessutom kommer projektet även analyseras 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 arbeta på 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ördan blev 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 andra delsystemen.
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. Det sprintå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öten var mer eller mindre givande. Under perioder med mycket utveckling gav det en bra inblick i de olika gruppernas framsteg. Personers och gruppers problem lyftes snabbt fram på ett
6.1. Metod
naturligt sätt, i och med frågan ”var har du för problem idag?”. Under perioder med mindre utveckling 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 ha varit orsaken till att vissa gruppmedlemmar upplevde det dagliga Scrummötet som mindre givande.
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 kunde därför jobba på flera grenar parallellt utan att behöva oroa sig för konflikter. Detta ledde dock också till att grenarna inte integrerades lika ofta som de egentligen borde ha gjorts och kunde ibland sträcka sig över flera sprintar. Användning av feature branches var väldigt smidigt för experiment och testning av idéer utan att behöva oroa sig om att ta sönder befintlig funk- tionalitet. Det gjorde också att samarbete på nya funktioner lätt kunde genomföras eftersom man enkelt kunde byta till den andra personens kodbas.
6.1.1.3 Kodgranskning
Gruppen tyckte att konceptet av kodgranskning var lovande, men genomförandet var be- gränsat. Tanken var att det skulle göras i samband med merge requests, men tidsbrist och otydligheter gjorde att kodgranskningen ofta inte genomfördes. Vissa merge requests var väl- digt små och gruppen tyckte därför inte att tiden var värd att lägga på dem. Informationen om hur kodgranskningar skulle genomföras hade inte heller spridits inom gruppen. Utö- ver det var också antalet merge requests relativt litet, då implementationen av funktionaliteter blev väldigt stora. Det förklarar också varför kodgranskningarna som genomfördes var på kod relaterad till Hjälmen, då Hjälmen hade funktionaliteter av mindre storlek som enklare integrerades.
6.1.1.4 Workshops
Gruppen använde sig av workshops för att dela erfarenheter och kunskap mellan gruppmed- lemmarna. Workshops internt inom gruppen gav en ytlig förståelse för tekniker, verktyg och implementationer som användes av delar av gruppen. Gruppens generella erfarenhet är att workshops inte drev utvecklingen eller projektet framåt, men många gruppmedlemmar tyc- ker att det var intressant och att de fick nya kunskaper de kan ha användning av i framtiden. Gruppmedlemmen som höll i workshopen fick även fördjupad förståelse för materialet då denne behövde förbereda sig och kunna besvara frågor.
6.1.2
Dokumentation
Under projektet har mycket tid gått åt till att skriva dokumentation. I början av arbetet la- des en stor del av tiden på att skriva dokument för att planera arbetet och ge stöd senare under projektet. Det var under denna period som projektplanen, kravspecifikationen, arki- tekturdokumentet, kvalitetsplanen och testplanen skrevs. Vissa av dessa dokument, motsva- rande projektplanen, kravspecifikationen och kvalitetsplanen skrevs för att planera metod och vilka krav som fanns. Därefter skrevs arkitekturdokumentet och testplanen som stöd för utveckling och testning när mer kunskap kring metod och krav erhållits. Dessa dokument uppdaterades därefter baserat på behov.
6.1. Metod
samt deras ansvarsområden. Det skapades en tid- och resursplan med milstolpar som skulle stödja utvecklingsprocessen, när den skulle påbörjas. Slutligen arbetades en plan för riskhan- tering fram. Efter skrivandet av projektplanen kom inte mycket av den att förändras i senare sprintar. Det visade sig att tid- och resursplanen inte kunde användas. Detta berodde dels på att gruppen var osäker på när utvecklingen skulle påbörjas samt att vissa funktioner och ar- kitekturen av systemet inte var klarställda när projektplanen skrevs. Detta hade kunnat lösas genom att uppdatera projektplanen, däremot hade gruppen redan gått vidare och använde kravspecifikationen som stöd för utvecklingen istället.
6.1.2.2 Kravspecifikation
Kravspecifikationen är det dokument som gruppen har haft mest nytta av under projektets gång. Den skrevs tidigt i projektet och har uppdaterats allt eftersom krav tillkom, togs bort el- ler förändrades. Kravspecifikationen gav också gruppmedlemmarna riktlinjer i utvecklings- arbetet. Den användes för att bestämma vad som skulle arbetas på i varje sprint för att upp- nå krav som fanns specificerade, likt en produktbacklogg. Den gav också stöd till gruppen genom att tydligt kunna kommunicera krav mellan kund och grupp, vilket ledde till färre missuppfattningar om systemets som skulle utvecklas.
6.1.2.3 Kvalitetsplan
Kvalitetsplanen skrevs för att formalisera vilka kvalitetsaspekter gruppen skulle fokusera på under arbetet och olika processer för att gruppens arbete skulle hålla hög kvalitet. När kvali- tetsplanen skrevs gav den upphov till många diskussioner i gruppen som gjorde att medlem- marna blev eniga om hur de olika processerna skulle skötas. Detta var nyttigt eftersom hela gruppen var överens gällande exempelvis kodstandard när utvecklingen väl påbörjades.
6.1.2.4 Arkitekturdokument
Arkitekturdokumentet skrevs för att formulera hur systemet som skulle utvecklas skulle upp- fylla de krav som fanns specificerade i kravspecifikationen. I dokumentet beskrevs delsystem, kommunikationen mellan delsystem samt designbeslut. Systemets arkitektur genomgick sto- ra förändringar under projektets gång. Dessa förändringar finns beskrivna i arkitekturdoku- mentet för att ge perspektiv på beslut och begränsningar. I praktiken användes inte arkitek- turdokumentet i någon större utsträckning och blev istället ett dokument som uppdaterades i samband med att nya beslut fattades vilket medförde att det ofta var inaktuellt.
6.1.2.5 Testplan
Testplanen skrevs för att planera tester och formalisera strategierna för hur testningen skul- le gå till. Det är också ett dokument som innehåller alla testfall som gruppen har utfört. Gruppen har inte fått mycket nytta av testplanen då testning ofta var en eftertanke under utvecklingsarbetet. Detta har gjort att många tester blivit inskrivna i efterhand då testet till- kom under utveckling istället för att vara ett planerat test. Gruppen tyckte att det var svårt att planera ut varje test i förväg, därför skrevs testfallen i efterhand eller samtidigt som de implementerades.
6.1.2.6 Generellt
Generellt sett har gruppen producerat många dokument vilket har upptagit mycket tid. Vissa dokument som projektplanen och kvalitetsplanen gav bra resultat när de skrevs men upplev- des inte som relevanta i de senare delarna av projektet. Anledningen till detta var att de inte användes av gruppen efter att de hade skrivits. Andra dokument som arkitekturdokumentet och testplanen användes i mycket liten utsträckning och uppdaterades ofta i efterhand då de hade blivit inaktuella. De användes snarare för att dokumentera vad gruppen hade gjort
6.2. Resultat
istället för att skriva vad gruppen skulle göra. Kravspecifikationen var det mest använda dokumentet och var till stöd för gruppen under utvecklingen.
Inom gruppen lades mycket tid på dokumentation och mindre tid på utveckling. Gruppen kände att mindre tid kunde ha spenderats på dokumentation och mer på utveckling. På så sätt hade gruppen kunnat lägga mer fokus på att göra prototypen mer robust och fler funktio- ner hade kunnat implementeras. Vidare hade mer tid kunnat avsättas för att testa prototypen och därmed höja dess kvalitet.
6.1.3
Systemanatomi
När systemanatomin skapades i början av projektet var många i gruppen tveksamma till dess relevans. Gruppen skapade den med tanken att det var en översikt av hur alla funk- tioner interagerade. Under skapandet visade det sig att det fanns oklarheter kring hur alla delar kommunicerade med varandra, framförallt med kundens delsystem. Gruppen diskute- rade kring dessa oklarheter och kom till slut överens om hur anatomin borde se ut. Parallellt med att systemanatomin skapades producerades även arkitekturdokumentet med gruppens systemöversikt, se Figur 5.1. Då gruppens systemöversikt innehöll merparten av den infor- mation som systemanatomin innehöll fanns alltså ett stort överlapp mellan dessa systembe- skrivningar. Just detta överlapp gav upphov till gruppens tveksamheter gällande systemana- tomins nödvändighet.
I takt med att arbetet fortlöpte användes eller uppdaterades inte systemanatomin. Grup- pen ansåg att systemanatomin var användbar i projektets inledande fas då gruppen blev ense om vilka användarfunktioner som skulle implementeras. Detta innebar alltså att systemana- tomin fyllde en funktion när den producerades men därefter snabbt blev irrelevant.
6.2
Resultat
I detta kapitel diskuteras projektets resultat, närmare bestämt hur arkitekturen utvecklats, val av tekniker samt återstående arbete.
6.2.1
Systemets utveckling
I detta delkapitel beskrivs hur systemets arkitektur har förändrats under projektets gång.
6.2.1.1 Första iterationen
Vid projektets start formulerades de grundläggande kommunikationsvägarna för systemet. Systemet delades upp i delsystem, se Figur 6.1 för uppdelningen och kommunikationsvägar- na. Det skapades även en systemanatomi för att förstå hur alla funktionaliteter skulle hänga samman, se Figur 6.2.
Figur 6.1: Tidig översikt över alla delsystem och hur de förväntades kommunicera. Blått mot- svarar redan befintliga system och grönt de som behövde skapas.
6.2. Resultat
Figur 6.2: Systemanatomi
6.2.1.2 Andra iterationen
Efter vidare diskussioner inom gruppen gällande hur Hjälmen och Dashboarden skulle kom- municera togs två alternativ fram. Ena alternativet var att upprätta en direktanslutning mel- lan Hjälmen och Dashboarden. Det andra alternativet var att en server skulle användas som mellanhand. Gruppen ansåg att en server skulle underlätta arbetet avsevärt då den skulle minska beroendet mellan Hjälmen och Dashboarden. Ett exempel på detta är att Dashboar- den alltid skulle vara tillgänglig oavsett Hjälmens tillgänglighet. Med dessa fördelar i åtanke valde gruppen att använda en server för att vidarebefordra videoströmmen, sensordata och meddelanden samt hysa Dashboard-webbsidan. Se Figur 6.3 för en översikt över systemet efter dessa ändringar.
Figur 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 kommunika- tionsmetod.
6.2. Resultat
6.2.1.3 Tredje iterationen
Efter en mer ingående undersökning av videoströmningsprotokoll beslutade gruppen för att använda sig av WebRTC. Bakgrunden till detta beslut var att WebRTC gav lägre latens än al- ternativen. Gruppen hade identifierat latens som en viktig faktor. Kunden bad även gruppen att använda Apache NiFi på serversidan och informerade gruppen om att Apache Ignite- dabasen inte kunde spara videoströmmen. Dessa ändringar resulterade i en ny systemöver- sikt, se Figur 6.4.
Figur 6.4: Översikt av alla delsystem och hur de kommunicerar. Blått motsvarar redan befint- liga system, grönt de som behöver skapas och rött kommunikationsmetod.
6.2.1.4 Fjärde iterationen
Efter tydliggörande gällande integrationen mellan Infokartan och Dashboard, samt Ignite bestämde gruppen i samspel med kunden att det inte är prioriterat att integrera projektgrup- pens system mot kundens befintliga kartapplikation. Att integrera dessa system är något kunden eventuellt kommer att göra efter projektets slut. Samtidigt togs beslutet att, inom ramarna för detta projekt, använda en MySQL-databas istället för Ignite. Bakgrunden till det- ta är att MySQL är lättare för projektgruppen att konfigurera samt att MySQL och Ignite har mycket snarlika gränssnitt vilket innebär att kunden enkelt kan ersätta projektgruppens MySQL-databas med en Ignite-databas.
Gruppen undersökte också vidare kring WebRTC och kom fram till att en Kurento Media Server skulle vara fördelaktig. Detta skulle möjliggöra att spara videoströmmar på servern samt att tillåta flera klienter att titta på samma videoström. För att få WebRTC att fungera satte gruppen upp en signaleringsserver skriven i Node.js, en TURN-server som använder sig av mjukvaran Coturn och en Kurento Media Server. Detta motsvarar den senaste och slutgiltiga iterationen av arkitekturen och ses i Figur 5.1.
6.2.2
Alternativ till implementationen
I detta delkapitel diskuteras val som projektgruppen gjorde under utvecklingens gång och alternativa lösningar som hade kunnat implementeras.
6.2. Resultat
het med Unreal. Valet i detta fall blev dock att använda Unity eftersom det redan fanns ett färdigt API för vissa tekniker som användes under projektet, exempelvis WebRTC. Microsoft rekommenderar dessutom Unity för att komma igång fort med utveckling till HoloLens. En nackdel med projektgruppens val var att Unreal Engine:s stöd för visuell programmering i formen av blueprints var något som projektgruppen hade kunnat haft stor nytta av. Om pro- jektgruppen hade använt Unreal hade dock hela WebRTC-implementationen behövt byggas från grunden.
6.2.2.2 Val av strömningsprotokoll
Valet av strömmingsprotokoll föll på WebRTC. Bakgrunden till detta var primärt dess lå- ga latens samt det faktum att JavaScript erbjuder ett färdigt API för att skicka- och ta emot WebRTC-strömmar. Innan projektgruppen beslutade att använda WebRTC övervägdes även strömningsprotokollet HLS. HLS erbjer stöd för direkt tillbakaspolning av videoströmmen, en funktion som kunden hade uttryckt intresse för. En nackdel med HLS är att protokollets utformning leder till signifikant latens. Gruppen identifierade latens som en viktig faktor, då kommunikation mellan Hjälmen och Dashboarden skulle vara så nära realtid som möjligt.
Vidare hade kunden önskemål om att en videoström skulle kunna visas i flera Dashboards samtidigt, något som HLS har inbyggt stöd för men WebRTC saknar. Genom att använda en mediaserver kunde WebRTC kompletteras med denna funktionalitet. På grund av vikten av låg latens och enkelheten att komplettera WebRTC med en mediaserver, valdes HLS bort.
6.2.2.3 Backend-server
Ett önskemål från kunden var att använda Apache NiFi i så stor utsträckning som möjligt, då kunden sedan tidigare använde NiFi. Projektgruppen upplevde dock NiFi som komplext efter försök att implementera vissa delar av projektet med hjälp av denna mjukvara. NiFi:s komplexitet i kombination med projektets begränsade omfattning resulterade i att projekt- gruppen såg NiFi som ett hinder i utvecklingen och valde att inte använda det i någon större utsträckning. Projektgruppen valde då att skriva merparten av all backend-mjukvara i Node.js då delar av projektgruppen har arbetat med Node.js tidigare och hade goda erfarenheter. Ef- tersom backend-mjukvaran inte innehåller några specifika tekniker bundna till Node.js var och är det möjligt att implementera dessa delar i flera andra programmeringsspråk.
6.2.2.4 Egen implementation av kommunikation med KMS
För att kommunicera med KMS fanns två alternativ, via ett Websocket-API eller Kurentos egna JavaScript-bibliotek. För att få god förståelse och flexibilitet använde projektgruppen sig av Websocket-API:t. Att skriva sin egen implementation var tidskrävande men gruppen anser att det resulterade i bättre kodstruktur.
6.2.3
Återstående arbete
Alla funktionella krav genomfördes med undantag för de som rörde sensordata. Då gruppen inte fick tillgång till en HoloLens kunde inte systemet testas och integreras mot den tänkta hårdvaran. Hela systemet skulle också behöva förbättrad robusthet och bättre felhantering, exempelvis felmeddelanden i Dashboarden om en videoanslutning misslyckas.
6.2.4
Lärdomar
Ett projekt av den här storleken innebär många utmaningar och möjligheter, vilket lägger grunden för många nya erfarenheter och lärdomar. I detta delkapitel beskrivs de viktigaste lärdomarna.
6.3. Arbetet i ett vidare sammanhang
6.2.4.1 Kundkontakt
En utmaning som var framträdande i projektets inledande fas var låg tillgänglighet från kun- dens sida. Gruppen hade många frågor till kunden som hade kunnat besvaras av medlemmar i hans team. Gruppen tog kontakt med en av dessa medlemmar, men hade kunnat göra det betydligt tidigare för att få bättre underlag för planering och utförande av projektet i ett tidi- gare skede.
6.2.4.2 Administration
För att projektgruppen skulle kunna samarbeta effektivt behövdes tillfällen då gruppen in- ternt kunde planera arbetet. Samtidigt ville gruppen minimera tiden som lades på möten och andra administrativa aktiviteter, därför bestämde sig gruppen för att ha ett vecko- och ett Scrum-möte varje vecka. Utöver dessa två fanns inga regelbundet inplanerade möten. Even- tuella andra möten bokades in efter behov eller på önskemål av en gruppmedlem. Genom att arbeta på detta sätt kunde projektgruppen försäkra sig om att så mycket som möjligt av tiden lades på aktiviteter som drev projektet framåt.
6.2.4.3 Distansläge
I samband med att universitetet övergick till distansläge behövde projektgruppen också om- organisera sitt arbete och nyttja digitala verktyg och hjälpmedel i en betydligt större utsträck- ning än planerat. Detta arbetssätt gav gruppens medlemmar många nya erfarenheter och lär-