discussion.tex

\chapter{Diskussion}
\label{cha:discussion}

\section{Resultat}
\label{sec:discussion-results}

% Finns det något i resultaten som sticker ut och behöver analyseras och kommenteras?
% Hur relaterar resultaten till det material som presenteras i teorikapitlet?
% Vad betyder teorin om betydelsen av resultaten, till exempel, vad betyder det att ett visst system har ett visst numeriskt värde i en användbarhetsbedömning, hur bra eller dåligt är det?
% Finns det något i resultaten som är oväntat baserat på litteraturgranskningen, eller är allt som man teoretisk skulle förvänta sig?

I detta avsnitt diskuteras de resultat som projektet kommit fram till.

\subsection{Lärdomar}

Att förbereda sig inför projekt med ordentliga förundersökningar och träningsuppgifter är definitivt något att ta med sig till kommande projekt. Det märktes i skillnaderna på hur lätt projektgruppen hade det med ROS och hur svårt gruppen hade det med PCL. Där alla gruppmedlemmar hade genomgått en grundlig utbildning i ROS men bara några få hade undersökt PCL men då inte särskilt noggrant. I framtiden kommer gruppen undersöka allt mer noggrant och vid tidsbrist dela upp undersökningarna mer så att allt undersöks grundligt av någon i gruppen istället för att alla undersöker ett område.

När projektgruppen i framtiden stöter på ett projekt som bygger vidare på existerande mjukvara eller hårdvara kommer ingen av oss glömma att testa och dokumentera testerna på det existerande systemet innan någon påbyggnad eller vidareutveckling kommer ske.

Vikten av att kunna uppskatta tiden olika aktiviteter tar är också något som gruppen tar med sig från projektet. Framförallt höll inte planeringen av undersökningarna inom PCL. Det var till stor del på grund av att PCL krävde mycket teoretiska förkunskaper för att kunna förstå hur de funktioner som PCL tillhandahöll ska användas. Det stora kravet på förkunskaper var inte uppenbart vid planeringen av undersökningarna och resterande aktiviteter fick hela tiden planeras om med hänsyn till dessa undersökningar. Därför kommer gruppmedlemmarna i framtida projekt att ta hänsyn till om de nödvändiga förkunskaper finns för att kunna genomföra projektet på det sätt som är planerat.

De rollspecifika dokument som skrevs i förstudien av projektet var bra då varje gruppmedlems erfarenhet inom deras specifika roll var varierande. Vissa gruppmedlemmar hade bra erfarenhet av rollen och visste hur de skulle gå tillväga. Andra gruppmedlemmar hade roller där de saknade eller hade väldigt lite erfarenhet inom de rollspecifika uppgifter som skulle genomföras. De rollspecifika dokumenten som skulle skrivas tvingade gruppmedlemmarna att sätta sig in i sin roll och snabbt få en uppfattning om vad som förväntades av dem. Det som gruppen kan ta med sig av denna erfarenhet är att tidigt i projekt tilldela uppgifter som tillhör den roll som projektmedlemmarna har för att de snabbt ska komma in i deras roll och få bättre insikt i vad som förväntas av dem inom projektet.

Erfarenheterna inom \textit{Slack} kommer bli användbara i det framtida arbetslivet och kommande projekt då det är ett vanligt förekommande verktyg inom kommunikation. Även \textit{Trello} är ett vanligt förekommande verktyg även om det finns en del annan mjukvara med liknande funktionalitet. Grundprincipen med att dela upp arbetet i aktiviteter och uppdatera statusen på dem är definitivt något gruppen kommer ta med oss. Vi lärde oss också att försöka göra aktiviteterna så små som möjligt och involvera hela gruppen i processen att skapa aktiviteter. Det resulterade i en bättre användning av \textit{Trello} samtidigt som det blev lättare att komma igång med arbetet.

Under projektets gång har projektgruppen använt oss av kodgranskning, även om några i grupppen var lite skeptiska till att någon måste läsa deras kod och godkänna den innan den togs in i den slutgiltiga kodbasen. Men genom att läsa varandras kod har gruppmedlemmarna lärt sig nya saker och förbättrat koden som gruppmedlemmarna skriver. I programmering blir man aldrig fullärd och vetskapen om att läsa andras kod kan vara väldigt lärorikt är definitivt något vi tar med oss. Det kommer vara till stor hjälp i vår utveckling som utvecklare.


\subsection{Vad återstår för att uppnå fullt värde för kunden?}
Det är en definitionsfråga. Om man definierar \textit{fullt värde för kunden} som det värde som kunden förväntade sig innan projektet eller i projektets tidiga skede krävs minst ett nytt projekt, vars mål är att lösa problemen med TreeD och sedan rekonstruera produkten från detta projekt så att den fungerar som den skulle innan omförhandlingen av kraven. Om man istället definierar "fullt värde för kunden" som det värde som kunden förväntar sig efter omförhandlingen av kraven skulle gruppen hävda att väldigt lite återstår. Meshgenereringen blev inte så automatiserad som gruppen hade hoppats och kunden förväntat sig, men detta beror mest på svårigheter att implementera en sådan process helt automatiskt då flera olika fall kan uppstå. Målet med projektet var att använda existerande algoritmer och inte skapa nya eftersom det hade tagit mycket längre tid och krävt helt andra kunskaper. Utöver detta tycker projektgruppen att kunden har fått ut det värde som kan förväntas av projektet efter omförhandlingen av kraven.


\subsection{Tidigare projekt}
Något som gruppen har tagit med sig från de tidigare projekt gruppmedlemmarna har genomfört är tydlig struktur på interna dokument samt gruppkontrakt. Strukturen på dokumenten har hjälpt till att hålla en hög standard även på interna dokument, det vill säga dokument som enbart är till för gruppen själva. Gruppkontraktet var uppskattat i tidigare projekt och ger tydliga riktlinjer för bland annat vad som förväntas av gruppens medlemmar, hur konflikter ska lösas och hur gruppen ska arbeta för att nå projektmålet.

Något som förbättrades från tidigare projekt är kommunikationen. Under vissa projekt som gruppens medlemmar tidigare genomfört har kommunikationen ibland varit bristande. Det har ibland varit svårt att få tag i medlemmar eller svårt att få en överblick av kommunikationen då många olika kommunikationskanaler använts. Projektgruppen löste det snabbt genom att använda \textit{Slack} för all kommunikation inom gruppen och delade upp kommunikationen i olika kanaler beroende på ämne. Gruppen såg också till att allas telefonnummer fanns tillgängliga ifall man behövde kontakta någon omedelbart.


\subsection{Alternativa implementationssätt}
Då projektets krav behövde omförhandlas långt in i projektet togs två olika system fram. Det första systemet som togs fram var byggt på ROS och hade en tät koppling till det tidigare systemet även om det skulle kunna användas fristående med annan hårdvara. Det andra systemet var inte lika beroende på hårdvaran som det första utan läser istället in punktmoln från filer på datorn. Det är inte heller byggt på ROS utan är implementerat helt med hjälp av klasser i C++. Båda de implementerade systemen uppfyller i princip samma systemanatomi, se figur \ref{fig:system_anatomy}, med den enda skillnaden att det andra systemet inte kan skanna 3D-objekt utan endast läsa in punktmoln från filer.

För att registrera punktmoln finns det många olika algoritmer och sätt att implementera dessa. I slutändan använde gruppen ICP då den gav bäst resultat och har bra stöd i PCL. Det finns dock flera alternativa algoritmer för registrering. Detta utforskas mer i Michael Karlssons individuella utredning, se kapitel \ref{cha:indiv-report-karlsson}.

Även för meshgenerering finns fler alternativa metoder. I vårt system används algoritmen \textit{Poisson surface reconstruction} då det är en vanlig algoritm som fungerar bra i många fall. Även den har bra stöd i PCL. På den här punkten skulle en hel del kunna förbättras, antingen genom att använda andra algoritmer eller genom att implementera användandet av algoritmen bättre, exempelvis genom att justera de parametrar som sätts.


\section{Metod}
\label{sec:discussion-method}
Som tydligt kan ses i denna rapport har inte projektet gått som det var planerat. Projektgruppen har under projektets gång (speciellt under projektets andra halva) varit kritiska över hur vi gått tillväga. I avsnitt \ref{cha:results_experiences} listas de erfarenheter som har dokumenterats under projektets gång. Bland dessa finns erfarenheter om vad som borde ha gjorts annorlunda. Gruppen borde ha testat det befintliga systemet, TreeD, mer rigoröst tidigt istället för att lita på att det fungerade felfritt.

När det gäller metoden som har använts i projektet anser projektgruppen att själva kärnan, eller idén bakom metoden har varit bra men att några av detaljerna av implementationen av denna metod har varit mindre bra. Som grupp håller alla med om att gruppen borde fokuserat mindre på ROS i början av projektet. I efterhand tycker gruppen att tanken var bra, att alla gjorde handledningsexempel och en kodutmaning tillsammans stärkte gruppens sammanhållning och skapade en bra anda. Gruppen borde istället fokuserat på till exempel PCL eller registrering av punktmoln eftersom systemet, både innan och efter omförhandlingen, inte var så beroende av ROS som vi trodde att det skulle vara.

Efter förstudiefasen och iteration 1 började fler och fler problem uppstå med projektet. De flesta av dessa problem hade sin grund i TreeDs system. Detta gjorde att gruppen mindre och mindre höll fast vid den metod som använts tidigare och sammanhållning blev sämre.

Något som förändrades genom projektets gång var längden på aktiviteterna, det vill säga deras omfattning mätt i tid. De stora undersöknings- och efterforskningsaktiviteterna som gruppen skapade i början var svåra att överblicka och få en uppfattning om hur långt arbetet hade kommit. Det förändrades då gruppen valde att skapa mindre aktiviteter när problemet med de större upptäcktes. Hade gruppen från början gjort mindre och mer lättöverskådliga aktiviteter hade eventuellt undersökningarna i början gått bättre och inte påverkat tidsplanen så negativt som de gjorde.

\section{Arbetet i vidare sammanhang}
\label{sec:work-wider-context}

Systemet är tänkt att användas i akademiska syften och därför ses inga etiska aspekter relaterade till projektet. Nedan beskrivs kopplingen mellan projektet och de samhälleliga aspekterna samt vilka specifika förbättringspunkter det finns till vårat system med avseende på hållbar utveckling.

\subsection{Hållbar utveckling}
\label{disc:hållbar_utveckling}
Ett system för 3D-kopiering har många positiva effekter på samhället. Systemet gynnar framförallt miljön eftersom att tillverka en önskad produkt istället för att köpa en fabrikstillverkad motsvarighet sparar avsevärt på naturens tillgångar. Dels kommer 3D-kopieringssystemet att använda mindre energi och dessutom kommer transporterna till och från affären att minska, vilket leder till minskade koldioxidutsläpp. Kreiger och Pearce  \cite{kreiger2013environmental} har gjort en studie där de skriver ut 3D-produkter i plast och jämför kostnaden för att tillverka produkter av plast i en fabrik. Med kostnaden menas den energi som går åt från råmaterial till färdig produkt samt kostnaden som går åt för transport. Det visar sig att tillverka en produkt i en 3D-skrivare kräver mellan 41-64 \% mindre energi än att fabrikstillverka produkten. Förklaringen till detta är att produkter som skrivs ut i en 3D-skrivare kan göras mer ihåliga och således kräver de också mindre material.

Det finns dessutom relaterade studier som visar att det blir billigare att skriva ut en produkt i en 3D-skrivare istället för att köpa en fabrikstillverkad \cite{wittbrodt2013life}. Det här främjar samhället i positiv beaktning eftersom det helt enkelt blir billigare för konsumenter att införskaffa sig de produkter de önskar.

\subsection{Specifika förbättringspunkter till vårt system}
Vårt system för 3D-kopiering är som tidigare nämnts ett generellt bra system för att främja hållbar utveckling. Det finns däremot en del aspekter som skulle kunna gjorts annorlunda vid systemets uppbyggnad för att ytterligare främja hållbar utveckling. För att utveckla detta har gruppen valt att titta på hur våra krav framställdes genom att besvara dessa frågor:

\begin{itemize}
	\item Vad skulle vi kunna göra annorlunda i kravprocessen?
	\item Vad har vi tagit hänsyn till i kravprocessen?
	\item Hur kan vi bedöma de krav vi satt på systemet med hållbar utveckling i åtanke?
\end{itemize}

Vid framställning av kraven till systemet fanns det inga tankar på att ta fram krav som främjar hållbar utveckling. Detta berodde på att ingen i projektgruppen hade erfarenheter från hållbar utveckling tidigare och således tänkte inte någon på det. Vid framtagning av krav till systemet har alltså ingen hänsyn tagits till att främja hållbar utveckling. Det som har tagits hänsyn till i kravprocessen är endast funktionaliteten av systemet. Att utveckla icke-funktionella krav för att främja hållbar utveckling är något som gruppen kunde ha gjort annorlunda. Det är också ett bra tillvägagångssätt enligt Raturi et al. \cite{raturi2014developing}.

En förbättring som gruppen kunde ha gjort är att systemet kunde ha haft ett icke-funktionellt krav att systemets beräkningar får ta en viss maximal tid. Detta är bra för energi- och miljösynpunkt eftersom hög processoranvändning under en lång tid leder till hög energiförbrukning för systemet.

Det finns även en relation mellan hur systemets energianvändning påverkas av hårdvaran i systemet. Den största energianvändande komponenten är processorn och därför skulle systemet även kunna ha ett icke-funktionellt krav att optimera processoranvändningen. Detta leder till att energianvändningen för systemet minskar vilket också är bra ur miljösynpunkt. Enligt Fan et al. \cite{fan2007power} ökar energiförbrukningen linjärt med processoranvändningen vilket inte är helt rättvisande och givetvis beror det på vilken processor som används.

För 3DCopys system innebär det här att gruppen skulle vilja kombinera de två aspekterna körningstid och processoranvändning till ett gemensamt icke-funktionellt krav. En kombination av dessa innebär att vi som grupp skulle behövt göra en studie över hur vi kan optimera processoranvändningen med avseende på energiförbrukning samtidigt som systemet inte får alltför lång körtid. Det optimala ur energisparningssynpunkt kanske skulle vara att låta systemet använda 70 \% av processorn och istället få lite längre körtid. Detta är någonting som gruppen skulle kunna undersökt i förstudiefasen för senare användning till kravprocessen.

För att bedöma de krav som vi har med hållbar utveckling i åtanke kommer endast de krav som inte berör kärnfunktionaliteten att bedömas, eftersom de är nödvändiga för systemets funktionalitet. Andra krav bedöms ur energisynpunkt, det vill säga om koden är tillräckligt optimerad för att uppfylla kravet eller om det blir för tungt beräkningsmässigt som gör att kravet inte uppfylls. Det skulle även vara möjligt att sätta upp icke-funktionella krav med avseende på det sociala området som gör att användaren känner sig tillfredsställd med produkten och på så vis bidrar till samhället. Detta bedöms genom att testa systemet med några användare och se huruvida det uppfyller användarens förväntningar eller inte.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% lorem.tex ends here