I detta avsnitt analyseras den slutgiltiga produkten utifrån värdet som har skapats för kun- den, alternativa implementationssätt samt vilka förbättringsmöjligheter som finns.
6.1.1
Värde för kunden
Generellt har värde skapats för kunden genom att ett system har utvecklats som täcker kun- dens behov för automatisk produktmatchning. Matchningssystemet är baserat på etablerade klassificeringsalgoritmer, och kan genomföra matchningar med hög säkerhet trots oregelbun- denheter i produktdatan. Detta ger kunden möjlighet att automatiskt godkänna matchningar med hög säkerhet, och underlättar kraftigt det manuella arbetet i övrigt genom matchnings- förslagen.
En viktig aspekt av systemet för kunden är skalbarhet, på grund av de expansionsplaner som kunden har för systemet. Detta har tagits i åtanke genom parallelliseringen av automatch- ningen per produktkategori och implementationen av flera algoritmer med olika prestan- dakrav.
Modulariteten i automatchningskoden gör att systemet lätt kan vidareutvecklas, och alterna- tiva algoritmer enkelt kan läggas till vid behov. Skrivningen av användarmanual och koddo- kumentation underlättar också vidareutvecklingen av systemet.
En annan viktig aspekt är att systemet ger kunden kontroll över exakt vad som läggs in i deras befintliga system, genom att matchningssystemet arbetar mot separata databastabel- ler. Administrationsgränssnittet är utvecklat med hänsyn för enkel integration till kundens nuvarande interna system, och med fokus på användbarhet för att göra det till ett naturligt tillägg till kundens arbetsprocess.
6.1.2
Alternativa implementationsmetoder
En alternativ implementationsmetod som projektgruppen kunde ha valt vore att endast im- plementera en matchningsalgoritm. Detta skulle ha möjliggjort utvecklandet av ett system som inte behöver vara lika modulärt. Genom detta skulle projektgruppen kunnat spara tid vid implementationen samt att algoritmen möjligtvis hade kunnat förbättrats till att nå bättre resultat än det som åstadkommits av de två algoritmerna. Samtidigt är det mycket svårt att förutsäga vilken algoritm som kommer passa bäst till ett visst problem, och modulariteten
6.1. Resultat
i koden har skapat goda förutsättningar för testning och implementation av andra alterna- tiv. Hade mer tid funnits i projektet kunde det ha varit fördelaktigt att tidigt testa ännu fler algoritmer, för att sedan välja den bästa och justera den till att prestera så bra som möjligt. Ett annat alternativt implementationsätt som projektgruppen kunde ha använt är testdriven utveckling. Detta innebär att testet för en funktion skrivs före själva funktionen skrivs. [24] Användandet av denna metod hade stridit mot hur projektgruppen skrev sina tester eftersom testerna oftast skrevs efter funktionerna och klasserna skrevs. Mot slutet av projektet skrevs dock testerna tillsammans med funktionerna. Detta gällde dock endast ett fåtal funktioner och projektgruppen kan inte sägas ha använt sig utav testdriven utveckling. Hade detta istäl- let gjorts från början hade troligtvis bättre tester skrivits eftersom författaren av funktionen själv hade behövt skriva testet.
6.1.3
Algoritmer
En insikt som framkom efter mycket testning och som gick emot kundens önskan var att resultatet av automatchningsalgoritmerna blev bättre om produkternas attribut ignorerades helt, eller att vikterna för attribut sattes väldigt låga, och fokus lades på namnmatchning. Kod för att ändå använda attribut vid matchning finns, men är inaktiverad. För att återaktivera användandet av attribut till fullo behövs endast ett fåtal ändringar: någon enstaka variabel behöver ändras, en överlagring av en funktion behöver raderas, samt en SQL-förfrågan behö- ver ändras. Rekommendationen är dock att detta väntar till att det är säkert att attributdatan i databasen innehåller mindre brus.
Testerna som utfördes under fas fyra visade också att algoritmerna i sitt slutgiltiga tillstånd inte kunde uppnå de krav som satts i projektets början. Detta berodde på att kraven sattes innan någon av projektmedlemmarna fått erfarenhet kring ämnet samt innan projektgruppen gjort en undersökning av databasen. Målet var initialt att kunna matcha 95% av produkterna korrekt. Detta krav ändrades till 70% efter en diskussion med kunden. Projektgruppen tror att det är möjligt att öka mängden korrekta automatchningar genom vidareutveckling av algoritmerna samt korrigering av brus i datamängden.
6.1.4
Förbättringsmöjligheter
Det finns en del brus och felaktigheter i databasen som påverkar resultaten, exempelvis fel värden på attribut eller leverantörsprodukter som är matchade mot två basprodukter. Det se- nare kan påverka algoritmerna kraftigt då de aldrig kan vara helt säkra på vilken basprodukt som liknande leverantörsprodukter ska matchas mot. Resultaten från algoritmerna kan alltså förbättras om kunden kan förbättra sin databas och rensa bort sådana felaktigheter.
Dataförberedelsen för DNN kan även förbättras genom att använda mer avancerade varian- ter av indataförberedelse, några av dessa varianter nämns i kapitel A. Framförallt genom att varje attribut hanteras som att den har ett fixt antal möjliga värden. Varje sådant diskret värde skulle då ses som en egen boolesk parameter i indatan, och där låta parametern anta värdet ett om attributen har det specifika värdet, och annars vara noll.
Kunden har möjligheten att välja om denne verkligen vill ha både DNN och kNN eller om bara en av dem ska användas. Ett alternativ som möjliggörs av systemet är att först använda DNN och sedan använda kNN på de matchningar som DNN har under 99% säkerhet på. På detta sätt fångas de flesta matchningarna via DNN som är snabbare vid stora datamängder, samtidigt som en sekundär kontroll fås för ett lägre antal, men mer svårmatchade, match- ningar. Tack vare modulariteten i koden finns även goda förutsättningar för att implementera andra matchningsalgoritmer vid behov.
6.2. Projektorganisation
6.2
Projektorganisation
Här diskuteras de metoder som har använts inom projektorganisationen, det vill säga: roller och kommunikation.
6.2.1
Roller
Tilldelningen av primära och sekundära roller till gruppmedlemmarna upplevdes som posi- tivt eftersom detta ser till att det oftast kommer finnas åtminstone en person närvarande som är insatt i och kan ta ansvar för varje arbetsområde.
Ett alternativ till detta hade varit att varje projektmedlem endast hade haft en roll. Detta hade minskat antalet områden varje projektmedlem hade haft ansvar för, men samtidigt gett varje projektmedlem större ansvar för sitt huvudområde. Fördelen med detta är alltså att varje projektmedlem hade varit mer insatt i sin egen roll istället för två roller. Nackdelen hade varit att varje projektmedlem inte hade haft någon annan att diskutera metoder eller liknande med eftersom ingen annan hade varit lika insatt.
6.2.2
Kommunikation
Kommunikationen via Discord fungerade väl då det fanns kanaler för gemensamma diskus- sioner, tekniska diskussioner, beslut, rapportering samt lokalbokning.
Det huvudsakliga alternativet till detta var Slack som hade tillfört möjligheten att starta in- dividuella trådar för enskilda problem som uppstod. Eftersom detta är en användbar förmå- ga för problemlösning och arkivering av lösningar efterliknades detta i Discord genom att varje projektmedlem hade möjlighet att skapa nya textkanaler och låsa diskussionerna i de kanalerna till en aktuell fråga. Med denna lösning kunde projektgruppen hålla parallella dis- kussioner och snabbt återhämta lösningar till återkommande problem. Dock har inte kanalen för tekniska diskussioner använts särskilt mycket på Discord och därför anses detta inte vara något som har varit begränsande.
Utöver användningen av mjukvara har även utveckling i grupp hjälpt med kommunikatio- nen. Då alla arbetade i samma utrymme kunde alla som jobbade i grupp ställa frågor direkt till varandra och få omedelbara svar från den som hade djupast förståelse för ett givet system eller metod.
6.3
Planering
Detta avsnitt består av en diskussion av projektgruppens planering, det vill säga: scrum, sprintar och möten
6.3.1
Scrum
Projektgruppen anpassade scrum genom att låta varje projektmedlem rapportera vad de ha- de gjort och planerade att göra dagligen i en Discord kanal. Denna lösning fungerade mindre bra. Detta för att faserna före och efter utvecklingen till mestadels bestod av dokumentredi- gering och därmed ansåg inte projektgruppen att det var intressant att veta vad varje pro- jektmedlem gjorde under dessa faser. Under utvecklingsfasen användes kanalen dock mer frekvent eftersom det var viktigare att koordinera arbetet när varje projektmedlem kunde arbeta på olika delar av systemet.
Ett alternativ till detta hade varit att ha korta möten varje dag där projektmedlemmarna kun- de berätta vad de gjorde dagen innan samt vad de planerade att göra samma dag. Detta följer
6.3. Planering
scrum-standarden närmare i form av en daily scrum och rekommenderas generellt för utveck- ling med denna metod. [19] Detta ansågs inte lämpligt då kandidatprojektet endast går på halvtid och det därmed fanns dagar då ingen projektmedlem arbetade med projektet. Nackdelen med scrum kan vara att processen kräver resurser under projektets gång för att genomföras korrekt. Eftersom projektgruppen hade valt en avskalad version av scrum hade kravet på dessa resurser minskat men inte försvunnit. Den avskalade metoden krävde fort- farande planeringsmöten och sprint reviews. En alternativ, icke-agil, process hade krävt mer resurser för planering i början av projektet men tillåtit lägre resurskostnad under projektets senare faser.
6.3.2
Sprintar
Projektgruppen arbetade under sprintar som pågick i en till två arbetsveckor. Genom varie- rande sprintlängd kunde projektgruppen anpassa sprintstart och slut efter inlämningar och deadlines.
Nackdelen med varierande längd på projektets sprintar är att de kunde gjort planeringen av dessa sprintar svårare. Om varje sprint hade samma längd hade gruppen fått mer erfarenhet av att jobba i en specifik tidsram. Dock ansågs en varierande längd på sprintar acceptabel eftersom inte var rimligt att ha en inlämning efter halva sprinten eftersom detta hade gjort det svårt att skapa sprintmål. På grund av detta var det bättre att korta ner sprinten till en vecka vid dessa tillfällen.
Ett alternativ mot scrum och sprintar är kontinuerlig leverans (eng. continuous delivery). Detta går ut på att projektgruppen alltid har mjukvara som går att leverera. För att uppnå detta måste projektgruppen arbeta i korta cykler där användbar mjukvara skapas. [25] Detta är dock inte en metod som var lämplig vid detta projekt då det inte fanns något att levere- ra förrän algoritmerna var grundligt implementerade. Hade uppdraget exempelvis varit att skapa en hemsida istället hade projektgruppen kunnat implementera en viss funktion i taget och därmed alltid haft en fungerande hemsida. På detta sätt har användargränssnittet nästan alltid varit levererbart och därmed den enda delen som kunde följa denna utvecklingsmetod, men användargränssnittet var inte den viktigaste delen av systemet och därför ansågs inte detta vara en lämplig metod.
6.3.3
Möten
Måndagsmötena var ett mycket användbart medel för att regelbundet fokusera om arbetet när det behövdes och tillförde en strikt rutin till utvecklingen då detta saknades i övriga projektmoment.
Handledarmötena tillförde däremot inte lika mycket nytta under projektet. Detta berodde till största del på att endast fyra handledarmöten hölls under projektets gång. Orsaken till detta var att det var svårt att planera in handledarmöten då handledaren och projektgruppen hade scheman som krockade mycket. Samtidigt tyckte inte handledaren att fler handledarmöten behövdes.
Även kundmötena var få till antalet på grund av att kunden var belägen i en annan ort. Trots detta fungerade samarbetet med kunden bra på grund av att möten över röstkommunikation hölls mer regelbundet och på grund av att kunden gav mycket frihet till projektgruppen gällande utvecklingen av systemet.
6.4. Utveckling
6.4
Utveckling
Under utvecklingen av systemet använde sig projektgruppen av grupprogrammering, kod- granskning och systemanatomin. Dessa diskuteras i kommande delavsnitt.
6.4.1
Grupprogrammering
Projektgruppen bestämde tidigt i projektet att utvecklingen skulle ske via grupprogramme- ring. Detta innebar att varje person i gruppen kodade exempelvis en egen funktion för att se till så att flera personer i gruppen inte gjorde exakt samma sak. Fördelen med grupp- rogrammering var alltså att alla projektmedlemmar aktivt kunde programmera eller skriva dokument. Det var även enkelt att ställa frågor då minst en annan projektmedlem arbetade med samma modul.
Ett alternativ till grupprogrammering är parprogrammering. Parprogrammering går ut på att två projektmedlemmar kodar på samma dator. Detta gör att en projektmedlem som kal- las ”föraren” skriver koden och den andra som kallas ”navigatör” finns där för att diskutera med och för att den kan kommentera det som föraren har gjort. [26] Sedan får de två projekt- medlemmarna själva avgöra när de ska byta roller så att båda får skriva kod. Tanken bakom detta utvecklingmetod är att både förare och navigatör ska kommunicera kontinuerligt med varandra medan de skriver koden och på så sätt säkerställa att utvecklingen sker effektivt. Grupprogrammering valdes istället för att den använder sig av en kommunikativ utveck- lingsprocess som liknar parprogrammering utan att någon utvecklare kan känna att den inte aktivt tillför till utvecklingen medan den agerar som navigatör.
6.4.2
Kodgranskning
Koden granskades när en projektmedlem gjorde en pull request. I samband med detta testa- des även koden automatiskt via Travis CI.
En alternativ granskningsmetod är att koden inte testas automatiskt utan den som granskar koden måste ladda ner den och testa den lokalt. Fördelen med denna metod är om tjänsten för automatisk testning får fel på grund av att något program eller paket saknas. Detta ger endast onödiga fel som inte har något att göra med om koden i sig fungerar. Med delade och väl- uppdaterade testfall hade denna metod fungerat lika väl som den automatiska testningen. Nackdelen med metoden är annars att det kan anses vara onödigt arbete att behöva ladda ner koden och testa den manuellt, speciellt om det är flera småfel som måste korrigeras. Dock är det enkelt att undvika småfelen om projektmedlemmen som lägger upp koden först testar den lokalt på sin egna dator för att se att allting fungerar som det ska. Utöver detta sparas en del tid för kodgranskaren genom att koden testas automatiskt eftersom kodgranskaren endast behöver fokusera på granskningen och kan låta testerna utföras automatisk under tiden.
6.4.3
Systemanatomi
Vid början av projektet var systemanatomin ett användbart hjälpmedel för att tydliggöra sy- stemets struktur. I synnerhet hjälpte systemanatomin strukturering av systemets olika bero- enden mellan delsystem och funktioner. Den uppdaterade systemanatomin som skapades under slutet av projektet tjänade inte samma funktion eftersom systemet redan var utveck- lat. Denna kunde dock istället fungera som en förklarande illustration av systemet som kan inkluderas i systemdokumentationen som levereras till kunden.
Utöver detta användes systemanatomin inte under utvecklingsfasen, och detta berodde till stor del på att endast några få personer utvecklade modulerna vilket gjorde att dessa per-
6.5. Tester
soner ändå kunde upprätthålla en god kännedom av systemet. Överlag var systemet också relativt simpelt, och utan krav eller funktioner som behövde förändras under utvecklingens gång. I ett projekt där fler personer är involverade eller där systemets struktur kontinuerligt behöver uppdateras kunde nog en systemanatomi ha varit ett mer värdefullt verktyg än i detta projekt.
6.5
Tester
Metoderna för testning av systemet beskrivs utifrån testfilosofin, enhetstester och acceptans- tester. Dessa beskrivs i följande delavsnitt.
6.5.1
Testfilosofi
Testfilosofin bottom-up som projektgruppen använde fungerade mindre bra då utvecklandet av systemet påbörjades några veckor före testerna skrevs. Detta gjorde att en stor andel funk- tioner inte hade tillhörande tester. På grund av detta fick några projektmedlemmar spendera en dryg vecka på att skriva tester till funktioner som redan hade skrivits. I samband med det- ta ignorerades testfilosofin eftersom det var många tester att skriva och systemet hade inte implementerats utifrån någon specifik strategi.
Det finns ett flertal alternativ till testfilosofin som projektgruppen har använt sig av. Några exempel är top-down och sandwich testing. Top-down är motsatsen till bottom-up vilket alltså innebär att funktionerna högst upp i hierarkin testas först och därmed skapas stubs för funk- tionerna som är längre ner i hierarkin. Sandwich testing innebär att tester skrivs för funktioner i mitten av funktionshierarkin först och sedan skrivs tester för funktioner som är både upp- åt och neråt i hierarkin samtidigt. Detta gör att stubs måste skrivas för funktionerna som är längre ner i hierarkin och drivers för funktionerna som är högre upp i hierarkin. Anledningen till att top-down och sandwich testing inte valdes var främst för att de funktioner som var högst upp i hierarkin inte kunde testas automatiskt. Detta beroende på att det hade tagit för lång tid att utföra testerna då eftersom dessa funktioner krävde mer processorkraft än vad som kändes lämpligt att använda på Travis CI.
6.5.2
Enhetstester
När det gäller enhetstesterna skrevs dessa ett tag efter att funktionerna och klasserna redan skrivits. Komplikationen med att lägga upp funktionen före testet innebär att när testet väl läggs upp kanske inte testerna går igenom eftersom det inte är säkert att funktionen fungerar som det är tänkt om den inte har testats. Detta gör att projektmedlemmen som skrev testet även måste korrigera funktionen för att kunna lägga upp testet eftersom Travis CI inte lå- ter kod läggas upp om testerna misslyckas. Därför är detta inte en rekommenderad metod, speciellt inte då testerna oftast skrevs av andra projektmedlemmar än de som skrev funktio- nerna.
En rekommenderad metod i detta projekt hade varit att personen som skrev funktionen skrev ett tillhörande test samtidigt så att inte funktionen lades upp före testet. Denna metod är re- kommenderad eftersom testerna gick ut på att se om systemet bibehöll samma funktionalitet och därmed har projektmedlemmen som skrev funktionen bäst förståelse över hur testet bör skrivas.
Någonting projektgruppen märkte mot slutet av projektet var att Travis CI exekverade på en gammal Ubuntu-version vilket gjorde att det inte var möjligt att få senaste versionen av vissa program. Detta gjorde att vissa funktioner inte kunde testas via Travis CI och behövdes därför testas lokalt. Hade projektgruppen känt till detta från början hade eventuellt en annan
6.6. Dokument
tjänst för automatisk testning av kod valts där all kod kunde ha testats automatiskt istället för att utföra några tester lokalt.
6.5.3
Acceptanstester
Acceptanstesterna gick ut på att se om systemet uppnådde de satta kraven. Dessa tester var de absolut sista testerna som utfördes och även dessa utfördes då projektgruppen var sam- lad. En alternativ metod till detta är att utföra acceptanstester kontinuerligt genom projektet för att hela tiden veta om systemet uppnår kraven. Detta alternativ hade varit en bra idé ef- tersom projektgruppen hade vetat om det var något som behövde korrigeras för att nå kraven under projektets gång. Denna metod hade gjort det möjligt för projektgruppen att upptäcka att systemet inte uppnådde alla krav mot slutet av projektet.
6.6
Dokument
Här diskuteras för- och nackdelar med verktyg och metoder vi har använt för att redigera och granska dokument.
6.6.1
Redigering
Ett alternativ som övervägdes istället för Sharelatex var den liknande tjänsten Overleaf och en kombinerad användning av lokal dokumentredigering och versionshantering med Git. Fördelen med att välja Overleaf var möjligheten att redigera samma projekt samtidigt från flera olika konton utan en betald prenumeration på tjänsten. Nackdelen med Overleaf låg i att kompilering tar längre tid än Sharelatex, speciellt vid kompilering av större projekt där många redigerar samtidigt. Detta upptäcktes under tidigare projektarbeten som en del av projektmedlemmarna hade.
Ett annat alternativ som övervägdes var lokal dokumentredigering och versionshantering med Git där en kopia av källkoden behålls för alla tidigare iterationer av varje TeX doku- ment. Detta kunde ha underlättat om tidigare iterationer av dokument innehöll information som var användbart senare under projektets gång. Nackdelen med detta hade varit om flera projektmedlemmar korrigerade samma dokument och inte kommunicerade tydligt vad de arbetade med, då det hade kunnat uppstå konflikter vid sammanfogningen av respektive projektmedlems version av dokumentet. Projektgruppen valde istället att ladda upp doku- menten på Google Drive vid de två sista inlämningarna och lät därmed den tjänstens ver-