Optimering och visualisering av en beläggningskammare

2018 | LIU-IDA/LITH-EX-G--18/011--SE

Op mering och visualisering av

en beläggningskammare

Op miza on and visualiza on of a coa ng chamber

Tjelvar Guo

Daniel Johnsson

Johan Karlsson

Rasmus Larsson

Emil Luusua

Axel Nordanskog

Alexander Zeijlon

Erik Örjehag

Handledare : Henrik Henriksson Examinator : Kris an Sandahl

Upphovsrä

De a dokument hålls llgängligt på Internet – eller dess fram da ersä are – under 25 år från publi-ceringsdatum under förutsä ning a inga extraordinära omständigheter uppstår.

Tillgång ll dokumentet innebär llstånd för var och en a läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och a använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrä en vid en senare dpunkt kan inte upphäva de a llstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För a garantera äktheten, säkerheten och

llgängligheten finns lösningar av teknisk och administra v art.

Upphovsmannens ideella rä innefa ar rä a bli nämnd som upphovsman i den omfa ning som god sed kräver vid användning av dokumentet på ovan beskrivna sä samt skydd mot a dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens li erära eller konstnärliga anseende eller egenart.

För y erligare informa on om Linköping University Electronic Press se förlagets hemsida h p://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 star ng from the date of publica on barring excep onal circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educa onal purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are condi onal upon the consent of the copyright owner. The publisher has taken technical and administra ve measures to assure authen city, security and accessibility.

According to intellectual property law the author has the right to be men oned when his/her work is accessed as described above and to be protected against infringement.

For addi onal informa on about the Linköping University Electronic Press and its procedu-res for publica on and for assurance of document integrity, please refer to its www home page: h p://www.ep.liu.se/.

©Tjelvar Guo, Daniel Johnsson, Johan Karlsson, Rasmus Larsson, Emil Luusua, Axel Nordanskog, Alexander Zeijlon, Erik Örjehag

Denna rapport behandlar kandidatprojektet Optily som utförts av 8 studenter på Tek-niska högskolan vid Linköpings universitet. Hela processen från planering och utveckling till resultatet av den slutgiltiga produkten presenteras och diskuteras. Även erfarenheter som fångats upp av projektgruppen under denna process behandlas.

Företaget Ionbond Sweden AB, som är kund i projektet, arbetar med ytbeläggning av rundskaftade föremål. För att underlätta planeringen av hur deras beläggningskammare ska packas har ett datorprogram kallat Optily utvecklats av projektgruppen. Detta har med framgång ökat effektiviteten i packningen av maskinerna vilket leder till ökad omsättning eftersom fler föremål kan köras tillsammans. Utöver ökad omsättning bidrar detta också till att hjälpa Ionbond Sweden AB att nå sina uppsatta miljömål. Programmet har även lyckats förbättra arbetssituationen för de anställda genom att på förhand visa hur maskinerna ska packas och vilka ordrar som då kommer få plats.

Genom att integrera systemet med Ionbond Sweden AB:s nuvarande produktdatabas hanteras alla olika produkter som kan behöva ytbeläggas. Packningens utformning tas se-dan fram genom att placera objekten med hjälp av en optimeringsalgoritm vilken når ett resultat som konsekvent är bättre än vad planeringsansvarig tidigare lyckats med. Resul-tatet av optimeringen visualiseras sedan med hjälp av en schematisk bild på hur objekten ska placeras i beläggningskammaren för att på bästa sätt utnyttja den tillgängliga volymen.

Vi vill tacka våra kontakter på Ionbond Sweden AB: Greger Håkansson, Johnny Andersson och Tobias Malm för ett gott samarbete. Dessutom vill vi tacka såväl vår handledare Henrik Henriksson som vår examinator Kristian Sandahl för god vägledning under arbetets gång.

Innehåll

Översatta termer xvii

I

Gemensam del

1

3.4 Model View Controller . . . 10

3.5 Utvecklingsmetodiken Scrum . . . 10 3.6 Trello . . . 12 3.7 Slack . . . 12 3.8 Automatiserad testning . . . 12 3.9 Optimering . . . 13 3.9.1 Beräkning av undre gräns . . . 13 3.9.2 oj! Algorithms . . . 13 3.9.3 Heuristiska metoder . . . 14 4 Metod 15 4.1 Utvecklingsarbetet . . . 15

4.2.2 Trello . . . 16

4.2.3 Möten . . . 16

4.2.4 Projektets implementation av Scrum . . . 17

4.2.5 Projektgruppens arbetsflöde med Git . . . 18

4.3 Metod för att svara på frågeställningarna . . . 18

4.3.1 Identifiering av kundens behov . . . 18

4.3.2 Erfarenhetsfångst . . . 19

4.3.3 Metod för att identifiera nyttan av en systemanatomi . . . 19

4.3.4 Undersöka potential för miljövinster . . . 20

5 Resultat 21 5.1 Systembeskrivning . . . 21

5.1.1 Integrering med befintlig databas . . . 21

5.1.2 Planera körning . . . 22

5.1.3 Optimering . . . 23

5.1.4 Visualisering . . . 24

5.2 Planeringsansvariges uppfattning av systemet . . . 26

5.3 Gemensamma erfarenheter . . . 26 5.3.1 Scrumrelaterade erfarenheter . . . 27 5.3.2 Vidareutveckling . . . 27 5.3.3 Verktygsrelaterade erfarenheter . . . 27 5.4 Användning av systemanatomin . . . 28 5.5 Hjälp för att nå miljömålen . . . 30

5.6 Översikt över individuella bidrag . . . 31

6 Diskussion 35 6.1 Resultat . . . 35 6.1.1 Värdeskapande . . . 35 6.1.2 Erfarenhetsfångst . . . 35 6.1.3 Anpassa systemanatomin . . . 36 6.1.4 Förbättring av miljöarbetet . . . 36 6.2 Alternativa implementationssätt . . . 36 6.2.1 Kotlin . . . 36 6.2.2 Alternativa programbibliotek . . . 37

6.2.3 Konsekvenser av valda metoderna . . . 38

6.2.4 Källkritik . . . 38

6.3 Arbetet i ett vidare sammanhang . . . 38

6.3.1 Samhälliga aspekter . . . 38

6.3.2 Etiska aspekter . . . 39

6.4 Förbättringsmöjligheter hos Optily . . . 39

7 Slutsatser 41

II Individuella delar

43

A.1.1 Syfte . . . 45

A.1.2 Frågeställningar . . . 45

A.3.1 Lean Startup . . . 46

A.3.2 MVP . . . 46

A.4 Metod . . . 47

A.5 Resultat . . . 47

A.5.1 Verkliga MVP:er . . . 47

A.5.2 Optilys MVP . . . 48

A.5.3 Utvecklingsprocessen . . . 50

A.5.4 Kundens användande av gruppens MVP . . . 50

A.6 Diskussion . . . 50

A.6.1 Jämförelse med MVP:er gjorda av företag . . . 51

A.6.2 MVP:ns påverkan på utvecklingsprocessen . . . 51

A.6.3 MVP:n värde för kunden . . . 52

A.7 Slutsatser . . . 52

B Val av programvarulicens, SaaS eller On-premises av Daniel Johnsson 53 B.1 Introduktion . . . 53 B.1.1 Syfte . . . 53 B.1.2 Frågeställningar . . . 53 B.2 Bakgrund . . . 54 B.3 Teori . . . 54 B.3.1 Programvarulicenser . . . 54 B.3.2 Nätverkseffekt . . . 55 B.4 Metod . . . 55 B.4.1 Begränsningar . . . 55 B.5 Resultat . . . 55 B.5.1 Från ett vinstperspektiv . . . 55 B.5.2 Från ett kundperspektiv . . . 56 B.5.3 Parametrar . . . 56 B.6 Diskussion . . . 57 B.6.1 Resultat . . . 57 B.6.2 Källor . . . 58 B.6.3 Projektperspektiv . . . 58 B.7 Slutsatser . . . 58

C Kotlin utan att skriva Kotlin av Johan Karlsson 61 C.1 Introduktion . . . 61 C.1.1 Syfte . . . 61 C.1.2 Frågeställningar . . . 61 C.2 Bakgrund . . . 62 C.2.1 Avgränsningar . . . 62 C.3 Teori . . . 62

C.3.1 Java Virtual Machine . . . 62

C.3.2 Halsteads komplexitetsmått . . . 63

C.3.3 Objektorienterade språk och Halsteads komplexitetsmått . . . 63

C.3.4 Undersöka prestanda . . . 64

C.4 Metod . . . 64

C.4.1 Val av funktionalitet att undersöka . . . 64

C.4.2 Korrekthet . . . 65 C.4.3 Prestanda . . . 65 C.4.4 Läsbarhet . . . 65 C.5 Resultat . . . 65 C.5.1 Quicksort . . . 65 C.5.2 Klassexempel . . . 68

C.6.2 Resultat - Car . . . 69

C.6.3 Andra val av kod att testa . . . 70

C.6.4 Andra metodval . . . 70

C.7 Slutsatser . . . 71

D Effektiv kodgranskning av Rasmus Larsson 73 D.1 Introduktion . . . 73 D.1.1 Syfte . . . 73 D.1.2 Frågeställningar . . . 73 D.2 Bakgrund . . . 74 D.3 Teori . . . 74 D.3.1 Formell kodgranskning . . . 74 D.3.2 Lättviktig kodgranskning . . . 76 D.4 Metod . . . 77 D.5 Resultat . . . 78

D.5.1 Effekt på detta projekt . . . 78

D.5.2 Formell granskning, svar på enkät . . . 79

D.5.3 Formell granskning, tidigare resultat . . . 82

D.6 Diskussion . . . 82

D.6.1 Effekterna kodgranskning hade på detta projekt . . . 82

D.6.2 Formell kodgranskning . . . 82

D.6.3 Lättviktig kodgranskning . . . 83

D.6.4 Källkritik . . . 84

D.7 Slutsatser . . . 85

E Metoder för hinkpackning, ett NP-svårt problem av Emil Luusua 87 E.1 Introduktion . . . 87 E.1.1 Syfte . . . 87 E.1.2 Frågeställningar . . . 88 E.2 Bakgrund . . . 88 E.3 Teori . . . 88 E.3.1 Trädsökning . . . 88 E.3.2 Dominanskriteriet . . . 89 E.3.3 Kolumngenerering . . . 89 E.4 Metod . . . 89 E.4.1 Prestandatestning . . . 90 E.5 Resultat . . . 90

E.5.1 Alternativa lösningsmetoder . . . 90

E.5.2 Implementation av en objektbaserad trädsökning . . . 92

E.5.3 Prestandatester . . . 92

E.6 Diskussion . . . 93

E.6.1 Lösningsmetodernas prestanda . . . 93

E.6.2 Lösningsmetodernas lämplighet för projektet . . . 94

E.6.3 Testmetod . . . 94

E.6.4 Källkritik . . . 95

E.7 Slutsatser . . . 95

F Värdet av beskrivande versionsinformation i mindre projekt av Axel Nordanskog 97 F.1 Introduktion . . . 97

F.1.1 Syfte . . . 97

F.2 Bakgrund . . . 98

F.3 Teori . . . 98

F.3.1 Fokusgruppsmetoden . . . 98

F.3.2 Hur incheckningsmeddelanden bör skrivas . . . 99

F.4 Metod . . . 99

F.4.1 Fokusgrupp . . . 99

F.4.2 Kompletterande tidskostnader . . . 100

F.4.3 Beräkning av total tidskostnad . . . 100

F.4.4 Studerande av incheckningsmeddelanden . . . 101

F.5 Resultat . . . 101

F.5.1 Effekt . . . 101

F.5.2 Tidskostnad . . . 102

F.5.3 Hur incheckningsmeddelanden skrivits . . . 103

F.6 Diskussion . . . 104

F.6.1 Resultat . . . 104

F.6.2 Metod . . . 105

F.6.3 Källkritik . . . 106

F.7 Slutsatser . . . 107

G Nyttan av ett strukturerat arbetsflöde i agil utveckling av Alexander Zeijlon 109 G.1 Introduktion . . . 109 G.1.1 Syfte . . . 109 G.1.2 Frågeställningar . . . 109 G.2 Bakgrund . . . 110 G.3 Teori . . . 110 G.3.1 Avgränsning . . . 110 G.4 Metod . . . 110 G.4.1 Enkäten . . . 110 G.4.2 Värderingsfrågor . . . 111 G.4.3 Egensvarsfrågor . . . 111 G.4.4 Skattning av data . . . 111 G.5 Resultat . . . 112 G.5.1 Scrums event . . . 112 G.5.2 Scrums artefakter . . . 114

G.5.3 Avvikelser från Scrums standard . . . 116

G.5.4 Avslutande frågor . . . 118

G.5.5 Sammanställning av värderingsfrågor . . . 119

G.6 Diskussion . . . 119

G.6.1 Processens vidareutveckling . . . 120

G.7 Slutsatser . . . 121

H Garantier utan testning av Erik Örjehag 123 H.1 Introduktion . . . 123 H.1.1 Syfte . . . 123 H.1.2 Frågeställningar . . . 123 H.1.3 Avgränsningar . . . 123 H.2 Bakgrund . . . 124 H.3 Teori . . . 124

H.3.1 Introduktion till testning . . . 124

H.3.2 Statisk kodanalys . . . 125

H.3.3 Programspråket Whiley . . . 125

H.3.4 Programspråket SPARK . . . 125

H.5.2 Pre-conditions kan ersätta kommentarer och asserts . . . 127

H.5.3 Ett exempel från Optily . . . 128

H.5.4 Heltäckande testfall är svåra att skriva . . . 130

H.6 Diskussion . . . 131

H.7 Slutsatser . . . 132

Figurer

1.1 Hur föremål placeras i en beläggningskammare. . . 3

3.1 MVC-processen . . . 10

4.1 Illustration av gruppens arbetsflöde med Git. . . 18

5.1 Skärmdump av programmet från databasfliken . . . 22

5.2 Skärmdump av programmet från orderlistafliken . . . 23

5.3 Skärmdump av programmet från parametrarfliken . . . 23

5.4 Resultatsvisualisering i användargränssnittet . . . 25 5.5 Resultattabell i PDF-dokument . . . 25 5.6 Resultatsvisualisering i PDF-dokument . . . 26 5.7 Första systemanatomin . . . 29 5.8 Andra systemanatomin . . . 30 5.9 Slutgiltiga systemanatomin . . . 31

5.10 Diagram över dataflöden . . . 31

A.1 Första skissen av Optily . . . 49

C.1 Vägen från kod till exekvering . . . 62

D.1 Programmerings-process enligt Michael E. Fagan . . . 75

D.2 Granskningsprocessen i detta projekt . . . 76

D.3 Andel reviderade aktiviteter under hela projektets gång . . . 78

D.4 Uppskattad tidsåtgång per arbetsdag på granskning i detta projekt . . . 78

D.5 Uppskattad effekt av granskning i detta projekt . . . 79

D.6 Respons på påståendet ”Denna typ av granskning hade varit utförbar på detta projekt” . . . 80

D.7 Respons på påståendet ”Denna typ av granskning hade fungerat bättre än gransk-ningen genom Trello” . . . 80

D.8 Respons på påståendet ”Denna typ av granskning hade gått att få till med avse-ende på schemaläggning” . . . 81

D.9 Respons på påståendet ”Denna typ av granskning hade gått att få till med avse-ende på tidsåtgång” . . . 81

E.1 Utseendet för ett objektbaserat sökträd. . . 91

E.2 Utseendet för ett hinkbaserat sökträd. . . 91

E.3 Andel testinstanser lösta till optimalitet på en tid under 60 sekunder. . . 93

G.1 Hur tydliga tycker du att syftet med Scrums events har varit? . . . 112

G.2 Till hur stor hjälp har Scrums events varit för att ge dig en bra helhetsbild över utvecklingen? . . . 113

Tabeller

C.1 Halsteads komplexitetsmått applicerat på C.1 . . . 64 C.2 Halsteads komplexitetsmått applicerat på både Java- och Kotlinversionen av

Quicksort . . . 67 C.3 Prestandaresultat för Quicksort . . . 67 C.4 Halsteads komplexitetsmått applicerat på både Java- och Kotlinversionen av Car . 68 C.5 Prestandaresultat för Car . . . 69 D.1 Steg i inspektionerna I1och I2 . . . 75

D.2 Tillåtna ansvarsfördelningar i granskningsprocessen som utförts i detta projekt . . 77 E.1 Resultat av utförda prestandatest. . . 92 F.1 Skrivtidsdata för var gruppmedlem och totalt: Incheckningsmeddelanden. . . 102 F.2 Skrivtidsdata för var gruppmedlem och totalt: Granskningsunderlag. . . 103 F.3 Andel incheckningsmeddelanden som beskrev vad som ändrats respektive varför

och hur det gjorts. . . 103 G.1 Övringa synpunkter? . . . 113 G.2 Vad tycker du hade kunnat göras bättre gällande Product backlog, för att

under-lätta utvecklingen? . . . 115 G.3 Vad tycker du hade kunnat göras bättre gällande Sprint backlog, för att underlätta

utvecklingen? . . . 116 G.4 Kopplat till din skattning i värderingsfråga 7, beskriv på vilket sätt det påverkades

och om det var negativt eller positivt? . . . 117 G.5 Är det något från standarden som utmärkt sig som extra bra när det gäller att få

ett strukturerat arbetsflöde? . . . 118 G.6 Är det något som har upplevts onödigt? . . . 118 G.7 Sammanställning av uträknade medelvärden för värderingsfrågor 1 - 7 . . . 119

Term/Förkortning Definition Sammanhang

beläggningskammare Den maskin som utför ytbeläggningen. ytbeläggning bivillkor Villkor som lösningen i ett

optimeringspro-blem måste uppfylla för att vara giltig.

optimering

boilerplate-kod Kod som behöver skrivas flera gånger utan några större förändringar.

programmering

bord Platta i botten av maskiner vari satelliter fästs.

ytbeläggning

BPP Bin Packing Problem: Ett

optimeringspro-blem för att fördela föremål i hinkar.

optimering

granskningsunderlag En beskrivning av förändringar som gjorts på en gren. Tänkt att agera underlag vid kodgranskning.

kodgranskning

heuristik En metod som bygger på att göra intelligen-ta gissningar för att snabbt komma fram till en bra, men ej garanterat optimal, lösning i ett optimeringsproblem.

optimering

historik En samling incheckningar med kopplingar för att indikera deras respektive ursprung.

Git

hylsa Adapter som används för att fästa objekt i tallrikar.

ytbeläggning

målfunktion Den funktion vars värde ska maximeras el-ler minimeras i ett optimeringsproblem.

optimering

s. Substantiv. ordklass

satellit Stativ varpå tallrikar träs. ytbeläggning

tallrik Rund platta med runda hål vari objekt som ska ytbeläggas placeras.

ytbeläggning

v. Verb. ordklass

versionsinformation Information om en version. Innefattar så-väl incheckningsmeddelanden som aktivi-tetsbeskrivningar.

konfigurations-hantering/Git

Svenskt term Engelsk term Sammanhang

gren branch Git

incheckning commit(s./v.) Git

incheckningsmeddelande commit message Git

jämförelse diff Git

sammanfogning merge(s.)/merging(v.) Git

utgåva release(s.)

konfigurations-hantering

utgåvebeskrivning release notes

konfigurations-hantering

utvecklingskatalog repository Git

Del I

1

Inledning

En teknik för att ytbelägga metallföremål, till exempel borrar eller fräsar, är att lägga en spän-ning över dem och låta joner attraheras till dem. Det görs i en så kallad beläggspän-ningskammare som illustreras i figur 1.1. Denna process ger föremålen en yta som kan nötas ner istället för själva föremålen. När beläggningen senare har nötts tunn kan den avlägsnas kemiskt innan föremålen beläggs på nytt. På så vis kan de få i princip oändlig livstid.

En körning med denna typ av beläggningskammare kräver dock stora mängder elektrici-tet och energiåtgången är ungefär lika stor oavsett hur fylld kammaren är. För att minimera kostnaden och energiåtgången, per belagt föremål, är det därför viktigt att fylla beläggnings-kammaren till så stor grad som möjligt. För att åstadkomma detta har projektgruppen ut-vecklat ett datorprogram som kan beräkna samt visualisera hur maskinen bör packas.

Projektet utfördes av åtta studenter vid Linköpings tekniska högskola. Fem av studenter-na läser till civilingenjör i datateknik och tre läser till civilingenjör i mjukvaruteknik. Projektet som studenterna utfört resulterade dels i denna kandidatrapport men också i programmet Optily som utvecklades åt Ionbond Sweden AB.

1.1

Motivering

Sättet på vilket kunden placerar rundskaftade föremål i beläggningskammaren illustreras i figur 1.1. De placeras i hylsor på tallrikar som sedan träs över satelliter på ett bord. Föremålen tenderar att variera i höjd. Det blir därför mycket svårt för planeringsansvarig, vilken är den roll på företaget som sköter planeringen av ytbeläggningen, att fördela tallrikarna över satelliterna på ett sådant sätt att beläggningskammaren fylls optimalt. Det blir även svårt att avgöra om en planerad körning över huvud taget får plats i beläggningskammaren.

Detta projekt har därför gått ut på att utveckla ett datorprogram som underlättar arbetet för planeringsansvarig, där ordrar med föremål som ska ytbeläggas tillsammans kan matas in. Programmet meddelar sedan om de inmatade ordrarna får plats i en körning och om så är fallet redovisas även hur tallrikarna bör placeras för att packas så tätt som möjligt. På så sätt syns tydligt om det finns plats över för ytterligare föremål. Mer bakgrund till varför detta är önskvärt ges i avsnitt 2.

Den här rapporten behandlar utvecklingen och resultatet av datorprogrammet Optily som projektgruppen utvecklat för att lösa tidigare nämnda utmaningar. Stort fokus läggs på att knyta samman arbetet som utförts med de frågeställningar som tas upp i avsnitt 1.3. Ef-tersom programmeringsspråket Kotlin, som teamet beslutade att använda, inte hade använts av någon i teamet förväntades det vara centralt för erfarenhetsfångsten. Ytterligare en aspekt som var viktig i erfarenhetsfångsten var utvecklingsmetodiken Scrum som användes under projektets gång.

1.2

Syfte

Rapporten ämnar att förklara vilken nytta som kan uppnås genom systemet som utvecklats under projektets gång. Det finns uppenbara ekonomiska fördelar av ett fungerande system men även andra typer av fördelar kan uppnås. Exempelvis kan arbetsmiljön för de anställda tänkas förbättras och företagets miljöpåverkan tänkas minskas. Rapporten har också som syfte att förklara metoderna bakom utvecklingen och vilka erfarenheter man kan ta med sig ifrån ett projekt av den här typen.

Rapporten innehåller även individuella delar där projektmedlemmarna enskilt behandlat ett ämne som varit relevant för projektet.

1.3

Frågeställningar

Frågeställningarna syftar till att beskriva projektet och rapporten utifrån intressanta och tan-keväckande frågor.

1. Hur kan Optily implementeras så att värde skapas för kunden? Denna fråga är central

i projektet och ämnar att besvara på vilka sätt Ionbond kan dra nytta av programmet.

2. Vilka erfarenheter kan dokumenteras från detta projekt som kan vara intressanta för

framtida projekt? Detta projekt är ett nischat projekt, gruppen utvecklar en lösning åt en

kund med ett specifikt problem. Det är därför viktigt att fånga erfarenheterna ur detta projekt eftersom de kan komma till användning i andra framtida liknande projekt.

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

syste-manatomi är ett, bland många, sätt att beskriva hur ett system byggs upp. Finns det några särskilda anledningar till att detta är ett bra sätt och hur har det i så fall använts inom grup-pen?

1.4. Avgränsningar

4. Hur kan Optily bistå kunden i att uppnå deras miljömål? Kunden har som mål att

kontinuerligt förbättra sitt arbete när det gäller frågor som miljö och energieffektivitet.

1.4

Avgränsningar

Såväl projektet som rapporten är begränsade; dessa begränsningar presenteras nedan.

1.4.1

Projektet

Varje projektmedlem har en tidsbudget på 400 timmar och projektet har därmed en samman-lagd tidsbudget på 3200 timmar. Projektet gick endast ut på att utveckla ett system som skulle hjälpa planeringsansvarig på att placera rundskaftade föremål i en beläggningsmaskin; and-ra typer av föremål behandlas ej av systemet. Planeringsansvarig har tidigare kunnat placeand-ra föremål från olika kunder på samma tallrik, detta var också något som Optily inte behövde göra. Programmet för inte heller någon typ av historik över körningar och kan inte prioritera vissa ordrar över andra.

1.4.2

Rapporten

Rapporten behandlar vissa ämnen rörande hållbarhet, till exempel energianvändning. Anta-gandet gällande denna grundar sig på genomsnittlig data tillhandahållen av Ionbond Swe-den AB. Datan är uppdelad års- och månadsvis. Gruppen har ingen möjlighet att mäta ener-gianvändningen med Optily i bruk under en sådan tidsperiod och en jämförelse kan därmed inte göras. Rapporten behandlar även arbetsmiljö. Gruppen har ingen heller möjlighet att ut-värdera hur denna påverkats efter långsiktig användning av Optily. Istället görs en intervju efter en kortare användningsperiod för att ändå kunna dra slutsatser gällande arbetsmiljön.

Viss information som projektgruppen får ta del av från Ionbond Sweden AB är hemlig, och får ej delas utanför projektet. På grund av detta kommer rapporten utesluta vissa detaljer gällande projektet.

2

Bakgrund

På företaget Ionbond Sweden AB utförs ytbehandlingar av bland annat rundskaftade före-mål [1]. En av deras beläggningsmaskiner illustreras i figur 1.1 och finns beskriven i av-snitt 1.1. Under sitt arbete har de stött på problem med placering, även det enligt avav-snitt 1.1. Planeringen av hur många föremål, och därmed även tallrikar, som ska ingå i varje kör-ning görs av Ionbond Sweden AB:s planeringsansvarig. Denna planering har tidigare gjorts utifrån uppskattningar med hjälp av Excel som inte medfört någon garanti på att en planerad körning kommer få plats i beläggningskammaren. Det har därför kunnat uppstå situationer då tallrikar inte fått plats när de väl ska placeras i kammaren och istället behövts lämnas till nästa körning. Eftersom en körning kan ta upp emot 12 timmar är det viktigt att packa maskinen så optimalt som möjligt.

Om det visar sig att alla föremål inte får plats kan leveransen av dessa föremål behöva senareläggas. Vid ett sådant tillfälle har planeringsansvarig behövt kontakta berörd kund för att ta reda på vilka föremål som kan vänta. Eftersom maskinerna körs dygnet runt har detta vid vissa tillfällen hanterats utanför arbetstid av planeringsansvarig. Det gör att ickeoptimal planering inte bara får onödigt höga ekonomiska och miljömässiga konsekvenser utan även bidrar till att öka stressen för de anställda.

Datorprogrammet var därför inte bara tänkt att sänka ekonomiska utgifter och miljöpå-verkan genom sänkt energiåtgång. Det var även tänkt att sänka de anställdas stress genom att låta planeringsansvarig arbeta proaktivt snarare än reaktivt.

2.1

Tidigare projekterfarenheter

Studenterna som ingår i gruppen har blandade erfarenheter från tidigare kurser och andra engagemang. En märkbart givande erfarenhet är att D-studenterna har genomfört ett robot-projekt med stort fokus på dokumentation och grupporganisation. De har därför kunnat bi-dra med värdefulla insikter kring till exempel hur en kravspecifikation ska skrivas och vad som bör ingå.

Storlek på projekt Genomgående har tidigare projekt inte genomförts i lika stor

omfatt-ning. En gruppstorlek på åtta personer är något nytt, även storleken på projektet är större än tidigare. Detta såg inte projektmedlemmarna som något problem, tvärt om. Det skulle

snara-re bli intsnara-ressant att genomföra ett projekt som mer liknar något som studenterna kan hamna i senare i arbetslivet.

Kundperspektiv Något som studenterna anser har saknats i tidigare kurser är bland annat

kundaspekten. Dessa kurser har genomförts genom att följa en vattenfallsprocess och tyvärr kan det då vara svårt att se om det som utvecklas faktiskt är vad som efterfrågas. Att med ett tydligt kundperspektiv, och faktisk kund, genomföra ett projekt i iterationer hoppas studen-terna kunna successivt ta fram en produkt som kunden faktiskt vill ha.

Automatiserad testning Studenterna har som uppfattning att testning är viktigt. Något

som studenterna saknat tidigare är ett sätt att testa mjukvaran till större grad än med enbart enhetstester. Studenterna har därför valt att även använda sig av GUI-testning.

3

Teori

Projektgruppen utvecklade systemet med hjälp av olika verktyg, både tekniska verktyg men också processverktyg. Teorin bakom hinkpackningsoptimeringen presenteras tillsammans med de optimeringsstrategier som används. Verktyg och teorin tas upp för att ge läsaren en bättre förståelse för rapporten.

3.1

Kotlin

Gruppen valde att utveckla programmet i programmeringspråket Kotlin [2] som är ett pro-grammeringsspråk utvecklat av JetBrains [3]. Spåket är en vidareutveckling av Java och an-vänds för närvarande till bland annat Androidutveckling. Med Kotlin har JetBrains introdu-cerat en rad nya funktioner som effektiviserar utvecklingen. Bland annat har de introduintrodu-cerat mer säkerhet genom att ändra hanterandet av null-typen [4] för att minska vanliga buggar relaterade till detta. Även operator overloading är något som inte finns i Java men som introdu-cerats i Kotlin [5].

Ett av huvudmålen med Kotlin var att förenkla Javas syntax som i många fall kan tyc-kas onödigt komplicerad. Enligt skaparna krävs mycket onödig kod för att få Java att uppnå önskad funktionalitet med sämre läsbar kod till följd [6]. Ett specifikt exempel gällande list-manipulering kan ses i kodexempel 3.1 och 3.2 för filtrering av positiva tal.

1 val p o s i t i v e N u m b e r s = n u m b e r s . f i l t e r { it > 0 } Kodexempel 3.1: Filtrering i Kotlin. 1 List < Int > p o s i t i v e N u m b e r s = n u m b e r s . s t r e a m () . 2 f i l t e r ( p -> p > 0) . c o l l e c t ( C o l l e c t o r s . t o L i s t () ) ;

Kodexempel 3.2: Filtrering i Java

3.2

IntelliJ IDEA

JetBrains är skaparna av den populära utvecklingsmiljön IntelliJ IDEA [7]. Miljön används främst för Java-utveckling men är också den huvudsakliga miljön för programspråket Kotlin. En av IDEAs många funktioner är till exempel stöd för att konvertera Java-kod till Kotlin-kod helt automatiskt.

3.3

Object-Relational Mapping

ORM står för Object-Relational Mapping och är en teknik för att beskriva relationen mellan ickekompatibla typsystem. Till exempel mellan datatyper i ett programmeringsspråk oc

h databastabeller i MySQL [8] [9]. När relationerna mellan de två typsystemen är specificera-de kan konvertering mellan databasen och programmet ske automatiskt. Detta resulterar i att instanser av klasser i exempelvis Kotlin kan sparas till och hämtas från en relationsdatabas på ett sömlöst vis. Utvecklaren behöver inte designa databastabellerna manuellt utan detta sker automatiskt utifrån specifikationen.

I detta projekt användes en ORM som kallas Hibernate, som är fullt kompatibel med den så kallade JPA-standarden. I denna ORM är det enkelt att skapa relationer mellan objekt genom att skriva annotations i klasserna över de olika medlemsvariablerna. Över en medlemsvariabel av typen List kan man till exempel använda annoteringarna @One-to-One, @One-to-Many och @Many-to-Many för att Hibernate automatiskt ska skapa dessa relationer i databasen.

3.4

Model View Controller

MVC står för Model View Controller och är ett designmönster som användes i projektet [10]. I designmönstret delas arkitekturen upp i tre olika delar för hur data ska sparas, modifieras och presenteras. Detta möjliggör smidig återanvändning av kod och gör det lättare att jobba parallellt med flera utvecklare i samma projekt.

Figur 3.1: MVC-processen (källa: [11])

I datalagret Model sparas data som ska delas mellan Controllers. Man kan säga att da-tan håller applikationens tillstånd. Enstaka tillstånd som inte behöver delas kan ligga i Con-trollern själv. Uppgiften hos applikationens Controllers är att utföra manipulation på datan utifrån användarens interaktion med gränssnittet. På engelska brukar denna manipulation kallas för applikationens Bussiness Logic. Applikationens Views har i uppgift att presentera datan för användaren i ett grafiskt gränssnitt.

3.5

Utvecklingsmetodiken Scrum

Scrum är enligt den officiella Scrumguiden ett ramverk för agil utveckling, där agil i sig syftar till att beskriva ett tankesätt kring utveckling. Processen att skapa en fungerande produkt ska

3.5. Utvecklingsmetodiken Scrum

vara flexibel för att enkelt tillåta ändringar i både planering och utförande. Genom att dela upp projektet i ett antal kortare sprintar kan omstruktureringar lätt införas i projekts tidsplan under början eller slutet av en sprint. Leverans av produkt ska ske iterativt, och målet är att man efter varje iteration ska ha en färdig produkt som ska kunna levereras till kund. I slutet av varje sprint hålls ett review-möte för att sammanfatta arbetet under sprinten. Scrum använder sig av två listor i utvecklingen av produkten. Ett Scrum-team består av produktansvarig, utvecklingsteamet och en utvecklingsledare. [12]

I avsnitt 4.2.4 beskrivs på vilket sätt gruppen avvek från standarden under utvecklingsar-betet.

Product Backlog Syftet med en Product Backlog är att det ska finnas en tydlig lista över vilka

aktiviteter som ska genomföras för att slutföra produkten. Denna lista är dynamisk eftersom kraven på produkten kan ändras.

Sprint Backlog I början av varje sprint skapas en Sprint Backlog. Denna lista innehåller de

aktiviteter teamet vill slutföra och är en delmängd av Product Backlog. Om teamet upptäc-ker att fler aktiviteter behöver genomföras för att klara av en sprint kan de definieras och inkluderas.

Produktansvarig Projektets Product Backlog är produktansvarigs ansvarsområde. Detta

in-nefattar att beskriva aktiviteterna och tydligt förklara syftet med dem för resten av teamet. Denna person ska också prioritera aktiviteterna i projektets Product Backlog samt se till att de reflekterar de krav som produkten ska uppfylla.

Utvecklingsteamet Alla projektmedlemmar, inklusive produktansvarige och

utvecklings-ledaren, är en del av utvecklingsteamet. Det är teamets ansvar och mål att leverera en färdig produkt i slutet av varje sprint.

Utvecklingsledaren Personen som arbetar för att utvecklingsteamet ska följa Scrums regler

och definitioner kallas för utvecklingsledaren. Detta innebär ett ansvar att planera in Scrum-möten, coacha teamet i användandet av Scrum samt reducera potentiella hinder för teamets utövande av Scrum. Exempel på hinder kan vara en otydlig Sprint Backlog, kommunikations-svårigheter i gruppen eller dåliga processverktyg.

Scrum begrepp Inom Scrum används en rad olika begrepp för att beskriva iterationer,

pla-nering och återkoppling på ett väldefinierat sätt. Detta för att skapa struktur och effektivisera möten. Varje event måste ha en förutbestämd längd som inte skall överskridas. Här följer en beskrivning av några av dessa begrepp.

Sprint Under sprinten är det tillåtet att förtydliga eller omförhandla överenskommelser

mellan produktägaren och utvecklingsteamet, till följd av nya lärdomar som uppstått. Detta förutsatt att inga ändringar görs som sänker kvalitetskraven eller riskera att sprintens mål inte möts.

Sprintplanering Under planeringsmötet bestämmer utvecklingsteamet vad som ska

åstad-kommas under den kommande sprint. Detta innefattar vilka aktiviteter som ska genomföras, hur de ska genomföras samt vad som ska levereras i slutet av sprinten. De aktiviteter som skall genomföras flyttas från Product Backlog till Sprint Backlog.

Daily Scrum Syftet med korta dagliga möten är att undersöka hur teamet ligger. Under

mötet ska varje team-medlem rapportera vad personen gjorde igår, planerar att genomföra idag samt vilka hinder personen upplever kan leda till att sprintmålen inte uppfylls.

Sprint review Ett review-möte hålls i slutet av varje sprint, där man sammanfattar vad som gjorts under den gångna sprinten. Under mötet besvaras vilka framsteg som har gjorts och vad som finns kvar att göra. Resultatet av mötet är en reviderad Product Backlog och introdu-cera nya aktiviteter som kan utföras under kommande sprintar.

Sprint retrospective Direkt efter review-mötet hålls ett retrospective-möte där

arbetsproces-sen granskas. Här diskuterar gruppen vad som fungerar bra, men även om någonting måste ändras i arbetsprocessen för att fungera bättre.

3.6

Trello

Trello är en webbaserad applikation för organisation av projekt [13]. I Trello kan man skapa virtuella tavlor och på dessa kan man sedan lägga in uppgifter som ska utföras i form av vir-tuella kort. Tavlorna kan namnges för att skapa strukur. En vanligt förekommande struktur är att till exempel ha tavlorna Att göra, Håller på med och Klart. Uppgifter som skapas på tav-lan Att göra kan sedan tilldelas enskilda projektmedlemmar som flyttar dem till de andra två tavlorna beroende på uppgiftens status. På så vis kan Trello bidra till att dels göra ett projekt överskådligt och även underlätta fördelningen av uppgifter i en projektgrupp.

3.7

Slack

Slack är en applikation där gruppmedlemmar kan kommunicera [14]. I Slack kan man skapa flera så kallade kanaler där man kan diskutera olika saker. En användare kan välja vilka kanaler denne vill delta i, och på så sätt kan man på ett smidigt sätt föra kommunikation även i mindre grupper som ingår i projektet. Till Slack kan man även koppla extra funktionalitet, som automatiska notifieringar vid gruppmöten och schemaändringar genom Google Calendar.

3.8

Automatiserad testning

Automatiserad enhetstestning går ut på att testa isolerade delar av koden för att säkerställa deras funktion. Att skriva automatiserade tester medför många fördelar. Det kan bland annat hjälpa till med att hitta buggar tidigt. Testerna ger även en säkerhet då koden omstruktureras eftersom utvecklarna kan vara säkra på att gränssnittet för en funktion inte förändras när implementationen ändras. Till sist ger testerna en bra dokumentation på hur funktionerna är ämnade att användas. Ett populärt ramverk som kan användas för automatiserad enhetstest-ning i Kotlin är JUnit [15]. Kodexempel 3.3 är ett test implementerat i Optily för att garantera att funktionen som läser celler i Excelfilen fungerar korrekt.

1 @T est

2 fun t e s t P r e t t y C e l l I d () {

3 val s hee t = w o r k b o o k . c r e a t e S h e e t () 4 val row = s hee t . c r e a t e R o w (2)

5 cell = row . c r e a t e C e l l (1)

6 val p r e t t y = xlsx . p r e t t y C e l l I d ( cell ) 7 a s s e r t T r u e ( p r e t t y . c o n t a i n s (" B3 ") ) 8 }

Kodexempel 3.3: Ett test av funktionen prettyCellId implementerat i JUnit

Utöver enhetstester kan även systemtester automatiseras. Dessa kan implementeras med hjälp av ramverket TestFX [16] som låter utvecklaren programmatiskt klicka runt i gränssnit-tet och testa funktionaligränssnit-tet på en hög nivå automatiskt. På så vis kan hela flöden i programmet i form av användarscenarion testas utan mänsklig inverkan.

3.9. Optimering

3.9

Optimering

Problemet att avgöra hur tallrikar ska placeras på satelliter i ytbeläggningsmaskinen har mo-dellerats som ett BPP. Ett sådant formuleras genom att n objekt med vikter w1, ..., wn skall

placeras i hinkar med kapacitet c. Viktsumman av objekten som placerats i samma hink får ej överskrida kapaciteten c och målet är att minimera antalet använda hinkar. Mer formellt kan detta uttryckas i följande ekvationer:

min n

∑

∑

∑

där yi = 1 om något objekt är placerat i hink i, annars yi = 0 och xij = 1 om objekt j är

placerat i hink i, annars xij=0. Optimala målfunktionsvärdet betecknas med z∗.

3.9.1

Beräkning av undre gräns

En optimistisk skattning för hur bra en optimal lösning skulle kunna bli kan beräknas genom att lösa problemet med relaxationen att xij ej behöver vara ett heltal. Resultatet av

relaxa-tionen blir att ett objekt kan delas upp i flera hinkar, detta gör att man alltid kan fylla alla hinkarna utom den sista till full kapacitet. Optimala målfunktionsvärdet zLges då av

zL = & _n

∑

vilket också utgör en undre gräns för z∗. I värsta fall utgörs alla objekts vikter av precis över halva hinkkapaciteten, alltså

wj = c

2+e e>0,∀j∈ {1, ..., n}

vilket innebär att inga objekt kan placeras i samma hink och z∗=n. Låter man e gå mot noll fås den undre gränsen

zL= lim e→0 & _n

∑

vilket visar att zL aldrig ger en sämre skattning än z∗/2. I fall där objektens vikt är liten i

förhållande till hinkarnas kapacitet erhålles dessutom en betydligt bättre skattning [17].

3.9.2

oj! Algorithms

oj! Algorithms är ett Javabibliotek distribuerat under MIT-licens, utvecklat och underhållet av Optimatika AB. Biblioteket innehåller verktyg för linjär algebra, finans och optimering. Med optimeringsverktygen kan ett problem definieras genom att skapa en modell. I modellen kan sedan variabler läggas till samt bivillkor dessa måste uppfylla och en målfunktion definieras. Villkor på vilka värden variablerna är tillåtna att anta kan även sättas, exempelvis att de endast får tillhöra mängden{2, 3, 4, 5, 6}eller intervallet[0, 10]. Därefter löses problemet av en färdig problemlösare genom att antingen minimera eller maximera målfunktionsvärdet under de villkor som specificerats. [18]

3.9.3

Heuristiska metoder

En heuristik är en algoritm som på ett intelligent sätt utnyttjar strukturen i ett problem för att hitta en bra, men inte garanterat optimal lösning på tidseffektivt sätt. Dessa används ofta på problem med NP-fullständig eller NP-svår komplexitet, vilket exempelvis BPP har. [19]

Nedan beskrivs två heuristiska metoder för att lösa BPP, sorterad första plats och sorterad bästa plats. Dessa har tidskomplexitetO(n log n)och har bevisats i värsta fall kunna resultera i ett fel på 22,2...% [20]. Dessa heuristiker kan användas som övre gräns då optimala lösningen skall finnas vilket snabbar på beräkningen avsevärt.

Sorterad första plats Objekt placeras i den hink som skapats vid det tidigaste tillfället enligt:

1. Sortera objekten i minskande ordning av vikt.

2. Placera det tyngsta, ej redan placerade objektet i första hinken där det får plats. 3. Om ingen sådan hink finns, skapa en ny och placera objektet i denna.

4. Om det fortfarande finns ej placerade objekt, gå till 2.

Sorterad bästa plats Objekt placeras i den hink med minsta återstående kapacitet enligt:

1. Sortera objekten i minskande ordning av vikt.

2. Placera det tyngsta, ej redan placerade objektet i den fullaste hinken där det får plats. 3. Om ingen sådan hink finns, skapa en ny och placera objektet i denna.

4

Metod

I ett projekt med många medlemmar är det viktigt att alla medlemmar kan ta vara på kunskap och erfarenheter som gruppen samlar på sig. Till exempel är det viktigt att alla i gruppen har en uppfattning av vad produkten ska göra. Det är också viktigt att alla i gruppen arbetar på samma sätt, annars är det lätt hänt att saker faller mellan stolarna. Nedan beskrivs dessa två aspekter av projektarbetet. Även metoderna för att svara på frågeställningarna presenteras nedan.

4.1

Utvecklingsarbetet

Utvecklingsarbetet i projektet följde en iterativ process med fyra huvuditerationer. Dessa ite-rationer var av olika karaktär, samt agil utveckling med hjälp av Scrum i iteration tre. Dessa beskrivs kortfattat nedan.

Iteration ett Den första iterationen gick ut på att komma igång med projektet, göra en grov

planering samt skapa en bra gruppdynamik. Här delades även gruppmedlemmarnas roller ut på ett demokratiskt sätt.

Iteration två Denna iteration gav gruppen möjlighet att fokusera på kravspecifikationen

och på att både projektgruppen och beställaren var överens om vad resultatet av arbetet skul-le vara. En inskul-ledande skiss över hur produkten skulskul-le fungera skapades av gruppen samt att bibliotek och utvecklingsverktyg testades. Här gjordes också ett antal kundbesök, dels för att säkerställa problembeskrivningens korrekthet och dels för testning av valda bibliotek i kundens IT-miljö.

Iteration tre Utvecklingsiterationen var den mest omfattande iterationen. Nu utfördes den

största delen av utvecklingsarbetet. Utvecklingsarbetet följde den agila utvecklingsmetoden Scrum som beskrivs i avsnitt 4.2.4. Gruppen tyckte att det skulle vara intressant att testa något som i stor utsträckning används i arbetslivet, och gruppen var redan i ett tidigt skede överens om att man ville jobba relativt strikt enligt Scrums utsatta standardstruktur. Dock gjordes också bedömningen att en egen modifikation behövde göras eftersom Scrum-standarden har längre sprinter än projektets avsatta tid tillåter.

Iteration fyra Under denna iteration låg stort fokus på att skriva klart kandidatrapporten och att förbereda samt slutföra de resterande seminarierna. Gruppen använde även under denna iteration tid för att opponera en annan kandidatgrupps kandidatrapport. Utöver detta valde gruppen även att finpolera Optily och implementera de sista önskade funktionerna som kunden hade. Slutligen genomfördes slutpresentationen av projektet och en sista version av Optily levererades och installerades hos kund.

4.2

Utvecklingsverktyg

För att se till att gruppen kunde vara effektiv och arbeta på ett samordnat sätt användes ett flertal verktyg och hur dessa användes presenteras nedan. En utförligare förklaring över de skillnader som gruppen gjorde gentemot standard Scrum samt en detaljerad beskrivning av hur gruppen jobbat med Git återfinns också.

4.2.1

Kotlin och IDEA

Det fanns två anledningar till att gruppen valde Kotlin som programmeringsspråk vid ut-vecklingen av produkten.

För det första valdes Kotlin eftersom gruppen ansåg att det skulle underlätta utvecklings-arbetet. Kotlins syntax är kompakt och genom att ta bort mycket så kallad boilerplate-kod eller upprepad kod ökas kodens läsbarhet. För det andra ville gruppen kombinera nytta med nöje och ta vara på möjligheten att lära sig ett nytt och modernt språk.

Utvecklingsmiljön IDEA användes för utföra utvecklingsarbetet. Detta val gjordes ef-tersom projektmedlemmarna hade goda erfarenheter av denna utvecklingsmiljö från tidigare projekt. Eftersom alla använde samma utvecklingsmiljö kunde samtliga dra nytta av förenk-lingar som IDEA kunde göra. Till exempel kan IDEA ge förslag på alternativ Kotlin-syntax som kan öka kodens läsbarhet.

4.2.2

Trello

Trello användes för att organisera arbetet med utvecklingsmetodiken Scrum. Ett kort repre-senterar en planerad aktivitet. Varje kort placeras i en lista för att indikera vilken status akti-viteten har. De listor som användes var Product backlog, Sprint backlog, In progress, Review och Done. Detta för att projektmedlemmarna på ett enkelt sätt kan spåra aktiviteter, och undvika duplicerat arbete.

Aktiviteterna sågs över inför varje sprint, och aktiviteter flyttades från Product backlog till Sprint backlog för att indikera att de ska utföras under kommande sprint. De kategoriserades även med någon av etiketterna Feature, Refactor, Bug och Test för att förtydliga aktivitetens syfte.

4.2.3

Möten

Möten spelade en stor roll under alla faser av projektet. Gruppen kände att det var viktigt att ha möten med så många ur gruppen som möjligt deltagande. Syftet med mötena var att samla och dela erfarenheter, och se till att alla hade möjlighet att arbeta mot samma mål.

Gruppmöten Gruppen samlades ofta för att diskutera vad systemet behövde göra.

Mö-ten användes också för att delegera arbetsuppgifter i den inledande fasen, till exempel för efterforskning av bibliotek. Under iteration tre hölls sprintmöten som förklaras vidare i av-snitt 4.2.4.

4.2. Utvecklingsverktyg

Kundmöten Det genomfördes ett antal kundmöten i början av projektet. Syftet med dessa

var att få en bättre förståelse av problemet. Detta innefattade bland annat en kravspecifi-kation som båda parter var nöjda med. I utvecklingsfasen hölls kontinuerlig kontakt med planeringsansvarig, som är slutanvändaren för produkten. Syftet med denna kontakt var att se till att utvecklingen av Optily följde vad planeringsansvarig önskade.

4.2.4

Projektets implementation av Scrum

Under utvecklingsarbetets gång utgick projektgruppen till så stor del som möjligt från Scrum-standarden. Detta eftersom projektmedlemmarna precis som med valet av ett nytt program-meringsspråk också ville lära sig att jobba enligt en populär och välanvänd utvecklingsme-tod. Samtidigt frångicks ett fåtal standarder eftersom dessa inte passade in i utvecklingsar-betet bland annat på grund av att det utfördes parallellt med andra kurser på universitetet. Här följer därför ett antal punkter som beskriver de ändringar i utförandet projektgruppen gjorde gentemot Scrum-standarden.

Daily Scrum Till skillnad från Scrum-standarden hölls inte ett daily Scrum-möte varje dag.

Dels på grund av att gruppen inte hade en dedikerad arbetsplats på campus och dels för att det många gånger föredrogs att jobba med inplanerade aktiviteter på annan plats än på campus. Mötet hölls dock om gruppen hade möjlighet att samlas.

Sprint backlog Enligt Scrum-standarden ska uppsatt backlog inte ändras under den

påföl-jande sprinten. Detta frångicks vid ett par tillfällen då gruppen beslutade att ett antal tasks behövde införas för att komplettera funktionalitet innan deploy hos kund. Detta gjordes ge-nom att i tillägg till sprint backlog, tillfälligt införa en deploy backlog i sprinten med aktivi-teter att utföra innan leverans av ny version till kund. Denna backlog fick högre prioritet än sprint backlog.

Sprint review och retrospective Enligt Scrum-standarden ska de två avslutande

sprintmö-tena hållas separata eftersom de fyller specifika separata syften. Review lägger fokus på pro-duktens utveckling under den gångna sprinten medan retrospective lägger fokus förbättring-ar och lärdomförbättring-ar om projektgruppens förbättring-arbetsprocess. Under utförandet ansågs det rimligt att slå samman review och retrospective till ett enda avslutande sprintmöte där speciellt retro-spective till stor del slopades och ersattes med följande uppsatta kvalitetspunkter i projektets kvalitetsplan:

• Vad har hunnits med?

• Vad har fungerat bra/mindre bra?

• Skulle något kunna göras på ett bättre sätt? • Har era kunskaper räckt till för att utföra arbetet? • Risker från föregående möte samt identifiera nya risker. • Vad har ni lärt er?

4.2.5

Projektgruppens arbetsflöde med Git

Nedan följer en kort beskrivning utav arbetsflödet med versionshanteringsverktyget Git [21]. Det illustreras även i figur 4.1.

Tag: release-alpha hotfix master release-alpha feature-y feature-x Tag: release-beta feature-z master feature release hotfix release-beta ny gren ny commit fast-forward kontinuerligt kont. merge Tag: release-alpha-2

Figur 4.1: Illustration av gruppens arbetsflöde med Git.

Grenen master utgjorde stam och viss utveckling gjordes direkt mot den men i huvudsak användes separata utvecklingsgrenar för var aktivitet. Dessa sammafogades med master när de slutförts och passerat såväl testning som kodgranskning.

Vid ett antal tillfällen gavs kunden en produktutgåva för fälttestning och som underlag för återkoppling. Inför respektive ny produktutgåva skapades release-grenar med syftet att testa programmet exporterat till en exekverbar JAR-fil [22]. Det var planerat att låta feature-freeze gälla för dessa grenar men ny funktionalitet tilläts läggas till om programmet fortfarande gick att köra från JAR med den.

En inchecknings-tagg skapades för var utgåva som gavs till kunden. Dessa kunde använ-das för att exempelvis se vilken funktionalitet som lagts till sedan den senaste produktutgå-van. Dessa var även tänkta att utgöra grunden för hotfix-grenar för att snabbt lösa och erbjuda lösningar på akuta buggar som påträffats under fälttestning. Även dessa var tänkta att resul-tera in en inchecknings-tagg men användes aldrig i praktiken eftersom de buggar som stöttes på inte fastställdes vara akuta.

4.3

Metod för att svara på frågeställningarna

Avsnittet nedan presenterar hur gruppen gick till väga för att svara på frågeställningarna som beskrevs i 1.3.

4.3.1

Identifiering av kundens behov

Denna del är central i all produktutveckling. Nedan beskrivs det hur gruppen gick till väga för att ta reda på vad kunden vill få ut av produkten.

Undersökningsfas I de två första iterationerna besökte gruppen kunden ett flertal gånger.

4.3. Metod för att svara på frågeställningarna

uppnå. Detta resulterade i en kravspecifikation från vilken sedan aktiviteter kunde skapas för utvecklingsarbetet.

Utvecklingsfasen Under främst iteration tre besökte gruppen kunden ett antal tillfällen.

Dessa tillfällen planerades in när gruppen tagit fram en ny version av programmet. Kunden fick möjlighet att testa programmet och komma med återkoppling på den funktionalitet som fanns vid det tillfället samt förbättringsförslag.

Värdeskapande Genom att jämföra den tidigare planeringsarbetet med den nya processen

där Optily används går det att ta fram resultat gällande hur Optily bistår verksamheten. Här är planeringsansvarig central och genom att diskutera frågor gällande den nya processen går det att säga till vilken grad Optily underlättat planeringsarbetet. En intervju med planerings-ansvarig genomfördes för att värdera Optily i projektets slutskede.

4.3.2

Erfarenhetsfångst

I mitten av iteration två, innan utvecklingsfasen började erfarenheter samlas genom att dis-kutera följande punkter under varje veckomöte:

• Vilka processrelaterade erfarenheter har erhållits? • Vilka tekniska erfarenheter har erhållits?

Dessa erfarenheter dokumenterades i ett särskilt protokoll. Under utvecklingsfasen, i itera-tion tre av projektet arbetade teamet i sprinter, se 4.1. I slutet på varje sprint hölls ett utvärde-ringsmöte vars syfte var att utvärdera arbetet som utförts, utvärdera utvecklingsmetodiken och fånga upp erfarenheter som uppstått under den gångna sprinten 4.2.4. I och med att er-farenhet samlades under utvärderingsmötet, plockades punkterna ”Vilka [...] erer-farenheter har erhållits?” bort från veckomötets agenda.

På så vis kunde erfarenheter diskuteras inom hela teamet, och alla fick ta del av det som enskilda individer erfarit. Dessa erfarenheter dokumenterades i ett protokoll som fördes un-der utvärun-deringsmötet. En sammanställning av erfarenheterna som fångats upp unun-der hela projektets gång kan hittas under 5.3.

4.3.3

Metod för att identifiera nyttan av en systemanatomi

En systemanatomi är tänkt att underlätta utvecklingen av programmet och öka förståelsen av programmet efter utvecklingens slut. Nedan beskrivs både hur gruppen tagit fram de systemanatomier som använts inom projektet och hur gruppen avgjort till vilken grad anato-mierna varit till hjälp.

Första versionen En första systemanatomi togs fram i grupp i den inledande fasen av

pro-jektet. Gruppen satte sig ner och funderade på vilken funktionalitet som programmet behöv-de. I detta skede visste inte gruppen exakt vad som efterfrågades från kund. Denna version utformades på ett sådant sätt som tidigare introducerats för projektmedlemmarna i studie-sammanhang.

Andra versionen Den andra versionen av systemanatomin togs fram efter att gruppen

kommit en bit längre in i projektet och när gruppen visste mer om vilken funktionalitet som behövdes. Gruppen utgick från kravspecifikationen men också en del brainstorming för att på så sätt skapa en tydligare bild. Gruppen tyckte också att den första versionen inte passade för detta projekt och den andra versionen blev därför utformad på ett annorlunda sätt. Denna anatomi blev sedan grund för de inledande aktiviteterna i utvecklingsarbetet.

Utvärdering efter projektets slut Efter projektets slut genomförde gruppen en utvärdering om nyttan av den systemanatomi som tagits fram. Detta gjordes genom att gruppen tillsam-mans försökte skapa en ny anatomi utifrån hur programmet såg ut efter utvecklingsfasen. Genom att successivt gå igenom skillnader och likheter försökte gruppen tillsammans svara på ifall den systemanatomin som togs fram varit till nytta i detta projektet.

4.3.4

Undersöka potential för miljövinster

Ionbond Sweden AB strävar efter att kontinuerligt förbättra miljöarbetet. Gruppen tog del av miljödokument som innehöll uppsatta mål samt historisk energianvändning. En över-siktlig genomgång gjordes för att få en bild av Ionbond Sweden AB:s miljöarbete. Efter att planeringsansvarig börjat använda Optily frågade gruppen om det gick att notera en högre fyllnadsgrad för att på så sätt kunna svara på om fyllnadsgraden ökat.

5

Resultat

Resultatet av projektarbetet utmynnande i ett system som har hjälpt kunden främst genom försäkran då systemet i ett tidigare skede avgöra ifall en mängd ordrar får plats i en och samma maskin. Detta leder till att man i framtiden kommer att undvika de situationer där man varit tvungen att prioritera om ordar vid packning.

Nedan presenteras en systembeskrivning samt erfarenheter som fångats upp under pro-jektets gång. Den slutgiltiga systemanatomin presenteras och jämförs med de tidigare ana-tomierna. Även en beskrivning om hur Optily kan hjälpa Ionbond Sweden AB att nå deras miljöarbete återges. Till sist presenteras de individuella delar projektmedlemmarna under-sökt.

5.1

Systembeskrivning

Systemet beskrivs nedan utifrån den trestegsprocess som utgör Optily. 1. Integrering med kundens befintliga databas.

2. Optimering av inmatade ordrar. 3. Visualisering av resultatet.

Detta är en naturlig arbetsgång eftersom den visar på hur systemet faktiskt fungerar. Kunden hade innan projektets inledning koll på information kring de olika föremålen som ytbeläggs. Detta innefattar bland annat dimension och specifik monteringsanordning. För att optime-ringen ska kunna hantera de specialfall som finns behöver systemet kunna ta detta i åtanke. För att sedan presentera resultatet för dels planeringsansvarig men också arbetarna som ska packa beläggningsmaskinen krävs det en visualisering som visar den nödvändiga informa-tionen.

5.1.1

Integrering med befintlig databas

Sättet företaget tidigare behandlat de olika föremål som ska ytbeläggas är genom en Excel fil. Planeringsansvarig har tidigare arbetat reaktivt och Excelfilen har mer fungerat som vägled-ning. Denna fil har bland annat innehållit dimensioner på de föremål som ska ytbehandlas.

Optilys föremålsdatabas grundar sig på att skapa en lokal databas som hämtar infor-mation från den Excelfil som planeringsansvarig arbetar med. Detta ger oss möjligheten att enklare och snabbare hantera de föremål som kan komma att ingå i en order. Det leder även till en lägre instegskurva eftersom företaget inte behöver lära sig hantera ett nytt system.

Planeringsansvarig uppdaterar fortfarande Excelfilen med information om nya föremål. Databasen som används läser av filen och skapar relevanta tabeller. Detta gör det lättare att under en körning av programmet säkerställa att all information finns att tillgå på ett enkelt sätt.

Embedded-Derby Med hjälp av Derby skapas en lokal föremålsdatabas som endast Optily

använder sig utav. Derby är ett bibliotek, skrivet i Java med vilket embedded-databaser enkelt kan skapas.

Hibernate-ORM Genom att använda ORM strukturen med hjälp av biblioteket

Hibernate-ORM [23] blir det enklare att hantera den informationen som används i programmet. En fördel med Hibernates ORM-hanterare är att den utför alla nödvändiga underliggande data-basquerys som behövs när objekt ska lagras i databasen. Den skapar även alla nödvändiga databastabeller själv utifrån de datatyper pekats ut som ORM-typer. På så vis kan en under-liggande databas existera samtidigt som den medföljande relationskomplexiteten abstraheras bort med hjälp av ORM-hanteraren.

5.1.2

Planera körning

Det första som behöver göras är att ladda in ett Excelark där alla föremål finns definierade, se bild 5.1. När en ny maskin ska köras behöver planeringsansvarig välja ut vilka ordrar som ska behandlas. Detta är något som görs manuellt utifrån vad planeringsansvarig vill ska vara med i körningen. En lista, se bild 5.2, över föremål planerade att ytbeläggas visas för användaren. I den kan antalet föremål och vilken unik lagerplats föremålen hör till ändras.

Figur 5.1: Skärmdump av programmet från databasfliken

Planeringsansvarig får sedan, i Optily, välja parametrar för den specifika körningen, se bild 5.3. När parametrar är valda kan användaren ställa in extra information som kan vara bra att ha, till exempel namn samt anteckningar för den packningen.

5.1. Systembeskrivning

Figur 5.2: Skärmdump av programmet från orderlistafliken

Figur 5.3: Skärmdump av programmet från parametrarfliken

5.1.3

Optimering

Optimeringen är specificerad att följa ett antal riktlinjer, baserat på krav ställda av kunden. 1. Blanda inte föremål från olika kunder på samma tallrik.

2. Blanda inte olika typer av föremål på samma tallrik. 3. Prioritera att använda så få satelliter som möjligt.

4. Antalet tillgängliga hylsor, tallrikar och satelliter är begränsat.

De två första riktlinjerna var inte något gruppen trodde existerade utifrån den inledande problemformuleringen, med dessa blev optimeringen enklare än vad gruppen förväntat. Hur optimeringen utförs beskrivs nedan i detalj.

Placering av föremål på tallrikar I optimeringens första steg placerar programmet ut fö-remål på passande tallrikar. I detta steg sker ingen optimering, utan programmet försöker endast fylla tallrikar föremål för föremål tills dess att inga föremål i orderlistan är oplace-rade. Detta innebär att den sista tallriken för en viss föremålstyp sannolikt kommer inneha oanvända platser, vilket är i enlighet med riktlinje 1 och 2.

Placering av tallrikar Problemet att placera tallrikar på satelliter har modellerats som ett

hinkpackningsproblem, och därför är den teori som presenterats i kapitel 3.9 applicerbar. Först tas en giltig lösning fram utifrån de två heuristikerna första- och bästa-plats-minskande, denna jämförs med den undre gränsen för hur bra en lösning skulle kunna bli i bästa möjli-ga fall. Överensstämmer dessa är den heuristiska lösningen möjli-garanterat optimal och används. Annars finns förbättringspotential och biblioteket används oj! Algorithms för att söka efter en bättre lösning. De undre och övre gränserna har nyttjats i problemdefinitionen som används i biblioteket för att effektivisera sökandet då detta är beräkningstungt, även en tidsgräns har satts på sökandet för att hålla programmet responsivt och användbart. Om problemet sak-nar lösning genom att tillgängliga satelliter inte räcker ges en varning till användaren som uppmanas att ändra parametrarna för problemet och försöka igen.

Verktygsbegränsningar Antalet verktyg, exempelvis tallrikar och hylsor, som behövs för

att belägga föremål är begränsat. En kontroll av verktygsåtgången för en körning görs mot det tillgängliga antalet verktyg, i fall att något av dessa inte är tillräcklig görs ingen prioritering av vilka ordrar som ska köras. Istället sägs problemet sakna lösning och användaren tvingas ändra gällande parametrar för körningen.

Resulterande packningsgrad Vid testning av optimeringen har det observerats att den

heu-ristiska lösningen i regel uppnår den beräknade undre gränsen. I en majoritet av övriga fall lyckas oj! Algorithms antingen förbättra denna eller verifiera att den ändå är optimal. Den resulterande packningen observeras vara optimal i en stor del av körda testfall. Den procen-tuella packningsgraden detta ger upphov till kan dock inte bestämmas då den helt beror på vilka ordrar som används i de olika testfallen.

5.1.4

Visualisering

När optimeringen uppnått ett resultat presenteras det grafiskt i användargränssnittet enligt figur 5.4. I resultatfiguren går det att avläsa vilken tallrik som ska placeras på vilken satellit. Beteckningarna som står på varje ruta i figuren kopplar tallrikarna till de inmatade ordrarna. Användaren kan även låta generera ett PDF-dokument med orderlista och optimeringsresul-tat enligt figur 5.5 respektiv figur 5.6.

Eftersom användargränssnittet skapats med JavaFX [24] ritades resultatbilden i det gra-fiska gränssnittet ut på en JavaFX-canvas. Vi planerade inledningsvis att använda biblioteket iText [25] för utritning till PDF men använde istället lågnivå-biblioteket PDFBox [26] på grund av dess mer öppna licens. För utritning av tabellen i PDF användes biblioteket Boxable [27].

5.1. Systembeskrivning

Figur 5.4: Resultatsvisualisering i användargränssnittet

Utritningsteknik Som figurer 5.4 och 5.6 visar visualiseras optimeringsresultatet på

sam-ma sätt i både användargränssnitt och PDF. Detta trots att utritning till JavaFX-canvas och PDFBox-dokument, som använts för användargränssnitt respektive PDF, har olika gränssnitt och funktionalitet. För att undvika att behöva skriva utritningsfunktionaliteten två gånger har därför en gemensam generell figur-struktur använts. Till den kan generella strukturer för linjer, etiketter och helfyllda rektanglar läggas till med olika inställningar såsom prickade, streckade och heldragna linjer. Figurer kan även lägges in i andra figurer som underfigurer. Satelliterna i optimeringsresultatet är exempel på underfigurer till figuren för hela resulta-tet. Figurer kan sedan ritas ut till godtyckliga renderingsmål genom att skicka med lambda-funktioner för utritning av linjer, etiketter och fyllda rektanglar till en generell funktion som hanterar renderingen. På så sätt har användargränssnitts- och PDF-specifik funktionalitet be-gränsats till implementation av dessa tre lambda-funktioner medan beskrivningen av resul-tatfiguren görs med den generella figur-strukturen. Det tydligaste exemplet på hur låg nivå man tvingas arbeta med PDFBox är att det inte finns något stöd för textjustering eller rad-brytningar, varken automatisk eller manuell. Den funktionalitet har projektgruppen istället skapat från grunden vilket kan ses i figur 5.6.

PDF utritning Figur 5.5 visar den resultat-tabell som finns i PDF:en och används för att få

en överblick över vilka föremål som ska ytbellägas samt vilka verktyg som behövs. Tabellen i figur 5.5 ritas endast ut i PDF:en då denna information endast är nödvändig vid packning av beläggningsmaskinen. Det samma gäller figur 5.6 då den extra informationen inte behöver framgå direkt i programmet.

Skapad 2018-04-26 16:51

Namn på körning

Till PDF:er kan flerradiga anteckningar skrivas. Dessa radbryts automatiskt för att hålla sig inom PDF:en.

Manuella radbrytningar fungerar också.

Figur 5.6: Resultatsvisualisering i PDF-dokument

5.2

Planeringsansvariges uppfattning av systemet

Intervjun med planeringsansvarig genomfördes efter att Optily använts under fem veckor. Det framkom att programmet fungerar väl och att planeringsprocessen förenklats. En tidig uppfattning var att stressen minskat eftersom fallet när en packning inte fick plats i belägg-ningsmaskinen ännu inte inträffat. Planeringsansvarig upptäcker detta fall i planeringsfasen och kan därför meddela berörd kund så fort ordern planeras. Planeringsansvarig tycker att detta proaktiva arbete ger Ionbond möjlighet att erbjuda bättre service. Kunder som köper Ionbonds beläggningstjänst får veta direkt om deras order kommer att fördröjas.

Planeringsansvarig är även av den uppfattning att Optily ökat packningsgraden. Främst för att man i ett tidigare skede kan se om det går att packa större ordrar. En ytterligare kom-mentar var att det sätt Optily är designat på ger stor möjlighet till även planering av andra typer av föremål som ska beläggas. Det går till exempel att introducera tallrikar av höjd 0 cm med 1 plats för att planera mer generella föremål med andra dimensioner, till exempel fö-remål som träs direkt på satelliter. Kort sagt anser planeringsansvarig att kontrollen över packningsprocessen ökat samt att det är bra att det är tydligt vad som går att packa och ej.

5.3

Gemensamma erfarenheter

Avsnittet nedan tar upp några av de erfarenheter som ådragits under projektets gång. Erfa-renherter gruppen erfodrat från Scrum är till exempel att det har underlättat eftersom sprin-tar tillät gruppen att planera om. En verktygserfarenhet är bland annat att Kotlin har varit intressant och roligt.