användes inte systemanatomin i någon större grad eftersom systemet var simpelt nog för utvecklarna att hålla koll på modulerna utan att använda systemanatomin. Vid slutet av pro- jektet uppdaterades dock systemanatomin för att ge en tydligare och mer korrekt bild av systemet.
5.2.4
Tekniska verktyg
I följande lista utvärderas de valda tekniska verktygen.
• Trello En tavla på Trello användes för att lägga upp kort som beskrev vad varje pro- jektmedlem gjorde för tillfället. Under faserna som bestod av dokumentredigering an- vändes detta främst till att lista saker som behövde korrigeras i de olika rapporterna och för att efterfråga granskning av dokumenten. Som mest användbart var det dock under utvecklingsfasen, då varje projektmedlem lade upp kort när de påbörjade arbetet på ett nytt moment, och när en pull request gjordes lades ett kort upp i en lista för att efterfråga kodgranskning. Sammantaget var Trello ett användbart och effektivt verktyg för uppdelning och koordinering av arbetet.
• Discord Discord har använts som projektgruppens primära kommunikationsmedel. Positiva aspekter av detta verktyg är enkel uppsättning av olika kanaler för olika syften samt att notifikationer skickas när meddelanden skrivs. Möjligheten för röstkommuni- kation har även uppskattats. En negativ aspekt med Discord är att textkanalerna inte tillåter att trådar skapas med kommentarer till specifika inlägg. Detta gör att kanalerna kan bli svårlästa om flera diskussioner sker samtidigt.
• Sharelatex För att skriva de dokument som ska lämnas in har onlineverktyget Share- latex använts. Positivt med detta är att många personer kan redigera samma LaTeX- dokument i realtid, men negativt är att detta gör att personer kan behöva vänta på varandra innan texten kan kompileras och ändringarna i dokumentet visas.
• Google Drive För dokument som inte ska lämnas in, exempelvis dagordningar, mö- tesprotokoll och andra anteckningar, har Google Drive och relaterade tjänster använts. Detta har fungerat väl eftersom alla dokument blir lättåtkomliga, redigerbara av fle- ra personer i realtid samt saknar de kompileringssvårigheter som finns i ShareLaTeX. Google Drive planerades även att användas för att versionshantera dokument skrivna i Sharelatex. Detta användes endast ett fåtal gånger.
• SqlDbx I analysväg har SqlDbx varit ett användbart verktyg för att studera kundens databas. Detta verktyg tillhandahåller enkel åtkomst till en databasserver, ger en över- blick över vilka tabeller som finns i databasen samt tillåter sökfraser och deras resultat att enkelt skickas mellan klient och server. SqlDbx innehåller även ett kraftfullt verktyg för att se differensen mellan resultatet för två sökfraser.
5.3
Översikt över individuella bidrag
I detta avsnitt presenteras en översikt över de individuella bidragens syfte, metod och resul- tat. Bidragen hittas i del två av denna kandidatrapport.
5.3.1
Undersökning av hur data ska hanteras för maskininlärning i Tensorflow
av Alfred Hagberg
Syftet med undersökningen är att få en förståelse hur data ska hanteras av olika former för att få en maskinilärningsalgoritm att fungera på ett bra sätt. Undersökning går översiktligt
5.3. Översikt över individuella bidrag
genom hur artificiella neurala nätverk fungerar samt hur det implementerats i ramverket Tensorflow.
Undersökningen genomförs både genom en litteraturstudie av tidigare upptäckter samt en egen empirisk studie där olika metoder testas för inmatning till neuronnätverk i Tensorflow. Resultatet värderas genom så kallad korsvalidering där en datamängd delas upp i k del- mängder och för varje del tränas nätverket på de k ´ 1 andra delmängderna och testas på den kvarstående delmängden. Resultatet blir en procentsats på hur ofta nätverket har rätt. Resultaten visar att man kan få stora förbättringar på nätverkets korrekthet om man använder Tensorflows indatakolumn bucketized column jämfört med numeric column. Det visar också att man behöver träna nätverket mycket mindre för att få en hög korrekthet med det. Utöver det så kan man också se att stora prestandaförbättringar kan få om man använder sig av indatakolumnen embedding column istället för indicator column, då det tar mycket mindre tid för träning och evaluering av nätverket.
5.3.2
En fördjupad granskning av utvärderingsmetriker för maskininlärda
klassificerare av Eric Nylander
Inom klassificering är det nödvändigt att testa effektiviteten av algoritmerna som används samt dess implementation. Detta följer från att det är omöjligt att veta i förväg vilken algoritm som är mest lämpad till ett givet problem. Med vissa algoritmer, så som neurala nätverk är det även omöjligt att veta i förväg det optimala formatet på nätverket. Målet med en klassificerare är att den ska generalisera väl, men testning av hur väl en algoritm generaliserar är ett svårt problem.
Av den anledningen undersöks och jämförs några olika metriker för utvärdering av klassifice- rare. Detta görs genom en litteraturstudie som undersöker möjliga utvärderingsmetriker och dess rimliga tillämpningsområden. Dessutom görs en metautvärdering av utvärderingarna av DNN- och kNN-implementationerna som gjordes i detta projekt som en direkt undersök- ning av dessa metoder.
5.3.3
En undersökning av pull-baserad versionshantering av Henrik Andersson
Pull-baserad versionshantering är namnet för den metod som används i detta projekt. Detta är en metod som växer snabbt inom utvecklandet av öppen mjukvara samt inom industrin. Denna metod är baserad på Git samt webbhotell som Github med funktioner för fork och pull request. Syftet med undersökningen är att få en klar bild av fördelarna och nackdelarna re- laterade till pull-baserad versionshantering. Undersökningen tar även upp hur pull-baserad versionshantering har påverkat arbetet under kandidatprojektet.
Resultat insamlas genom en undersökning om hur metoden används i ”open source”-projekt på Github samt genom ett frågeformulär inom projektgruppen.
Resultatet visar att den undersökta metoden gav en positiv inverkan på kandidatporjektet. Projektmedlemmarna tyckte att metoden förenklade samarbetet och gjorde kodsammanfog- ningar enklare. Undersökningen visar också att många av de fördelar pull-baserad versions- hantering har över centraliserade metoder är samma som för andra decentraliserade metoder. Den stora skillnaden pull-baserad utveckling bidrar med för öppna mjukvaruprojekt är att metoden gör samarbetet mellan utvecklare enklare utan att det skapar en negativ inverkan på kodbidragslatens.
5.3. Översikt över individuella bidrag
Viktigt att nämna är att undersökningen inte tar upp egenskaper hos pull requests som inte berör versionshantering och kodsammanfogningar, så som kontinuerlig integration. Dessa tas delvis upp i kapitel G.
5.3.4
Anpassning av k-nearest neighbor till produktmatchning av Jonathan
Lundgren
K-nearest neighbor är en av algoritmerna som implementerades i projektet på grund av dess enkelhet och anpassningsbarhet. För att algoritmen ska fungera så bra som möjligt finns dock många anpassningar som kan göras, särskilt när det gäller vilka avståndsfunktioner som an- vänds och hur informationen om produkten bearbetas. Denna del av rapporten utvärderar algoritmens lämplighet överlag för problemområdet och utvärderar olika avståndsfunktio- ner genom testning. Slutsatserna som dras är att vissa förbättringar kan nås genom enkla an- passningar, samt att det går att uppnå rimligt hög matchningssäkerhet med algoritmen, men att tillräcklig förbättring när det gäller körtid skulle kräva mer komplexa vidareutvecklingar som då skulle kunna undergräva algoritmens styrka i att vara enkel att implementera. Trots detta kan det fortfarande finnas värde i att implementera algoritmen, eftersom den kan vara en bra utgångspunkt och referenspunkt vid början av utvecklingen samt användas som ett komplement när extra säkerhet eftersträvas för matchningen av ett mindre antal produkter.
5.3.5
Implementerar mjukvaru- och datateknik studenter idag modularitet i
projekt? av Leif Eriksson
Modularitet är ofta förslaget som ett sätt att göra kod underhållsvänligare och minska hur mycket som behövs skrivas om vid en systemförändring. I och med dessa två påståenden är det av intresse att veta om studenter idag lär sig om modularitet och om de faktiskt använ- der det i praktiken. För att svara på dessa frågor delades en enkät ut till samtliga kandidat- projektsgrupper, samt så tillfrågades examinatorn och studierektorn för att se om deras bild överensstämde med resultatet av enkäten.
Inga konkreta resultat kan på grund av problem med enkäten tyvärr dras av denna. Dock tyder enkätens resultat och de två tillfrågade personernas åsikter på att modularitet används av studenter som en metod för att bland annat strukturera system.
5.3.6
Teamledaren som en coachande ledare och samordnare i ett agilt projekt av
Mustaf Musse
Under projektutvecklingen har teamledaren ett viktigt roll i projektgruppen. I detta indivi- duella bidrag utfördes en undersökning där teamledarens roll under projekts gång analyse- rades.
Syftet med rapporten är att förtydliga rollen som teamledaren har i sådana små projekt som kandidatarbetet samt hur en teamledare kan på bästa sätt leda en grupp genom att vara en bra coachande ledare och samordnare. Dessutom jämför rapporten hur teamledarna i de olika projektgrupperna har uppfattat rollen.
Metoderna för att samla data för rapporten är egna observationer under projektets gång samt läsning av olika artiklar om ämnet.
Resultatet visar hur teamledaren har agerat under olika faser av projektet och vilka egen- skaper som teamledaren hade för att coacha och samordna projektgruppen. Dessutom tar resultatet upp de viktigast egenskaper som framtida projektgrupper kan tänka sig innan de väljer teamledare.
5.3. Översikt över individuella bidrag
5.3.7
Undersökning av testning med kontinuerlig integration av Robin
Andersson
Kontinuerlig integration är ett sätt att utveckla programvara genom att all kod testas konti- nuerligt under utvecklingen. Detta genom att gruppen exempelvis har ett centralt versions- hanteringsrepositorium där all kod samlas, och om kod läggs upp i repositoriumt testas den automatiskt av en tjänst som exempelvis Travis CI.
Syftet med undersökningen är att ta reda på om projektgruppen har använt sig av kontinu- erlig integration som den är beskriven teoretiskt eller om projektgruppen endast har använt sig av automatiska tester.
Undersökningen genomfördes genom en sökning efter källor som beskriver teorin bakom kontinuerlig integration och sedan jämfördes teorin med projektgruppens praktiska arbete. Resultatet visar att projektgruppen har använt sig av kontinuerlig integration som det är definierat generellt, men jämförs projektgruppens arbete mot ett antal specifika tillämpningar så har projektgruppen inte använt sig av kontinuerlig integration. Detta innebär alltså att olika källor beskriver kontinuerlig integration på olika sätt och därmed beror resultatet på vilka källor som har valts för att beskriva teorin bakom kontinuerlig integration.
6
Diskussion
I detta kapitel diskuteras först det uppnådda resultatet, sedan diskuteras de valda metoderna och slutligen sätts arbetet i ett större sammanhang där det jämförs mot olika aspekter.