I detta avsnitt beskrivs metoder som projektgruppen vidtagit f¨or att utf¨ora projektet. Detta f¨or att kunna reflektera ¨over valen som gjorts och se vilka av dem som fungerat bra samt f¨or att kunna reflektera ¨over hur liknande framtida projekt kan g˚a tillv¨aga f¨or att lyckas med sina arbetsuppgifter.
6.2.1 F¨orstudier
I b¨orjan av projekttiden l˚ag fokus i projektgruppen p˚a att hitta ett s¨att att tolka 3D-modeller. Omedelbart efter att Assimp bekr¨aftats klara de uppsatta kraven, startades utvecklingen av verktyget. Projektgruppen f¨oll i f¨allan att inte l¨asa p˚a tillr¨ackligt om ¨amnet innan implementa- tionen p˚ab¨orjades. Att arbeta med 3D-modeller ¨ar inte n˚agot nytt och det finns absolut m¨ojlighet att hitta rapporter om tidigare arbeten som bearbetar liknande problem. Hade detta t¨ankts p˚a tidigare hade l¨osningen till problemet troligen inte beh¨ovt ¨andras under utvecklingen.
6.2.2 Utvecklingsmetodik
D˚a valet av implementation f¨or att uppn˚a det v¨arde som kunden efterfr˚agar inte har varit en sj¨alvklarhet har ett flertal l¨osningar genomarbetats, evaluerats och ibland ¨aven f¨orkastats under projekttiden f¨or att n˚a den produkt som presenteras i Avsnitt 5. Ut¨over de tv˚a uppenbart separata l¨osningarna som presenterats, har dessa tv˚a implementationer sj¨alva genomg˚att ett flertal iterationer och designval, som har p˚averkat den utvecklingsmetodik som anv¨ants. F¨or att m¨ojligg¨ora f¨or effektiv kundrespons, se 6.2.4, implementerades dessa l¨osningar ibland parallellt f¨or att senare l¨attare och tydligare kunna visa de f¨ordelar och nackdelar som de olika l¨osningarna besitter. Detta s¨att att arbeta m˚a ha haft sina nackdelar i och med att viss utvecklingstid gick f¨orlorad. Men den har b˚ade bidragit till insikter och erfarenheter som kunnat anv¨andas vid fortsatt utveckling och att kundens faktiska efterfr˚agan b¨attre uppfyllts.
D˚a en stor l¨osning skulle integreras med projektet presenterades l¨osningen f¨or hela gruppen, se 4.5. Under dessa presentationer var fokus p˚a att f¨orklara tanken bakom l¨osningen mer ¨an sj¨alva koden. Dessa presentationer gav chansen f¨or andra i gruppen att lyfta tankar kring l¨osningen, alternativt komma med f¨orslag p˚a andra l¨osningar. Denna metod anser gruppen ger de slutgiltiga l¨osningarna som integreras med verktyget en h¨ogre standard, d˚a l¨osningarna ¨ar mer genomt¨ankta. Det leder i slut¨andan till att slutprodukten som levererades till kunden hade en h¨ogre kvalit´e ¨an om presentationerna inte hade h˚allits. Detta i sin tur leder till ett st¨orre v¨arde, sett fr˚an kundens perspektiv.
Under hela projektet utvecklades verktyget med hj¨alp av en agil Scrum-modell. Denna agila metod m¨ojligg¨or f¨or gruppen att kunna vara mer flexibel d˚a ¨andringar fr˚an ursprungsid´een uppkommer. Ett tydligt exempel p˚a detta var d˚a gruppen ins˚ag att det beh¨ovdes en nya l¨osning, voxelisering, som kr¨avdes f¨or att klara av sv˚arare modeller. D˚a kunde gruppen enkelt omf¨ordela arbetet f¨or att se till att det fanns gruppmedlemmar som kunde utveckla den nya l¨osningen. Detta tack vare utvecklingsmodellen. Detta anser gruppen var en viktig komponent till att kunna skapa det v¨arde p˚a verktyget som levererades till kunden. Genom att arbeta agilt har verktyget aldrig varit l˚ast till den l¨osning som valdes fr˚an b¨orjan, utan ist¨allet blivit en levande process som f¨or¨andrats kontinuerligt fr˚an b¨orjan till slutet. Denna metod har ut¨over detta varit ett m˚aste f¨or att kunna f¨or¨andra designbeslut utifr˚an kundkontakt, se 6.2.4.
v¨anda sig till en specifik gruppmedlem f¨or fr˚agor g¨allande dennes omr˚ade. N˚agot som kunde ha f¨orb¨attrats skulle vara att ha en till roll, en expertroll. Denne hade d˚a kunnat s¨atta sig in rej¨alt i problemet i ett tidigt stadie, inom tidigare studier om 3D-modeller och dylikt, och kanske kunnat hitta tekniker s˚asom voxelisering tidigare. Detta hade m¨ojligtvis gjort att L¨osning 2 hade implementerats fr˚an b¨orjan. Dock hade en s˚adan roll inneburit att gruppen beh¨ovt ta bort en av de existerande rollerna, vilket gruppen inte hade velat g¨ora. Detta eftersom alla roller ans˚ags vara viktiga i projektet.
6.2.4 Kundkontakt
Fr˚an projektets b¨orjan har en god uppr¨atth˚allen kundkontakt varit grundl¨aggande f¨or hur arbetet utformats. Som beskrivet i 6.2.2 ovan och i Avsnitt 5 f¨or¨andrades verktygets l¨osning signifikant fr˚an den initiala implementationen. Detta d˚a det f¨orst senare under projektets framskridande framgick, f¨or b˚ade kunden och projektgruppen, vad den efterfr˚agade produkten skulle uppfylla. D˚a var det essentiellt med denna kommunikation mellan parterna. Ut¨over den konstanta diskus- sion som h˚allits elektroniskt mellan parterna, har de tre demonstrationstillf¨allena organiserats. Dessa var mycket givande och insiktsfulla f¨or att skapa det v¨arde som efterfr˚agas. M¨oten blev tillf¨allen d˚a produkten kunde visas upp f¨or att visa nuvarande status i arbetet, samt utbyta tan- kar kring designen. Den respons som utkommit fr˚an detta har stark p˚averkat hur projekttiden har f¨ordelats f¨or alla medlemmarna och vad som senare blev det slutgiltiga fokuset implementa- tionsm¨assigt.
6.2.5 Kodgranskning
Vid kodgranskningen var tiden fr˚an att en granskning skapades tills att den godk¨andes ett problem. Det berodde inte p˚a att det tog l˚ang tid att g¨ora sj¨alva granskningen utan p˚a grund av att det tog l˚ang tid innan n˚agon gjorde granskningen. Detta kom upp som ett problem f¨or att personer inte kunde arbeta p˚a sina issues f¨or att kod som beh¨ovdes var i granskningsstadiet och inte fanns tillg¨anglig. Det var ¨aven ofta andra issues som v¨antade p˚a granskning och d¨armed inte var klara vid sprintavsluten. Gruppen best¨amde d¨arf¨or att granskning skulle vara h¨ogsta prioritet, vilket innebar att om det fanns en merge request skulle den granskas innan annat arbete fortsatte. Anledningen till problemet ¨ar antagligen en kombination av att gruppmedlemmarna har andra kurser samtidigt vilket g¨or att vissa inte arbetar med projektet p˚a en hel dag och d¨armed inte granskar, tillsammans med att de arkitekturella valen var linj¨ara och d¨armed sv˚arare att utveckla parallellt. Gruppen lyckades d¨arf¨or inte l¨osa problemet helt men det ¨ar ocks˚a d¨arf¨or inte troligt att skapa lika stora problem i andra projekt.
6.3
Begr¨ansningar
Resultaten och dess utveckling har p˚averkats av begr¨ansningar hos projektgruppen i sig och faktorer som ber¨or projektgruppen. Den mest markanta begr¨ansningen ¨ar det maxantal timmar som f˚ar arbetas per gruppmedlem. Detta har medf¨ort att gruppen noga beh¨ovt budgetera de timmar som funnits samt har de beh¨ovt prioritera olika arbetsuppgifter ¨over andra. Detta re- sulterade i att allt som ville implementeras eller g¨oras inte hanns med, eller prioriterades l¨agre. Detta f¨ors¨akrade ¨aven att de viktigaste ¨arendena fick utrymme att arbetas med ordentligt och d¨armed hj¨alpte till att s¨akra kvalit´en p˚a arbetet gruppen ville uppn˚a.
Ytterligare en begr¨ansande faktor ¨ar gruppmedlemmarnas initiala kunskap r¨orande problemet, arbetss¨attet och den valda l¨osningsg˚angen. D˚a alla medlemmar inledningsvis inte hade arbe- tat med C#, Visual Studio eller 3D-modeller i n˚agon st¨orre utstr¨ackning var det mycket tid
uppstartsstr¨ackan m˚anga olika perspektiv som kanske inte lyfts fram om alla medlemmar tidigare studerat ¨amnet och d¨arf¨or bidrog detta till att fler erfarenheter utforskades.
Gruppmedlemmarna har under projektet f¨oljt riktlinjerna f¨or kursen TDDD96 och har d¨arf¨or blivit begr¨ansade enligt dessa. Gruppen har ¨aven f˚att v¨agledning i hur rapport och projektstruk- tur b¨or formuleras. Dessa har delvis varit begr¨ansningar, men har ¨aven hj¨alpt projektgruppen att strukturera arbetet och v¨aglett dem f¨or att kunna slutf¨ora projektet v¨al under de 3200 timmarna som tilldelats gruppen.
Slutligen har ¨aven den r˚adande v¨arldssituationen r¨orande covid-19 begr¨ansat gruppen och p˚averkat den m¨otesstruktur som initialt p˚ab¨orjades. D˚a Link¨opings Universitet deklarerade distansl¨age anpassade gruppen sin m¨otesstruktur som resulterade i m¨oten via Zoom. Detta gav projekt- gruppen erfarenhet av att beh¨ova arbeta under speciella omst¨andigheter och vara mer flexibla. Dock begr¨ansade det den kommunikation som kan beh¨ovas n¨ar en grupp arbetar tillsammans. Gruppen valde att b¨orja arbeta med dagliga sprintm¨oten f¨or att kompensera f¨or den kontakt som f¨orlorades. Detta f¨orde projektgruppen n¨armre arbetet och medlemmarna fick chans att f¨olja varandras utveckling n¨armre.
6.4
K¨allkritik
K¨allor till arbetet har h¨amtats fr˚an olika typer av hemsidor och rapporter. Vid utvecklingen av metoden med voxelisering f¨or generering av nodgrafer har information, inspiration och kun- skap h¨amtats fr˚an diverse rapporter som arbetat med liknande problem. Dessa rapporter har sammanst¨allts av forskare inom omr˚adet och kan d¨arf¨or anses p˚alitliga. B˚ada l¨osningarna f¨or generering av nodgrafer anv¨ander sig mycket av linj¨ar algebra. Denna kunskap har h¨amtats fr˚an tidigare kurser projektgruppen arbetat med och kursb¨ocker, som kan anses tillf¨orlitliga. Infor- mation om det bibliotek (Assimp) och de verktyg som anv¨ants under projektets g˚ang har fr¨amst h¨amtats fr˚an den officiella dokumentation som finns tillg¨anglig. Detta har gjorts f¨or att f¨ors¨akra sig om trov¨ardigheten i vad dessa bibliotek och verktyg kan anv¨andas till. Ett bekymmer med officiella dokument skrivna av f¨oretaget eller organisationen som tagit fram verktyget ¨ar att de inte framh˚aller problem eller brister med produkten. Detta har projektgruppen tagit h¨ansyn till vid utvecklingen.
6.5
Framtida utveckling
En bieffekt av att gruppen bytt l¨osning till att arbeta med voxelisering ¨ar att ett tidigare baskrav inte l¨angre kan bekr¨aftas. Detta baskrav ¨ar att en projicering av b˚agen p˚a 3D-modellen ska visa att b˚agen aldrig ¨ar n¨armare en v¨agg i modellen ¨an 20 procent av bredden p˚a v¨agen. Den f¨orsta l¨osningen kom med en garanti att kravet var uppfyllt och d¨armed skrevs inga tester f¨or att bevisa det. Men voxeliseringsl¨osningen saknar denna garanti och kan d¨armed inte bekr¨afta att kravet ¨ar uppfyllt. Detta leder till att framtida arbete p˚a verktyget f¨orst och fr¨amst b¨or vara att kontrollera att detta baskrav fortfarande h˚aller.
Efter att detta baskrav blivit uppfyllt kan det framtida arbetet forts¨atta i tv˚a olika riktningar. Antingen fokuseras arbetet p˚a att minska nodantalet i korsningar, eller p˚a att uppfylla de tv˚a f¨oljande extrakraven:
• Extrakrav 1 - Processer f¨or att ¨overs¨atta 3D-modellerna ska l¨osas med multitr˚ading. • Extrakrav 2 - En b˚age mellan tv˚a noder ska kunna representeras av en Bezierkruva.
Utifr˚an m¨oten med kunden upplever gruppen att kunden anser att Extrakrav 2 ¨ar det viktigaste extrakravet. Detta d˚a det kravet skulle dra ned nodantalet avsev¨art. Det anser kunden ¨ar mer prioriterat ¨an att dra ned tiden att generera nodgrafen, vilket Extrakrav 1 g¨or.