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.
5.3. Gemensamma erfarenheter
5.3.1
Scrumrelaterade erfarenheter
Det har varit lärorikt för projektgruppen att strukturera upp och utveckla sin arbetsprocess enligt Scrum. Som tidigare nämnt har fokus legat på att försöka följa Scrum-standarden till så hög grad som möjligt. Avstick från standarden har dock gjorts när gruppen gemensamt har bedömt det som nödvändigt, exempelvis när det inte varit praktiskt genomförbart att hålla Daily Scrum’s varje dag på grund av konflikter mellan projektmedlemmarnas varierande scheman.
Innan gruppen började använda sig av Scrum, erfors det att det var svårt att lägga tid på projektet. En orsak som togs upp var avsaknaden av specificerade aktiviteter. Implementa- tionen av Scrum tillförde bland annat aktiviteter som medlemmarna av gruppen kunde välja att arbeta på, vilket löste detta problem.
När en deploy vid ett tillfälle gjordes hos kund, frångicks också standarden eftersom kund snabbt lade till ett antal önskemål på produkten. Dessa prioriterades sedan in mitt i den på- gående sprinten vilket bidrog negativt på både sprintens överskådlighet och på det redan uppsatta sprintmålet. Att jobba agilt med Scrum ska innebära att man relativt snabbt kan in- föra ändringar under utvecklingens gång. Det erfarades dock att om oplanerade ändringar införs allt för hastigt, rubbas den underliggande strukturen. Istället bör ändringarna ha in- förts i kommande sprints. Detta har resulterat i erfarenheter kring hur Scrums olika events och artefakter faktiskt har ett viktigt syfte i att hålla utvecklingen strukturerad samtidigt som den är agil.
Nästan halvvägs in i projektet hade gruppen ett möte med kunden, där det visade sig att gruppens bild av optimeringsproblemet avvek från verkligheten. Detta ledde till att gruppen höll ett möte dagen därpå, där optimeringsproblemet diskuterades och korrigerades med hjälp av informationen som samlats från mötet med kunden. Eftersom projektet fortfarande var i planeringsstadiet hade detta inte alltför stora effekter; endast modeller behövde justeras.
5.3.2
Vidareutveckling
Något kunden efterfrågade var att det systemet vi tog fram skulle vara enkelt att vidare- utveckla. Genom att dokumentera och motivera val av bibliotek, verktyg och programme- ringsspråk får kunden en inblick och visar det sig att någon fortsätter med projektet blir det enklare att komma igång. Olika gränssnitt och moduler dokumenterades genomgående med förhoppningen att det ska vara ett komplement till programkoden.
5.3.3
Verktygsrelaterade erfarenheter
Genom detta projekt användes flera olika verktyg som på något sätt underlättade utveckling- en. Några av dessa presenteras nedan.
Kotlin Eftersom programmet utvecklades i Kotlin tog projektgruppen vara på chansen att
lära sig ett nytt programmeringsspråk. Kotlin var ett väldigt nytt språk när projektet utfördes, och ingen av projektmedlemmarna hade arbetat med det förut. Alla i gruppen håller med om att det var både lärorikt och kul att använda sig av ett nytt språk. Kotlins bidrog också till att minska ner antalet onödiga rader kod eftersom dess syntax är mer kompakt än motsvarande kod skriven i Java. Det kunde vara svårt att hitta kodexempel i detta språk, men tack vare möjligheten att översätta Javakod till Kotlinkod var detta inte ett problem. Dessutom fanns det gott om bibliotek att använda, eftersom Javabibliotek även fungerar i Kotlin.
Git Alla projektmedlemmar var bekanta med versionshanteringsverktyget Git, men de fles- ta har endast använt sig av det i mindre projekt. Det var därför väldigt lärorikt att samordna ett projekt av den här storleken, eftersom man blev uppmanad att prova på fler funktioner i verktyget. Att arbeta i grenar som beskrivs i 4.2.5 var nytt för många av medlemmarna, men trots detta upplevdes det vara väldigt smidigt att samordna parallell utveckling i projektet.
UI-testning Genom att använda oss av verktyg som tillät oss att testa gränssnittet mot an- vändaren sparade vi tid. Grunden för användargränssnittet togs fram tidigt och för att sä- kerställa att det fortfarande fungerade genom alla senare versioner hade mycket testningstid krävts. Genom att automatisera det med hjälp av TestFX [16] förenklades istället den proces- sen.
Enhetstestning Enhetstestning har använts under hela utvecklingsfasen. Detta har visat sig
vara ett smidigt verktyg för att snabbt verifiera att elementär funktionalitet i programmet ej förstörts av gjorda förändringar. Att skriva testerna var en engångskostnad i tid, själva körningen av testerna utfördes på några sekunder.
JavaFX JavaFX användes för att konstuera det grafiska användargränssnittet i programmet.
Det visade sig att JavaFX underlättade arbetet med designmönstret Model View Controller som beskrivs i 3.4. Detta tack vare att den grafiska layouten och funktionaliteten separeras på ett sätt som motsvarar Controller och View.
Hibernate Med hjälp av Hibernate möjliggjordes sparandet av objekt i databasen. Det var
speciellt praktiskt att använda sig av en ORM-lösning som Hibernate eftersom denna auto- matiskt kunde hantera relationer mellan objekt som skulle lagras.
5.4
Användning av systemanatomin
Den första systemanatomin gruppen tog fram var enligt gruppen utformad på ett sådant sätt att gruppen inte tyckte att den hjälpte. Den var utformad efter exempel som tidigare presenterats i kurssammanhang och presenteras i figur 5.7.
5.4. Användning av systemanatomin
Figur 5.7: Första systemanatomin
Gruppen tyckte inte riktigt att den passade eftersom exempelvis GUI-funktionalitet var svår att placera i diagrammet. Gruppen visste nämligen inte riktigt hur dataflödena skulle se ut.
Detta är något som den andra systemanatomin reflekterade bättre. Vid detta stadium hade gruppen undersökt de bibliotek som skulle användas, främst GUI biblioteket och gruppen hade en bättre förståelse över hur programmet rimligen skulle kunna struktureras. Denna systemanatomi presenteras i figur 5.8.
Databas Välja fil Filtrera på filformat Spara path Inläsning från excel Spara till databas "Översättare" Överföring av resultat Tabell-design (ID osv.) Hylsor Tallrikar Satelliter Höjd Antal Parametrar för optimering Datahanterare Order Artikelnr. Kund Antal Orderlista Lägg till Ta bort Modifiera Query
Optimering Fyll tallrikar Hantera "spill" Nivåskillnader Sortera tallrikar Optimera tallrikar på satelliter #1 #2 Produkter Antal Hylsa Finns på tallrik Bricka Distans Typ av tallrik Lediga positioner på tallrik Finns på satellit Generera tabell Antal tillgängliga satelliter Fyllnadsgrad Visualisering Generera bild Olika vyer Överblick Per satellit
Generera PDF Spara på disk Välja plats GUI
Figur 5.8: Andra systemanatomin
När utvecklingen var nästintill färdig skapade gruppen ytterligare en systemanatomi. Denna skulle reflektera hur systemet blev till slut och presenteras i figur 5.9. Även ett dia- gram över systemets dataflöde presenteras i figur 5.10 vilket ska försöka representera hur de olika modulerna i programmet sitter ihop.
5.5
Hjälp för att nå miljömålen
Målet med denna frågeställning var att ta reda på om Optily kunde bistå Ionbond Sweden AB i deras arbete att nå sina miljömål. Planeringsansvarig ansåg att Optily ökat packnings- graden. Detta är dock något som inte kan säkerställas då det ej finns någon historisk data att tillgå. Det gör det då svårt att dra konkreta slutsatser om Optily ökat packningsgraden och på så sätt minskat energiförbrukningen per belagt föremål. Visar det sig att den uppmätta energianvändningen minskat kan Optily bidragit till detta.