Vårterminen 2020 | LIU-IDA/LITH-EX-G--20/018--SE
Nodgrafer i gruvsystem
Nodegraphs for mine tunnel complexes
Christina Dahlén
Viktor Hellqvist
Isak Häggström
Jonatan Jonsson
Techit Lerssongkram
Jens Lindgren
Ebba Lindström
Alexander Olsson
Handledare : Daniel Ståhl Examinator : Kristian SandahlUpphovsr¨
att
Detta dokument h˚alls tillg¨angligt p˚a Internet - eller dess framtida ers¨attare - under 25 ˚ar fr˚an publiceringsdatum under f¨oruts¨attning att inga extraordin¨ara omst¨andigheter uppst˚ar.
Tillg˚ang till dokumentet inneb¨ar tillst˚and f¨or var och en att l¨asa, ladda ner, skriva ut enstaka kopior f¨or enskilt bruk och att anv¨anda det of¨or¨andrat f¨or ickekommersiell forskning och f¨or un-dervisning. ¨Overf¨oring av upphovsr¨atten vid en senare tidpunkt kan inte upph¨ava detta tillst˚and. All annan anv¨andning av dokumentet kr¨aver upphovsmannens medgivande. F¨or att garantera ¨
aktheten, s¨akerheten och tillg¨angligheten finns l¨osningar av teknisk och administrativ art. Upphovsmannens ideella r¨att innefattar r¨att att bli n¨amnd som upphovsman i den omfattning som god sed kr¨aver vid anv¨andning av dokumentet p˚a ovan beskrivna s¨att samt skydd mot att dokumentet ¨andras eller presenteras i s˚adan form eller i s˚adant sammanhang som ¨ar kr¨ankande f¨or upphovsmannens litter¨ara eller konstn¨arliga anseende eller egenart.
F¨or ytterligare information om Link¨oping University Electronic Press se f¨orlagets 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 download, 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¨oping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. Christina Dahl´en Viktor Hellqvist Isak H¨aggstr¨om c Jonatan Jonsson Techit Lerssongkram Jens Lindgren Ebba Lindstr¨om Alexander Olsson
Sammanfattning
Denna kandidatrapport avhandlar ett arbete utf¨ort av ˚atta studenter som studerar p˚a civilin-genj¨orsprogrammen i mjukvaruteknik eller datateknik p˚a Link¨opings universitet och har deltagit i kursen Kandidatprojekt i programvaruutveckling TDDD96. Rapporten ¨ar en sammanfattning av det arbete studenterna utf¨ort under v˚arterminen 2020, d˚a kursen fortl¨opt. Studenterna har under kursens g˚ang arbetat med att leverera en slutprodukt som ska generera en nodgraf be-skrivande gruvschakten i LKABs gruvsystem ˚at kunden Combitech. Slutsatserna f¨orklarar hur projektgruppen lyckats skapa v¨arde f¨or kunden genom att producera ett generellt verktyg som kan anv¨andas med varierad indata, lyckats identifiera processrelaterade, teamarbetsrelaterade och tekniska erfarenheter samt att projektgruppen inte fann n˚agot st¨od i att kontinuerligt revi-dera en systemanatomi. Rapporten behandlar ¨aven individuella studier skrivna av gruppmed-lemmarna som analyserar ett valfritt ¨amne kopplat till arbetet.
Dokumenthistorik
Version Datum Utf¨orda f¨or¨andringar Granskad
0.1 2020-03-11 F¨orsta utkast Alla gruppmedlemmar
0.2 2020-04-10 Opponerings- och handledarkommentarer Alla gruppmedlemmar
0.3 2020-04-15 Inspektion Lindstr¨om, E. Dahl´en, C
0.4 2020-05-04 Inspektion Lindstr¨om, E. Jonsson, J
Projektidentitet
Kandidatgrupp 5, 2020 Link¨opings UniversitetInstitutionen f¨or Datavetenskap (IDA)
Gruppmedlemmar
Namn Ansvarsomr˚ade Telefon E-post
Christina Dahl´en Teamledare 070-1468575 chrda875@student.liu.se Viktor Hellqvist Arkitekt 073-3655006 vikhe931@student.liu.se Isak H¨aggstr¨om Kundansvarig 076-2670452 isaha512@student.liu.se Jonatan Jonsson Kvalitetssamordnare 072-3159030 jonjo049@student.liu.se Techit Lerssongkram Testansvarig 070-7406183 tecle667@student.liu.se Jens Lindgren Konfigurationsansvarig 076-9080747 jenli669@student.liu.se Ebba Lindstr¨om Dokumentansvarig 073-3149219 ebbli818@student.liu.se Alexander Olsson Utvecklingsledare 073-9862774 aleol711@student.liu.se
Kund Combitech Kundkontakt
Niklas Lanz´en, niklas.lanzen@combitech.se Handledare
F¨
orfattarens tack
Vi vill tacka Combitech f¨or uppdraget som vi blev tilldelade. Combitech har varit en h¨angiven kund som givit oss en rolig m¨ojlighet att f˚a l¨ara oss att jobba med en riktig uppgift mot en riktig kund. Vi skulle vilja framh¨ava ett extra stort tack till Niklas Lanz´en f¨or ett utm¨arkt samarbete. Vi har alltid upplevt bra kundkontakt med snabba och informativa svar.
Vi vill ¨aven g¨arna tacka Daniel St˚ahl f¨or den givna handledningen sedan projektstart. Daniel har alltid varit tillg¨anglig f¨or att svara p˚a fr˚agor fr˚an gruppen eller individuella gruppmedlemmar. Han har ¨aven varit n¨arvarande under hela projektets g˚ang under veckovisa m¨oten f¨or att st¨amma av att vi ligger p˚a r¨att bana. ¨Aven ett tack till Kristian Sandahl, examinator f¨or kursen, f¨or tydlig information och snabbt agerande d˚a Link¨opings universitet b¨orjade med distansstudier. Sista tacket g˚ar til Anton Or¨o, Bj¨orn Mode´e, Rasmus Karlb¨ack och Christopher Olli, kvalitets-coacher f¨or projektet, som hj¨alpt till vid utv¨ardering av v˚ar implementation av Scrum.
Inneh˚
all
1 Inledning 15 1.1 Motivering . . . 15 1.2 Syfte . . . 15 1.3 Fr˚agest¨allning . . . 16 1.4 Avgr¨ansningar . . . 16 1.5 Definitioner . . . 16 2 Bakgrund 18 2.1 Best¨allare . . . 18 2.2 Erfarenheter . . . 18 3 Teori 19 3.1 Verktyg . . . 193.1.1 Open Asset Import Library . . . 19
3.1.2 Unity . . . 19
3.1.3 Microsoft Visual Studio 2019 . . . 19
3.1.4 Git . . . 20
3.1.5 Gitlab . . . 20
3.1.6 LATEX . . . . 20
3.1.7 Overleaf . . . 20
3.1.8 Zoom Video Communications . . . 20
3.2 Ramverk och arbetsmetod . . . 20
3.2.1 Parprogrammering . . . 20 3.2.2 Scrum . . . 21 3.3 Filformat . . . 21 3.3.1 .fbx . . . 21 3.3.2 XML . . . 21 3.4 Matematisk teori . . . 21 3.4.1 Linj¨ar algebra . . . 21 3.4.2 Voxelisering . . . 21 4 Metod 23 4.1 Roller . . . 23 4.1.1 Teamledare . . . 23 4.1.2 Analysansvarig . . . 23 4.1.3 Arkitekt . . . 23 4.1.4 Utvecklingsledare . . . 23 4.1.5 Testledare . . . 24
4.1.8 Konfigurationsansvarig . . . 24
4.2 Utbildning . . . 24
4.3 Tidslinje . . . 25
4.4 Utvecklingsmetodik . . . 25
4.4.1 Metoder . . . 25
4.4.2 Hur verktygen anv¨ants . . . 26
4.5 Metod f¨or att f˚anga erfarenheter . . . 27
5 Resultat 29 5.1 Systemanatomi . . . 29 5.1.1 Arkitektur¨oversikt . . . 30 5.2 Beskrivning av verktyget . . . 31 5.3 Verktygsspecifika l¨osningar . . . 34 5.3.1 L¨osning 1 . . . 34 5.3.2 L¨osning 2 . . . 35 5.4 V¨arde f¨or kunden . . . 37 5.5 Gemensamma erfarenheter . . . 37 5.5.1 Processrelaterade erfarenheter . . . 38 5.5.2 Teamarbetesrelaterade erfarenheter . . . 38 5.5.3 Tekniska erfarenheter . . . 38 5.6 Processomr˚ade . . . 39 5.7 Dokument . . . 39
5.8 Oversikt av individuella bidrag . . . .¨ 40
5.8.1 Scrum och andra iterativa arbetss¨atts applicerbarhet i kandidatprojekt av Jonatan Jonsson . . . 40
5.8.2 Parprogrammeringens mest l¨ampade arbetsomr˚aden av Alexander Olsson 40 5.8.3 En unders¨okning av rollerna Teamledare och Scrum-master av Christina Dahl´en . . . 40
5.8.4 H˚allbar utveckling i mjukvaruprojekt av Isak H¨aggstr¨om . . . 40
5.8.5 Distansl¨agets p˚averkan p˚a agila metoder i mjukvaruprojekt av Ebba Lindstr¨om 41 5.8.6 Utveckling av simuleringsverktyg f¨or utbildningssyfte i moderna spelmo-torer av Jens Lindgren . . . 41
5.8.7 Virtuell verklighet (VR) f¨or s¨akerhet i gruvindustrin av Techit Lerssongkram 41 5.8.8 Hur kodgranskning anv¨ands och vilka f¨ordelar som kan f˚as av Viktor Hellqvist 41 6 Diskussion 42 6.1 Resultat . . . 42
6.1.1 Systemanatomin . . . 42
6.1.2 V¨arde f¨or kund . . . 42
6.2.3 Roller . . . 43 6.2.4 Kundkontakt . . . 44 6.2.5 Kodgranskning . . . 44 6.3 Begr¨ansningar . . . 44 6.4 K¨allkritik . . . 45 6.5 Framtida utveckling . . . 45
6.6 Arbetet i vidare sammanhang . . . 46
6.6.1 Etiska aspekter . . . 46
6.6.2 Sociala aspekter . . . 46
6.6.3 Milj¨oaspekter . . . 46
7 Slutsats 47 7.1 Hur skapar projektgruppen v¨arde f¨or kunden med ett verktyg som kan generera en nodgraf? . . . 47
7.2 Vilka erfarenheter ifr˚an detta projekt kan vara intressant f¨or inblandade parter och den framtida utvecklingen av SUM-projektet? . . . 47
7.3 Vilket st¨od, i utvecklingssyfte, finner projektgruppen genom att kontinuerligt re-videra den systemanatomi som skapats? . . . 47
Bilaga A - Scrum och andra iterativa arbetss¨atts applicerbarhet i kandidatpro-jekt - Jonatan Jonsson 48 A.1 Inledning . . . 48
A.1.1 Syfte . . . 48
A.1.2 Fr˚agest¨allning . . . 48
A.1.3 Bakgrund . . . 48
A.1.4 Avgr¨ansning . . . 48
A.2 Teori . . . 49
A.2.1 Scrum . . . 49
A.2.2 Scrumvariabler . . . 50
A.3 Metod . . . 51
A.3.1 Interna utv¨arderingar . . . 51
A.3.2 Enk¨atunders¨okning . . . 51
A.3.3 Informationss¨okning . . . 51
A.4 Resultat . . . 53
A.4.1 Sprint & Scrumm¨otes utv¨arderingar . . . 53
A.4.2 Enk¨at . . . 54
A.5 Diskussion . . . 55
A.5.1 Metod . . . 55
A.5.2 Resultat . . . 55
B.1 Inledning . . . 58 B.1.1 Syfte . . . 58 B.1.2 Fr˚agest¨allning . . . 58 B.2 Bakgrund . . . 58 B.3 Teori . . . 58 B.3.1 Parprogrammering . . . 58 B.4 Metod . . . 59 B.4.1 Litteraturstudie . . . 59 B.4.2 Intervjuer . . . 60 B.5 Resultat . . . 60 B.5.1 Artiklar . . . 60 B.5.2 Litteraturstudien . . . 61 B.5.3 Intervjuer . . . 63 B.6 Diskussion . . . 64 B.6.1 Metod . . . 65 B.6.2 Resultat . . . 65 B.7 Slutsats . . . 65
B.7.1 F¨or vilken typ av arbetsuppgifter ¨ar parprogrammering mest l¨ampligt? . . 66
Bilaga C - En unders¨okning av rollerna Teamledare och Scrum-master - Christi-na Dahl´en 67 C.1 Inledning . . . 67 C.1.1 Syfte . . . 67 C.1.2 Fr˚agest¨allning . . . 67 C.2 Bakgrund . . . 67 C.3 Teori . . . 67 C.3.1 En ¨oversikt av Scrum-verksamheten . . . 68 C.3.2 Scrum-sprint . . . 68 C.3.3 Scrum-master . . . 68 C.3.4 Teamledare . . . 68 C.4 Metod . . . 69 C.4.1 Intervju av studenter . . . 69 C.4.2 Litteraturstudie . . . 70 C.5 Resultat . . . 70 C.5.1 Intervju av studenter . . . 70 C.5.2 Litteraturstudien . . . 72 C.6 Diskussion . . . 73 C.6.1 Diskussion av metod . . . 73 C.6.2 Diskussion av resultat . . . 74 C.7 Slutsats . . . 75
C.7.2 Vilka ansvarsomr˚aden tar en Scrum-master i j¨amf¨orelse med en
Team-ledare i ett projekt liknande det i kursen TDDD96? . . . 75
Bilaga D - H˚allbar utveckling i mjukvaruprojekt - Isak H¨aggstr¨om 77 D.1 Inledning . . . 77 D.1.1 Syfte . . . 77 D.1.2 Fr˚agest¨allning . . . 77 D.1.3 Avgr¨ansning . . . 77 D.2 Bakgrund . . . 77 D.3 Teori . . . 78 D.3.1 SusAD-Analys . . . 78 D.4 Metod . . . 79 D.4.1 Intervjuerna . . . 79 D.5 Resultat . . . 80 D.5.1 Ekonomisk dimension . . . 80 D.5.2 Milj¨odimension . . . 80 D.5.3 Teknisk dimension . . . 80 D.5.4 Sociala dimension . . . 81 D.5.5 Individuella dimension . . . 81 D.5.6 SusAD-diagram . . . 82 D.6 Diskussion . . . 82 D.6.1 Diskussion av metod . . . 83 D.6.2 Diskussion av resultat . . . 83 D.6.3 SusAD-Analysen . . . 83 D.6.4 Vidareutveckling . . . 83 D.7 Slutsats . . . 84
D.7.1 Hur kan man med hj¨alp av en SusAD-analys ta h¨ansyn till h˚allbar utveck-ling i ett mjukvaruprojekt som projektgruppen har arbetat med? . . . 84
D.7.2 Vilka unika risker och m¨ojligheter finns det med v˚art projekt? . . . 84
Bilaga E - Distansl¨agets p˚averkan p˚a agila metoder i mjukvaruprojekt - Ebba Lindstr¨om 85 E.1 Inledning . . . 85
E.1.1 Bakgrund . . . 85
E.1.2 Fr˚agest¨allning . . . 85
E.1.3 Avgr¨ansningar . . . 85
E.2 Teori . . . 86
E.2.1 Agila metoder . . . 86
E.2.2 Tematisk analys . . . 86
E.3.2 Etiska aspekter . . . 87
E.3.3 Enk¨ater . . . 87
E.3.4 Urval . . . 87
E.3.5 Analys . . . 87
E.4 Resultat . . . 88
E.4.1 Tematisk analys . . . 88
E.4.2 Enk¨atsvar . . . 91
E.5 Diskussion . . . 91
E.5.1 Metod . . . 91
E.5.2 Hur har det pl¨otsliga distansl¨aget p˚averkat hur m˚algruppen arbetar med agila metoder? . . . 92
E.5.3 Vilka f¨or¨andringar p˚a arbetss¨att tror m˚algruppen det kommer inneb¨ara ¨ aven efter covid-19? . . . 92
E.5.4 Framtida studier . . . 93
E.6 Slutsats . . . 93
E.6.1 Hur har det pl¨otsliga distansl¨aget p˚averkat hur m˚algruppen arbetar med agila metoder? . . . 93
E.6.2 Vilka f¨or¨andringar p˚a arbetss¨att tror m˚algruppen det kommer inneb¨ara ¨ aven efter covid-19? . . . 93
Bilaga F - Utveckling av simuleringsverktyg f¨or utbildningssyfte i moderna spel-motorer - Jens Lindgren 94 F.1 Inledning . . . 94 F.1.1 Syfte . . . 94 F.1.2 Avgr¨ansningar . . . 94 F.1.3 Fr˚agest¨allningar . . . 94 F.2 Bakgrund . . . 95 F.3 Teori . . . 95 F.3.1 Didaktik . . . 95 F.3.2 Matematisk modell . . . 95 F.4 Metod . . . 97 F.4.1 Resurser . . . 97 F.4.2 Utveckling . . . 98 F.5 Utv¨ardering . . . 98 F.5.1 Informationss¨okning . . . 98 F.5.2 Intervjupersoner . . . 98 F.5.3 Intervjustruktur . . . 99
F.5.4 Utv¨ardering av intervjuer . . . 99
F.6 Resultat . . . 99
F.6.1 Tidsredovisning . . . 99
F.7.2 Optimering av utvecklingsprocess . . . 103
F.7.3 Utbildningsv¨arde . . . 103
F.8 Slutsats . . . 103
F.8.1 Kan Unity anv¨andas f¨or att skapa fysiksimulationer med v¨arde i utbild-ningssyfte? . . . 103
F.8.2 Hur stor arbetsinsats kr¨avs f¨or att skapa fysiksimulationer med hj¨alp av Unity? . . . 104
F.8.3 Hur kan arbetsprocesser f¨or framst¨allning av fysiksimuleringsverktyg i Uni-ty effektiviseras? . . . 104
Bilaga G - Virtuell verklighet (VR) f¨or s¨akerhet i gruvindustrin - Techit Lerssongkram 105 G.1 Inledning . . . 105 G.1.1 Syfte . . . 105 G.1.2 Fr˚agest¨allning . . . 105 G.2 Bakgrund . . . 105 G.3 Teori . . . 106 G.3.1 Gruvarbete . . . 106 G.3.2 Datorsimulering . . . 106 G.3.3 Virtuell verklighet . . . 107 G.3.4 Typer av VR . . . 107 G.3.5 VR i gruvutbildning . . . 108 G.3.6 Moduler f¨or VR-tr¨aning . . . 110 G.4 Metod . . . 111 G.4.1 Informationss¨okning . . . 112 G.4.2 Analys . . . 112 G.5 Resultat . . . 112
G.5.1 Hur kan VR anv¨andas i gruvutbildning f¨or att f¨orb¨attra s¨akerheten i gruvindustrin . . . 112
G.5.2 Vilka typer utav VR har utforskat eller pr¨ovat f¨or att f¨orb¨attra s¨akerheten i gruvindustrin? . . . 113
G.6 Diskussion . . . 113
G.6.1 Resultat . . . 113
G.6.2 Metod . . . 114
G.7 Slutsats . . . 114
Bilaga H - Hur kodgranskning anv¨ands och vilka f¨ordelar som kan f˚as - Viktor Hellqvist 115 H.1 Inledning . . . 115
H.1.1 Syfte . . . 115
H.3.1 Kodinspektion . . . 116
H.3.2 Modern kodgranskning . . . 116
H.4 Metod . . . 116
H.5 Resultat . . . 117
H.5.1 Metoder f¨or kodgranskning . . . 117
H.5.2 F¨ordelar med kodgranskning . . . 117
H.6 Diskussion . . . 118
H.7 Slutsats . . . 119
H.7.1 Vilka metoder ¨ar vanligast att anv¨anda f¨or kodgranskning i mjukvarupro-jekt? . . . 119
H.7.2 Vilka f¨ordelar kan f˚as av att anv¨anda sig av kodgranskning? . . . 119
H.7.3 Vilka av f¨ordelarna ¨ar mest relevanta och ¨ar det v¨art att i ett projekt som v˚art anv¨anda sig av kodgranskning? . . . 119
Bilaga I Utv¨arderingsdokument Mall 120 Bilaga J Utv¨arderingsdokument 123 Bilaga K Scrum & Sprint Utv¨arderingar 135 Bilaga L Enk¨at - Scrum & Sprints i kandidatprojekt 137 L.1 Inledande fr˚agor . . . 137
L.2 Sprints . . . 137
L.3 SCRUM . . . 139
L.4 Ovriga arbets¨¨ att . . . 139
L.5 Avslutande fr˚agor . . . 140 Bilaga M Enk¨atsvar - Distansl¨agets p˚averkan p˚a agila metoder i
mjukvarupro-jekt 141
Bilaga N Intervjufr˚agor - Distansl¨agets p˚averkan p˚a agila metoder i
1
Inledning
H˚allbarhet ¨ar en central fr˚aga vid utvecklingen av morgondagens samh¨alle. I takt med att samh¨allets milj¨omedvetenhet ¨okar blir det tydligt att st¨orre krav m˚aste st¨allas f¨or att begr¨ansa v˚ar milj¨op˚averkan. Gruvindustrin hamnar ofta i fokus p˚a grund av de m˚anga kortsiktiga och l˚angsiktiga effekterna av malmbrytning. Ett exempel ¨ar milj¨op˚averkan och hur malmbrytning, genom att syssels¨atta stora andelar mark, f¨or¨andrar landskapsbilden [93]. Som ett led i att effek-tivisera industrin och reducera de negativa milj¨okonsekvenserna vid malmbrytning startades pro-jektet Sustainable Underground Mining[69] (SUM). I samband med detta ¨onskar projektpartnern Combitech att utveckla mjukvara som kan optimera effektiviteten i gruvschaktsnavigering. Detta m¨ojligg¨or bevaring av resurser f¨or flertalet parter i logistikkedjan som uppst˚ar vid malmbrytning och dessa parter kan d¨armer agera mer milj¨onyttigt. Denna rapport beskriver utvecklingspro-cesserna och implementationen av ett verktyg som kan beskriva f¨orflyttningsm¨ojligheterna f¨or gruvfordon i gruvschakt genom att bearbeta rena 3D-modeller av dessa. Verktyget implemen-teras som ett program som kan k¨oras via kommandotolk eller integreras som en subrutin i ett st¨orre mjukvaruprojekt.
1.1
Motivering
M˚alet f¨or SUM-projektet ¨ar att hitta nya digitaliserade metoder som siktar mot att optimera framtidens gruvverksamhet, vilket i sin tur ska ¨oka den svenska gruvindustrins konkurrenskraft samt skapa tillv¨axt och arbete. Detta kan utforskas genom att skapa en virtuell testgruva som kan anv¨andas f¨or att unders¨oka vilka tillv¨agag˚angss¨att som ¨ar mest effektiva att arbeta p˚a f¨or att n˚a ¨onskat resultat. F¨or att kunna skapa denna virtuella testgruva beh¨ovs information om gruvschakten som beskriver hur g˚angarna breder ut sig och hur fordon har m¨ojlighet att navigera genom dessa. Hittills har gruvorna kunnat visualiseras med hj¨alp av 3D-modeller, d¨aremot finns behov av ytterligare data som modellerna inte innefattar. Vitala egenskaper s˚asom positioner, l¨angd och lutning p˚a g˚angarna ¨ar i nul¨aget sv˚ara att ber¨akna och det saknas ett automatiserat s¨att att samla informationen p˚a. En projektgrupp har d¨arf¨or tillsats f¨or att skapa ett program som kan utf¨ora dessa ber¨akningar och producera en datafil som inneh˚aller den relevanta datan.
1.2
Syfte
Nedan f¨oljer de syften projektgruppen arbetar med
• Syftet med arbetet som projektgruppen utf¨or ¨ar att f¨orenkla verksamheten f¨or utvecklings-gruppen i SUM-projektet. Detta genom att skapa en produkt som omvandlar en 3D-modell av ett gruvsystem till en nodgraf som h˚aller information om systemets egenskaper. • Produktens syfte ¨ar att g¨ora ber¨akningar baserat p˚a en 3D-modell f¨or att ta fram
rele-vant information om gruvg˚angar och schakt f¨or att kunna ta beslut ber¨orande fordon och transport i gruvorna.
• Rapportens syfte ¨ar att beskriva utvecklingen och framtagandet av denna produkt samt vilka verktyg och arbetsmodeller som anv¨ands f¨or att f˚a det resultat som kommer presen-teras.
1.3
Fr˚
agest¨
allning
Rapporten besvarar fr˚agest¨allningarna nedan genom att utg˚a ifr˚an gruppens erfarenheter och upplevelser:
1. Hur skapar projektgruppen v¨arde f¨or kunden med ett verktyg som kan generera en nodgraf? 2. Vilka erfarenheter ifr˚an detta projekt kan vara intressant f¨or inblandade parter och den
framtida utvecklingen av SUM-projektet?
3. Vilket st¨od, i utvecklingssyfte, finner projektgruppen genom att kontinuerligt revidera den systemanatomi som skapats?
1.4
Avgr¨
ansningar
Projektet omfattar 400 timmar per gruppmedlem vilket resulterar i totalt 3200 arbetstimmar. Denna tid innefattar planering, utbildning, utveckling, utv¨ardering och dokumentering av pro-jektet.
Utvecklingen begr¨ansas i avseende att produkten endast ska uppfylla bas-kraven enligt Krav-specifikationen [47], och det finns inga f¨orv¨antningar att utveckling ut¨over detta kommer ske. Rapporten begr¨ansas i avseende att endast ber¨ora information relevant f¨or projektets utveck-ling samt information som ¨ar n¨odv¨andig f¨or att besvara de fr˚agest¨allningar som st¨allts. Den individuella rapporten ¨ar begr¨ansad med en rekommendation p˚a en storlek av 5-7 sidor.
1.5
Definitioner
1. .NET - En systemkomponent som ¨ar del av operativsystemet Microsoft Windows. Hanterar exekvering av program.
2. 3D-mesh - En sammanh¨angande tredimensionell yta uppbyggd av polygoner, oftast forma-de som triangelytor, som i sin tur ¨ar uppbyggda av ett flertal vertices som ¨ar ihopkopplade utav faces.
3. Assimp (Open Asset Import Library) - Ett ¨oppet k¨allkodsprojekt f¨or att l¨asa in 3D-filer. 4. Backlog - En lista ¨over alla issues som ska l¨osas f¨or att f¨ardigutveckla verktyget.
5. Bindings - Ett API som ger m¨ojligheten att anv¨anda ett bibliotek som ¨ar skrivet i ett annat spr˚ak.
6. B˚age - En f¨orbindelse mellan tv˚a noder.
7. C# - Ett objektorienterat programmeringsspr˚ak. 8. Covid-19 - Ett v¨arldsomfattande virus.
9. Face - En yta som sp¨anns upp av tre vertices i indatafilen. 10. Feature - En viss funktion i verktyget.
11. Git - Ett program som anv¨ands f¨or versionshantering.
14. Kunden - Konsultbolaget Combitech.
15. Merge Request - En beg¨aran att sl˚a ihop en utvecklingsgren med huvudgrenen. 16. Nod - En punkt som ¨ar signifikant f¨or att representera gruvan i utdatafilen. 17. Nodgraf - Ett system av noder och b˚agar som beskriver sambandet mellan dem. 18. Scene - En total struktur som best˚ar av en eller flera meshes.
19. Scrum - En arbetsmodell som bygger p˚a iterativt arbete genom hela projektet.
20. Sprint - En utvecklingsiteration under en best¨amd tid, d¨ar gruppmedlemmarna har issues som ska l¨osas tills sprinten ¨ar slut.
21. Systemanatomi - Ett beskrivande diagram ¨over beroendena och funktionerna i ett system. 22. Unity - Ett program f¨or hantering av 3D-modeller.
23. Vertex - Ett, i geometrisk mening, h¨orn som beskriver en signifikant position f¨or gruvans utformning i indatafilen.
24. Verktyget - Den nodgenerande mjukvaran som utvecklats i projektet.
25. Voxel - En ”pixel” med koordinater i tre dimensioner, ofta representerad som en kub centrerad p˚a denna koordinat.
2
Bakgrund
Detta avsnitt beskriver kunden, bakgrunden till projektet samt tar upp projektgruppens tidigare erfarenheter inom de aktuella omr˚adena.
Sedan slutet av 1800-talet har brytning av j¨arnmalm i Kiruna gjorts utav Luossavaara-Kiirunavaara Aktiebolag (LKAB)[65]. Nu har LKAB tillsammans med ABB, Epiroc, Combitech och Volvokon-cernen startat ett projekt, Sustainable Underground Mining (SUM), som ska leda till framtidens gruvindustri. Denna gruva ¨ar koldioxidfri, digitaliserad och autonom. I grova drag ¨ar m˚alet med samarbetet att gemensamt hitta smartare l¨osningar och nya metoder f¨or framtidens gruvdrift[69]. Projektgruppen arbetade mot Combitech som har uppdraget att utveckla en Virtual Mine, en digital tvilling av en gruva vilken till exempel kan vara en 3D-modell. Projektgruppen fick i uppdrag att bygga det verktyg som tar in 3D-modellen och omvandlar denna till en nodgraf med n¨odv¨andig information ang˚aende b˚agar och noder. Nodgrafen ska sedan anv¨andas f¨or ber¨akningar inom andra omr˚aden i verksamheten. Ett av syftena ¨ar att kunna identifiera vilka fordon som kan f¨ardas i specifika gruvschakt. Det andra syftet ¨ar att graferna ska kunna anv¨andas f¨or att planera framtida ut¨okningar av gruvan, genom att ber¨akna hur effektiva olika ut¨okningar av gruvan skulle bli. Genom att kunna konvertera 3D-modellerna till nodgrafer kan simuleringar k¨oras p˚a flera olika 3D-modeller f¨orest¨allandes den ut¨okade gruvan f¨or att se vilken ut¨okning som skulle vara mest effektiv. P˚a s˚a s¨att ¨ar det m¨ojligt att spara b˚ade pengar och p˚a milj¨on.
2.1
Best¨
allare
Projektgruppens best¨allare var Combitech, d¨ar kontaktperson har varit Niklas Lanz´en. Com-bitech AB ¨ar ett obundet konsultbolag och ett dotterbolag till Saab AB. De har verksamhet inom teknik, milj¨o och s¨akerhet. F¨oretaget har mer ¨an 1900 anst¨allda i Norden[25]. F¨or att projektgruppen under projektets g˚angvoxeliseringen skulle ha m¨ojlighet att testa verktyget har Combitech f¨orsett dem med .fbx-filer beskrivande realistiska gruvsystem vilka har anv¨ants som testdata f¨or verktyget.
2.2
Erfarenheter
Gruppmedlemmarna ¨ar studenter vid Link¨opings universitet som studerar till civilingenj¨or i antingen datateknik eller mjukvaruteknik. Under utbildningen har diverse programmeringsspr˚ak l¨arts ut, d¨aribland Java och C++. En kurs som haft betydelse f¨or projektarbetet har varit kursen i Programutvecklingsmetodik (TDDC93), som gav medlemmarna i gruppen f¨orst˚aelse f¨or hur olika viktiga projektmoment anv¨ands f¨or att utveckla produkter i ett team.
3
Teori
Detta kapitel beskriver den underliggande teorin som anv¨ants vid utvecklingen. Detta omfattar bland annat verktyg, hj¨alpmedel som anv¨ants i projektet samt bakomliggande matematisk teori.
3.1
Verktyg
F¨oljande avsnitt beskriver de verktyg projektmedlemmarna anv¨ant f¨or att genomf¨ora projektet.
3.1.1 Open Asset Import Library
Open Asset Import Library (Assimp) ¨ar ett ¨oppet k¨allkodsprojekt och ¨ar skrivet huvudsakligen i C++ men har bindings till flera olika spr˚ak, d¨aribland C# [6]. Biblioteket kan l¨asa in ¨over 40 olika 3D-filformat och skapa en datastruktur kallad scene. Scene-strukturen inneh˚aller olika mycket information beroende p˚a vilket filformat som l¨asts in men informationen kommer se likadan ut oavsett vilken filtyp den kommer fr˚an. Scene-strukturen best˚ar av s˚a kallade meshes, vilka ¨ar sammanh¨angande delar av den totala 3D-modellen. Varje mesh best˚ar av vertices som sp¨anner upp trianglar, kallade faces. Se Figur 1.
Figur 1: Hur Assimp representerar 3D-modeller
3.1.2 Unity
Unity ¨ar en utvecklingsplattform f¨or 3D-projekt i realtid. Unity kan anv¨andas till bland annat visualisering och skapande av 3D-modeller, samt inom spel- och grafikv¨arlden [94].
3.1.4 Git
Git ¨ar ett gratis versionshanteringsprogram med ¨oppen k¨allkod. Det ¨ar speciellt utvecklat f¨or att hantera stora, komplexa och distribuerade projekt. Detta g¨or Git, bland annat, genom att alla som har tillg˚ang till ett projekt kan klona ner det vid en viss tidpunkt, jobba med projektet och skicka upp gjorda ¨andringar till datakatalogen f¨or projektet. F¨or att f¨orenkla i st¨orre projekt finns det m¨ojlighet att jobba med f¨orgreningar. N¨ar ett projekt startas via Git s˚a finns endast en gren, kallad master. Vid behov, till exempel n¨ar flera funktioner ska implementeras samtidigt, kan flera grenar skapas. Detta f¨or att underl¨atta vid senare sammanslagning (merge)[40]. En individuell version av projektet p˚a Git kallas ofta en Git snapshot, vilket allts˚a ¨ar projektet vid en viss tidpunkt. Alla individuella versioner g˚ar alltid att ˚aterg˚a till vid behov[104].
3.1.5 Gitlab
Gitlab ¨ar en webbaserad applikation som med hj¨alp av att grafiskt representera en Git-datakatalog ska f¨orenkla vid utveckling[42].
3.1.6 LATEX
Latex ¨ar ett typs¨attningssystem framtaget f¨or att framf¨orallt f¨orenkla vid skapandet av veten-skapliga artiklar och tekniska rapporter. Det finns m˚anga f¨ordelar med att skriva dokument i Latex, n˚agra av dessa ¨ar att det ¨ar l¨attare med konsekvent formatering, skriva matematiska formler samt referenshantering[100].
3.1.7 Overleaf
Overleaf ¨ar en internetbaserad tj¨anst f¨or att skriva dokument i Latex. Tj¨ansten tillhandah˚aller bland annat dokumentdelning, direktuppdateringar samt m¨ojlighet att kompilera dokumenten direkt i webbl¨asaren f¨or att enkelt se hur Latex-filen utvecklas[76].
3.1.8 Zoom Video Communications
Zoom ¨ar ett amerikanskt f¨oretag som tillhandah˚aller tj¨anster f¨or videokonferenser. Deras produk-ter ger m¨ojlighet till videodelning, sk¨armdelning, r¨ostsamtal med mera d¨ar ett flertal personer kan delta[110].
3.2
Ramverk och arbetsmetod
Nedan f¨oljer de ramverk och arbetssmetoder som har anv¨ants.
3.2.1 Parprogrammering
Parprogrammering ¨ar en systemutvecklingsmetod som anv¨ands vid programvaruutveckling. Me-toden inneb¨ar att tv˚a programmerare arbetar tillsammans vid en gemensam dator. Den ena skriver koden (f¨oraren) medan den andra granskar koden (navigat¨oren) och f¨ors¨oker beh˚alla hel-hetsbilden ¨over projektet [21]. N˚agra av de fr¨amsta f¨ordelarna med parprogrammeirng ¨ar att
3.2.2 Scrum
Scrum ¨ar en metod som anv¨ands vid systemutveckling, som inneb¨ar att teamet fokuserar p˚a kortare tidsperioder (sprintar) d¨ar delm˚al genomf¨ors. Varje arbetsgrupp som anv¨ander sig av Scrum har en Scrum master. Dennes uppgift ¨ar att utifr˚an en product Backlog (en lista med funktioner f¨or att n˚a kravlistan f¨or verktyget), dela ut uppgifter till arbetsgruppen samt h˚alla i reflekterande m¨oten efter varje sprint och starta upp nya sprints[80].
3.3
Filformat
I f¨oljande stycke finns en kort beskrivning av filformaten som utnyttjats i projektet.
3.3.1 .fbx
Filmbox (.fbx) ¨ar ett filformat som ¨ags av Autodesk och ¨ar utvecklat f¨or att g¨ora kompatibiliteten mellan applikationer f¨or skapandet av digitalt inneh˚all b¨attre[53]. Det anv¨ands allts˚a f¨or att spara 3D/2D-modeller.
3.3.2 XML
Exstensible Markup Language (XML) ¨ar ett m¨arkspr˚ak (markup language) , som ¨ar ett format f¨or dokument. Ett XML-dokument inneh˚aller data omgiven av dess tagg[68]. Detta g¨or det m¨ojligt att se exakt vilken typ av data du tittar p˚a och f¨orenklar d¨armed l¨asning av filen f¨or m¨anniskor.
3.4
Matematisk teori
Detta avsnitt beskriver den matematiska teorin som ¨ar relevant f¨or projektet.
3.4.1 Linj¨ar algebra
Linj¨ar algebra ¨ar den matematiska studien om bland mycket annat vektorer, linj¨ara transformer och ekvationsystem. Matematiken till¨ampas i m˚anga olika praktiker s˚a som naturvetenskap, fysik och datavetenskap. Man kan anv¨anda linj¨ar algebra f¨or att beskriva positioner och avst˚and i flerdimensionella rum och spelar d¨arf¨or ¨aven en stor roll inom datortgrafik d¨ar transformer, exempelvis projektioner och rotationer, anv¨ands f¨or att skapa 3D-modeller.
I skapandet av en 3D-modell representeras punkter i form av vektorer och skal¨arer som tillsam-mans skapar figurer som kan finnas i flerdimensionella rum. Dessa kan man sedan l˚ata manipu-leras med exempelvis rotationsmatriser och translationer f¨or att skapa en levande 3D-modell. [39]
3.4.2 Voxelisering
Voxelisering ¨ar processen att producera en diskret 3D-representation av ett objekt. Slutresultatet best˚ar av s˚a kallades voxels, som kan ses som tredimensionella pixlar. Voxelisering har m˚anga
Det finns mycket tidigare forskning inom omr˚adet. En del har handlat om hur voxeliseringen fr˚an en 3D-modell faktiskt g˚ar till, exempelvis genom att kunna identifiera n¨ar en triangel sk¨ar en kub som Akenine-M¨oller beskriver i sin rapport [1]. Annan forskning handlar om hur det fr˚an dessa voxel-representationer ¨ar m¨ojligt att kunna s¨aga n˚agot om den ursprungliga modellen. Exempelvis genom att hitta mitten av modellen med hj¨alp av s˚a kallad skeletonization, n˚agot som Pal´agyi och Kuba har skrivit om i sitt forskningsarbete [77].
4
Metod
Detta kapitel beskriver hur projektgruppen har arbetat f¨or att besvara sina fr˚agest¨allningar och n˚a sina m˚al.
4.1
Roller
I b¨orjan av projektet fick varje gruppmedlem en specifik roll. Syftet med rollindelningen var fr¨amst att de olika medlemmarna skulle ha ansvar f¨or att olika delar av projektet fungerade som de skulle. Det gjorde att alla gruppmedlemmar k¨ande ett ¨agandeskap i projektet eftersom alla hade ett viktigt uppdrag. Det var ¨aven ett s¨att att minimera risken att viktiga projektmoment skulle missas. F¨or att utse de olika rollerna fick varje gruppmedlem s¨aga vilken roll de helst ville ha. D˚a mer ¨an en medlem ville ha samma roll h¨olls en omr¨ostning. Nedan f¨oljer de ˚atta rollerna som gruppen hade och en kort beskrivning om vad de innebar.
4.1.1 Teamledare
Teamledaren ansvarar f¨or att gruppen arbetar och kommunicerar effektivt. Denne ska ha en generell ¨overblick ¨over arbetet och s¨akerst¨aller att projektm˚al uppfylls och att projektarbetet f¨oljer de processer som gruppen framst¨allt. Teamledaren har ¨aven avsvar att erbjuda coaching f¨or gruppmedlemmarna samt har sista ordet om det beh¨ovs. Andra ansvarsomr˚aden hos team-ledaren ¨ar att kommunikation ut˚at sk¨ots p˚a ett representabelt s¨att. V¨art att n¨amnas ¨ar ocks˚a att teamledaren ses inte som en projektledare och f¨ordelar d¨armed inte sj¨alva arbetet f¨or grupp-medlemmarna.
4.1.2 Analysansvarig
Analysansvarig ansvarar f¨or att information, beslut och fr˚agor kommuniceras mellan projekt-grupp och kund. Denne unders¨oker kontexten f¨or kundens best¨allning och ser till att kraven som fastst¨alls kommer att leda till att slutprodukten tillgodoser kundens behov. Kontakten sker veckovis, prim¨art via e-post men samtal och m¨oten kan ocks˚a f¨orekomma.
4.1.3 Arkitekt
Ariktekten ansvarar f¨or den ¨overgripande designen av produkten, genom att skriva blocksche-man och beskriva produktens utformning som till exempel relationer mellan mjukvarumoduler. Arkitekten ¨ar ¨aven ytterst ansvarig f¨or utvecklingsplattform, programmeringsspr˚ak och proto-koll.
4.1.4 Utvecklingsledare
Utvecklingsledaren ansvarar f¨or design av produkten p˚a detaljniv˚a. Denne fattar beslut om utvecklingsmilj¨o och s¨akerst¨aller att koden som skrivs h˚aller en god standard och att individuella utvecklare f¨oljer testplanen. Utvecklingsledaren agerar ¨aven Scrum master p˚a de Scrum-m¨oten som gruppen har.
4.1.5 Testledare
Testledaren ansvarar f¨or de tester som skapas f¨or verktyget samt att s¨atta upp en teststruktur f¨or projektgruppen att f¨olja, och har ansvaret ¨over att systemtester skrivs och h˚aller en viss standard.
4.1.6 Kvalitetssamordnare
Kvalitetssamordnaren g¨or avv¨agningar av arbetsfokus s˚a att produktens ¨overgripande kvalit´e ska bli s˚a god som m¨ojligt. Denne bed¨omer tillsammans med testledaren om krav ¨ar uppfyllda, och konstruerar tillsammans med testledaren de tester som ¨ar n¨odv¨andiga f¨or att s¨akerst¨alla att de m¨atbara kvalit´erelaterade kraven ¨ar uppfyllda. Kvalitetssamordnaren ¨ar ocks˚a den som ser till att alla korrekturl¨asningar och inspektioner av dokument utf¨ors.
4.1.7 Dokumentansvarig
Dokumentansvarig leder arbetet med dokumentation inom projektet. Denne ser till att projekt-dokumentationen ¨ar korrekt skriven och enhetlig, samt s¨akerst¨aller att dokument f¨ardigst¨alls och levereras i tid. Dokumentansvarig agerar ¨aven sekreterare p˚a de m¨oten som gruppen har.
4.1.8 Konfigurationsansvarig
Konfigurationsansvarig best¨ammer vad som ska versionshanteras samt vad som ska ing˚a i en utg˚ava av en leverabel. Konfigurationsansvarig v¨aljer ¨aven versionshanteringsverktyg samt s¨akerst¨aller att dessa anv¨ands p˚a r¨att s¨att. Detta inneb¨ar att s¨atta upp riktlinjer f¨or hur utvecklare ska in-tegrera sin kod med resterande.
4.2
Utbildning
I samband med projektet beh¨ovde projektgruppens medlemmar utveckla sina kunskaper inom bland annat C#, Assimp, LaTeX, GitLab, Unity, Visual Studio m.m. F¨or att bilda en gemensam kunskapsgrund inom dessa omr˚aden skapades diverse dokument och handledningar med infor-mation om hur de fungerar samt hur projektgruppen skulle arbeta med dem. Dessa riktlinjer och handledningar framst¨alldes av de gruppmedlemmar som hade mest erfarenhet inom respek-tive spr˚ak eller verktyg. Exempel p˚a dokument och handledningar var hur arbete med grenar och merge requests p˚a Git skulle genomf¨oras, vilka kodkonventioner som g¨allde f¨or programut-veckling samt hur de olika dokumenten som skrevs skulle h˚allas enhetliga. I slutet av projektet levererades ¨aven dokumentation till kunden i samband med slutprodukten d¨ar det beskrevs hur den ¨ar t¨ankt att anv¨andas.
Under andra halvan av projektet spred sig viruset covid-19 runt om i hela v¨arlden och Link¨opings Universitet b¨orjade med distansl¨age. Detta gjorde att gruppens medlemmar ¨aven var tvungna att l¨ara sig om hur m¨oten och presentationer kan ske p˚a distans. Ett antal provm¨oten h¨olls via Zoom f¨or att medlemmarna skulle bekanta sig med programmet och arbetss¨attet.
4.3
Tidslinje
Enligt rekommendation fr˚an handledaren tog gruppen fram en tidslinje f¨or projektet. Anledning-en till att tidslinjAnledning-en togs fram var att gruppAnledning-en skulle f˚a en ¨oversiktlig bild och en visualisering ¨
over hur mycket tid som ˚aterstod fram till slutgiltig deadline f¨or att kunna planera vad som skul-le g¨oras och n¨ar i tiden. Tidslinjen togs fram gemensamt, genom att f¨orst skriva ut de deadlines som fanns fr˚an kursens h˚all, sedan l¨agga in interna deadlines f¨or att s¨akerst¨alla att arbetet blev klart i tid och att inget viktigt missades. Inf¨or varje sprint kunde gruppen se ¨over tidslinjen f¨or att f˚a en bild ¨over hur bra projektet l˚ag till i f¨orh˚allande till tid och vad som var viktigt att f˚a klart just denna sprint. I Figur 2 finns en visualisering av tidslinjen, d¨ar externa deadlines ¨ar ¨over linjen, och interna deadlines ¨ar under linjen. Tidslinjen markerar ¨aven ut tenta-p, d¨ar gruppen inte f¨orv¨antades arbeta lika mycket p˚a projektet som under resterande tid. Ut¨over de deadlines som framg˚ar i Figur 2 arbetade projektgruppen ¨aven med tv˚a interna deadlines inf¨or varje do-kumentinl¨amning. Den f¨orsta innefattade att dokumenten skulle vara f¨ardiga f¨or inspektion och den andra att dokumenten skulle vara korrekturl¨asta och reviderade f¨or inl¨amning.
Figur 2: Tidslinje
4.4
Utvecklingsmetodik
Nedan f¨oljer en beskrivning av den metodik som anv¨ants under kursen, samt hur olika verktygen anv¨ants.
4.4.1 Metoder
Nedan f¨oljer enskilda specifika metoder som gruppen anv¨ande sig av. Scrum
Projektgruppen arbetade agilt enligt en egenmodifierad Scrum-modell. Anledningen till valet var att gruppen ville arbeta agilt och ans˚ag att Scrum passade bra f¨or ¨andam˚alet. Det m¨ojliggjorde att projektgruppen fick god insyn i alla delar av projektet och kunde utv¨ardera b˚ade sitt ar-betss¨att och sin implementation av verktyget p˚a ett enkelt s¨att. Arbetsmodellen ¨ar baserad p˚a att arbeta med korta iterationer (sprints) och med retrospektiva m¨oten. M˚alet med metoden ¨ar att kunna utv¨ardera och f¨orb¨attra arbetsmetodiken under projektets g˚ang samt att ge flexibilitet
tionen att gruppen skulle kunna arbeta parallellt i st¨orsta m¨ojliga m˚an med olika projektmoment, s¨arskilt i de fall d¨ar vissa beh¨ovde implementeras innan andra. Backlogen skapades i projektets start och inneh¨oll olika funktioner eller egenskaper som verktyget skulle omfatta. Det kunde dock h¨anda att nya issues skapades under projektets g˚ang, exempelvis om ett fel hittas. F¨or att underl¨atta f¨or gruppen togs en mall f¨or hur issues ser ut fram. En issue skulle ha en f¨orklarande titel f¨or att alla i gruppen skulle f¨orst˚a vad den innebar, men sedan ¨aven ha en mer djupg˚aende beskrivning. Hur en issue skulle se ut fanns beskrivet tydligt och var en del av gruppens utbild-ning.
De retrospektiva m¨otena inleddes med att gruppen gick igenom hur l˚angt varje gruppmedlem hade kommit p˚a sina issues. Detta gjordes genom att varje medlem hade en egen kanban br¨ada d¨ar en given issue drogs mellan olika kategorier som representerade var i utvecklingen det speci-fika m˚alet l˚ag. Efter det visades en kanban br¨ada som inneh¨oll alla m˚al f¨or iterationen samt hur utvecklingen av de hade g˚att. Genom att analysera hur stor del av alla uppsatta m˚al som hade avklarats under sprinten diskuterade gruppen hur sprinten hade g˚att. Gruppen utv¨arderade hur f¨or¨andringarna fr˚an f¨orra sprinten hade f¨oljts samt vad som hade g˚att bra och mindre bra under den senaste sprinten. Slutligen best¨amde gruppen vilka eventuella f¨or¨andringar som skulle g¨oras under n¨astkommande sprint.
Ut¨over de retrospektiva m¨otena h¨olls ¨aven dagliga m¨oten p˚a cirka 15 minuter under projektets senare halva. Under dessa m¨oten gick utvecklingsledaren igenom vad varje person hade gjort sedan senaste m¨otet. Det gav gruppen en uppfattning om hur det gick f¨or de olika medlemmarna under sprintens g˚ang. Det gav ¨aven gruppmedlemmarna m¨ojligheten att lyfta fr˚agor ifall det fanns oklarheter med uppgiften eller om de beh¨ovde hj¨alp med att l¨osa n˚agot s¨arskilt problem. Anledningen till att de dagliga m¨otena inte h¨olls under f¨orsta halvan av projektet var eftersom det var logistiskt sv˚art att f˚a ihop m¨oten varje dag.
Parprogrammering
Under f¨orsta delen av projektet arbetade gruppen med parprogrammering. Anledningen till detta var b˚ade p˚a grund av de positiva effekter parprogrammering har visat sig ha [14] samt att antalet issues som kunde implementeras samtidigt var begr¨ansat. Under andra delen av projektet slutade dock gruppen med parprogrammering. Anledningen till detta var d˚a Folkh¨alsomyndigheten under v˚aren 2020 uppmuntrade till distansarbete om m¨ojligt i och med covid-19. Detta gjorde att gruppmedlemmarna arbetade p˚a distans och ans˚ag d˚a att det var komplicerat att programmera i par. Gruppen ¨overgick d¨arf¨or till att koda enskilt.
Angrepp fr˚an olika vinklar
D˚a gruppen skulle ta sig an ett helt nytt problem som ingen gruppmedlem hade speciell erfa-renhet av sedan tidigare diskuterades olika metoder att angripa problemet p˚a. D˚a kom gruppen fram till att dela upp gruppmedlemmar f¨or att f¨ors¨oka l¨osa problemet med olika strategier. M˚alet med metoden var att ¨oka chansen att problemet l¨ostes, detta genom att testa olika l¨osningar samtidigt. Det var p˚a f¨orhand uttalat att om tv˚a eller flera l¨osningar fungerade skulle enbart en l¨osning integreras med verktyget. Vilken l¨osning som valdes diskuterades och best¨amdes inom projektgruppen.
4.4.2 Hur verktygen anv¨ants
Nedan f¨oljer hur de olika verktygen har anv¨ants under projektets g˚ang. Assimp
Eftersom verktyget ska kunna generera nodgrafer utifr˚an .fbx-filer m˚aste dessa l¨asas in p˚a n˚agot s¨att. Ett ¨onskem˚al fr˚an kunden var ¨aven att verktyget i m˚an av tid skulle kunna hantera flera filformat. F¨or att tolka information fr˚an 3D-modeller p˚a ett enhetligt s¨att anv¨andes d¨arf¨or Open Asset Import Library (Assimp), som har st¨od f¨or .fbx-filer, men ¨aven m˚anga andra filformat.
struktur som verktyget arbetar med, vilket kr¨aver en ¨overs¨attning fr˚an den datastruktur som genereras av Assimp. Genom att skapa en egen struktur blir verktyget inte beroende av Assimp i framtiden, och endast den klassen som tolkar och g¨or om .fbx-filen till v˚ar egna struktur beh¨over ¨
andras. Verktygets struktur liknar p˚a m˚anga s¨att en f¨orenklad scene med problemspecifika ju-steringar, till exempel att varje face inneh˚aller sin normalvektor.
Git
Git anv¨andes som verktyg f¨or versionshantering. Projektet bestod av tv˚a huvudsakliga grenar, d¨ar den f¨orsta grenen var mastergrenen. Den anv¨andes f¨or kod som var redo f¨or demonstration till kunden. D¨ar lades endast kod till som har genomg˚att ordentlig testning och har uppfyllt s¨arskilda krav fr˚an kravspecifikationen. Den andra grenen var utvecklingsgrenen anv¨andes f¨or att l¨agga upp kod f¨or varje ny feature som skapades f¨or verktyget. D˚a en ny feature skulle utvecklas skapades en ny gren fr˚an den existerande utvecklingsgrenen d¨ar programmeringen av denna feature skedde, tillsammans med enhetstester f¨or denna. F¨or att sedan kunna l¨agga till den i utvecklingsgrenen beh¨ovde tv˚a andra gruppmedlemmar godk¨anna koden. P˚a s˚a s¨att minimerades risken att koden p˚a utvecklingsgrenen inneh¨oll buggar och andra felaktigheter. Det kanbanbr¨ade som anv¨andes f¨or det agila arbetet var den inbyggda som finns i GitLab. P˚a s˚a s¨att kunde issues kopplas direkt till v˚ara m˚al, och tack vare detta tydligt se n¨ar de hade blivit avklarade genom att konstatera ifall en gren f¨or en issue hade blivit godk¨and till utvecklingsgrenen eller inte.
Unity
Ut¨over verktygets fr¨amsta funktionalitet utvecklades ¨aven ett verktyg f¨or att visualisera det slut-giltiga resultatet i en 3D-modellering i Unity. Visuliseringen hade tv˚a viktiga anv¨andningsomr˚aden:
1. Mindre insatta intressenter som ¨ar involverade med verktyget, s˚asom potentiella kunder, kan f˚a en ¨oversk˚adlig vy av vad som faktiskt genereras.
2. Fels¨okning vid framtida utbyggnader av verktyget.
4.5
Metod f¨
or att f˚
anga erfarenheter
Nedan beskrivs de tre metoder som anv¨ants f¨or att f˚anga upp erfarenheter inom projektgruppen. L¨osningspresentationer D˚a gruppen utvecklade verktyget parallellt beh¨ovdes det en metod f¨or att s¨akerst¨alla att alla gruppmedlemmar f¨orstod hur varje enskild del av verktyget fungerade. Detta l¨ostes med l¨osningspresentationer. D˚a en ny st¨orre l¨osning skulle integreras med verktyget fick gruppmedlemmen som utvecklat l¨osningen h˚alla en presentation hur l¨osningen fungerade. Under denna presentation fick ¨aven gruppmedlemmen ber¨atta vad som varit l¨att samt vad som varit en st¨orre utmaning med l¨osningen. De andra gruppmedlemmarna uppmanades att st¨alla fr˚agor f¨or att f¨orst˚a l¨osningen. Denna metod gav alla gruppmedlemmar en inblick av hur varje del av verktyget fungerade samt erfarenheten av vad som varit sv˚art med att utveckla just den l¨osningen.
Sprintavslut
Under sprintavsluten fick varje gruppmedlem ber¨atta hur arbetet har fungerat under sprinten. D˚a gick gruppmedlemmen genom vilka erfarenheter som kunde tas med fr˚an sprinten. Detta kunde b˚ade vara erfarenheter f¨or den enskilda gruppmedlemmen eller erfarenheter som hela gruppen kunde dra nytta av. Dessa erfarenheter dokumenterades ¨aven i den veckovisa rapporten som skickades in till handledare och examinator. Syftet med att dokumentera erfarenheterna var att gruppen skulle ha m¨ojlighet att unders¨oka vilka erfarenheter gruppen haft under projektets g˚ang.
och hur gruppen upplevde att m¨otet gick. Under reflektionstillf¨allena kunde alla gruppmedlem-mar framf¨ora sina tankar kring samarbetet med kunden. Detta gjorde att gruppen kunde f˚anga upp erfarenheter fr˚an att arbeta med en kund.
5
Resultat
Detta avsnitt presenterar resultat i f¨orh˚allande till de fr˚agest¨allningarna som unders¨okts. In-ledningsvis beskrivs den systemanatomi som tagits fram av projektgruppen. Sedan f¨oljer en presentation av strukturen f¨or det verktyg som skapats, detta leder sedan till en beskrivning av hur verktygets l¨osningar tillsammans med andra faktorer har skapat v¨arde f¨or kunden. Slutligen presenteras de relevanta erfarenheter projektgruppen har identifierat under projektet.
5.1
Systemanatomi
Tidigt under projektets g˚ang h¨olls ett gemensamt m¨ote d¨ar alla gruppmedlemmar var n¨arvarande och en diskussion om hur verktyget b¨or struktureras inleddes. Detta var ett bra s¨att att f˚a en gemensam ¨overblick av vad som b¨or ing˚a i systemet, och resultatet av denna diskussion blev den systemanatomi som sedan har arbetats utefter, enligt Figur 3.
Få en nodgraf
Översätta till
XML Skriva till fil
Skapa Bågar Skapa Noder Översätta från FXB Läsa FXB fil Ta emot argument från terminal Kommandotolk .NET Dator Funktionalitet Miljö Beroende av
F¨ortydligande av systemanatomi och programfl¨ode
Efter inspektion av Figur 3 framg˚ar det att strukturen ¨ar v¨aldigt linj¨ar, vilket ¨ar en konsekvens av att verktyget endast ska kunna utf¨ora den n˚agorlunda specifika uppgiften den ¨ar designad att uppn˚a. Systemanatomin ska tolkas enligt det som beskrivs till h¨oger i figuren. Gr¨ona rek-tanglar representerar tydligt distinkta och separata funktionaliteter, orangef¨argade rektanglar representerar milj¨ospecifika systemkomponenter(som ej utvecklas eller ing˚ar i detta arbete). Till sist visar de pilar som sammankopplar dessa, genom att peka fr˚an ett delsteg till ett annat, att ett beroende finns.
D˚a verktyget ¨ar designat att anv¨andas endast p˚a en dator ¨ar detta det grundl¨aggande beroendet f¨or hela anatomin. P˚a denna anv¨ands ramverket .NET tillsammans med den inbyggda kom-mandotolken f¨or att anv¨andaren ska kunna f¨ormedla att verktyget ska anv¨andas samt vilken in-och utdatafil som ska hanteras. D˚a denna information ¨ar angiven som en l˚ang str¨ang i anv¨and terminal s˚a tolkas och separeras detta som f¨orsta steg av verktyget, Ta emot argument fr˚an terminal. Sedan avl¨ases .fbx-filen angiven av anv¨andaren vilken omg˚aende ¨overs¨atts fr˚an .fbx till den struktur som har definierats och utvecklats f¨or detta verktyg. Detta steg utg¨or majoriteten av verktyget, och ¨ar den del av processen som ¨ar tidskr¨avande. ¨Oversiktligt kan denna skapade struktur brytas ner till tre ¨overgripande komponenter; noder och b˚agar som bygger upp en nod-graf. N¨ar denna ¨ar skapad ¨ar n¨asta steg att ¨overs¨atta strukturen till ett mer ¨oversk˚adligt och l¨attexporterbart format, och med krav fr˚an kunden valdes XML-formatet f¨or detta. Slutligen skrivs detta till den angivna utdatafilen och verktyget har uppfyllt sin funktion, och producerat en nodgraf.
5.1.1 Arkitektur¨oversikt
Efter att systemanatomin framst¨allts och ytterligare diskussioner med kund och handledare h˚allits kunde en arkitekturplan implementeras, se Figur 4.
5.2
Beskrivning av verktyget
Verktygets funktion ¨ar att skapa en nodgraf utifr˚an en given indatafil beskrivande en gruva. Initialt inneb¨ar detta att indata i form av 3D-modeller av filtypen .fbx finns tillg¨anglig. Det-ta processeras sedan genom att identifikation och konstruktion av noder som ¨ar signifikanta f¨or gruvutformningen skapas, s˚a som korsningar och ˚aterv¨andsgr¨ander. Dessa sammankopplas sedan med b˚agar d¨ar gruvg˚angar f¨orbinder dessa punkter i modellen, som ut¨over detta ¨aven specifice-rar minimala avst˚and i h¨ojd och bredd mellan dessa noder. Dessa relationer sammanst¨alls och sparas sedan i en nodgraf vilken d˚a har all v¨asentlig information som skulle vilja avl¨asas ur modellen. Strukturen ¨overs¨atts och sparas slutligen till filformatet XML f¨or vidare anv¨andning och processering. Relevant anv¨andning av utdatafilen ¨ar avl¨asning av dimensionsbegr¨ansningar som specifika g˚angar i gruvan har f¨or att ber¨akna framkomlighet, eller ber¨akna vad kortaste avst˚andet mellan ett visst par av noder i grafen ¨ar, med mera. De senast n¨amnda funktionerna ¨
ar inte ber¨akningar som detta verktyg ska kunna utf¨ora.
I sin mest grundl¨aggande form s˚a ¨ar informationen som ska ¨overs¨attas med hj¨alp av verktyget den samling vertices som bygger upp triangelformade polygoner, som i sin tur bygger upp den scene som representerar gruvan.
I Figur 5 visas hur en gruvg˚ang med ytorna borttagna kan se ut. Det framg˚ar tydligt h¨ar hur best˚andsdelarna till ytorna ¨ar triangelformade polygoner, vilka blir mer kompakta ju mer ytan vrider sig i rummet. Marken i en gruva ¨ar till exempel v¨aldigt plan och kr¨aver inte m˚anga polygoner f¨or att beskrivas, medan gruvtaket som ¨ar valvformat f¨oljaktligen inneh˚aller m˚anga polygoner.
En mer utzoomad bild av hur dessa polygoner bygger upp en hel gruva visas i Figur 6. Allt som ¨
ar svartf¨argat i figuren ¨ar ett stort antal polygoner, som fr˚an bildens avst˚and ¨ar sv˚arutskilda. Dessa bygger tillsammans upp gruvschakten.
Enligt programfl¨odet ¨ar sista steget att konvertera den resulterade nodgrafen till den best¨amda XML-standarden. Strukturen p˚a XML-formatet kan ses till h¨oger i Figur 7, och ett exempel p˚a en faktisk utskrift enligt den strukturen kan ses till v¨anster i samma figur. Denna utskrift beskriver en av de mest simpla nodgrafer som kan ¨overs¨attas, d˚a den endast best˚ar av tv˚a noder med en sammankopplande b˚age vilket motsvarar en rak korridor i gruvan.
5.3
Verktygsspecifika l¨
osningar
Projektet resulterade i tv˚a olika l¨osningar f¨or att generera en nodgraf. Anledningen till detta var att kunden inledningsvis f¨ors˚ag projektgruppen med indata-filer d¨ar gruppen kunde g¨ora vissa antaganden. Senare under projektet skickade kunden mer avancerad indata som gjorde att de antaganden gruppen gjort inte l¨angre kunde appliceras. Detta beror p˚a att de senare modellerna var genererade med hj¨alp av en 3D-kamera nere i gruvan. D¨arf¨or utvecklades en ny l¨osning f¨or att kunna hantera mer generella indata-filer. Nedan f¨oljer en beskrivning av de tv˚a olika l¨osningar gruppen producerat. De figurer av genererade nodgrafer som presenteras h¨ar har gjorts med hj¨alp av det verktyg projektgruppen utvecklat i Unity f¨or visualisering.
5.3.1 L¨osning 1
Den f¨orsta l¨osningen som togs fram av projektgruppen anv¨ander sig av vissa antaganden f¨or att kunna identifiera de olika gruvg˚angarna. Exempelvis m˚aste en mesh ha ett sammanh¨angande golv, gruvg˚angen m˚aste ha ungef¨ar 90 grader mellan vertices vid slut¨andarna av golvet, samt att en mesh endast f˚ar ha en in- och en utg˚ang. Ifall n˚agot av kraven ovan inte ¨ar uppfyllda fungerar inte algoritmen som f¨orv¨antat.
Algoritmen unders¨oker varje mesh som bygger upp gruvan och identifierar var noder och b˚agar b¨or placeras ut i denna. Det g¨ors genom att f¨orst identifiera vad som ¨ar golvet i en s˚adan gruvg˚ang. Sedan placerades noder ut i mitten av det identifierade golvet. Efter att alla olika mesh-objekt f˚att en motsvarande nodgraf sl˚as dessa ihop till en sammanh¨angande graf genom att sammanfoga dessa p˚a l¨ampliga st¨allen. Detta g¨ors genom att identifiera n¨ar olika gruvg˚angar sk¨ar varandra och en korsning sker. Den resulterande nodgrafen fr˚an gruvg˚angen i Figur 8 kan ses i Figur 9.
Figur 9: Genererad nodgraf utifr˚an Figur 8, d¨ar de lila punkterna representerar noder samt de turkosa linjerna representerar b˚agar
5.3.2 L¨osning 2
F¨or L¨osning 2 kr¨avs totalt tv˚a stycken antagande, att modellen m˚aste vara ”sluten” i tak och golv samt att meshen i helhet ¨ar sammanh¨angande. Denna bygger p˚a att anv¨anda en voxelre-presentation av gruvan, allts˚a ett 3D-rutn¨at d¨ar varje kub (voxel) kan vara ifylld eller inte ifylld. F¨orsta steget ¨ar d¨arf¨or att skapa en voxelrepresentation av gruvan. Voxelmodellen skapas i tv˚a steg; F¨orsta steget ¨ar att fylla alla voxlar som sk¨ar ett face i 3D-modellen, vilket i detta projekt g¨ors enligt Akenine-M¨ollers forskning [1]. Detta skapar ett skal av gruvan och de ifyllda voxlarna representerar d˚a v¨aggar, golv och tak i gruvan. Efter det fylls skalet i s˚a att gruvan blir en fylld volym. Det finns d˚a en diskret 3D-representation av gruvan att forts¨atta utifr˚an, hur det kan se ut visas i Figur 10.
Med en voxelrepresentation av gruvan kan gruvmodellen tunnas ut s˚a att alla tunnlar i gruvan ¨
ar exakt 1 voxel i bredd och h¨ojd. F¨ortunningen av gruvan sker i tv˚a steg, f¨orsta steget ¨ar att ta bort voxlar baserat p˚a en avst˚andskarta. Det inneb¨ar att en voxel tas bort baserat p˚a hur l˚angt ifr˚an n¨armaste icke-ifyllda voxel den ¨ar. Detta steg utf¨ors f¨or att f¨orb¨attra resultatet fr˚an n¨astkommande steg. Detta steg ¨ar att applicera en skeletonization-algoritm, vilken i detta projekt ¨ar baserad p˚a Pal´agyi och Kubas forskning [77]. Det ¨ar en typ av algoritm gjord f¨or att minska en generell 3D-modell till ett skelett, med 1 voxel i bredd och h¨ojd, som beskriver modellen.
P˚a en ¨overgripande niv˚a fungerar skeletonization-algoritmen genom att stegvis ta bort voxlar genom att bed¨oma om en voxel ¨ar viktig f¨or att beh˚alla geometrin och topologin eller inte. Om en voxel exempelvis endast har tv˚a n¨arliggande grannar s˚a ¨ar den voxeln essentiell f¨or strukturen och b¨or inte tas bort. I Figur 11 ses samma del av gruvan som i Figur 10 efter att f¨ortunningen har skett. Som syns i figuren ¨ar alla gruvg˚angarna nu 1 voxel i bredd och alla voxlar f¨orutom de i korsningar och slut av g˚angar har exakt tv˚a grannar.
Figur 11: F¨ortunnad representation av gruvg˚angen i Figur 10
Fr˚an modellen skapas sedan en nodgraf genom att vandra igenom hela modellen. En voxel som endast har en granne, och d¨armed ¨ar slutet p˚a en gruvg˚ang, anv¨ands som startpunkt och en nod skapas vid positionen f¨or voxeln. Algoritmen b¨orjar sedan vandra fr˚an den voxeln tills att b˚agen mellan start-voxeln och nuvarande position avviker f¨or mycket fr˚an de voxlar som har passerats. N¨ar det h¨ander skapas en ny nod p˚a positionen och vandringen forts¨atter. Vid korsningar och i slutet p˚a g˚angar skapas alltid noder f¨or att nodgrafen ska forts¨atta ˚at flera h˚all eller stanna. N¨ar alla voxlar har bes¨okts ¨ar vandringen f¨ardig och nodgrafen representerar hela gruvan. Den resulterande nodgrafen kan ses i Figur 12.
Figur 12: Resulterande nodgraf fr˚an den f¨ortunnade gruvg˚angen i Figur 11, med samma f¨argkod som Figur 9
5.4
V¨
arde f¨
or kunden
Fr˚agest¨allning 1 i projektet ¨ar hur projektgruppen skapar v¨arde f¨or kunden med ett verktyg som kan generera en nodgraf. L¨osning 2 ¨ar implementerad med en s˚a generell metod som m¨ojligt f¨or att kunna anv¨andas i kundens externa system d¨ar indata inte kan garanteras ha samma specifikationer vid varje anv¨andningstillf¨alle. Detta m¨ojligg¨ors med den voxeliseringsteknik som implementerats f¨or att identifiera gruvg˚angar. Projektgruppen har ¨aven bidragit med sina re-flektioner kring vad som har varit enkelt och sv˚art att jobba med under utvecklingens g˚ang vid demonstrationer och m¨oten. Att bidra med s˚adana erfarenheter m¨ojligg¨or f¨or Combitech att vid vidareutveckling vara medvetna om var tid b¨or fokuseras. Annat i utvecklingen som bidrar till v¨arde f¨or kunden och f¨orenklar vidareutvecklingen ¨ar v¨aldokumenterad kod och f¨orklarande variabelnamn. I nul¨aget ¨ar det sv˚art att svara p˚a om Combitech kommer att anv¨anda sig av verktyget i det externa systemet, men det finns tillr¨ackligt med funktionalitet f¨or att verktyget kan anv¨andas f¨or vidareutveckling. Slutligen ligger det huvudsakliga v¨ardet f¨or kunden i att pro-jektgruppen har utforskat olika metoder att framst¨alla nodgrafer fr˚an 3D-modeller och kommit fram till ett tillv¨agag˚angss¨att som kan till¨ampas p˚a en stor variation av indata.
5.5
Gemensamma erfarenheter
Projektet har givit gruppmedlemmarna m˚anga nya erfarenheter vilka kan delas in i processrela-terade, teamarbetesrelaterade samt tekniska erfarenheter. Erfarenheterna finns beskrivna nedan, och dessa kommer projektmedlemmarna att ta med sig i kommande projekt d¨ar dessa ¨ar appli-cerbara.
5.5.1 Processrelaterade erfarenheter
Gruppmedlemmarna hade innan projektet teoretisk kunskap om Scrum men inte praktiskt ar-betat med metoden. Under projektet har gruppmedlemmarna f˚att erfarenhet av att planera och s¨atta upp sprintar och vid retrospektiva m¨oten v¨ardera hur de har g˚att vilket upplevts som l¨arorikt. Utv¨arderingarna har varit bra f¨or att anpassa metoden p˚a ett s¨att som passar gruppen. Eftersom projektet har innefattat mycket dokumentskrivande har gruppen ¨aven arbetat med dokumenten p˚a ett agilt s¨att.
En annan l¨arorik erfarenhet har varit att arbeta mot en kund. Tidigare projekt som medlem-marna har arbetat med har varit i en universitetsmilj¨o d¨ar problemet som ska l¨osas har varit v¨al definierat och l¨attillg¨anglig personal funnits f¨or fr˚agor. Dessa problem skiljer sig v¨aldigt mycket fr˚an den upplevelse gruppen har haft med kunden i detta projekt. Gruppen hade en del problem i b¨orjan av projektet med att fastst¨alla kravspecifikationen och upplevde en del problem vid kommunikationen med kunden d˚a det tog l˚ang tid att f˚a svar. Det uppstod ¨aven en del problem med att planera in m¨oten d˚a det var sv˚art att hitta tider som b˚ada parter kunde m¨otas. Dessa logistikkomplikationer har varit l¨arorika och har ¨oppnat upp ¨ogonen f¨or projektgruppen om hur samarbeten fungerar utanf¨or universitet.
Kodgranskningen upplevde gruppen var bra och att det f¨orh¨ojde kodkvalit´e och hj¨alpte till att dela kunskap i gruppen. Men gruppen hade ¨aven en del problem med att det vid m˚anga tillf¨allen tog l˚ang tid fr˚an att en gruppmedlem lade upp en merge request till det att tv˚a andra medlemmar granskat och godk¨ant denna f¨orfr˚agan. Fortsatt arbete som berodde p˚a denna f¨orfr˚agan kunde d¨arf¨or tvingas skjutas upp.
5.5.2 Teamarbetesrelaterade erfarenheter
Gruppen har upplevt att samarbetet fungerat bra. Medlemmarna har tagit p˚a sig de ansvars-omr˚aden som f¨oljer med deras roll n¨ar det har beh¨ovts och kommunikationen i gruppen har fungerat bra. Under f¨orsta halvan av projektet h¨oll gruppen ungef¨ar 3 m¨oten varje vecka och all annan kommunikation skedde via Slack. Det fungerade bra men de dagliga m¨oten som h¨olls under den senare halvan av projektet upplever gruppen f¨orb¨attrade kommunikationen mycket. Det blev enklare att veta vad gruppen arbetade med och gjorde det enklare att komma med fr˚agor eller funderingar till gruppen.
5.5.3 Tekniska erfarenheter
Utveckling i projektet har skett i spr˚aket C# vilket ingen av gruppmedlemmarna tidigare ar-betat med i st¨orre utstr¨ackning, och nu har f˚att erfarenhet av att utveckla i. St¨orsta delen av utvecklingen handlade om 3D-modeller och hur dom representeras i datastrukturer. Endast en av medlemmarna hade tidigare arbetat med 3D-modeller s˚a det var n˚agot som gruppen l¨art sig under projektet.
5.6
Processomr˚
ade
Tillsammans med studenter fr˚an kursen TDDE46 har processomr˚adet Way of working behand-lats under projektets g˚ang. Detta har i gruppen praktiskt utf¨orts genom att utv¨ardera det anv¨anda arbetss¨attet, Scrum, vid ett flertal tillf¨allen. Utv¨arderingarnas fokus var att som grupp diskutera och evaluera tv˚a huvudomr˚aden: strukturen av sprintarna samt de sprintavslutande Scrum-m¨otena.
F¨or att kunna utv¨ardera, med konkreta siffror, hur detta processomr˚ade utvecklades under pro-jekttiden s˚a tillsattes, tillsammans med studenterna fr˚an kursen TDDE46, metriker som speglar gruppens effektivitet och produktivitet. Till exempel s˚a j¨amf¨ordes antalet sprintm˚al som sattes upp kontra hur m˚anga som utf¨ordes, om det fanns tid f¨or att g˚a igenom samtliga m¨otespunkter vid varje Scrum-m¨ote, och vilka f¨or¨andringar som skulle utf¨oras inf¨or n¨asta sprint, i avseende till exempel dess l¨angd, f¨or att f¨orb¨attra gruppens m¨ojlighet att jobba effektivare. F¨or att se samtliga specifika fr˚agor som behandlar dessa metriker h¨anvisas det till Bilaga I - Utv¨arderingsdokument -Mall, vilken inneh˚aller den mall som f¨oljdes vid varje utv¨arderingstilf¨alle. Slutligen kan det ¨aven avl¨asas exakt hur gruppen f¨orh¨olls sig till dessa fr˚agor vid varje utv¨ardering i efterf¨oljande bilaga, Bilaga J - Utv¨arderingsdokument, d¨ar samtliga svar finns. F¨or en mer koncis sammanfattning av dessa svar, och en mer generell slutsats och diskussion om hur ett fokus p˚a detta processomr˚ade kan p˚averka grupper i liknande kandidatprojekt, h¨anvisas det till Bilaga A - Scrum och andra iterativa arbetss¨atts applicerbarhet i kandidatprojekt.
5.7
Dokument
I Tabell 1 f¨oljer de dokument som gruppen har producerat under projektets g˚ang i enlighet med kursm˚alen. Samtliga av dessa har reviderats ett flertal g˚anger och har hj¨alpt projektgruppen att strukturera arbetet genom att t¨anka igenom projektet i sin helhet.
Dokument Deadline Statusrapport 2020-02-24 Arkitekturdokument 2020-03-11 Projektplan 2020-03-11 Kravspecifikation 2020-03-11 Kvalitetsplan 2020-03-11 Testplan 2020-04-20 Testrapport 2020-04-20 Utv¨ardering 2020-04-20 Kandidatrapport 2020-05-08 Tabell 1: Dokumentlista
5.8
Oversikt av individuella bidrag
¨
Nedan f¨oljer sammanfattningar av de individuella studierna som gruppmedlemmarna bidragit med.
5.8.1 Scrum och andra iterativa arbetss¨atts applicerbarhet i kandidatprojekt av Jonatan Jonsson
I detta delkapitel har en djupare utredning om det anv¨anda romverket Scrum och andra agila arbetss¨att utf¨orts med inriktning mot projektgrupper som antar kandidatprojektskursen. Med hj¨alp av interna utv¨arderingar och en enk¨atunders¨okning underbyggda av tidigare studier in-om in-omr˚adet har likheter och skillnader i implementation av Scrum och sprints identifierats bland dessa projektgrupper. Ut¨over detta har ¨aven vikten av att utv¨ardera det anv¨anda agila arbetss¨attet besvarats f¨or att ge en helhetsbild av utnyttjandet av Scrum i gruppprojekt.
5.8.2 Parprogrammeringens mest l¨ampade arbetsomr˚aden av Alexander Olsson Efter den v¨arldsomfattande covid-19 krisen b¨orjade projektgruppen att arbeta p˚a distans. D¨armed togs ¨aven beslutet att sluta parprogrammera. Detta ledde till att gruppmedlemmarna fick erfa-renheter fr˚an att arbeta b˚ade med och utan parprogrammering. Denna studie svarar p˚a fr˚agan ang˚aende vilka arbetsuppgifter som parprogrammering ¨ar mest l¨ampligt f¨or. Studien g¨or detta genom en omfattande litteraturstudie, samt genom intervjuer av gruppmedlemmarna ang˚aende deras erfarenheter kring arbetet med och utan parprogrammering.
5.8.3 En unders¨okning av rollerna Teamledare och Scrum-master av Christina Dahl´en
En unders¨okning som analyserar rollerna Teamledare och Scrum-master f¨or att svara p˚a fr˚agest¨allningarna Vilken roll tar en Scrum-master i j¨amf¨orelse med en Team-ledare i generella mjukvaruprojekt?
och Hur v¨al speglar kursuppl¨agget i TDDD96 en realistisk rollf¨ordelning i ett mjukvaruprojekt?. Unders¨okningen genomf¨ordes med hj¨alp av verktygen informationssamling och intervju av stu-denter som l¨aser kursen TDDD96 under v˚arterminen 2020 f¨or att kunna dra nyanserade slutsat-ser. Studien resulterade i att slutsatsen f¨or den f¨orsta fr˚agest¨allningen blev att en Scrum-master och teamledare har liknande arbetsuppgifter, d¨aremot arbetar de inom olika omr˚aden i projektet och anpassar d¨arf¨or sina arbetsuppgifter. I regel arbetar en Scrum-master n¨ara produkten och ¨
ar resultatdriven medans en teamledare arbetar n¨ara projektgruppen och ¨ar kommunikations-driven. Slutsatsen som drogs f¨or den andra fr˚agest¨allningen var att trots att m˚anga andra aspek-ter av projektkursen speglar verkliga situationer s˚a speglar kursen TDDD96 inte en realistiskt rollf¨ordelning i ett mjukvaruprojekt. Detta berodde p˚a att den rekommenderade rollf¨ordelningen inneh¨oll ¨overfl¨odiga roller och inte anpassade sig efter det unika arbetet varje projekt utf¨or.
5.8.4 H˚allbar utveckling i mjukvaruprojekt av Isak H¨aggstr¨om
Projektgruppens arbete g¨ors f¨or att effektivisera gruvdrift och d¨arf¨or unders¨oks i detta avsnitt h˚allbar utveckling med hj¨alp av en SusAD analys p˚a mjukvaruutveckling och det specifika pro-jektet sustainable underground mining.
5.8.5 Distansl¨agets p˚averkan p˚a agila metoder i mjukvaruprojekt av Ebba Lindstr¨om Restriktionerna i och med covid-19 gjorde att m˚anga mjukvaruf¨oretag ¨overgick till ett di-stansl¨age. Denna studie unders¨oker hur det agila arbetss¨attet har p˚averkats i och med di-stansl¨aget och vad det kommer inneb¨ara f¨or framtida arbetss¨att i branschen. Studien anv¨ander sig av tematisk analys p˚a data insamlat via semitrukturerade intervjuer samt enk¨ater. Studi-en hittade fem olika teman f¨or att besvara fr˚agest¨allningen, dessa var Inte s˚a stor f¨or¨andring, Effektivitet, Kommunikation, Insikter och l¨ardomar samt Spekulationer om framtiden.
5.8.6 Utveckling av simuleringsverktyg f¨or utbildningssyfte i moderna spelmotorer av Jens Lindgren
Unity anv¨andes f¨or att visualisera de grafer som genererades av projektet. I denna studie un-ders¨oks Unity som ett verktyg f¨or att skapa simuleringsverktyg i utbildningssyfte genom utveck-ling av en prototyp. Studien producerade ett simuleringsverktyg f¨or PID-reglering av dr¨onare och insikter kring utvecklingen som kan v¨agleda framtida projekt.
5.8.7 Virtuell verklighet (VR) f¨or s¨akerhet i gruvindustrin av Techit Lerssongkram Denna del presenterar en unders¨okning som visar vad virtuell verklighet (VR) ¨ar och hur den kan anv¨andas f¨or att f¨orb¨attra s¨akerheten i gruvindustrin. VR: s huvudfokus och olika typer av VR-system kommer att g˚as genom. F¨or att ge en tydlig bild hur VR anv¨ands i gruvindustrin ges n˚agra exempel f¨or olika VR-tr¨aningsmoduler som tr¨anar gruvarbetare f¨or att f¨orb¨attra s¨akerheten i deras arbetsmilj¨oer och r¨adda liv.
5.8.8 Hur kodgranskning anv¨ands och vilka f¨ordelar som kan f˚as av Viktor Hellqvist Kodgranskning anv¨ands ofta i mjukvaruprojekt och har ¨aven anv¨ants i detta projekt. I denna rapport g¨ors en litteraturstudie p˚a hur kodgranskning anv¨ands idag och vilka f¨ordelar som kan f˚as av att anv¨anda kodgranskning i ett mjukvaruprojekt.
