Linköpings universitet SE–581 83 Linköping
Linköpings universitet | Insitutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik
202020 | LIU-IDA/LITH-EX-G--2020/020--SE
Drone Interactive Map
–
Ett lättanvänt system för kartläggning med drönare
Drone Interactive Map
–
A Simple System for Aerial Imagery Using Drones
Herman Appelgren
Marcus Elander
Maya Fogelberg
Ludvig Fors
Daniel Myrén
Henrik Nilsson
Arvid Sundqvist
Handledare : Jonas Wallgren 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/.
© Herman Appelgren, Marcus Elander, Maya Fogelberg, Ludvig Fors, Daniel Myrén, Henrik Nilsson, Arvid Sundqvist
Sammanfattning
Denna rapport handlar om sju studenters kandidatarbete som utfördes i kursen TDDD96 -Kandidatprojekt i programvaruutveckling vid Linköpings universitet under våren 2020. Målet med projektet var att utveckla en webbapplikation som visar en karta, där an-vändaren kan styra drönare genom att specificera ett område på denna karta. Drönarna tar flygfoton över området som sedan visas på kartan. Resultatet blev en fungerande produkt för demonstrationssyften, en teknisk beskrivning av produkten och en användarmanual. Rapporten innehåller även sju individuella delar som ger en fördjupning inom olika del-områden av projektet.
Projektgruppen vill rikta sina tack till kunden RISE och speciellt till kontaktpersonen Andreas Gising som varit till mycket stor hjälp under projektets gång med både teknisk hjälp och gott samarbete. Gruppen vill även tacka de externa parter som tillhandahållit sin tid för intervjuer och användartester. Dessutom tackas handledare Jonas Wallgren och examinator Kristian Sandahl för stöd och rådgivning under arbetets gång.
Innehåll
Sammanfattning iii Författarens tack iv Innehåll v Figurer xii Tabeller xiii 1 Inledning 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställning . . . 2 1.4 Avgränsningar . . . 2 1.5 Begreppsdefinitioner . . . 2 2 Bakgrund 4 2.1 Kunden . . . 4 2.2 Kundens vision . . . 4 2.3 Nuläge . . . 5 2.4 Resurser . . . 5 2.4.1 Lokaler . . . 5 2.4.2 Gruppmedlemmar . . . 5 2.4.3 Ekonomi . . . 6 2.5 Organisation . . . 6 2.5.1 Roller . . . 6 2.5.2 Handledare . . . 82.5.3 Gruppuppdelning och delansvar . . . 8
2.6 Tidigare erfarenheter . . . 8
2.7 Distansläge . . . 8
2.8 RISE Drone System . . . 8
3 Teori 10 3.1 Verktyg . . . 10
3.1.1 Kommunikation . . . 10
3.1.2 Editorer . . . 11
3.1.3 Lagring . . . 11
3.1.4 Planering och rapportering . . . 11
3.2 Programmeringsspråk . . . 11
3.2.1 Python . . . 12
3.2.2 JavaScript . . . 12
3.3.1 ER-modellen . . . 12
3.3.2 SQLite3 . . . 13
3.3.3 SQLAlchemy . . . 13
3.4 Andra bibliotek/verktyg . . . 13
3.4.1 Node.js . . . 13
3.4.2 Node Packet Manager . . . 13
3.4.3 React . . . 14 3.4.4 Material Design . . . 14 3.4.5 Leaflet . . . 14 3.4.6 Redux . . . 14 3.4.7 Socket.IO . . . 14 3.4.8 ZeroMQ . . . 14 3.4.9 Flask . . . 14 3.4.10 Tileserver . . . 15 3.4.11 OSM-data . . . 15 3.5 Användbarhet . . . 15 4 Metod 16 4.1 Metod för hur frågeställningarna besvaras . . . 16
4.1.1 Hur har systemet implementerats så att det skapar värde för kunden? . 16 4.1.2 Hur har systemets utformning påverkats av dess tänkta användarsce-nario? . . . 17
4.1.3 Hur har erfarenheter från tidigare projekt påverkat detta projekt, och vilka erfarenheter från detta projekt kan vara intressanta för framtida projekt? . . . 17
4.1.4 Vilka delar av förarbetet skapade värde inför implementationsfasen? . . 17
4.1.5 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 17 4.2 Utvecklingsplan . . . 17 4.2.1 Utvecklingsmetod . . . 18 4.2.2 Veckoplanering . . . 19 4.2.3 Versionshantering . . . 20 5 Resultat 23 5.1 Systembeskrivning . . . 23
5.1.1 Översiktlig beskrivning av systemet . . . 23
5.1.2 Front-end . . . 23
5.1.3 Back-end . . . 26
5.1.4 Kommunikation . . . 27
5.1.5 Tileserver . . . 28
5.1.6 Värde för kunden . . . 29
5.2 Utvärdering av hur väl produkten uppfyller kraven . . . 29
5.2.1 Kravspecifikation . . . 29
5.2.2 Kvalitetskrav . . . 30
5.3 Arbetsbeskrivning . . . 31
5.3.1 Förarbete . . . 31
5.3.2 Samarbete med kunden . . . 32
5.3.3 Kvalitetsarbete . . . 32 5.3.4 Testarbete . . . 33 5.4 Gemensamma erfarenheter . . . 33 5.4.1 Erfarenheter från projektet . . . 33 5.4.2 Tidigare erfarenheter . . . 36 5.4.3 Distansläge . . . 37
5.5.1 En jämförelse av mjukvaruarkitekturer för front-endutveckling av
Ar-vid Sundqvist . . . 38
5.5.2 Hur tester kan användas vid mjukvaruutveckling av Daniel Myrén . . . 38
5.5.3 Gruppdynamikens inverkan på produktionsresultat av Henrik Nilsson 38 5.5.4 Att anpassa ett flygfoto till en kartbild av Herman Appelgren . . . 38
5.5.5 Scrum som utvecklingsmetod för ett kandidatprojekt av Ludvig Fors . . 38
5.5.6 Utvärdering och förbättring av kvalitetsprocess av Marcus Elander . . . 38
5.5.7 Hållbar utveckling av system ur ett miljö, individuellt och ekonomiskt perspektiv av Maya Fogelberg . . . 39
6 Diskussion 40 6.1 Utvärdering av resultat . . . 40
6.1.1 Restlista . . . 40
6.1.2 Möjligheter till vidareutveckling . . . 41
6.1.3 Alternativa designbeslut . . . 41 6.2 Diskussion av erfarenheter . . . 43 6.2.1 Kundkontakten . . . 43 6.2.2 Förberedelsearbetet . . . 43 6.2.3 Systemanatomin . . . 43 6.2.4 Dokumentarbetet . . . 43 6.2.5 Tidsplanering . . . 43 6.2.6 Tidigare erfarenheter . . . 44 6.2.7 Uppdelning i utvecklingsgrupper . . . 44 6.2.8 Ansvarsfördelning . . . 45
6.2.9 Jämförelse mellan tidigare erfarenheter och erfarenheter från detta projekt 45 6.3 Metod . . . 45
6.3.1 Källkritik . . . 45
6.3.2 Diskussion av utvecklingsmetod . . . 45
6.4 Arbetet i ett vidare sammanhang . . . 46
6.4.1 Samhälleliga aspekter . . . 46
6.4.2 Miljömässiga aspekter . . . 46
6.4.3 Etiska aspekter . . . 46
7 Slutsatser 48 7.1 Frågeställningar . . . 48
7.1.1 Hur har systemet implementerats så att det skapar värde för kunden? . 48 7.1.2 Hur har systemets utformning påverkats av dess tänkta användarsce-nario? . . . 48
7.1.3 Hur har erfarenheter från tidigare projekt påverkat detta projekt, och vilka erfarenheter från detta projekt kan vara intressanta för framtida projekt? . . . 48
7.1.4 Vilka delar av förarbetet skapade värde inför implementationsfasen? . . 49
7.1.5 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 49 7.2 Projektets syfte . . . 49
A En jämförelse av mjukvaruarkitekturer för frontend utveckling av Arvid Sundqvist 50 A.1 Inledning . . . 50
A.1.1 Syfte . . . 50
A.1.2 Frågeställningar . . . 50
A.2 Bakgrund . . . 50
A.3 Teori . . . 51
A.3.1 Vad är en mjukvaruarkitektur? . . . 51
A.3.3 Klassisk MVC . . . 52
A.3.4 MVVM . . . 53
A.3.5 Komponentbaserad arkitektur . . . 53
A.3.6 DIM-arkitekturen . . . 54
A.4 Metod . . . 54
A.4.1 Informationssökande . . . 54
A.5 Resultat . . . 55
A.5.1 Skillnader och likheter mellan DIM-arkitekturen och MVVM . . . 55
A.5.2 Fördelar med DIM-arkitekturen . . . 56
A.5.3 Förbättringsmöjligheter med DIM-arkitekturen . . . 56
A.6 Diskussion . . . 56
A.7 Slutsatser . . . 57
B Hur tester kan användas vid mjukvaruutveckling av Daniel Myrén 58 B.1 Inledning . . . 58 B.1.1 Syfte . . . 58 B.1.2 Frågeställning . . . 58 B.2 Bakgrund . . . 59 B.3 Begränsningar . . . 59 B.4 Teori . . . 59 B.4.1 Enhetstest . . . 59 B.4.2 Integrationstest . . . 59 B.4.3 Systemtester . . . 60 B.4.4 Acceptanstester . . . 60 B.4.5 Vattenfallsmetoden . . . 60 B.4.6 Agil testning . . . 60 B.4.7 Testdriven utveckling . . . 61 B.5 Metod . . . 61 B.6 Resultat . . . 61 B.6.1 Enhetstester . . . 61 B.6.2 Integrationstester . . . 61 B.6.3 Systemtester . . . 62 B.6.4 Acceptanstester . . . 62 B.6.5 Testmetod . . . 62 B.7 Diskussion . . . 62 B.8 Slutsatser . . . 62
C Gruppdynamikens inverkan på produktionsresultat, av Henrik Nilsson 64 C.1 Inledning . . . 64 C.1.1 Syfte . . . 64 C.1.2 Frågeställning . . . 64 C.2 Bakgrund . . . 64 C.3 Teori . . . 65 C.3.1 Definitioner . . . 65 C.3.2 Tidigare arbete . . . 65 C.4 Metod . . . 66 C.4.1 Enkät . . . 66 C.4.2 Litteraturstudie . . . 68 C.5 Resultat . . . 68 C.5.1 Enkät . . . 68 C.5.2 Litteraturstudie . . . 71 C.5.3 Tolkning . . . 72 C.6 Diskussion . . . 73
C.6.1 Metod . . . 73
C.6.2 Resultat . . . 73
C.7 Slutsatser . . . 74
D Att anpassa ett flygfoto till en kartbild, av Herman Appelgren 75 D.1 Inledning . . . 75 D.1.1 Bakgrund . . . 75 D.1.2 Frågeställning . . . 75 D.1.3 Begränsningar . . . 76 D.2 Metod . . . 76 D.3 Teori . . . 76 D.3.1 Tidigare arbete . . . 76 D.3.2 Perspektivtransform . . . 77 D.3.3 Kantdetektering . . . 77 D.3.4 OpenCV . . . 77 D.3.5 Numpy . . . 78 D.3.6 Matplotlib . . . 78 D.4 Resultat . . . 78
D.4.1 Extrahera konturer från kartbilden . . . 78
D.4.2 Extrahera konturer från flygfotot . . . 79
D.4.3 Matchning av konturer . . . 80
D.4.4 Resultat på exempelbilder . . . 81
D.5 Diskussion . . . 81
D.6 Slutsatser . . . 82
E Scrum som utvecklingsmetod för ett kandidatprojekt av Ludvig Fors 83 E.1 Inledning . . . 83 E.1.1 Syfte . . . 83 E.1.2 Frågeställning . . . 83 E.2 Bakgrund . . . 83 E.3 Teori . . . 84 E.3.1 Scrum . . . 84 E.4 Metod . . . 84
E.4.1 Empirisk studie . . . 84
E.4.2 Litteraturstudie . . . 85
E.5 Resultat . . . 85
E.5.1 Attitydutveckling . . . 85
E.5.2 Bidragande komponenter . . . 85
E.5.3 Utmaningar . . . 85
E.5.4 Resultat av litteraturstudie . . . 86
E.6 Diskussion . . . 86
E.6.1 Passande och opassande komponenter i Scrum . . . 86
E.6.2 Attityder mot Scrum . . . 87
E.6.3 Utmaningar . . . 87
E.6.4 Kvalitet på studie . . . 87
E.7 Slutsatser . . . 87
E.7.1 Vilka komponenter av Scrum bidrog mest till ökad produktivitet inom projektet? . . . 87
E.7.2 Hur förändrades projektgruppens attityd till Scrum under projektets gång? . . . 88
E.7.3 Vad fanns det för utmaningar med att använda Scrum inom projekt-gruppen? . . . 88
F Utvärdering och förbättring av en kvalitetsprocess av Marcus Elander 89 F.1 Inledning . . . 89 F.1.1 Syfte . . . 89 F.1.2 Frågeställning . . . 89 F.2 Bakgrund . . . 89 F.3 Teori . . . 90 F.3.1 Mjukvarukvalitet . . . 90
F.3.2 Capability Maturity Model Integration (CMMI) . . . 90
F.3.3 Kodgranskning . . . 91
F.4 Metod . . . 91
F.5 Resultat . . . 91
F.5.1 Presentation av data . . . 92
F.5.2 Feedback från deltagande gruppmedlemmar . . . 92
F.5.3 Genomförda förändringar . . . 92
F.6 Diskussion . . . 92
F.6.1 Resultat . . . 93
F.6.2 Alternativa tillvägagångssätt . . . 93
F.6.3 Att utvärdera processer . . . 93
F.7 Slutsatser . . . 94
F.7.1 Frågeställningar . . . 94
F.7.2 Avslutande tankar . . . 94
G Hållbar utveckling av system ur ett miljö, individuellt och ekonomiskt perspek-tiv av Maya Fogelberg 95 G.1 Inledning . . . 95 G.1.1 Syfte . . . 95 G.1.2 Frågeställning . . . 95 G.1.3 Avgränsningar . . . 95 G.1.4 Begreppsdefinitioner . . . 96 G.2 Bakgrund . . . 96 G.3 Teori . . . 96 G.3.1 SusAF . . . 96 G.3.2 SusAD . . . 96 G.3.3 Dimensioner . . . 97 G.3.4 Effekter . . . 97 G.4 Metod . . . 98 G.4.1 Intervjuer . . . 98 G.4.2 Frågor . . . 98 G.5 Resultat . . . 99 G.5.1 Miljöaspekten . . . 100 G.5.2 Ekonomiaspekten . . . 100 G.5.3 Individaspekten . . . 101 G.5.4 Dimensioner . . . 101 G.5.5 SusAD . . . 101 G.6 Diskussion . . . 102 G.6.1 Resultat . . . 103 G.6.2 Interjuver . . . 104 G.7 Slutsatser . . . 104
G.7.1 Vilka effekter kan vårt system ge för miljömässiga, individuella och ekonomiska aspekter av hållbarhet? . . . 104
G.7.2 Vilka samband finns mellan dessa aspekter? . . . 104
G.7.3 Hur kan ett sustainable usability diagram ge förståelse för ett systems påverkan ur ett hållbarhets perspektiv? . . . 104
H Viktade enkätsvar för undersökning om gruppdynamik och produktionsmål 105
I Enkätsvar för Scrum som utvecklingsmetod 107
J Enkätsvar om kodgranskning som arbetsprocess 110
K RDS API 113
L API 122
Figurer
2.1 Organisationsschema. . . 7
4.1 Arbetsflöde enligt GitFlow. . . 21
5.1 Systemöversikt. . . 24
5.2 Systemets startläge med fyra utplacerade noder. . . 25
5.3 Systemets huvudläge med två öppna sidomenyer. . . 25
5.4 Dialogruta för att bekräfta områdesdefinitionen. . . 25
5.5 Systemanatomi . . . 32
5.6 Första utkastet av tidsplanen. . . 34
5.7 Andra utkastet av tidsplan, för senare delen av projektet. . . 34
5.8 Antalet arbetstimmar som spenderades på design och implementation av systemet. 35 5.9 Antalet arbetstimmar som spenderades på kandidatrapporten. . . 35
A.1 Förälder/barn Dataflow. . . 52
A.2 MVC. . . 53
A.3 MVVM. . . 54
A.4 DIM arkitektur. . . 55
C.1 RT mot KO . . . 69
C.2 RT mot PF . . . 69
C.3 GG mot KO . . . 70
C.4 GG mot PF . . . 70
D.1 Fyra steg i behandlingen av en kartbild. . . 79
D.2 Fyra steg i behandlingen av ett flygfoto. . . 80
D.3 Matchning av bilder och anpassad placering. . . 81
G.1 Sustainable usability diagram. . . 97
G.2 Sustainable usability diagram med effekter. . . 102
I.1 Attityden mot Scrum före projektstart. . . 107
I.2 Attityden mot Scrum efter projektstart. . . 108
I.3 Bidragande scrumkomponenter. . . 108
I.4 Förhindrande scrumkomponenter. . . 108
I.5 Utmaningar med Scrum. . . 109
I.6 Hanterande av utmaningarna. . . 109
J.1 Svar på om att skriva bra kod. . . 110
J.2 Motivering till varför föregående svar. . . 111
J.3 Svar på om man tyckte om helgruppsgranskning. . . 111
J.4 Svar på om man tyckte om releasegranskning. . . 112
J.5 Svar på om man tycker produkten håller hög standard. . . 112
Tabeller
1.1 Definitioner av projekttermer . . . 2
2.1 Projektdeltagare . . . 5
4.1 Utvecklingstermer. . . 17
4.2 Utvecklingsschema . . . 19
5.1 Sammanställning av kravspecifikationens krav. . . 30
C.1 Enkätfrågor . . . 66
C.2 Datapunkter av enkätsvar . . . 71
F.1 Frågor i avslutande enkät. . . 91
F.2 Insamlad data från kodgranskning med front-end . . . 92
F.3 Insamlad data från kodgranskning med back-end . . . 92
G.1 Definitioner av projekttermer del G . . . 96
G.2 Frågor rörande miljöaspekten . . . 99
G.3 Frågor rörande ekonomiaspekten . . . 99
G.4 Frågor rörande den Individuella aspekten . . . 99
H.1 Viktade enkätsvar för undersökning om gruppdynamik och produktionsmål . . . 105
H.2 Viktade enkätsvar för undersökning om gruppdynamik och produktionsmål (fort-sättning...) . . . 106
1
Inledning
Drönare används idag för kartläggning och andra uppgifter av räddningstjänsten och många andra organisationer. Användningsområdena är många men användarna desto färre. Hög-presterande drönare är i dagsläget svårmanövrerade och kräver utbildade användare. Detta gör att drönaranvändning ibland undviks, trots att det skulle förenkla arbetet i många verk-samheter.
Målet med projektet som beskrivs i denna rapport var att implementera ett system som låter användaren hantera drönare utan att behöva fokusera på manövreringen. Som tänkt målgrupp för systemet var i första hand räddningsledare som använder drönare för att spå-ra spridningen av bränder. Projektet skedde på beställning av Research Institute of Sweden (RISE). Denna rapport beskriver processen från idé till färdigt system. Projektet genomfördes av sju studenter i kursen TDDD96, Kandidatprojekt i programvaruutveckling.
1.1
Motivering
När räddningsledare använder drönare i sitt arbete krävs det idag en extra grupp som foku-serar helt på informationsinsamling med drönare. Visionen med det system som implemen-terades i detta projekt är att räddningsledaren, utan utbildning i hur en drönare manövreras, enkelt ska kunna styra en drönare, även under en potentiellt stressfylld situation. Systemet låter användaren snabbt komma igång och fokuserar på användarvänlighet. Systemet åstad-kommer detta genom ett lättanvänt användargränssnit, där bilderna drönarna tar presenteras på en karta. Användaren behöver inte manuellt manövrera drönarna, utan specificerar istäl-let endast vilket område som är av intresse och överlåter detaljerna om hur dessa foton tas till systemet.
1.2
Syfte
Syftet med projektet var att utveckla det system som beskrivs ovan. Projektet innefattade hela utvecklingsprocessen, inklusive specifikation av krav tillsammans med kunden, design och implementation av systemet samt leverans av system inklusive dokumentation till kunden.
Denna kandidatrapport ingick även som en del av projektet. Rapportens syfte är att besva-ra frågeställningarna i avsnitt 1.3. I besva-rapporten diskutebesva-ras hur användbarhet syns i ett system
1.3. Frågeställning
och hur man skapar ett mervärde för kunden. Stort fokus ligger också på hur olika faktorer som förarbete, tidigare erfarenheter och olika utvecklingsmetoder påverkat projektarbetet.
1.3
Frågeställning
I denna rapport behandlas följande frågeställningar.
1. Hur har systemet implementerats så att det skapar värde för kunden? 2. Hur har systemets utformning påverkats av dess tänkta användarscenario?
3. Hur har erfarenheter från tidigare projekt påverkat detta projekt, och vilka erfarenheter från detta projekt kan vara intressanta för framtida projekt?
4. Vilka delar av förarbetet skapade värde inför implementationsfasen? 5. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?
1.4
Avgränsningar
Systemet implementerades utan möjlighet att testa med verkliga drönare. Istället användes en simulering av systemets samspel med drönare. Detta begränsade vilka tester av systemet som kunde genomföras och ställde högre krav på simuleringen av systemet.
Under utvecklingen hade systemet i första hand en räddningsledare vid brandutryckning som tänkt användare. Analysen av systemet begränsas därför till detta användarscenario.
1.5
Begreppsdefinitioner
Se tabell 1.1 för definitioner av begrepp som används i resten av denna rapport.
Tabell 1.1: Definitioner av projekttermer
Ord Definition
Projektgruppen Personerna som genomförde projektet och står som författare till denna rapport.
Projektkursen Den kurs vid Linköpings Universitet som detta projekt utförs un-der. Denna har kurskod TDDD96. [1]
Universitetet Linköpings universitet.
Kunden Research Institute of Sweden eller representant för detsamma. Kursledning De handledare och den examinator som ansvarar för
projektkur-sen.
Produkten Den produkt som kunden RISE beställt och som utvecklades och levererades av projektgruppen.
RDS RISE Drone System, ett system för drönarhantering som utveck-las av kunden.
Modul En del av produkten med avgränsad funktionalitet. En moduls skala varierar.
Front-end Den modul av produkten som vänder sig mot användaren. Detta inkluderar bland annat användargränssnitt och de system som körs av slutanvändaren.
1.5. Begreppsdefinitioner
forts. från föregående sida
Ord Definition
Användargränssnitt Undermodul till front-end. Detta är vad användaren ser och in-teragerar med.
Back-end De moduler som servar front-end, bland annat svarsserver och databas.
2
Bakgrund
Detta projekt beställdes av kunden RISE, ett statligt forskningsinstitut. Deras vision för pro-jektet var att underlätta användningen av drönarsystem för kritiska räddningsoperationer. I dagsläget är detta arbete svårt och utbildningskrävande.
2.1
Kunden
RISE är ett oberoende statligt forskningsinstitut som genom att agera innovationspartner tar sig an samhällets utmaningar. De utvecklar allt från solenergi och vindkraft till drönare. RISE är en samling av flera forskningsinstitut med ett hundratal testbäddar och demonstrations-miljöer. Institutet ägs av svenska staten och arbetar inom områdena näringsliv, akademi och offentlig sektor. De utvecklar tjänster, produkter, teknologier och material som ska bidra till en hållbar framtid och ett konkurrenskraftigt näringsliv. Den avdelning som står som kund till detta projekt är RISE division Digitala system som arbetar i huvudsak med digitalisering inom olika områden i samhället.
2.2
Kundens vision
RISE vision för projektet var att skapa ett system som tar drönaranvändning närmare använ-daren. Systemet ska låta räddningsledare få en översikt vid t.ex. en industribrand. Drönare fotograferar verkligheten och visar dessa fotografier på en karta. System ska vara lättanvänt och kunna användas under pressade situationer. Systemet ska ta över det huvudsakliga an-svaret för att manövrera drönarna från användaren.
Systemet har två olika lägen. I det manuella läget kan användaren av systemet panorera över en karta. Systemet följer då efter användarens vy och tar löpande flygfoton som täcker den vy användaren ser vid tillfället. Håller användaren vyn stilla över ett område tas bilder kontinuerligt över detta område. I det autonoma läget tar systemet istället löpande flygfoton över ett område som användaren specificerat vid uppstart av systemet.
2.4. Resurser
2.3
Nuläge
Beskrivningen av nuläget togs fram genom intervju med en representant för Räddningstjäns-ten i Göteborg. Idag styrs drönare manuellt med en fjärrkontroll, vilket kräver utbildning av användaren. Processen ser enligt intervjupersonen ut så att en operatör finns tillgänglig och att räddningsledaren får be om vad hen vill se, alternativt att operatören förklarar vad som går att ta reda på. Bilder från drönaren strömmas till en mediaenhet som sedan måste med-dela räddningsledaren vad de sett. Vägen mellan att begära en bild och få den levererad är lång. Som konsekvens av den manuella styrningen kan användaren som kontrollerar dröna-ren bli stressad och orolig för att något ska gå fel. Detta begränsar de områden där drönare kan användas, vilket systemet ämnar lösa.
2.4
Resurser
Projektet hade tillgång till och utnyttjade flera olika typer av resurser. Dessa listas i avsnitten nedan.
2.4.1
Lokaler
Projektarbetet utfördes till en början i lokaler vid Linköpings Universitet. Bland dessa fanns en speciellt tilldelad lokal i projektkursen som teamledaren hade möjlighet att boka. RISE tillhandahöll inga lokaler för utvecklingsarbete. Efter att distansläget påbörjats (se avsnitt 2.7) genomfördes allt arbete hemifrån, då universitetets lokaler skulle undvikas under de rådande omständigheterna.
2.4.2
Gruppmedlemmar
Projektet hade sju projektmedlemmar. Dessa listas nedan tillsammans med sina projektroller och kontaktuppgifter. Projektet utvecklades i sin helhet av dessa personer, med stöd från jektkursens personal och kontaktpersoner hos kunden RISE. I avsnitt 2.5.1 beskrivs åtta pro-jektroller. Dessa fördelades mellan projektets sju deltagare genom att tre av projektmedlem-marna delade ansvaret som utvecklingsledare. H. Nilsson hade det huvudsakliga ansvaret och var därför tilldelad titeln utvecklingsledare. Han stöttades av M. Elander och D. Myrén som hade specifikt ansvar för systemets front-end respektive back-end.
Tabell 2.1: Projektdeltagare
Namn Ansvar E-post
Appelgren, Herman Dokumentansvarig herap603@student.liu.se Elander, Marcus Kvalitetssamordnare marel184@student.liu.se Fogelberg, Maya Analysansvarig mayfo508@student.liu.se
Fors, Ludvig Teamledare ludfo119@student.liu.se
Myrén, Daniel Testledare danmy683@student.liu.se
Nilsson, Henrik Utvecklingsansvarig Konfigurationsansvarig
henni142@student.liu.se
2.5. Organisation
2.4.3
Ekonomi
Varje projektmedlem hade 400 timmar att lägga på projektet. Detta inkluderade alla aktivite-ter inom projektkursen, inklusive seminarier och föreläsningar, utvecklingstid, och övrig tid som projektdeltagarna disponerade själva. Under projektets gång blev gruppen erbjuden att gå ner till 380 timmar per person, vilket antogs av sex av gruppens sju medlemmar. Projekt-gruppens totala tidsbudget var således 2 680 timmar. Tiden inkluderade förberedelser, skri-vande av rapport, implementation av system och schemalagda kursmoment. Utöver lagd tid hanterade projektet inga ekonomiska resurser. Projektmedlemmarna bekostade själva interna aktiviteter, som kick-off.
2.5
Organisation
Detta kapitel beskriver projektets organisation. Projektets organisationsschema visas i figur 2.1.
2.5.1
Roller
Analysansvarig. Projektmedlemmen med denna roll hanterade den huvudsakliga
kontak-ten med projektets kund. Analysansvarig ansvarade för att kundens krav dokumenterades och såg till att producerad produkt skulle uppnå dessa. Kravpecifikationen var en stor del i detta arbete (se avsnitt 5.3.1.2). Analysansvarig såg till att kundens behov uppfylldes.
Arkitekt. Arkitekten ansvarade för produktens övergripande struktur och designbeslut.
Denna arkitektur dokumenterades av arkitekten i gruppens arkitekturdokument (se avsnitt 5.3.1.1). Personen med denna projektroll identifierade de huvudsakliga modulerna, såväl ex-terna som inex-terna. Arkitekten såg till att en systemanatomi producerades och hölls uppdate-rad under projektets gång (se avsnitt 5.3.1.5).
Dokumentansvarig. Dokumentansvarig definierade den standard som skrivna
projektar-tefakter följer. Dokument som hanterades internt i projektgruppen samordnades och sam-manställdes av denna projektroll. Hen hade även huvudsakligt ansvar för att planera arbetet inför de inlämningar som genomfördes under projektets gång och agerade som huvudsaklig arbetsledare i det arbetet. Projektmedlemmen med denna roll hade även ett extra ansvar för att agera kunskapsbank för det huvudsakliga redigeringsverktyget som användes, Overleaf (se avsnitt 3.1.2).
Konfigurationsansvarig. Projektmedlemmen med rollen som konfigurationsansvarig hade
som huvudsaklig arbetsuppgift att administrera och kontrollera produktens versionshante-ring i utvecklingsarbetet. Konfigurationsansvarig hade även som speciellt ansvar att hjälpa övriga projektmedlemmar att använda GitLab (se avsnitt 3.1.3), projektets versionshante-ringssystem. I detta ingick även att hantera och övervaka de automatiska tester som inte-grerades och de projektbrädor som sattes upp för att dokumentera utvecklingens mål och problem. Konfigurationsansvarig fastställde användningsprinciper för versionshanterings-systemet (se avsnitt 4.2.3).
Kvalitetsansvarig. Personen med kvalitetsansvar såg till att produktens kvalitetskrav och
kvalitetsmål uppfylldes. Hen följde produktens utveckling och identifierade problem, samt hade överblick över dess utvecklingsstadium. Kvalitetsansvarig hade även huvudsakligt an-svar i att väga hur mycket resurser som borde ha lagts för att produkten skulle uppnå till-fredsställande kvalitet. Hur detta arbete genomfördes definierade kvalitetsansvarig i en kva-litetsplan (se avsnitt 5.3.1.3).
2.5. Organisation
Team
Kund
Kursledning
: Kommunikation sker mellan dessa parter Arkitekt - Arvid Sundqvist
Testledare - Daniel Myrén
Kvalitetsansvarig - Marcus Elander Analysansvarig - Maya Fogelberg Konfigurationsansvarig - Henrik Nilsson Dokumentansvarig - Herman Appelgren
Teamledare - Ludvig Fors
Lennart Ochel Andreas Gising
Examinator - Kristian Sandahl Handledare - Jonas Wallgren
Figur 2.1: Organisationsschema.
Teamledare. Teamledaren agerade som projektgruppens övergripande ledare. Denna
per-son ansvarade för att leda projektets arbete och styra dess riktning. Gruppmedlemmen med detta ansvar hade övergripande kontroll över hela projektprocessen och hade huvudsakligt ansvar för alla övergripande beslut. Särskilt hade teamledaren initiativansvar i planerande och strategiska beslut. Som standard agerade även teamledaren ordförande på möten och ansvarade således för mötesinbjudan och eventuell salsbokning till dessa. Teamledaren age-rade även som huvudsaklig kontakt mot kursledningen. Vid interna problem som ej kunde lösas inom gruppen var det även teamledarens ansvar att ta hjälp av kursledningen.
Testledare. Testledaren säkerställde att testningen av produkten genomfördes under
2.6. Tidigare erfarenheter
dessa testfall integrerades även på GitLab (se avsnitt 3.1.3). Testledarens arbete låg som hu-vudsaklig grund till kvalitetsansvarigs arbete och dessa projektroller samarbetade således nära. Testledaren ansvarade även för att ta fram projektets testplan (se avsnitt 5.3.1.6).
Utvecklingsledare. Som utvecklingsledare ansvarade medlemmen med denna roll för att
planera och ha uppsyn över produktens utveckling. Denna strategiska roll hade utöver det planerande ansvaret även i uppgift att fatta specifika designbeslut och välja övergripande utvecklingsmetod (se avsnitt 5.3.1.7). Denna roll arbetade tillsammans med arkitekten för att se till att systemet var realiserbart och hade möjlighet att uppnå produktkraven.
2.5.2
Handledare
Projektetgruppen fick handledning av Jonas Wallgren. Detta innebar att frågor rörande pro-jektet i första hand togs upp med honom.
2.5.3
Gruppuppdelning och delansvar
Under projektets utvecklingsfas delades projektgruppen upp. Syftet med uppdelningen var att minimera den mängd utbildning som var tvungen att göras innan implementationen av systemet kunde påbörjas. Denna uppdelning gjordes framför allt i systemets två huvudsakli-ga moduler, front-end och back-end. Inom dessa grupper var projektmedlemmarna ytterlihuvudsakli-ga- ytterliga-re tilldelade delansvar, och dessa ansvarade för att leda en specifik del av utvecklingen. Detta innebar även att denna gruppmedlem hade ansvar för att förbereda den specifika delen av implementationen för integration i produkten (se avsnitt 4.2.3).
2.6
Tidigare erfarenheter
Projektmedlemarna har alla under sina år på universitetet genomfört större projektarbeten, exempelvis i kurserna TSEA29 - Konstruktion med mikrodatorer [2] eller TDDD80 - Mobila och sociala applikationer. [3] Båda dessa kurser innehöll större projekt där krav ställdes på projekt-medlemarnas kommunikation, planering och tekniska kunskaper. Erfarenheterna användes som grund för planering av hur projektet skulle genomföras.
Projektmedlemarnas erfarenhet av de språk som användes i projektet varierar. En stor del av projektet bestod av att utveckla en webbapplikation. För att lyckas med projektet behövde projektmedlemmarna därför fördjupa sina kunskaper om detta.
2.7
Distansläge
Under arbetes gång drabbades världen av en pandemi i form av sjukdomen covid-19. Av denna anledning behövde universitets verksamhet övergå till ett distansläge och likaså pro-jektarbetet. Innebörden av detta var att fysiska möten och gemensamt arbete begränsades och diverse verktyg för distansutveckling och möten fick undersökas och tas i bruk.
2.8
RISE Drone System
RISE Drone System, förkortat RDS, är ett system som RISE utvecklar för att bland annat kunna hantera och styra drönare. RDS består av flera delmoduler som tillsammans utgör systemet i sin helhet. De delmoduler som utgör RDS är Get Image Application (GIA) som körs på drö-naren och Swarm Control Service (SCS) som är ett system på marken som kommunicerar med drönaren.
I detta kandidatprojekt utvecklades ytterligare en modul till RDS som kallas Interactive Map Module (IMM) vars syfte är styra drönarna genom att skicka kartdata till RDS och att till-handahålla en webbapplikation där kartdata som tillhandahålls från RDS presenteras. IMM
2.8. RISE Drone System
är beroende av RDS och kommunicerar kontinuerligt med detta. IMM är kompatibel med både modulerna Get Image Application och Swarm Control Service.
3
Teori
I denna del beskrivs den teoretiska bakgrunden för projektgruppens arbete.
3.1
Verktyg
Vissa projektmedlemmar hade särskilt ansvar för att välja och underhålla verktyg för pro-jektets genomförande. Detta val gjordes på rekommendation från kursledningen och efter gruppens egna undersökningar. Verktygen valdes genom att flera alternativ undersöktes och vägdes mot varandra. Dessa diskuterades sedan i grupp eller undersöktes närmare av särkilt berörda projektroller, till exempel utvecklingsansvarig för val av utvecklingsverktyg. Konfi-gurationsansvarig hade ett särkilt ansvar att se till att verktyg hölls tillgängliga och funge-rande (se avsnitt 2.5.1).
3.1.1
Kommunikation
Ett projekts kommunikation, internt och externt, är kritisk. För detta användes flera verktyg. • Slack är en kanalbaserad textkommunikationsapplikation för mobila och stationära plattformar. Kanaler skapas för olika ämnen och diskussioner sker i trådar. Denna an-vändes som projektets huvudsakliga kommunikationsväg. All intern projektrelaterad kommunikation skedde i den projektorganisation som skapats för projektet. [4]
• Messenger är en textkommunikationsapplikation från Facebook. Både gruppchattar och personliga meddelanden kan skapas, men utformningen är enklare än Slack. Grup-pen hade en Messenger-grupp där icke projektkritisk kommunikation sker. [5]
• E-post användes främst av teamledaren i syfte att sprida viktig information till grupp-medlemmarna. Informationen kom från kursledningen eller från andra externa parter. E-posttjänsten Microsoft Outlook användes inom projektet, dit medlemmarna hade till-gång via Linköpings universitets lärplattform Lisam. I detta verktyg skapades även en gruppmail där projektledaren kunde dela information till samtliga projektmedlemmar. [6]
3.2. Programmeringsspråk
• Discord är ett kommunikationsverktyg som användes för att diskutera arbete medan utveckling genomfördes, detta efter att distansläget inleddes och fysisk kontakt försvå-rades. Genom uppdelning i virtuella servrar kunde projektmedlemarna enkelt prata med de som berördes av aktuellt implementationsarbete. [7]
• Zoom är ett videokonferensverktyg som användes som mötesplats med handledaren efter att distansläget inleddes. [8]
3.1.2
Editorer
Flera olika redigeringsverktyg användes i projektet för att skapa kod och dokument.
• Overleaf är ett webbaserat LaTeX-redigeringsverktyg. Detta användes för att framstäl-la dokument i LaTeX. Overleaf erbjuder gemensam redigering, vilket möjliggjorde för projektmedlemmarna att arbeta tillsammans med att skriva och redigera dessa doku-ment. [9]
• I Google Docs skrevs huvudsakligen gruppens interna dokument. Detta redigerings-verktyg liknar alternativ från Microsoft som Word och WordPad, men erbjuder smidig gemensam redigering och delning på Google Drive. [10]
• Visual Studio Code är en lättviktig kodeditor som tillhandahåller både första- och tred-jepartstillägg som kan underlätta vid programmering och texthantering. [11]
3.1.3
Lagring
Följande lagringstjänster användes i projektet för att lagra kod och dokument.
• Google Drive användes för lagring av projektdokument och arbetsfiler. Här skrevs och sparades bland annat mötesprotokoll, filer givna av kursledningen samt andra interna dokument. [12]
• GitLab var det verktyg som användes för hantering och lagring av projektets Git-repositories. På GitLab användes även Kanban-brädor för att spåra utveckling av såväl produkt som dokument. Genom Linköpings Universitet hade projektgruppen tillgång till en fullversion av mjukvaran som körs på universitetets egna servrar. [13]
3.1.4
Planering och rapportering
Följande tjänster användes för att administrera projektet.
• Webbverktyget Clockify användes för att logga lagda projekttimmar. I detta verktyg kan aktiviteter beskrivas och tidsestimeras. Användaren loggar sedan sina timmar un-der en specifik aktivitet. Med detta hölls en noggrann uppsikt över projektets tidsåt-gång. [14]
• För att schemalägga projektgruppsgemensam tid användes Google Calendar, där en kalender upprättades som alla projektmedlemmar hade tillgång till. I kalendern lades bland annat möten, obligatoriska projektmoment och gemensam arbetstid in. [15]
3.2
Programmeringsspråk
3.3. Databas
3.2.1
Python
Python är ett dynamiskt typat programmeringsspråk. Enligt StackOverflows mätning 2019 är Python idag det mest populära programmeringsspråk som inte körs i en webbläsare [16]. Python är, i likhet med JavaScript (se avsnitt 3.2.2), ett interpreterat språk. Språkets syntax är sparsam med tecken och kodblock definieras av indentering. [17]
Det var ett krav från kunden att Python skulle användas för projektets back-end. Det passade bra för projektgruppens arbete, eftersom samtliga projektmedlemmar hade tidigare erfarenhet av programmering i Python.
3.2.2
JavaScript
JavaScript är ett dynamiskt typat programmeringsspråk för webbutveckling som på senare år börjat användas för mycket mer än bara webb. Syntaxen liknar C och Java (från vilket det fått sitt namn) men är i grunden ett helt annat programmeringsspråk än dessa. JavaScript är, i likhet med Python (se avsnitt 3.2.1), ett interpreterat språk. [18]
För att bygga dynamiska webbsidor finns i princip inget alternativ till JavaScript. Java-Script är idag det mest populära programmeringsspråket enligt StackOverflows mätning 2019. [16] På samma lista återfinns även TypeScript, en utökning av JavaScript som kompile-rar ned till vanlig JavaScript-kod. I övrigt är WebAssembly det enda programmeringsspråket bland de tio populäraste som kan köras direkt i moderna webbläsare [19], utan att kompi-leras ned till JavaScript. Valet blev således enkelt. Valet gjordes även att använda JavaScript med så få tillägg som möjligt, alltså uteslöts tillägg som TypeScript. Detta beslut grundades i att projektets medlemmar hade begränsat med erfarenhet av webbprogrammering, och att lägga till ytterligare nya konstruktioner upplevdes som ett extra hinder i inlärningsfasen av projektets utveckling.
3.3
Databas
En databas är ett system som sparar data på ett strukturerat sätt. En användare av en databas kan hämta sparad data, ändra befintlig data och lägga till ny data i databasen. En databas bör vid varje tillfälle vara sammanhängande och alltså fri från logiska motsägelser.
För att åstadkomma detta består en databas av flera distinkta delar. Själva datan sparas i någon typ av filstruktur på en eller flera (i fallet distribuerade databaser) fysiska datorer. Närmast den fysiska datan finns en databashanterare. Databashanteraren är det program som interagerar direkt med datan som sparats på fil, och har därför kontroll över och känne-dom om den fysiska datarepresentationen. Databashanteraren implementerar algoritmer och datastrukturer som möjliggör effektiv interaktion med datan. Slutligen tillhandahåller data-bashanteraren ett API där användaren av databasen genom förfrågningar (eng. query) kan interagera med datan i databasen utan kännedom om den fysiska lagringsstrukturen. [20]
3.3.1
ER-modellen
Den entitetsrelationella datamodellen (ER-modellen) är en populär datamodell för databaser [21]. I ER-modellens konceptuella datamodell delas datan upp i tre delar: entiteter, relatio-ner och attribut. Entiteter är objekt i domänen som ska modelleras. Dessa har attribut, som är information om den specifika entiteten. För varje entitetstyp måste det finnas någon upp-sättning attribut som unikt bestämmer varje entitet av denna typ, en så kallad nyckel. Det är mycket vanligt att denna nyckel består av ett unikt heltal som bestäms automatiskt när en entitet läggs till i databasen. Entiteter förhåller sig till varandra genom relationer. Den logiska datamodellen i ER-modeller uttrycks i form av tabeller. Varje entitetstyp och relation-styp motsvarar en tabell. Varje rad i en tabell representerar en entitets- eller relationsinstans.
3.4. Andra bibliotek/verktyg
Tabellernas kolumner motsvarar de attribut den aktuella entitets- eller relationstypen har. Re-lationstabellerna har förutom relationens attribut även kolumner för de entiteter som ingår i relationen. Entiteterna identifieras med sina nycklar i respektive entitetstabell. [22]
Ändringar i en ER-databas sker genom grupper av ändringar kallade transaktioner. Da-tabashanteraren ska säkerställa att alla transaktioner uppfyller följande s.k. ACID-kriterier. ACID-transaktioner garanterar databasens integritet.
• Atomära – Ändringarna i en transaktion är ska antingen utföras som helhet eller inte alls. Avbryts transaktionen, t.ex. till följd av ett strömavbrott eller att ändringarna är ogiltiga, ska alltså inte delar av transaktionen utföras.
• Konsistenta – Är databasen logiskt sammanhängande innan en transaktion ska den även vara det efter transaktionen.
• Isolerade – Separata transaktioner ska inte märka av varandra, och ska i synnerhet inte kunna få tillgång till andra transaktioners delvis genomförda ändringar.
• Hållbara – En genomförd transaktions ändringar ska inte kunna försvinna ur databasen annat än genom ändringar utförda av efterföljande transaktioner.
3.3.2
SQLite3
SQLite3 är en populär databashanterare med öppen källkod som är licensierad i public do-main. SQLite3 har en filbaserad struktur, där hela databasen sparas som en fil. Databashan-teraren kan köras integrerat i programmet som använder den, utan krav på en dedikerad tråd eller fristående process. SQLite3 har stöd för transaktioner som uppfyller kraven ovan. Endast en instans av databashanteraren kan interagera med filen vid varje tillfälle, men flera transaktioner kan vara aktiva genom samma instans. SQLite3 har stöd för de flesta funktioner i SQL-standarden. I Python 3.8 finns stöd för SQLite3 inbyggt i modulen sqlite3. [23]–[25]
3.3.3
SQLAlchemy
SQLAlchemy är ett Python-bibliotek för interaktion med SQL-baserade databaser. Biblioteket möjliggör interaktion med databasen genom vanliga Python-objekt, inklusive skapande av tabeller och hantering av relationer. SQL-anropen skapas och hanteras dolt för användaren, vilket förutom ökad abstraktion även minskar systemets sårbarhet för SQL-baserade attacker. [26]
3.4
Andra bibliotek/verktyg
Projektet använde flera färdiga bibliotek under implementation av produkten utöver de som angetts ovan. Detta avsnitt redogör för dessa bibliotek.
3.4.1
Node.js
Node.js (eller bara Node) är en exekveringsmiljö för JavaScript som bygger på Googles öppna V8-motor. Under utvecklingsarbetet användes Node för att paketera och sköta körningen av produktens användargränssnitt. [27], [28]
3.4.2
Node Packet Manager
Node Package Manager (NPM) är en tilläggshanterare för Node.js. Projektgruppen använde NPM för att samla och installera alla tillägg till front-end. [29]
3.4. Andra bibliotek/verktyg
3.4.3
React
React är ett av flera populära JavaScript-ramverk för användargränssnitt. React har en egen syntax kallad JSX som är en blandning av JavaScript och HTML, och kan antingen läggas till på redan existerande hemsidor eller användas för att skapa en från grunden. React utvecklas av Facebook och har öppen källkod. [30]
3.4.4
Material Design
Material Design är ett system av riktlinjer, komponenter och verktyg vars mål är att skapa stilrena produkter. Material Design-standarden skapades och underhålls av Google. I detta projekt implementerades Material Design med biblioteket Material-UI, en samling av verktyg för att arbeta med Material Design i React. [31], [32]
3.4.5
Leaflet
Leaflet är ett JavaScript-bibliotek med öppen källkod som används för att hantera kartor. Det tillhandahåller ett flertal funktioner för detta och ett väldokumenterat API. I detta projekt användes ett abstraktionslager som heter React Leaflet. [33], [34]
3.4.6
Redux
Redux är ett bibliotek för centraliserad datalagring i JavaScript-applikationer. [35] Redux byg-ger på Flux-arkitekturen, vilket är en variant av ett Observer Pattern. [36], [37] I detta projekt användes React Redux och Redux Toolkit, som abstraherar och till viss del underlättar ut-vecklingen med Redux. [38], [39]
3.4.7
Socket.IO
Socket.IO är ursprungligen ett JavaScript-bibliotek som tillhandahåller en robust metod för att skicka meddelanden mellan klienter och servrar, men finns idag även till många andra programmeringsspråk. En server definieras med en ip-address och portnummer dit klienter-na kan ansluta. När en klient ansluter sig till servern kan utbytet av meddelanden inledas mellan klienten och servern. För att skicka meddelanden använder sig Socket.IO av en me-tod som kallas long-polling. [40] Socket.IO stödjer också WebSockets som är en snabbare meme-tod. [41])
3.4.8
ZeroMQ
ZeroMQ är ett meddelandebibliotek som används för att skicka meddelanden genom soc-kets. Två enheter kan kommunicera med varandra genom att den ena enheten binder sig till en socket som den andra enheten sedan kan koppla sig till. På så sätt blir tvåvägskommuni-kation mellan dessa enheter möjligt. [42]
3.4.9
Flask
Flask är skrivet i programmeringsspråket Python och används för att skapa webbapplikatio-ner. Flask är ett microframework [43]. Med micro menas att Flask som standard inte tillhanda-håller någon funktionalitet som kan hanteras av redan existerande bibliotek och istället tillåts Flask att enkelt kunna utökas med sådana bibliotek. [43]. Ett exempel på ett sådant biblio-tek som används i detta projekt är Flask-Socket.IO som har använts i detta projekt som get Flask möjlighet att kommunicera med hjälp av Socket.IO. [44] Flask är bland annat beroen-de av biblioteket Werkzeug som implementerar Pythons webbserver gateway-API, som är standard för Python-webbapplikationer. För mer information om Flask och dess beroenden se [43] och [45].
3.5. Användbarhet
3.4.10
Tileserver
En tile är en kvadratisk bild som är placerad i ett rutnät och tillsammans med andra tiles bildar en karta. En tileserver är en server som på begäran förser en klient med tiles. I anropet till servern anges var på kartan och på vilken zoomnivå klienten vill ha tiles, vilka då renderas baserat på befintlig kartdata och sedan skickas till klienten. [46]
3.4.11
OSM-data
OSM står för OpenStreetMap vilket är en karttjänst med öppen källkod. Tjänsten är fri för alla att använda och utveckla för eget eller kommersiellt bruk, förutsatt att man följer OpenStre-etMaps licensavtal. OSM-data är rå kartdata som kan laddas ner från OpenStreOpenStre-etMaps webb-sida. OSM-data kan användas för att skapa en egen tileserver, För mer information om hur en egen tileserver skapades se 5.1.5. [47]
3.5
Användbarhet
Användbarhet innebär hur lätt det är för en användare i ett givet sammanhang att uppnå ett visst mål på ett effektivt sätt. Exempel på mått för att mäta detta är:
• Hur stor andel av givna uppgifter en användare klarar.
• Hur lång tid det tar för användaren att klara av givna uppgifter. • Hur många eller hur få fel som användaren råkar ut för.
Olika metoder kan användas för att testa användbarhet så som användartester och utvärde-ringar av systemet. [48]
4
Metod
I detta avsnitt redovisas hur projektgruppen har arbetat under projektet. Detta inkluderar dels en redogörelse för hur frågeställningarna i avsnitt 1.3 besvaras, dels en beskrivning av projektgruppens utvecklingsmetod.
4.1
Metod för hur frågeställningarna besvaras
Detta avsnitt avser att redogöra för tillvägagångsättet för att besvara rapportens frågeställ-ningar.
4.1.1
Hur har systemet implementerats så att det skapar värde för kunden?
Under utvecklingsarbetets förfas fördes nära diskussioner med kunden gällande dennes vi-sion av hur systemet skulle fungera. Med utgång från dessa diskusvi-sioner formulerades en kravspecifikation som beskrev förväntningar på systemets funktionalitet. Kravspecifikatio-nen låg sedan till grund för desigKravspecifikatio-nen och utvecklingen av systemet. Nya versioner av krav-specifikationen med mindre ändringar togs fram under utvecklingens implementationsfas för att säkerställa att kunden och projektgruppen hade en gemensam syn på vad systemet skulle åstadkomma.
Projektgruppen hade veckovisa möten med kunden under hela projektets gång där kun-den fick uppdateringar på hur projektet framskred. Under dessa möten hade kunkun-den och projektgruppen möjlighet att lyfta frågor som uppkommit om systemets utveckling. Vanligt-vis närvarade projektgruppens analysansvariga och kvalitetssamordnare på dessa möten.
När utvecklingsarbetet närmade sig sitt slutskede genomfördes två systemdemonstratio-ner för kunden. Den första demonstrationen genomfördes i samband med att implementatio-nen av systemets funktionalitet slutförts. Syftet med denna demonstration var att låta kunden ge synpunkter på systemets funktionalitet innan projektets avslut. Den andra demonstratio-nen genomfördes när utvecklingsarbetet hade avslutats. Kunden och projektgruppen gick då gemensamt igenom kravspecifikationen och kontrollerade att systemet uppfyllde dessa krav. En restlista upprättades över de krav som inte uppfylldes av systemet.
4.2. Utvecklingsplan
4.1.2
Hur har systemets utformning påverkats av dess tänkta användarscenario?
För att besvara denna fråga genomfördes en intervju med en medarbetare från räddnings-tjänsten. Under denna intervju låg fokus på hur deras arbetssituation ser ut vid brandutryck-ningar. Syftet med denna intervju var att ringa in de egenskaper systemet behöver ha för att vara till stöd i deras arbete. Under intervjun presenterades även förslag på systemets an-vändargränssnitt. Hur intervjupersonerna från räddningstjänsten interagerade med systemet dokumenterades och stod sedan som grund för utvecklingsarbetet.
4.1.3
Hur har erfarenheter från tidigare projekt påverkat detta projekt, och vilka
erfarenheter från detta projekt kan vara intressanta för framtida projekt?
Under projektet startskede fördes diskussioner inom projektgruppen om erfarenheter från ti-digare projektkurser. Dessa erfarenheter dokumenterades och påverkade hur projektplanen utformades. Åtgärder formulerades för att minimera risken att negativa erfarenheter upp-repade sig, medan positiva erfarenheter lyftes fram. För att samla lärdomar utvärderades arbetet både på veckovisa möten med hela projektgruppen och handledaren samt på åter-blicksmöten (se avsnitt 4.2.1.5). På dessa möten fick projektmedlemmarna möjlighet att lyfta sådant de ansett fungerat bra och sådant som inte fungerat så bra. Dessa synpunkter låg sedan till grund för ändringar av arbetssättet under efterföljande veckor. Diskussioner från dessa möten dokumenterades i mötesprotokoll som användes under skrivandet av denna rapport. I slutet av projektet hölls även ett möte med hela projektgruppen som helt ägnades åt att diskutera och sammanställa erfarenheter från projektet som sedan dokumenterades till denna rapport.
4.1.4
Vilka delar av förarbetet skapade värde inför implementationsfasen?
Under projektets gång fördes kontinuerligt diskussioner om val av teknologier, planering och arbetsfördelning. Dessa diskussioner står som grund för analysen av förarbetets påverkan på projektet. Med värde menas i detta fall positiv påverkan på arbetsgången med avseende på exempelvis tidsåtgång eller minskad risk för problem.
4.1.5
Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?
För att få en tydlig och konkret bild av systemets uppbyggnad togs en systemanatomi fram. Denna hjälpte gruppen att se vad som praktiskt behövde implementeras och om den initiala bilden av systemet var sund.
4.2
Utvecklingsplan
Projektet har arbetat efter arbetssättet Scrum och använt Git för versionshantering. Eftersom detta avsnitt innehåller många utvecklingsspecifika uttryck på engelska följer i tabell 4.1 de-finitioner av några begrepp.
Tabell 4.1: Utvecklingstermer.
Uttryck Beskrivning
Branch Gren. Ett Git-objekt som definierar en ny förgrening i utveck-lingshistoriken.
Main branch Gren där levererbara versioner av mjukvaran läggs till.
4.2. Utvecklingsplan
forts. från föregående sida
Uttryck Beskrivning
Release branch Gren där potentiellt levererbara versioner av mjukvaran läggs till.
Development branch Gren där kompletta features läggs till.
Feature branch Gren fokuserad på en minimal utvecklingsidé. Commit Ändring av kod som läggs på en branch.
Issue Identifierat problem eller förändringsuppmaning som samlas och hanteras i Kanban-brädor på GitLab.
Merge Sammanslagning av en branch till en annan. Merge request Förfrågan om att få göra en merge.
Fast forward Term som beskriver att ändringarna som görs vid en merge kan göras utan konflikter som måste lösas manuellt.
Repository Förvaringsplatsen för Git. Branches, commits, issues och merge requests samlas alla i ett repository. I detta projekt ligger dessa på GitLab (se avsnitt 3.1.3).
4.2.1
Utvecklingsmetod
Under projektets utvecklingsarbete har en variant av Scrum använts. Scrum är en agil ut-vecklingsmetod som definierar hur arbete utförs, med förhoppning om att effektivisera det. Iterationslängden var en vecka lång. I huvudsak följde detta projekt den metod som utformas i The Scrum Guide. [49] Nedan listas dess olika händelser och hur de modifierades till detta projekt.
4.2.1.1 Utvecklingsmöte
Denna händelse kallas i The Scrum Guide för Sprint Planning. Här sattes ett utvecklingsmål för veckan och en plan gjordes därefter. Detta mål såg i första hand till så att nästkommande milstolpe möttes, men kunde involvera andra utvecklingsmål. Målet i sig uttrycktes som ett specifikt utvecklingsstadium hos produkten. Målet formulerades alltså inte som att ”Städa upp koden”, utan istället ”Produkten ska kunna levereras med en uppstädad kodbas”.
Här valdes aktiviteter utifrån de issues som låg i respektive utvecklings-repository. Dessa betraktades som projektets Product Backlog. Då issues valts så att de uppfyllde utvecklingsmå-let lades dessa i en GitLab-milstolpe. En milstolpe skapades för varje vecka och motsvarade alltså en Sprint Backlog. Notera att dessa milstolpar representerade sprint-målet och inte nöd-vändigtvis projektets utvecklingsmilstolpar.
Det som bestämts under detta möte ändrades inte under veckans gång, om inte utveck-lingsledare sade så. Detta gjordes endast vid extraordinära händelser, som att projektets mål plötsligt ändras av en extern part.
4.2.1.2 Dagliga scrums
Dagliga scrums genomfördes varannan dag, eftersom projektmedlemmarna hade andra kur-ser parallellt med detta projekt. På dessa möten planerades de nästkommande 48 timmarnas arbete i detalj. Det var viktigt att inte planera längre fram än dessa 48 timmar, eftersom den diskussionen ändå skulle komma vid nästa möte. Dessa möten fick ej ta mer än 10 minuter. Under detta möte besvarade varje utvecklingsmedlem frågorna:
4.2. Utvecklingsplan
2. Vad gör jag idag och imorgon som innebär att produkten tar sig närmare målet? 3. Vilka problem har jag just nu som hindrar mig från att produkten utvecklas?
När frågorna besvarades gällde det att hålla det kort. Målet var att informera övriga par-ter om vilken utveckling produkten hade gjort. Hade produkten inte gjort någon utveckling skulle projektmedlemmen exempelvis inte spendera tid på att förklara hur jobbigt ett pro-blem hen fastnat på var. Att inte ha gjort någon utveckling var alltså ett godtagbart svar. Problem togs upp under fråga 3, men beskrivningen hölls kort och saklig. Efter att dessa tre frågor besvarats individuellt gavs en kort stund åt att reflektera över om utvecklingen var i fas med planeringen och om några andra möten behövdes. Efter detta avslutades den dagliga scrumen.
Då mötet avslutats fick detaljer gärna diskuteras, men det ansågs viktigt att detta inte gjor-des på den dagliga scrumen. Det gjorde att utvecklare som inte behövde delta i diskussionen kunde göra andra saker.
4.2.1.3 Utveckling
Utvecklingsarbetet skedde på distans. När en projektmedlem satte sig för att jobba med ut-veckling fanns hen alltid tillgänglig på Discord (se 3.1.1). Där kunde då projektmedlemmen dela skärm med andra utvecklare och föra diskussioner. I övrigt utfördes arbetet på samma sätt som om det bedrivits på universitetet.
4.2.1.4 Restarbete
Om arbete återstod i slutet av arbetsveckan var målet att det i största möjliga mån ändå skulle genomföras under nästkommande vecka. Såg det ut att bli stora mängder restarbete kvar informerades utvecklingsledaren så tidigt som möjligt.
4.2.1.5 Återblick
Återblicken var en kombination av Scrum retrospective och Scrum review från The Scrum Guide. I detta projekt genomfördes den endast av projektets tre utvecklingsledare. Under återblicken gjordes en metaanalys av veckans arbete. Frågor som diskuterades var hur arbetet fungerat för utvecklarna, hur processen fungerat, vad som kunde förbättras och vilka ändringar som borde göras. För att alla problem och åsikter skulle komma fram var det viktigt att övri-ga projektmedlemmar hade meddelat utvecklingsledarna innan veckans slut om eventuella problem som hade uppstått under veckan.
4.2.2
Veckoplanering
Schemaläggningen för aktiviteterna ovan anges i tabell 4.2.
Tabell 4.2: Utvecklingsschema
Mån Tis Ons Tors Fre Lör Sön
Utvecklingsmöte X
Daglig Scrum X X X
Utveckling X X X X X
Restarbete X
4.2. Utvecklingsplan
4.2.3
Versionshantering
Git användes för projektets versionshantering. Detta skedde på uppmaning av kursledning-en. En fullständig version av verktyget GitLab fanns tillgängligt för projektets deltagare via Linköpings universitet (se avsnitt 3.1.3). Det finns många sätt att använda Git men grundat i en diskussion på Atlassians webbplats [50] användes en anpassning av GitFlow. GitFlow definierades av Vincent Driessen år 2010 [51] och är en robust metod för att hantera projekt i större skala. Eftersom detta projekt var i något mindre skala implementerades arbetssättet på ett något mer ledigt sätt. Målet var dock att hålla den övergripande strukturen som definierat. Arbetsflödet i GitFlow illustreras i figur 4.1.
I detta arbete gavs några av projektrollerna speciella ansvar för versionshanteringen. När en ny release-kandidat kom till development-branchen fick testledaren och kvalitetssamord-naren (se avsnitt 2.5.1) ansvar att granska denna så att den höll eftersökt kvalitet. Samma sak gällde för varje delansvarig (till exempel gränssnittsansvarig) då feature-brancher föreslogs för merge till utvecklings-branchen.
4.2.3.1 Commit-meddelanden
Meddelanden i Git höll en gemensam struktur. Alla meddelanden och text rörande kod och utvecklingsarbete skrevs på engelska. Det fanns inga krav på att språket skulle vara formellt, men däremot skulle språket vara precist och därför lades det vikt på korrekt terminologi. Tempus hölls konsekvent och commit-meddelanden skrevs i presens, till exempel ”Add new feature.” istället för ”Added new feature.”. Varje commit-meddelande listade tydligt de änd-ringar som gjorts och vid större ändänd-ringar beskrevs även de ingående komponenternas inter-aktion. Varje commit var sammanhängande och rörde en minimalt nödvändig mängd änd-ringar. Stora ändringar delades i största möjliga mån upp i flera commits. Meddelanden som ”skräp git”, ”test”, ”fungerar nu” eller ”!%#&” var strängeligen förbjudna.
4.2.3.2 Merge requests
När en feature branch var redo att merge:as till utvecklings-branchen gjordes detta genom en merge-request. Denna granskades och godkändes av minst en (för back-end) eller två (för front-end) granskare utöver skribenten innan en merge kunde ske. Det lägre antalet granskare för back-end berodde på att denna utvecklingsgrupp var mindre än utvecklingsgruppen för front-end. En merge tilläts endast om den kunde göras fast forward, vilket betydde att ansvarig utvecklare själv var tvungen att hantera konflikter. Dessa skulle lösas med en lokal merge.
4.2.3.3 Releases och versionsnummer
Under utvecklingsarbetet jobbade en utvecklare alltid mot en release. Varje release hade ett versionsnummer på formen X.X.X där version 1.0.0 var projektets första kompletta version. Varje sprint-mål motsvarade en release, och dessa ökade versionsnummret till X.1.0, X.2.0, X.3.0 och så vidare.
Nuvarande release var den release som just då jobbades mot. Under arbetet mot nuvaran-de release prioriteranuvaran-des nuvaran-de tillägg som ingick i nuvaran-det mål som satts för nuvaran-den aktuella sprinten. Tillägg som ingick i kommande releaser fick arbetas med, men dessa kunde inte mergeas till development-branchen förrän den release tillägget siktade mot var nuvarande release.
Nästa release blev nuvarande release då en release branch skapades. Detta betydde att alla tillägg till nuvarande release var integrerade och att man nu kunde gå vidare till nästa release. Således var alltså nuvarande release till exempel 0.3.0 fram till att en release branch skapas. Nuvarande release blev då direkt 0.4.0.
4.2. Utvecklingsplan
Feature
Development
Release
Master
0.2.0 0.1.0 Merge request Branch Pull Commit
4.2. Utvecklingsplan
4.2.3.4 Branchstruktur
Gitflow definierar fem olika typer av branches. [51] Denna struktur användes även i detta projekt, med mindre ändringar. Projektet hade två huvudsakliga branches, Development och Master, samt tre typer av temporära branches, Feature, Release och Hotfix.
• Development - Denna branch hade till syfte att integrera tillägg. Notera att tillägg från nästa release inte fick läggas till på Development innan en release branch skapats för nuvarande release.
• Master - Denna branch samlade kompletta och testade versioner av mjukvaran. I Git-Flow innehåller master vanligtvis endast kompletta helversioner (1.X.X, 2.X.X, osv), men eftersom detta projekt var så begränsat i omfattning lades även första nivån av subversioner på master.
• Feature - Feature-branches, som ibland kallas Topic branches i annan litteratur, förgrenas från och mergas till Development. Syftet med en feature-branch var att isolera ändring-ar relaterade till en minimal utvecklingsidé. Dessa hölls därför begränsade i omfattning och mergades tillbaka till Development så tidigt som möjligt.
• Release - Dessa branches förgrenades från Development och mergades till Master. Release-branches innehöll releases med komplett tilläggsinnehåll och var endast till för att testning och buggfixar skulle kunna ske separerat från vidare utveckling. En-dast små ändringar fick alltså göras på release-branches. En utvecklingsledare skapade release-branchen och lämnade sedan över till kvalitets- och testansvariga.
• Hotfix - Hotfix-branches förgrenades från Master och kunde sedan mergeas tillbaka till Master eller Development. En hotfix lagade ett kritiskt problem i produkten som upp-täcks efter det berörda tillägget kommit till Master. En Hotfix ökade versionsnummret med x.x.1.
5
Resultat
I denna del av rapporten beskrivs och sammanställs resultaten av projektet som projektgrup-pen har åstadkommit.
5.1
Systembeskrivning
I detta avsnitt beskrivs systemets design och implementation.
5.1.1
Översiktlig beskrivning av systemet
Det framtagna systemet består av ett grafiskt användargränssnitt, en databas och en tileser-ver. Systemet kommunicerar i sin tur med kundens system RDS (se figur 5.1). Front-end består av en webbapplikation skriven i JavaScript (se avsnitt 3.2.2) med Reacts (se avsnitt 3.4.3) syntax JSX. Front-ends syfte är att visualisera och interagera med användaren. Projek-tets back-end är skriven i Python (se avsnitt 3.2.1) och består av en databas, en tileserver och kommunikationshantering mellan RDS och front-end. Databasens syfte är att lagra informa-tion som är vital för systemet. Tileserverns huvudsakliga uppgift är att tillhandahålla använ-dargränssnittet med en interaktiv karta som användaren kan navigera i och att möjliggöra bildbehandling i back-end.
5.1.2
Front-end
Front-end består av ett användargränssnitt där information presenteras för användaren. Ge-nom gränssnittet interagerar användaren med systemet. Således består front-end i huvudsak av system för att hämta och visa information.
5.1.2.1 Grafiskt användargränssnitt
Hela det grafiska användargränssnittet skapades med Material Design (se avsnitt 3.4.4) i åtan-ke och använder flera av dess tillhandahållna principer och verktyg. Användargränssnittet implementerades i React-komponenter (se avsnitt 3.4.3). Huvudmodulen i front-end är kar-tan, som tillhandahålls av React Leaflet (se avsnitt 3.4.5). Denna hämtar kartinformation i form av bilder från back-end. Kartkomponenten hanterar även uppvisningen av tagna flyg-foton med Leaflets image overlay-komponent.
5.1. Systembeskrivning
GUI Client
Webserver Tileserver
Interactive Map Module
PUB SUB REQ
SUB PUB REP
RISE DRONE SYSTEM
Databas P O I-li n k P IC -l in k IN F O -l in k Figur 5.1: Systemöversikt.
Den andra huvudsakliga modulen är sidomenyerna. Här implementerades en egen React-komponent med hjälp Material-UI som byggklossar. Sidomenyerna är minimerade vid upp-start och kunde öppnas genom att klicka på deras respektive flik. Flikarna är placerade un-der varandra längs sidan av skärmen och flyttas med ut då en meny öppnas. I dessa me-nyer befinner sig merparten av interaktionsmöjligheterna för användaren, som ändring av inställningar och läsning av meddelanden. Samtliga av dessa interaktioner sker genom olika typer av knappar som utlöser meddelanden antingen till back-end eller till storage (se avsnitt 5.1.2.2). I den vänstra av dessa flikar kan användaren välja mellan manuellt och autonomt lä-ge (se avsnitt 2.2). Användaren kan även välja mellan att visa flygfoton tagna med IR-kamera eller vanlig färgkamera (RGB).
Systemet har två separata lägen: ett huvudläge (se figur 5.3), samt ett uppstartsläge (se figur 5.2). I uppstartsläget tas menyerna bort och en röd ram placeras runt skärmens kanter. Användaren placerar här ut markörer för att markera det kartområde inom vilket systemet ska användas. Detta område används sedan för att begränsa hur långt användaren kan pano-rera i huvudläget, samt begränsar vilket område drönarna får röra sig inom. När användaren placerat ut minst tre noder kan hen gå vidare till huvudläget. För att hindra att användaren råkar byta läge visas först en dialogruta (se figur 5.4). Då området bekräftats av använda-ren skickas det till back-end. För att tydligt visa användaanvända-ren att tillräckligt många noder har placerats ut blir knappen nere till höger grön när det markerade området är giltigt (se figur 5.2). När användaren omdirigerats till huvudläget startas bildtagningen. Skulle användaren vilja undersöka ett nytt område kan knappen ”redefine area” användas för att återvända till startläget.
