• No results found

Maskininlärning för automatisk matchning av produkter

N/A
N/A
Protected

Academic year: 2021

Share "Maskininlärning för automatisk matchning av produkter"

Copied!
117
0
0

Loading.... (view fulltext now)

Full text

(1)

Linköpings universitet

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

Vårterminen 2018 | LIU-IDA/LITH-EX-G--18/015--SE

Maskininlärning för

automatisk matchning av

produkter

Machine learning for automatic product matching

Henrik Andersson

Robin Andersson

Leif Eriksson

Alfred Hagberg

Jonathan Lundgren

Mustaf Musse

Eric Nylander

Handledare : Simon Mehari Examinator : Kristian Sandahl

(2)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admi-nistrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstan-ces. 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 unchang-ed for non-commercial research and unchang-educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity 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/.

c Henrik Andersson Robin Andersson Leif Eriksson Alfred Hagberg Jonathan Lundgren Mustaf Musse Eric Nylander

(3)

Sammanfattning

Denna rapport behandlar det kandidatarbete som har utförts av sju studenter från civilin-genjörsprogrammen datateknik och mjukvaruteknik på Tekniska högskolan vid Linköpings universitet. Projektets mål var att ta fram ett system som via maskininlärning automatiskt skapade matchningar mellan företagets interna basprodukter och produkter från diverse le-verantörer. Beställningen av systemet gjordes av Byggvarulistan i Sverige AB.

Det utvecklade systemet ska lösa problemet företaget hade med att behöva göra alla match-ningar manuellt. Systemet innehåller en maskininlärningsdel som utför matchmatch-ningarna och ett administrationsgränssnitt för att korrigera och acceptera dessa matchningar. Utvecklingen av systemet har behövts anpassas till de rådande förutsättningarna med visst brus i kundens databas. Graden av nytta som kunden kommer utvinna från systemet beror därför delvis på hur kvaliteten på databasens innehåll kan förbättras för att ge bättre förutsättningar till matchningssystemet.

Rapporten beskriver hur utvecklingen av systemet har skett samt vad det slutgiltiga systemet blev. Detta gjordes utifrån en analys av de använda utvecklingsprocesserna och det slutgil-tiga systemet i ett bredare sammanhang. Det finns även sju individuella bidrag från vardera projektmedlem där denne utvärderar ett arbetsmetod, algoritm, roll eller liknande relaterat till projektet.

(4)

Tillkännagivanden

Detta kandidatarbete var en väldigt svår process, inte bara projektet utan också att dokumen-tera allt noggrant och skriva färdigt all dokumentation som behövdes. Det var inte bara en utmanande men också en lärorik process där vi lärde oss mycket, inte minst att leverera alla dokument och produkt i tid men också hur viktigt det är att hjälpa varanda och fungera som ett team.

Härmed vill vi rikta ett stort tack till alla som hjälpte oss under de intensiva veckorna där vi kämpade mot alla odds att bli klara med kandidatarbetet.

Vi vill också tacka Patrik Dahlén, chief technology officer (CTO) på Byggvarulistan AB som var vår kontaktperson. Patrik har varit hjälpsam och generös under hela projektets gång och försåg oss med de resurser som krävdes för att utföra projektet.

Sist men inte minst vill vi rikta ett jättestort tack till Simon Mehari, handledare, och Kristian Sandahl, examinator, för deras konstruktiva kritik och råd under projektets gång.

(5)

Innehållsförteckning

Sammanfattning iii Tillkännagivanden iv Innehållsförteckning v Figurer viii Tabeller ix Ordlista x Förkortningar xi

I

Gemensamma erfarenheter och diskussion

1

1 Inledning 2 1.1 Motivering . . . 2 1.2 Syfte . . . 2 1.3 Mål . . . 3 1.4 Frågeställning . . . 3 1.5 Begränsningar . . . 3 2 Bakgrund 5 3 Teori 7 3.1 Vektyg . . . 7 3.2 Algoritmer . . . 8 3.3 Utvärdering av algoritmer . . . 10 3.4 Utvecklingsprocesser . . . 10 4 Metod 12 4.1 Projektorganisation . . . 12 4.2 Utvecklingsmetod . . . 13 4.3 Utvecklingsverktyg . . . 16

4.4 Metod för att fånga erfarenheter . . . 18

5 Resultat 19 5.1 Systembeskrivning . . . 19

5.2 Gemensamma erfarenheter . . . 24

5.3 Översikt över individuella bidrag . . . 25

(6)

6.1 Resultat . . . 29 6.2 Projektorganisation . . . 31 6.3 Planering . . . 31 6.4 Utveckling . . . 33 6.5 Tester . . . 34 6.6 Dokument . . . 35 6.7 Versionshantering . . . 36

6.8 Metod för att fånga erfarenheter . . . 36

6.9 Källkritik . . . 37

6.10 Förbättringar från tidigare projekt . . . 37

6.11 Viktigaste lärdomar inför framtiden . . . 38

6.12 Arbetet i ett vidare sammanhang . . . 38

7 Slutsatser 40 7.1 Hur kan ett system för automatchning av byggvaruprodukter implementeras för att skapa värde för kunden? . . . 40

7.2 Vilka erfarenheter kan dokumenteras från projektet som kan vara intressanta för framtida projekt? . . . 40

7.3 Vilket stöd kan fås genom att skapa och följa upp en systemanatomi? . . . 41

II Individuella bidrag

42

A Undersökning av hur data ska hanteras för maskininlärning i Tensorflow av Al-fred Hagberg 43 A.1 Inledning . . . 43 A.2 Metod . . . 43 A.3 Teori . . . 44 A.4 Undersökning . . . 47 A.5 Resultat . . . 48 A.6 Diskussion . . . 49 A.7 Slutsatser . . . 49

B En fördjupad granskning av utvärderingsmetriker för maskininlärda klassifice-rare av Eric Nylander 51 B.1 Syfte och motivering . . . 51

B.2 Problemformulering . . . 51

B.3 Frågeställning . . . 52

B.4 Avgränsningar . . . 52

B.5 Teori . . . 52

B.6 Metod . . . 55

B.7 Resultat och diskussion . . . 56

B.8 Slutsatser . . . 57

C En undersökning av pull-baserad versionshantering av Henrik Andersson 59 C.1 Inledning . . . 59

C.2 Bakgrund och teori . . . 60

C.3 Metod . . . 61

C.4 Resultat . . . 62

C.5 Diskussion . . . 64

C.6 Slutsats . . . 65

D Anpassning av K-nearest neighbor till produktmatchning av Jonathan Lundgren 66 D.1 Inledning och syfte . . . 66

(7)

D.2 Bakgrund . . . 66 D.3 Teori . . . 67 D.4 Metod . . . 68 D.5 Resultat . . . 69 D.6 Diskussion . . . 70 D.7 Slutsatser . . . 71

E Implementerar mjukvaru- och datateknikstudenter idag modularitet i projekt? av Leif Eriksson 73 E.1 Inledning och syfte . . . 73

E.2 Bakgrund . . . 74

E.3 Metod . . . 74

E.4 Resultat . . . 74

E.5 Diskussion . . . 77

E.6 Slutsats . . . 78

F Teamledaren som en coachande ledare och samordnare i ett agilt projekt av Mu-staf Musse 79 F.1 Inledning . . . 79 F.2 Bakgrund . . . 80 F.3 Teori . . . 80 F.4 Metod . . . 82 F.5 Resultat . . . 82 F.6 Diskussion . . . 83 F.7 Slutsats . . . 84

G Undersökning av testning med kontinuerlig integration av Robin Andersson 85 G.1 Inledning . . . 85 G.2 Bakgrund . . . 85 G.3 Teori . . . 86 G.4 Metod . . . 87 G.5 Resultat . . . 87 G.6 Diskussion . . . 90 G.7 Slutsatser . . . 91 Litteratur 93 Bilagor 98

(8)

Figurer

5.1 Översikt av systemets moduler . . . 19

5.2 Systemanatomin för systemet . . . 20

5.3 Graf över antal matchningar vid angiven säkerhet för KNN . . . 21

5.4 Graf över faktisk säkerhet mot KNN angiven säkerhet . . . 21

5.5 Precision-Recall graf för KNN samt för DNN, här kallat TF . . . 22

5.6 Graf över antal matchningar vid angiven säkerhet för DNN, här kallat TF. . . 23

5.7 Graf över faktisk säkerhet mot DNN, här kallat TF, angiven säkerhet. Visar tydligt att majoriteten av matchningarna ligger vid hög accuracy. . . 23

A.1 Exempel på struktur av ett artificiellt neuronnätverk . . . 45

A.2 Struktur på Tensorflows olika implementationer av DNN . . . 46

A.3 Hur feature columns integreras med DNN i Tensorflow . . . 47

A.4 Korrekthet för modellerna efter antal träningssteg . . . 49

C.1 Rekommenderat arbetsflöde . . . 63

E.1 Pajdiagram över svarsresultatet för frågan "Har modularitet varit på tal under projektet?" . . . 75

E.2 Pajdiagram över svarsresultatet för frågan "Har modularitet använts under pro-jektet?" . . . 76

E.3 Pajdiagram över svarsresultatet för frågan "Har modularitet minskat mängden ar-bete vid en systemförändring? Eller för att testa olika alternativ?" . . . 76

E.4 Pajdiagram över svarsresultatet för frågan "Hade modularitet kunnat minska mängden omarbete?" . . . 77

(9)

Tabeller

4.1 Medlemsroller . . . 12

A.1 Modellernas körtider . . . 49

B.1 En 3-klass klassificerares förvirringsmatris . . . 53

B.2 Binär klassificerare . . . 53

C.1 Svar till C.3 . . . 64

D.1 Test av olika värden på K . . . 70

D.2 Test av olika avståndsfunktioner för numeriska värden . . . 70

D.3 Test av olika avståndsfunktioner för produktnamn . . . 70

D.4 Test av olika avståndskonstanter för inkompatibla attribut . . . 70

E.1 Frågor och svarsalternativ i utdelad enkät . . . 75

G.1 Fowlers tillämpningar . . . 88

G.2 Stolbergs mål . . . 90

(10)

Ordlista

accuracy En klassificerares angiven sannolikhet att en specifik klass passar för en instans

basprodukt En generaliserad representation av en fysisk produkt med definierade specifi-kationer

branch En funktion i vissa versionshanteringssystem som tillåter avgrening från repositori-ets nuvarande gren

code review En digital genomgång av kod på Github. Personen som utför granskningen väl-jer om koden är godkänd eller behöver ändras för att få sammanfogas med repositori-umt

commit En handling som gör en uppsättning kodändringar permanenta i ett repositorie

continuous integration En utvecklingsmetod där man kontinuerlig testar och integrerar skriven kod

djupa neurala nätverk En mängd algoritmer som använder skiktade nodstrukturer för ma-skininlärning

driver En driver används under testning. Denna härmar exekveraren av modul eller funk-tion.

förgrena Verb för skapandet av en fork

fork En funktion på Github som tillåter andra användare att skapa en identisk kopia av ett annat repositorium

grundkopia En kopia av ett repositorium som inte innehåller fullständig historik eller annan metadata

klassificerare En funktion som binder en omärkt datainstans från ett dataset till en bemärk-ning utifrån interna datastrukturer

klassificering Att identifiera vilken kategori utfifrån en mängd kategorier som en ny obser-vation tillhör

leverantör Tredjepart som säljer eller levererar en tjänst eller produkt

leverantörsprodukt En produkt ifrån en leverantör. Beskrivs av attribut tagna ifrån leveran-törens webbsida

matchning En 1:1 koppling mellan en leverantörsprodukt och en basprodukt.

mock Ett objekt som simulerar ett annat objekt

precision Procentuellt mått över hur stor del av totala gjorda antalet matchningar som är korrekta

projektmedlem En av studenterna som arbetar med projektet Maskininlärning för automa-tisk matchning av produkter kursen Kandidatprojekt i programvaruutveckling

pull request En funktion på Github som tillåter bidrag samt ändring av kod mellan reposi-torier

(11)

recall Procentuellt mått över hur stor del av samtliga möjliga korrekta matchningar som al-goritmen har funnit

repositorium En lagringsplats för programkod som hanteras med hjälp av versionshante-ringsprogram

riktighet Antalet korrekta klassificeringar som en klassificerare gör genom totala mängden klassificeringar som en klassificerare gör

sprint En kortare tidsperiod, oftast endast någon vecka, med mätbara mål som ska vara kla-ra vid periodens slut. Börjar med planering och slutar med en sprint review där man evaluerar sprintens resultat

stub En stub används under testning då en modul ej blivit implementerad. Denna härmar returninging ifrån en modul eller funktion som inte har blivit implementerad.

subkutan (Som befinner sig) under huden

supervised machine learning Ett maskininlärningsramverk som binder utdata till indata med hjälp av utdata/indata exempelpar

TeX Typsättningsspråk

tråd En samlad kommunikation om ett ämne som visas av en textkommunikationstjänst

utvärderingsmetrik Ett mätetal som effektivt framställer värdet av en metod

voice over Internet protocol En metod för leverans av röstkommunikation över nätet

Förkortningar

ANN artificiellt neuronnätverk

AUC ytan under en ROC-kurva (eng. area under ROC curve)

CI continuous integration. Ordlista: continuous integration

CTO chief technology officer

DNN djupa neurala nätverk. Ordlista: djupa neurala nätverk

FPR graden av falska positiva värden (eng. false positive rate)

KA konfigurationsansvarig

kNN k-nearest neighbors

ROC receiver operating characteristic

SML supervised machine learning. Ordlista: supervised machine learning

TF Tensorflow

TPR graden av sanna positiva värden (eng. true positive rate)

(12)

Del I

(13)

1

Inledning

Det här kandidatarbetet utfördes av en projektgrupp bestående av sju civilingenjörsstuden-ter i årskurs tre, varav fyra av dem läser datateknik och tre av dem läser mjukvaruteknik. Projektet pågick under vårterminen 2018 vid Tekniska högskolan vid Linköpings universitet.

1.1

Motivering

I dagsläget är det svårt för byggbranchen att hitta ett sätt att jämföra produkter från olika byggvaruhus. Detta beror framförallt på att det inte finns centraliserade artikelnummer eller något större samarbete mellan varuhusen. När privatpersoner ska hitta produkter till bygg-projekt finns problem i att produkterna de letar efter kan ha olika namn i olika butiker eller att specifikationerna för själva produkterna är oklara. Trots detta är byggvaror generaliserbara och varierar inte stort mellan olika varuhus.

För att lösa dessa problem började Byggvarulistan i Sverige AB att samla en stor mängd data i en databas. I denna databas har de definierat egna basprodukter som de matchar mot olika leverantörers produkter. I dagsläget sker en stor del av denna matchning manuellt. Företaget är därför i stort behov av att automatisera denna matchning. Detta för att fler produkter ska kunna läggas in snabbare i deras databas, vilket ökar värdet av deras tjänst.

1.2

Syfte

Detta avsnitt ger en överblick över rapportens och projektets syfte.

1.2.1

Rapportens syfte

Del 1: Gemensamma erfarenheter och diskussion skrivs som en undersökning av projektet i syfte att utvärdera arbetet och arbetsprocessen med undersökning av arbetet i ett vidare samman-hang. Detta görs för att försörja projektmedlemmarna med en reflekterande genomgång av arbetet som gjordes under terminen.

Del 2: Individuella bidrag är ett kompletterande moment som ger varje projektmedlem erfaren-heten av en undersökning på egen hand med tillhörande rapport.

1.2.2

Projektets syfte

Syftet med projektet var att framställa en lösning till uppdraget som kunden lade fram. Ge-nom detta gavs projektmedlemmarna praktisk erfarenhet av att arbeta i projekt mot en kund under verkliga förutsättningar. Projektgruppen skulle dessutom samla erfarenhet av att an-vända programutvecklingsmetodiker och verktyg i denna praktiska miljö. Dessa

(14)

analysera-1.3. Mål

des utifrån samhälleliga, miljömässiga och etiska aspekter som en diskussion av systemets hållbarhet.

1.3

Mål

De övergripande målen för kandidatarbetet är indelade i rapportens mål samt projektets mål.

1.3.1

Rapportens mål

Denna rapport skrevs som en del av kursen TDDD96 Kandidatprojekt i programvaruutveck-ling. I Del 1: Gemensamma erfarenheter och diskussion förklaras hur projektet har utförts, vad bakgrunden var, vilka metoder som har använts för att ta fram resultatet, diskussion av re-sultatet i vidare sammanhang och till slut vilka slutsatser som drogs. I rapporten beskrivs också projektgruppens erfarenheter under projektets gång, vilka andra dokument som skrevs i samband med projektet och teorin bakom de verktyg och algoritmer som har använts. Del 2: Individuella bidrag gav varje projektmedlem uppdrag att undersöka ett område som gärna är relaterat till projektet. Dessa undersökningar redovisas genom bakgrund, metod, resultat, diskussion och slutsatser. Detta för att varje projektmedlem ska få erfarenhet av att skriva en individuell rapport.

1.3.2

Projektets mål

Projektgruppen skulle utveckla ett system som automatiskt matchade byggvaruprodukter från olika leverantörer till de basprodukter som fanns i kundens databas. Denna matchning gjordes förut manuellt, och det som efterfrågades var ett system som automatiskt kunde ge-nomföra dessa matchningar samt ge möjlighet att administrera de automatchade produkter-na.

Varje projektmedlem hade även ansvar över ett särskilt område i projektutvecklingen för att se till så att området mötte kvalitetskraven som kunden och projektgruppen kom överens om i kravspecifikationen. [1]

1.4

Frågeställning

Under detta avsnitt beskrivs de frågeställningar som ska besvaras i denna kandidatrapport.

1. Hur kan ett system för automatchning av byggvaruprodukter implementeras för att skapa värde för kunden?

2. Vilka erfarenheter kan dokumenteras från projektet som kan vara intressanta för fram-tida projekt?

3. Vilket stöd kan fås genom att skapa och följa upp en systemanatomi?

1.5

Begränsningar

Detta avsnitt behandlar de begränsningar som innebar någon form av restriktion på arbetet som utfördes eller resultaten som producerats. Dessa berör schemarelaterade, resursrelatera-de, erfarenhetsrelaterade och tekniska aspekter.

(15)

1.5. Begränsningar

1.5.1

Schemabegränsningar

Kursen påbörjades vid början av vårterminen, 15 januari, men projektval skedde inte förrän vecka 4 och därefter påbörjades projektarbetet. Projektet avslutades 23 maj och allt arbete på projektet förväntades ske inom dessa tidsramar. Projektgruppen var alltså förutom en total mängd timmar också begränsade att lägga dessa timmar inom ett visst intervall.

1.5.2

Resursbegränsningar

Projektgruppen hade totalt 2800 timmar att ägna åt projektarbetet. Varje person hade 400 timmar och under dessa ingick utveckling av systemet, föreläsningar, seminarier, möten och dokumentskrivning.

1.5.3

Erfarenhetsbegränsningar

Projektet använde metoder och verktyg som flera projektmedlemmar inte hade erfarenhet med. Detta ledde till outbildad uppskattning i beslut som togs under planering och utveck-ling.

1.5.4

Tekniska begränsningar

Systemets utförande var begränsat till en del tekniska verktyg. Projektgruppen var begrän-sad att utveckla ett webbaserat administrationsgränsnitt i ASP.NET Core 2 med Entity Fram-ework Core. Dessutom arbetade projektgruppen mot en databas hanterad via Microsoft SQL Server 2016 och förväntades anpassa all interaktion med databasen efter den förutsättningen.

(16)

2

Bakgrund

Maskininlärning är ett område inom datavetenskapen som under senare år fått fler tillämp-ningsområden. I många situationer kan lärande system användas för att skapa automatise-rade lösningar till problem som tidigare inte kunnat lösas på ett bra sätt av IT-system. Inom byggvarubranchen finns ett behov för ett automatiskt system där kunder och företag kan hit-ta och beställa byggvaror från olika leverantörer. Svårigheten i att utveckla ett sådant system är att branschen är väldigt decentraliserad - olika leverantörer har olika standarder för att beskriva sina produkter och samverkar inte i någon delad tjänst som kan samla och jämföra dessa produkter.

På grund av detta utvecklar projektets kund - Byggvarulistan i Sverige AB - ett system som aktivt insamlar information om byggvaruprodukter från olika leverantörer och samlar dessa i en webbtjänst där kunder enkelt kan beställa en uppsättning byggvaror från olika leverantö-rer. En kärna i detta system är företagets lista med basprodukter, som beskriver egenskaper-na hos allmänegenskaper-na byggvaruprodukter och sammankopplar dessa med de olika leverantörer-nas specifika produkter. För att detta system ska bli skalbart vill Byggvarulistan övergå från manuell matchning av produkter till automatisk matchning genom maskininlärning. Fokus för detta projekt var att utveckla detta automatchningssystem samt ett tillhörande administ-rationsgränssnitt för att verifiera och redigera matchningar.

De viktigaste ickefunktionella kraven på detta system handlar och matchningssäkerhet och körtid. För att inga felaktiga matchningar ska läggas in i kundens tjänst är säkerheten på matchningarna viktig. Detta betyder inte att alla matchningar som görs behöver vara av hög säkerhet, men att om en matchning ska kunna automatiskt godkännas behöver det finnas en mycket hög sannolikhet för att den matchningen är korrekt. Körtidskravet grundar sig i skal-barheten av systemet. Kundens databas innehåller vid tiden av denna rapports skrivande ett miljontal leverantörsprodukter och ett tusental basprodukter. Det finns även planer från kun-dens sida att utöka tjänsten och därför är det av största vikt att systemet som implementeras kan prestera väl trots en mycket stor och ständigt växande databas.

Tidigare erfarenheter

Projektmedlemmarna har från sin studietid flera tidigare erfarenheter av projektarbeten i större grupper. Ungefär hälften av projektgruppen hade även tidigare erfarenhet av projekt inom maskininlärning. Baserat på negativa erfarenheter från tidigare projekt fastslog projekt-gruppen att kommunikation är en viktig aspekt för att arbetet ska fungera bra. Om någon sit-ter fast med ett problem bör den fråga om hjälp, och alla borde koordinera vilka uppgifsit-ter de arbetar på så att inget arbete sker i onödan. Något som har hjälpt med detta i tidigare projekt var regelbundna statusmöten. En annan negativ erfarenhet var när vissa personer behövde ta på sig mycket mer arbete än andra. Uppdelning av arbetet i tydliga ansvarsområden, gärna

(17)

i små grupper där personer kan hjälpas åt, identifierades som en annan lämplig metod som kan motverka detta samt effektivisera arbetet.

(18)

3

Teori

Detta kapitel beskriver teorin bakom de verktyg, algoritmer och utvecklingsprocesser som projektgruppen har använt under projektets gång.

3.1

Vektyg

Teorin bakom Git, Github, Trello, Discord, Sharelatex, Google Drive, SqlDbx, pyodbc, Travis continuous integration (CI) och Tensorflow beskrivs i kommande delavsnitt.

3.1.1

Git och Github

Git är ett program som används för versionshantering av källkod. Git används genom att utvecklaren skapar eller klonar ett repositorium, redigerar koden och skapar en commit med dessa ändringar. Git skapar sedan en versionshistorik över alla kodändringar. [2]

Via webbhotellet Github får användaren tillgång till att skapa repositorier som sedan kan nås via internet. Github har en myriad av funktioner för att förenkla arbetet i mjukvarupro-jekt. De relevanta funktionerna för detta projektet var främst pull requests, code reviews och forks. Pull requests och code reviews används tillsammans genom att en utvecklare skapar en pull request och via ett inbyggt gränssnitt på Githubs hemsida kan sedan en annan utveck-lare kommentera den inkluderade koden. Om utveckutveck-laren tycker att koden är väl skriven och uppfyller alla relevanta standarder för projektet kan koden accepteras och sammanfoga med repositoriumt. En pull request är i sin tur en funktion som tillåter utvecklare att begära kodsammanfogning mellan repositorier. [3]

En fork är en funktion som skapar en personlig kopia av ett annat repositorium. Denna funk-tionen används ofta för att hålla olika utvecklares arbetsflöden separata. [4]

3.1.2

Trello

Trello är ett verktyg för planering där projektgrupper kan skapa tavlor som delas med pro-jektmedlemmarna. Dessa tavlor innehåller listor av kort med exempelvis vad som ska utfö-ras, vad som utförs, vad som ska granskas och vad som är slutfört. Trello kan därför jämföras med att ha en fysisk tavla med listor där post-it lappar flyttas runt. På korten kan det skrivas kommentarer, checklistor, förfallodatum och liknande. [5]

3.1.3

Discord

Discord är ett verktyg för både textbaserad och röstbaserad kommunikation. Den har stöd för skapandet av privata servrar som kan innehålla flera text- och röstkanaler. [6]

(19)

3.2. Algoritmer

3.1.4

Sharelatex

Sharelatex är en dokumentredigeringstjänst som baseras på TeX för att förenkla samarbete i detta typsättningsspråk. Via tjänsten kan projekt skapas för att gruppera relevanta TeX-filer så att det blir enkelt att veta var en TeX-fil bör finnas. Tjänsten gör det även möjligt för flera personer att skriva på samma TeX-fil simultant. [7, 8]

3.1.5

Google Drive

Google Drive är en molnbaserad lagringstjänst där en grupp kan ha en gemensam mapp. Detta innebär att den senast uppdaterade versionen av undermappar och filer är tillgäng-lig för alla gruppmedlemmar. Google Drive ger en även möjtillgäng-ligheten att använda Googles dokumentredigerings-, presentations- och kalkylbladstjänst. [9]

3.1.6

SqlDbx

SqlDbx är ett program som låter användaren koppla upp sig mot en databas och manipulera den med vanliga SQL kommandon. Vid hämtning av data från en databas visas den efter att den har formaterats. Datan kan sedan enkelt kopieras in i ett kalkylblad eller liknande om så önskas. [10]

3.1.7

pyodbc

Pyodbc är ett python bibliotek som låter användaren koppla upp sig mot en databas. Sedan kan användaren hämta data från databasen genom att skriva SQL queries i python. Därefter kan användaren exempelvis göra något med datan och sedan lägga in ändringarna i databa-sen via SQL queries. [11]

3.1.8

Travis CI

Travis CI är en tjänst för automatisk testning av kod som kopplas ihop med ett Github repositorium. Efter att Travis CI har kopplats till repositoriumt kan tester skrivas i en .travis.yml-fil som Travis CI kör automatiskt när kod läggs upp i repositoriumt. [12]

3.1.9

Tensorflow

Tensorflow (TF) är ett bibliotek som används för högnivå implementationer av maskininlär-ningsalgoritmer, främst neurala nätverk. Det är anpassat för att kunna köras på många olika typer av enheter och arkitekturer såsom mobila enheter och grafikprocessorer. [13]

3.2

Algoritmer

Under följande delavsnitt beskrivs algoritmerna djupa neurala nätverk (DNN) och k-nearest neighbors (kNN) samt den bakomliggande teorin som krävs för att förstå behovet av dessa algoritmer.

3.2.1

Maskininlärning

Maskininlärning kretsar kring utformandet av program som förbättrar sin förmåga att lösa problem genom olika typer av observationer. Nyttan i att utforma ett program på detta sätt är flerfaldig; ett lärande program kan anpassa sig till situationer som från början är okända eller som förändras på oförutsägbara sätt, och ett lärande program kan angripa komplexa problem där inte kunskaperna eller möjligheterna finns för utvecklare att utforma egna konventionella lösningar. [14, p. 693]

(20)

3.2. Algoritmer

En mer formell definition av ett lärande program ges av Mitchell (1997). Han beskriver ett program som lärande av en erfarenhet E om det genom denna erfarenhet förbättrar sin för-måga att lösa en uppsättning uppgifter T med avseende på ett tillhörande prestandamått P. [15, p. 2]

3.2.2

Supervised machine learning

Supervised machine learning (SML) är en typ av maskininlärning där en samling exempel på indata till och utdata från en okänd funktion f används för inlärning av en hypotesfunktion h som approximerar f , och därmed kan predicera utdata givet ny indata. Samlingen exem-pel kallas träningsdata, och för att utvärdera säkerheten hos hypotesen används en separat mängd indata-utdatapar som kallas testdata. Det finns många olika SML-algoritmer som på olika sätt använder träningsdatan för att utforma hypotesfunktionen. [14, p. 695]

3.2.3

Klassificering

Maskininlärningsproblem kan delas in i två olika kategorier, klassificering och regression, baserat på vilken form utdatan som ska produceras har. Klassificering innebär att utdatan be-står av diskreta värden från en ändlig mängd möjligheter. Regression är motsatsen till detta, där utdatan består av kontinuerliga numeriska värden. [14, p. 696] Produktmatchningen som är det relevanta problemet för detta projekt, och beskrivs i kapitel 2, faller under klassificering då utdatan är ett urval bland en ändlig mängd basprodukter.

3.2.4

Artificiella neuronnätverk

Artificiella neuronnätverk (ANN) försöker imitera den mänskliga hjärnan genom ett nätverk där noderna representerar neuroner som har en insignal och en utsignal. Varje signal mul-tipliceras med en vikt på varje koppling mellan noder, adderas och matas sedan in i noden som har en så kallad transferfunktion som kan till exempel vara tanh(x).

För att ett nätverk ska kunna användas till maskininlärning måste det hitta bra vikter på kopplingarna mellan neuronerna. Eftersom önskad utsignal genereras av att en insignal ma-tas in måste nätverket lära sig rätt vikter för det. Detta görs genom algoritmens backpropaga-tion, där önskad utdata matas in i utdatalagret. Då beräknas felet för varje neuron och hur vikterna ska justeras för att felet ska bli mindre. Sedan propageras felet till de andra lagren och för varje vikt beräknas hur den ska justeras för att felet ska bli mindre. Detta kallas för nedstigning via gradient då felet är en funktion av avståndet mellan nodernas utdata och önskad utdata beroende av nodernas vikter. Tar man då negativa gradienten av felfunktio-nen med avseende så får man vilket håll man ska justera vikterna för att felfunktiofelfunktio-nens värde ska bli mindre. [16] En djupare förklaring av neuronnät finns i Alfred Hagbergs individuella del i kapitel A.3.1.

3.2.5

Djupa neurala nätverk

Djupa neurala nätverk (DNN) är en variant av ANN. DNN är artificiella neuronnät med fler än ett lager mellan indata- och utdatalagret, så kallade dolda lager.[16]

3.2.6

k-Nearest neighbors

K-nearest neighbors (kNN) är en SML-algoritm som kan användas till klassificering. När indata ska klassificeras gör algoritmen en sökning genom träningsexemplen efter den mest liknande indatan som tidigare klassificerats, och återanvänder denna tidigare klassificering. Likheten definieras av någon utvald avståndsfunktion. Denna algoritm är simpel att imple-mentera men ändå generell nog att kunna appliceras till många problemdomäner på grund

(21)

3.3. Utvärdering av algoritmer

av att algoritmen inte behöver modellera de underliggande sambanden i datamängden. En mer genomförlig beskrivning av algoritmen ges i Jonathan Lundgrens individuella bidrag, kapitel D.

3.3

Utvärdering av algoritmer

I syfte att utvärdera effektiviteten hos SML-algoritmer krävs utvärderingsmetoder anpassade efter maskininlärda klassificerare. Dessa metoder delar exempeldatan i träningsdata som an-vänds för inlärning av modellen och testdata som anan-vänds vid utvärderingen av den inlärda modellen.

3.3.1

Korsvalidering

För utvärdering av maskininlärningsalgoritmer finns en metod som kallas k-delad korsvali-dering. Övergripande innebär k-delad korsvalidering att exempeldatan delas upp i k stycken olika delar. Algoritmen tränas på k ´ 1 stycken av dessa delar och utvärderas på den åter-stående delen. Detta upprepas k gånger, en gång med varje unik del som utvärderingsdel. [17]

3.3.2

Utvärderingsmetriker

För att bedöma resultaten från en klassificerare finns ett flertal utvärderingsmetriker. De främsta i det här projektet är precision och recall. Precision är kvoten av antalet korrekt gjorda klassificeringar dividerat med det totala antalet gjorda klassificeringar och recall är kvoten av antalet korrekt gjorda klassificeringar dividerat med totala antalet möjliga korrekta klassi-ficeringar. [18]

Mer information om utvärderingsmetriker och utvärderingsmetoder kan hittas i Eric Nylan-ders kapitel B.

3.4

Utvecklingsprocesser

I denna del presenteras två utvecklingsprocesser gruppen valde att använda.

3.4.1

Scrum

Scrumär ett agilt ramverk för projektutveckling som delar upp ansvar i projektgruppen en-ligt olika förbestämda roller.

• Product Owner är rollen som står i centrum i scrum-metoden och väntas övervaka en product backlog som beskriver de övergripande delmål som projektgruppen måste uppnå. Denna roll uppfylls av kontaktpersonen hos kunden.

• Scrum Master innefattar rollen av en analysansvarig i den mån att den väntas försäkra att målen som projektgruppen försöker uppnå passar kundens krav.

• Development Team är rollen som utför utvecklingen av produkten med hjälp av sprin-tar och en sprint backlog som projektgruppen avgör vid sprintmöten. Under scrum vän-tas dessutom scrummöten ske dagligen med syfte att rapportera vad som har gjorts och vad som planeras göras under dagen.

Arbetet inom ramverket delas upp i sprintar. En sprint varar mellan två och fyra veckor samt har ett slutgiltigt mål som ska vara uppfyllt vid sprintens slut. Varje sprint börjar med

(22)

3.4. Utvecklingsprocesser

ett planeringsmöte där projektgruppen går igenom en lista med ogjort arbete och beslutar sig för ett mål baserat på vad som behöver göras. Varje sprint avslutas med en sprint review där projektgruppen utvärderar sprinten. Under en sprint sker även dagliga möten kallade scummöten. Vid dessa möten presenterar varje projektmedlem vad de åstadkommit och vad de planerar att göra. [19]

3.4.2

Systemanatomi

Syftet bakom en systemanatomi är att alla medlemmar i exempelvis ett projekt ska ha en ge-mensam bild över hur systemet ser ut. En systemanatomi är på detta sätt enkel att komma överens om än exempelvis en systembeskrivning på flera hundra sidor. Systemanatomin vi-sar hur olika större funktioner eller förmågor beror på varandra inom systemet. Tankesättet som skapandet av systemanatomin baseras på är vad som successivt ska ske efter att syste-met har startats. Att bilden över systesyste-met är korrekt är inte det väsentliga, huvudsaken är att projektmedlemmarna kan skapa systemet utifrån den bild de har över systemet. [20]

(23)

4

Metod

Metoden som projektgruppen har använt baseras på kursens struktur, råd från kurshandle-daren, samt projektgruppens egna erfarenheter med liknande projektgrupper.

4.1

Projektorganisation

Här presenteras och redovisas den struktur som försågs av kursens uppsättning och anvis-ningar, samt de anpassningar projektgruppen gjorde efter kundens och medlemmarnas möj-ligheter, behov och önskemål. Projektgruppens krav beskrivs i gruppavtalet, kundens krav beskrivs i kravspecifikationen och kursens krav beskrevs på föreläsningar och på kurshemsi-dan. [1, 21, 22]

4.1.1

Roller

Roller delades ut så att alla projektmedlemmar skulle få ett eget ansvarsområde. Detta genom att varje projektmedlem fick rangordna de tre roller som den helst ville ha. Utifrån detta delades två roller ut till varje projektmedlem, en huvudroll och en sekundär roll. Orsaken till att projektgruppen valde att ha sekundära roller var för att den som hade den sekundära rollen skulle kunna stötta den som hade huvudrollen så att den inte behövde göra arbetet själv. De sekundära rollerna användes även som reserv om den som hade huvudrollen inte var närvarande. Varje projektmedlems roller visas i tabell 4.1.

Tabell 4.1: Medlemsroller

Namn Huvudroll Sekundär roll

Alfred Hagberg Utvecklingsledare Arkitekt Eric Nylander Dokumentansvarig &

kvalitetssamordnare

Analysansvarig Henrik Andersson Konfigurationsansvarig Testledare

Jonathan Lundgren Analysansvarig Utvecklingsledare

Leif Eriksson Arkitekt Teamledare

Mustaf Musse Teamledare Konfigurationsansvarig

Robin Andersson Testledare Dokumentansvarig & kvalitetssamordnare

4.1.2

Handledare

Kurshandledarna agerade som resurser för förtydligande av kursens krav och rådgivare för projektets genomförande. Detta innefattade frågor om dokumentmallar, kund- och

(24)

sekretess-4.2. Utvecklingsmetod

avtal samt olika utvecklingsmetoder. Handledaren agerade även som mellanhand för exami-natorn i kursen och fanns som stöd vid tekniska frågor.

4.1.3

Kommunikation

Den huvudsakliga kommunikationskanalen var kommunikationsklienten Discord. Projekt-gruppen valde denna eftersom den tillförde möjlighet att organisera kommunikationen fack-ligt för snabb åtkomst av relevant information, samt att den innehåller en voice over Internet protocol (VoIP)-tjänst.

4.2

Utvecklingsmetod

Utvecklingen använde en anpassad scrum-liknande metod som baserades på användningen av Trello för strukturering av delmoment i projektet. Nedan beskrivs de metoder som använ-des för planering, utveckling, testning och dokumentering av projektet.

4.2.1

Scrum

Gruppen valde att använda sig av en anpassad version av den agila utvecklingsprocessen sc-rum. I syfte att anpassa denna metod efter projektstrukturen valde projektgruppen att föregå dagliga scrummöten och istället att låta projektmedlemmarna rapportera vad de hade gjort och planerade göra dagligen i en specifik Discord-kanal.

Sprintar

Varje sprint planerades på ett sprintmöte som föll på måndagen efter föregående sprint hade slutförts. Längden för en sprint bestämdes på detta sprintmöte och blev en till två arbetsvec-kor lång. Under detta möte användes en backlog av mål för projektet. Projektgruppen dis-kuterade vilka mål som ansågs viktiga och valde en eller flera av dessa mål som sprintmål. Sprintmålen delades ofta in i delmål som spårades via Trello.

Vid slutet av varje sprint, innan nästkommande sprintmöte, genomförde projektgruppen en

sprint reviewdär varje projektmedlem gav sin åsikt om hur väl den föregående sprinten fungerade och vad som kunde förbättras inför nästa sprint. Dessutom diskuterade projekt-gruppen hur kraven för projektet förändrades under föregående sprint och därifrån ändrades de relevanta dokumenten och övergripande målen.

4.2.2

Möten

Obligatoriska möten skedde varje måndag morgon där projektgruppen diskuterade vad de åstadkommit under den föregående veckan och hur den kommande veckan skulle planeras. Vid dessa möten skrevs även veckorapporter enligt kurskrav. Vid början av en sprint ägnades en stor del av mötestiden till planering av sprinten där kunden hade möjlighet att närvara. Vid behov hölls flera gruppmöten under veckan för grupparbete och klargörelse av otydliga moment.

Kundmöten med kontaktpersonen skedde kontinuerligt under projektets gång. Vid dessa möten gav projektgruppen en uppdaterad bild av produktens status och kontaktpersonen hade möjlighet att ge åsikter och redigera krav. Samtidigt hade projektgruppen möjlighet att ställa tekniska frågor och förtydliga existerande krav.

Handledarmöten fyra gånger under projektets gång och var till för att projektgruppen skulle få ledning om exempelvis hur dokumenten skulle skrivas och hur kundkontakt skulle hante-ras.

(25)

4.2. Utvecklingsmetod

4.2.3

Planering

För planering av arbetet användes den webbaserade projektledningstjänsten Trello. Detta lät projektgruppen skapa scrumtavlor för sprintplanering och för aktiviteter som skulle utföras. Detta gjorde att alla projektmedlemmar hade en översikt över vad som skulle utföras. Om en projektmedlem kom på något som borde utföras kunde denne skapa ett kort för den aktivite-ten som sedan andra projektmedlemmar kunde skriva upp sig själva på om de tänkte utföra den aktiviteten.

4.2.4

Utbildning

Projektgruppen deltog i alla seminarier och föreläsningar med syfte att utbilda samtliga i pro-jektgruppen. Andra typer av utbildningar skedde kontinuerligt mellan projektmedlemmarna i form av gruppmöten, studiecirklar samt skapandet och läsandet av manualer.

Varje projektmedlem läste dessutom igenom all dokumentation som andra projektmedlem-mar skrivit och som berörde projektets utveckling. Detta innefattade till exempel kravspeci-fikationen och en contributor’s guide som projektgruppen använde som manual för versions-hanteringsprocessen.

Förutom detta tog varje projektmedlem eget ansvar för att utbilda sig inom ansvarsområdet och andra områden som den arbetade med. Om en projektmedlem hade problem så tog den hjälp från de andra projektmedlemmarna och projektgruppens handledare.

4.2.5

Systemanatomi

Vid början av projektet skapades en systemanatomi för att ge en överblick över systemet. Systemanatomin skulle användas som stöd under projektets utveckling genom att projekt-gruppen skulle kunna jämföra den med systemet för att avgöra ungefär vad som saknades för att systemet skulle bli färdigt. Systemanatomin uppdaterades även senare i projektet när en tydligare bild av systemets eftersökta funktioner fanns.

4.2.6

Utveckling

Utvecklingen av projektet delades upp i moduler. Dessa moduler tilldelades sedan grupper på två till tre personer som ansvariga för denna. Medlemmarna i dessa grupper väntades ut-föra utveckling på dessa moduler tillsammans och agera som stöd till varandra. Detta ersatte

parprogrammeringsom agil utvecklingsmetod i scrum.

Code reviews tillkom utifrån versionshanteringslösningen som projektgruppen använde. Vid varje pull request väntades en annan projektmedlem granska koden innan den godkändes och integrerades i projektet.

4.2.7

Tester

Testningen av produkten följde testfilosofin Bottom-Up vilket innebar att projektgruppen valde att göra de funktioner och klasser som var längst ner i hierarkin och skapa drivers för att kunna använda dessa funktioner. Sedan arbetade sig projektgruppen successivt upp-åt i funktionsanrops hierarkin tills roten nåddes och därmed blev det även successivt färre drivers. För att säkerställa att produkten testades ordentligt utfördes enhetstester, integra-tionstester, systemtester och acceptanstester.

(26)

4.2. Utvecklingsmetod

Enhetstester

Enhetstesterna utfördes genom att konfigurationsansvarig integrerade projektgruppens cen-trala Github repositorium med Travis CI. Detta gjorde det möjligt att testa all kod innan den sammanfogades med koden i det centrala repositoriumt. Om koden inte klarade testerna sammanfogades den inte med koden i repositoriumt vilket tvingade projektmedlemmarna som skrev koden att se över den igen. Testerna som kördes skrevs i skript som Travis CI körde automatisk när projektmedlemmarna gjorde pull requests.

Integrationstester

Integrationstesterna utfördes genom att testa hur algoritmen för automatchning matchade produkter. Detta skedde genom k-delad korsvalidering. Datan med kända matchningar de-lades upp så att 90% av datan användes som träningsdata och resterande 10% användes som utvärderingsdata. Utvärderingsdata roterades sedan så att varje 10% fick användas som utvärderingsdata en gång. Automatchningarna givna av testerna jämfördes sedan mot de korrekta matchningarna för att få fram värden på korrektheten av algoritmerna.

Systemtester

Systemtesterna utfördes vid slutet av projektet när produkten i sin helhet var klar så att projektgruppen kunde verifiera att de automatiska matchningar som gjordes blev korrekta samt för att verifiera att användargränssnittet och matchningsalgortimerna fungerade till-sammans. Dessa tester användes alltså från ett användarperspektiv där projektgruppen kun-de se att produkten fungerakun-de som kraven specificerakun-de att kun-den skulle.

Acceptanstester

Acceptanstester utfördes för att verifiera att systemet faktiskt var acceptabelt nog att leverera till kunden. Dessa tester baserades på kravspecifikationen där projektgruppen kontrollerade att systemet uppnådde alla krav. [1] Det var först och främst projektgruppen som utförde dessa tester, men sedan fick även kunden testa produkten för att avgöra om den mötte för-väntningarna som kunden hade.

4.2.8

Dokumentredigering

Dokumentskrivningen skedde i den molnbaserade dokumentredigeringstjänsten Sharelatex. Fördelen med användandet av denna tjänst var att alla projektmedlemmar hade möjlighet att redigera TeX-dokumenten simultant och hade tillgång till den senast kontinuerligt uppdate-rade versionen av varje dokument.

Efter ett första utkast av ett dokument skrevs hade alla projektmedlemmar ansvar att hit-ta eventuella shit-tavfel och grammatiska fel. Utöver det skulle alla projektmedlemmar ge sitt godkännande att kursens krav på dokumentet uppfylldes enligt deras uppskattning. Detta säkerställde en robust grund till dokumentets utvecklande i senare iterationer.

Efter att alla projektmedlemmar hade haft chansen att kommentera på dokumentet gavs an-svar för en närmare inspektion över till de dokumentanan-svariga i syfte att säkerställa att do-kumentet mötte den standard som dodo-kumentet baserades på.

I senare iterativa dokumentutvecklingar gavs ansvaret för dokumentgranskning till minst två projektmedlemmar för effektiv uppdelning av personresurser.

(27)

4.3. Utvecklingsverktyg

4.2.9

Versionshantering

Versionshanteringen av projektets filer hanterades via Google Drive, Sharelatex samt Github beroende på vilken typ av fil det var.

Anteckningar, protokoll och diverse andra mindre dokument skrevs i Google Docs och dela-des via Google Drive. Google Docs och Google Drive innehåller inbyggda versionshanterare som sparar en kopia varje gång en fil ändras. [23]

Större dokument som till exempel kandidatrapporten, projektplanen och testplanen skrevs i Sharelatex och planerades versionshanteras via Google Drive. Dokument som till exempel gruppkontrakt och veckorapporter hade separata filer beroende på revision och krävde därav inte versionshantering.

All programkod som skrevs för projektet versionshanterades via Github och Git. På Github hade projektgruppen ett privat repositorium innehållandes all kod relaterad till administra-tionsgränssnittet och automatchningen. Detta repositorie agerade som en central nod som projektmedlemmarna interagerade med via Githubs inbyggda funktioner fork och pull re-quest. Detta repositorie administrerades av konfigurationsansvarig.

Arbetsstrukturen för versionshantering av programkod tillät projektet att ta hjälp av många funktioner som underlättade kodskrivning i grupp. Dessa funktioner inkluderade automa-tisk hantering av code reviews, visualisering samt information om kodsammanfogningar, automatisk testning av kod och enkel Markdown-baserad dokumentation för kodrelaterade artiklar.

4.2.10

Kodgranskning

Granskning av kod gjordes i samband med att en projektmedlem gjorde en pull request. Då granskades koden av en eller flera projektmedlemmar för att se om det fanns någonting att förbättra innan koden godkändes och integrerades i projektet. I samband med att en projekt-medlem skapade en pull request testades koden automatiskt vilket gjorde att projektmed-lemmen som granskade koden inte behövde testa den lokalt på sin egna dator.

4.3

Utvecklingsverktyg

För projektet användes en mängd utvecklingsverktyg. Dessa har beskrivits tidigare i doku-mentet och var följande:

• Trello • Github • Discord • Sharelatex • Google Drive

Anledningen till att dessa verktyg användes var för att de antingen var rekommenderade av examinatorn eller för att de var verktygen för ändamålet projektmedlemmarna trivdes med att använda.

(28)

4.3. Utvecklingsverktyg

Trello användes som ett alternativ till en fysisk scrumtavla. Github användes för att versions-hantera programkod. Discord användes för att organisera digital kommunikation. Sharelatex och Google Drive valdes för dokumentskrivande.

Utöver dessa fick varje projektmedlem själv välja vilka verktyg de skulle använda för att skriva programkod. Följande verktyg användes för skrivandet av programkod:

• Visual Studio Code • Visual Studio 2017 • Nvim

• Emacs • Notepad++ • SqlDbx

Anledningen till detta var att alla ramverk och bibliotek som användes i projektet var i stort sett plattformsagnostiska med undantag för SQL Server 2016. Projektgruppen kunde inte hitta en bra anledning till att tvinga alla projektmedlemmar att arbeta på samma plattform med samma verktyg.

4.3.1

SQL Server

Databasen för programmet var en nedskalad version av Byggvarulistans databas. Databasen laddades upp till Azure av kunden samt projektmedlemmarna. Detta möjligjorde att alla projektmedlemmar kunde arbeta mot databasen genom diverse program utan att behöva ha sin egen instans. Under projektets första halva inhystes även en version av databasen av en projektmedlem. Projektgruppen valde att fortsätta använda den existerande databasen med mindre modifieringar och tillägg för att möjliggöra automatchning i kombination med administration.

4.3.2

ASP.NET Core och Entitiy Framework Core

Administrationsgränssnittet skrevs helt i C# med hjälp av ramverken ASP.NET Core 2 och Entitity Framework Core. Detta var ett önskemål av kunden så att de enkelt skulle kunna integrera gränssnittet med sitt egna. Projektgruppen såg ingen anledning till att gå mot kun-dens önskning då ramverken uppfyllde ändamålet för gränssnittet väl.

4.3.3

Python

Programkoden för automatchningsalgoritmerna var helt skriven i Python 3.6. Projektgrup-pen valde Python eftersom det hade många väletablerade maskininlärningsbibliotek och för att många i projektgruppen redan hade erfarenhet av språket sedan tidigare.

För testning av programkoden valde projektgruppen även att använda det i Python inbyggda biblioteken unittest samt hypothesis.

För utvecklandet av en av automatchningsalgoritmerna användes Googles bibliotek Tensor-flow.

För kommunikation mellan automatchningsalgoritmerna och databasen användes Python biblioteket pyodbc.

(29)

4.4. Metod för att fånga erfarenheter

4.4

Metod för att fånga erfarenheter

För att fånga projektmedlemmarnas individuella erfarenheter har projektgruppen haft många möten där utvecklingen av produkten har diskuterats. Under dessa möten skrevs pro-tokoll så att frånvarande projektmedlemmar kunde se vad projektgruppen hade diskuterat samt för att alla skulle kunna se viktiga beslut som togs.

Projektgruppen programmerade även mycket i grupp för att säkerställa att så många indivi-duella erfarenheter som möjligt skulle blandas under utvecklingen. En kanal skapades även i Discord där alla projektmedlemmar kunde observera och delta i diverse diskussioner kring projektets tekniska delar.

Det etablerades även tidigt i projektet att om en projektmedlem fastnade med en uppgift skulle denne informera projektgruppen om detta så snart som möjligt. Detta för att projekt-gruppen skulle få chansen att hålla sig informerad om hinder i utvecklingen samt kunna ge råd till projektmedlemmen som fastnat. Utöver detta skulle projektgruppen hålla en öppen dialog med hög tolerans. Detta fastställdes i gruppavtalet som alla projektmedlemmar skrev på. [21]

(30)

5

Resultat

I detta kapitel beskrivs resultaten av projektet. Först presenteras systembeskrivning som in-nehåller systemanatomin samt användargränssnittet. Sedan diskuteras projektgruppens ge-mensamma erfarenheter under projektets gång. Till slut presenteras en skiss över de indivi-duella bidragen.

5.1

Systembeskrivning

Här presenteras en översiktlig beskrivning av systemets arkitektur, användargränssnittet och hur detta används, samt en redogörelse för hur denna arkitektur kan skapa värde för kunden.

5.1.1

Översiktlig beskrivning av systemet

Systemet består av tre huvudsakliga moduler som samverkar med varandra. Dessa moduler illustreras i figur 5.1.

Figur 5.1: Översikt av systemets moduler

Kärnan i systemet utgörs av automatchningsmodulen, som använder information från kun-dens databas över byggvaruartiklar för att skapa förslag på automatiska matchningar mot basprodukter för nya byggvaruartiklar. Denna automatchningsmodul utvecklades för att en-kelt tillåta utbyte av vilken algoritm som används för att skapa dessa matchningar. Två algo-ritmer implementerades i det slutgiltiga systemet: kNN och DNN.

Den andra viktiga modulen är administrationsgränssnittet, som hämtar de automatiska matchningarna från automatchningsmodulen och låter en administratör verifiera eller re-digera dessa. Detta sker genom kommunikation med den tredje modulen som är kundens databas - en Microsoft SQL Server. Denna databas utökades med extra tabeller innehållande information som används av de implementerade algoritmerna.

(31)

5.1. Systembeskrivning

Godkänna/ändra

matching (förslag) Byta gjord matching (söka själv) Matcha ny produkt (mot befintlig) Matcha ny produkt (skapa ny basprodukt) Matcha om/kontrollera alla gjorda matchingar ASP.Net UI Webbläsare Databas Server Matcher Editera autogjorda Basprodukter

Ladda data Förbered data

Träna matching Testa matcher Matcha data Spara data Föruppdelar data (fork)

Figur 5.2: Systemanatomin för systemet

5.1.2

Automatchning

Automatchningsmodulen, som skrevs i Python, utgörs huvudsakligen av ett centralt ramverk bestående i av tre huvuddelar: hämtning av produktinformation från databasen, multitrådad exekvering av en utbytbar matchningsalgoritm som skapar matchningar utifrån denna in-formation samt uppladdning av dessa matchningar till databasen. Detta ramverk innehåller också funktionalitet för att täcka ett antal basfall där ingen avancerad matchningsalgoritm behövs, till exempel när det går att hitta en unik produktkod som stämmer överens med en produkt som redan finns inlagd. De två algoritmerna som implementerades - kNN och DNN - arbetar enligt samma gränssnitt mot det centrala ramverket. Algoritmerna ger för varje gjord matchning en säkerhet - en så kallad accuracy - som approximerar sannolikheten att den specifika matchningen är korrekt. Multitrådning och parallelism uppnås genom att olika produktkategorier behandlas separat. I ramverket implementerades också funktionalitet för att kunna kombinera resultaten från de två algoritmerna till matchningar som då får högre säkerhet.

För att förbättra matchningssäkerheten hos systemet testades och förbättrades dessa algorit-mer kontinuerligt under projektets gång. Testningen skedde via korsvalidering som beskrivs i 4.2.7 och resultatet sammanställdes och presenterades i figur 5.3-5.7. Figurerna 5.3 och 5.6 visar antalet gjorda matchingar vid specifik accuracy. Jämförelser mellan algoritmernas accu-racy mot procenten korrekta matchningar vid specifik accuaccu-racy visas i figurerna 5.4 och 5.7. Figur 5.5 visar sambandet mellan precision och recall för båda algoritmerna. Detta samband är då framtaget genom att avbilda precision på recall för varje accuracy, för att på detta sätt visa hur en ökning av precision tvingar fram en minskning av recall.

KNN

För kNN-matcharen uppnåddes vid korsvalidering ett resultat av cirka 28500 korrekta match-ningar av totalt cirka 41000 stycken. De korrekta matchmatch-ningarna låg med majoritet i interval-let 94% till 100% accuracy vilket kan ses i figur 5.3. I figur 5.4 syns att den accuracy som ges av kNN stämmer bra överens med den faktiska säkerhet som gavs av korsvalideringen,

(32)

5.1. Systembeskrivning

även om visst brus finns. Figur 5.5 visar begränsningen på algoritmen och sambanden mellan precision och recall för denna.

Figur 5.3: Graf över antal matchningar vid angiven säkerhet för KNN

Figur 5.4: Graf över faktisk säkerhet mot KNN angiven säkerhet

DNN

För DNN-matcharen uppnåddes vid korsvalidering ett resultat av cirka 33000 korrekta matchningar av totalt cirka 41000 stycken. De korrekta matchningarna låg med stor majoritet i intervallet 99% till 100% accuracy vilket kan ses i figur 5.6. I figur 5.7 syns att den accuracy

(33)

5.1. Systembeskrivning

Figur 5.5: Precision-Recall graf för KNN samt för DNN, här kallat TF

som ges av DNN stämmer bra överens med den faktiska säkerhet som gavs av korsvalide-ringen, med ett något mindre brus än för kNN. Figur 5.5 visar begränsningen på algoritmen och sambanden mellan precision och recall för denna. Dessa tre grafer tillsammans visar att DNN ger en majoritet av resultaten i intervallet 99% till 100% accuracy och att majoriteten av dessa matchningar är korrekta.

Figur 5.6 visar även en topp av antal fel vid accuracy 0% som visar de produkter som DNN inte klara av att matcha alls, alternativt inte tycker tillhör någon kategori alls, och därmed inte kommer in i systemet som matchningar. De produkter som i framtiden tillhör denna grupp av icke-matchade produkter är potentiellt produkter som saknar basprodukt.

5.1.3

Databas

Databasmodulen är en utökning av den databas som kunden redan använder. De automa-tiskt skapade matchningarna läggs till i en ny tabell, där de sparas tillsammans med värden som uppskattar sannolikheten att matchningarna är korrekta. För att automatchningarna ska läggas till i kundens ordinarie system måste de matchningar som bedöms vara korrekta ko-pieras över till den ursprungliga tabellen över produktmatchningar.

Nya tabeller har lagts till vilka sparar metadata som används av matchningsalgoritmerna. Bland dessa ingår tabeller för kategoribindning, ord till namnmatchning samt för Tensorflow-data.

5.1.4

Användargränssnitt

Användargränssnittet är utvecklat i ASP.NET Core 2 och kommunicerar med kundens da-tabas genom att visa matchningarna som algoritmerna har utfört. Via användargränssnittet kan användaren acceptera en matchning, visa mer information om en matchning eller ändra en matchning. Användaren kan även sortera matchningarna utifrån hur de har utförts, alltså via någon av algoritmerna eller med hjälp av något ID. Slutligen kan användaren även söka

(34)

5.1. Systembeskrivning

Figur 5.6: Graf över antal matchningar vid angiven säkerhet för DNN, här kallat TF.

Figur 5.7: Graf över faktisk säkerhet mot DNN, här kallat TF, angiven säkerhet. Visar tydligt att majoriteten av matchningarna ligger vid hög accuracy.

(35)

5.2. Gemensamma erfarenheter

efter en matchning manuellt genom att skriva in vilken produkt som sökes. En översikt över användargränssnittet finns i bilaga 1.

Trycker användaren på ”Info” visas matchningen mer detaljerat genom att visa vilka attribut basprodukten och leverantörsprodukten har. Detta är nödvändigt om osäkerhet uppstår över matchningen eftersom attributen kan jämföras för att se om det verkligen är en matchning. Sedan kan användaren välja att acceptera matchningen eller att ändra den. Ett exempel på hur detta ser ut finns i bilaga 2.

Väljer användaren däremot att ändra matchningen visas en lista över alla basprodukter. Ge-nom att välj ”Choose” kan användaren sedan välja en ny basprodukt att matcha leverantörs-produkten mot. Det går även att söka efter en basprodukt genom att skriva något i sökrutan. Detta illustreras i bilaga 3 via ett exempel.

5.2

Gemensamma erfarenheter

I detta avsnitt beskrivs projektgruppens lärdomar och erfarenheter i projektet. Detta involve-rar: projektorganisation, arbetsprocess, systemanatomi och de tekniska verktyg projektgrup-pen använt sig av.

5.2.1

Projektorganisation

Att varje projektmedlem hade två roller var användbart då detta gjorde att exempelvis testle-daren och arkitekten fick stöd med att skriva sina dokument vilket gjorde det möjligt att hålla en högre kvalitet på dokumenten. Det gjorde även att personen som hade huvudansvaret för ett område hade någon att diskutera med om hur någonting skulle utföras. Det var även an-vändbart om projektmedlemmen som hade huvudansvaret var frånvarande för då fanns det en reserv för just den rollen.

Övrigt gällande projektorganisation har ett problem funnits med att hitta lämpliga lokaler till grupparbete eftersom tillgängligheten på dessa har varit begränsad. Projektgruppen har även haft problem med att hitta tider för möten där alla kan närvara på grund av schemakrockar. Detta har lett till att projektgruppen har anpassat sin arbetsprocess, vilket diskuteras vidare i nästa avsnitt.

5.2.2

Arbetsprocess

Som det har nämnts i tidigare avsnitt har projektgruppen använt en anpassad version av sc-rum för att strukturera arbetet. Överlag har detta varit en effektiv metod för att ta fram de konkreta aktiviteter som är viktigast att utföra på kort sikt och fördela dessa över projekt-gruppens medlemmar. Det har också bidragit med en flexibilitet i arbetet eftersom innehållet i varje iteration väljs till att vara det som är viktigast för stunden.

Anpassningen som projektgruppen gjorde var att ersätta de dagliga scrum-mötena med in-dividuella statusrapporter i kommunikationsverktyget Discord. Detta var ett bra beslut ef-tersom schemakrockar skulle gjort det svårt att hitta tider varje dag när alla kan närvara, och eftersom projektets omfång innebär att betydliga framsteg inte behöver ske exakt varje dag. Samtidigt låter statusrapporterna ändå alla medlemmar att få en överblick över varandras arbete.

5.2.3

Systemanatomi

Systemanatomin som presenterades i Figur 5.2 skapades i projektets tidiga skede. Denna an-vändes då som hjälpmedel för att skapa en struktur för systemets olika moduler. Efter detta

(36)

5.3. Översikt över individuella bidrag

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

References

Related documents

Sjukhuset minskade därmed mängden smittförande avfall, som skickades iväg för behandling, med 15 ton förra året.. Eftersom hanteringen av smittförande avfall är mycket kostsam

Förutom möjligheten att rita enkla geometriska former kan olika molekylstrukturer, atomer och bindningar ritas, i vissa program finns även mallar för laboratorieutrustning

För att kunna fällas till ansvar för sexuellt utnyttjande krävs, som tidigare redogjorts för, att någon har haft sexuellt umgänge med annan genom att ha otillbörligt utnyttjat

Använd mjuk blyertspenna om du behöver sudda för att ändra ditt svar!. Markera

Det internationella samfundet, däribland Sverige, som inför Rio +20 framhävt behovet av över- gången till en grön ekonomi, har även blundat för de stora pro- blemen

I pilotstudien är detta tema och det samspel mellan personal och närstående det beskriver en förutsättning för att personalen skall kunna skapa sig en bild av patienten

[r]

Den adaptiva modellen tar i beräkningarna för värmesystemets effekt hänsyn till närvaron i lägenheten. Om ingen är hemma kommer värmesystemet att vara avstängt och