DEGREE PROJECT, IN INFORMATION AND COMMUNICATION TECHNOLOGY FIRST LEVEL
STOCKHOLM, SWEDEN 2015
Lageravstämning i oljebranschen
UTVECKLING AV NY FUNKTIONALITET FÖR
ETT LAGERHANTERINGSSYSTEM
JOHNY PREMANANTHAM & XINMAO WANG
K T H R O Y AL I N S T I T U T E O F T E C H N O L O G Y
1
Abstract
This study examines the development process to create new functionality for a fuel inventory management system used by Preem AB.
The reason why Preem AB recruited students to take on this challenge was due to the potential improvements that could be made to their exisiting system. This study will explain how the system can be improved by developing new functionality from existing data. The aim of this study is to provide ideas, guidelines and answers on how new functionality can benefit their fuel inventory management system.
Preem AB is Sweden’s largest producer of fuel and contributes with about half of all the fuel consumed in Sweden [1]. Therefore, a lot of aspects needs to be taken into consideration.
Having good control of the fuel inventory is good for the economic viability. The company risks losing millions because of deficiencies in their inventory management system, which is currently the case. One way to minimize this problem is to apply certain funtionality to their system. The students who participated in the project were given different responsibilities; the areas the project focused on were the development of a new graphical user interface, database management and also the development of new functionality – which is the sole purpose of this study.
A specification and prototypes for each function has been developed to clarify how the inventory management system can be optimized. The specifications are intended to describe how the functionality can optimize the fuel inventory management system. The prototypes are programs that are implemented to answer the problem formulation (see section 1.2). The inventory management system can be more efficient and benefit through the innovation of new functionality. One of many benefits may include a function that takes over the role of an employee, meaning it will replace the manual labor usually required for the job. There are many opportunities to create new functionality such as this, which was in fact discovered early in the project. The functionality that were selected to be implemented consisted of those who were most likely to benefit Preem AB.
Keywords:
2
Sammanfattning
I denna studie undersöks utvecklingsprocessen för att skapa ny funktionalitet till Preem AB:s lagerhanteringssystem som hanterar drivmedelsvarulagret.
Anledningen till att Preem AB rekryterade studenter för att ta sig an denna utmaning var på grund av de potentiella möjligheterna i förbättring av flera komponenter i lagerhanteringssystemet. Studien ska förklara hur systemet kan förbättras genom att utveckla ny funktionalitet från befintlig data. Målet med studien är att ge idéer, riktlinjer och svar på hur ny funktionalitet kan förbättra Preems hantering av drivmedelsvarulagret.
Preem AB är Sveriges största producent av drivmedel och bidrar med ungefär hälften av allt drivmedel som förbrukas i Sverige. [1] Preem AB har därmed mycket i åtanke då ansvaret för stora mängder drivmedel är riskfyllt inom många aspekter.
Att ha god kontroll över drivmedelsvarulagret är viktigt för den ekonomiska lönsamheten. Bolaget kan förlora miljonbelopp på grund av brister i deras lagerhanteringssystem. Ett sätt att minimera problemet kan vara att applicera ny funktionalitet i deras system.
Studenterna som deltog i projektet fick olika ansvarsområden, de områden som Preem AB sökte hjälp i var utvecklandet av det grafiska gränssnittet, databashantering och området denna studie sätter fokus på – utveckling av ny funktionalitet.
En kravspecifikation för varje funktion och prototyper i form av kod har tagits fram. Kravspecifikationerna är till för att beskriva hur funktionaliteten kan optimera lagerhanteringssystemet. Prototyperna är program som är implementerade att kunna besvara problemformuleringarna (se avsnitt 1.2). Genom nyskapandet av funktionalitet kan lagerhanteringssystemet effektiviseras och på så sätt erhålla ekonomiska fördelar – en fördel kan vara att en funktion tar över rollen som en anställd har. Det fanns många möjligheter att skapa ny funktionalitet, den funktionalitet som valdes att utvecklas var den som mest troligt skulle gynna Preem AB.
Nyckelord:
4 2.3 Data ...17 2.3.1 Filformat ...18 2.4. Programmeringsparadigm ...18 2.5 Programmeringsspråk ...18 Kapitel 3 Metod ...19 3.1 Förstudie ...19 3.1.1 Fallstudie ...19 3.1.2 Datainsamling ...20 3.1.3 Avgränsning i arbetet ...20 3.2 Projektprocessen ...21 3.2.1 Agil utveckling ...21 3.2.2 Parprogrammering ...21 3.3 Systemdokumentation ...22 3.3.1 Kravspecifikation ...22 3.3.2 UML ...22 3.4 Systemmiljö ...22
3.4.1 IDE (Integrated development evironment) ...22
3.4.2 GitHub (Versionshantering) ...22
3.4.3 Java ...23
Kapitel 4 Sammanställning av data ...24
4.1 Insamlad data ...24
4.1.1 Kvalitativ data ...24
4.2 Användbart kvantitativt data...24
Kapitel 5 Analys ...27
5.1 Kravspecifikation för utvald funktionalitet ...27
5.2 Modellering av utvald funktionalitet ...32
5.3 Prototyper ...32
Kapitel 6 Resultat ...33
6.1 Kravspecifikation ...33
6.2 Modeller...33
5 6.2.3 Optimera leveransplaneringen ...35 6.3 Prototyp ...36 Kapitel 7 Diskussion ...39 7.1 Metodval ...39 7.1.1 Förstudie ...39 7.1.2 Projektprocessen ...39 7.1.3 System dokumentation ...40
7.2 Samhälleliga och etiska aspekter ...40
7.3 Förslag till vidare forskning ...41
7.4 Slutsats ...41
Källförteckning ...42
Bilagor ...44
Bilaga A. Kravspecifikation för “Para ihop omatchande rapporter m.h.a. annat data än vad som används för tillfället” ...44
Bilaga B. Kravspecifikation för “Ta reda på cisternernas dödvolymsnivå” ...48
6
Ordlista
Cistern: En behållare till förvaring av bränsle. Pejl: Mätinstrument som är placerad i en cistern.
IT-system: System som med informationsteknik hanterar och utbyter information. I begreppet
innefattas även kommunkationsutrustning, datorer, servrar m.m.
Bränsletabell: En tabell som visar förhållandet mellan bränslenivån och pejlens alla möjliga
mått.
Nucleus: Kassasystem som bearbetar transaktionsdata m.m.
mcdMonitorII: Mjukvara som samlar och bearbetar data från pejlen.
SiteInfo: SiteInfo är mcdMonitorII:s presentationssystem - en webbapplikation.
Forcourt-server / Point-of-sale: En Forcourt-server även kallad “Point-of-Sale” är en dator
som sköter dialogen med banken för att se om ett kort är godkänt för tankning, beräknar ut fakturan, meddelar banken om hur mycket som ska betalas, m.m.
Lagerkontroll: Detta system är en webbapplikation skapad av Preem AB för att hålla reda på
cisternvarulagret. Information från SiteInfo och från leverantören sammanställs här för att kunna granskas och bearbetas.
Utvecklingsmiljö (eng. Integrated development evironment, IDE): En
utvecklingsmiljö är ett datorprogram som innehåller en del funktioner som tillsammans underlättar vid programmering. Funktionerna är sådana som kompilator, textredigerare och debugger.
MCD AB: Preem AB samarbetar med ett företag som heter MCD AB (Miljö & Cisterninstrument
7
Figurförteckning
Figur 2.1: Alla komponenter som tillsammans utgör lagerhanteringssystemet ... 12
Figur 2.2: Hur en horisontell cisterns komponenter integreras med respektive system ... 14
Figur 2.3: Olika volymmått och deras innebörd ... 15
Figur 2.4: Hur alla komponenter/system kopplas ihop i en drivmedelsanläggning [4] ... 16
Figur 5.1: Två rapporter som skiljer sig i tid men stämmer överens i både volym och temperatur (om 8000 liter av 8 graders drivmedel blandas med 5000 liter 7 graders drivmedel kommer sluttemperaturen bli ~7,6 grader (termodynamikens nollte huvudsats)) ... 28
Figur 5.2: Grafisk presentation över lösningsförslaget för matchning av rapporter ... 28
Figur 5.3: Grafisk presentation över lösningsförslaget för att hitta dödvolym ... 29
Figur 5.4: Nivåförändrings historik för anläggningen 46507 cistern 1 (De små nivåökningarna kan bero på drivmedlet som befinner sig i sugledningen faller tillbaka till cisternen) ... 30
Figur 5.5: Transaktionhistorik för anläggning 46507 cistern 1 ... 31
Figur 5.6: Grafisk presentation över lösningsförslaget för optimering av leveransplaneringen . 32 Figur 6.1: Flödet för att jämföra om leveransrapporterna stämmer överens med pejlmätningarna ... 34
Figur 6.2: Flödet för att hitta dödvolymsnivå ... 35
Figur 6.3: Flödet för att optimera leveransplaneringen ... 36
Figur 6.4: Resultat från en körning för att hitta dödvolymsnivå för åtta anläggningar ... 38
Figur b.1: Historiskt lägsta volym ... 49
Figur c.1: Cistern nummer 2 på anläggningen 46113 som endast använd sig av hälften av hela kapaciteten ... 53
8
Kapitel 1 Introduktion
En överblick av rapportens innehåll samt en förklaring av problemet som är i fråga fås i detta kapitel.
1.1 Bakgrund
Lagerhanteringssystem används av företag med försäljning av fysiska artiklar, där de exempelvis kan ta reda på aktuellt lagersaldo och ha kontroll på sitt lagervärde. Preem AB, arbetsprojektägare, säljer stora mängder drivmedel och använder ett lagerhanteringssystem som är grundstenen för denna studie.
Ett företag kan kräva ett specialiserat lagerhanteringssystem eftersom försäljning av varierande varor bidrar till olika problem. Det finns alltså inte en generell lösning till hur ett komplett lagerhanteringssystem kan skapas.
För att kunna göra avstämningar i varulagret och utveckla ny funktionalitet måste kontinuerlig mätdata från cisternerna finnas tillgängligt. MCD AB är företaget som gör det möjligt, med hjälp av deras nivåmätningssystem mcdMonitorII. mcdMonitorII är en programvara som övervakar mätdata och visar upp den på en bildskärm samt vidarebefordrar vid planerade tidpunkter eller på begäran till deras internettjänst. Den mätdata som mcdMonitorII behandlar är avgörande för att utveckla funktionalitet för lagerhanteringssystemet.
mcdMonitorII omvandlar den data som pejlen returnerar till grafiska objekt och format som är mer lätthanterliga. Detta system har tillgång till en mängd data som är av intresse för denna studie, exempelvis så har den tillgång till systemets loggningar av aktuell status, volym, nivå, temperatur, leveranser m.m.
1.2 Problemformulering
Problemet ligger i att Preems lagerhanteringssystem brister i funktionalitet. För att skapa ny funktionalitet krävs tillgång till viss data. Dessa data fås av Preems olika system så som mcdMonitorII, Forcourt-server m.fl.
Det fanns redan en mängd funktionalitet, men Preem AB var ute efter innovativa lösningar på hur ny funktionalitet skulle kunna optimera systemet. För tillfället måste data bearbetas manuellt för att utföra vissa processer, det vill säga att Preem AB slösar arbetskraft på att utföra ett arbete som kan automatiseras genom utvecklandet av ny funktionalitet.
9
Problem: Att sammanställa och para ihop leveransrapporterna, som inte stämmer överens i tid
mot respektive pejlrapport måste för tillfället göras manuellt. Leveransrapporterna innehåller information så som volymen, start tiden, stop tiden e.t.c. angående en särskild leverans. Medans pejlrapporterna innehåller information angående hur mycket volym en cistern har vid en särskild tidpunkt. Genom att jämföra dessa rapporter kan avvikelser upptäckas.
Frågeställning: Hur kan Preem AB para ihop leveransrapporter och pejlrapporter som inte
stämmer överens i tid?
Problem: På grund av flera faktorer är det svårt att veta vid vilken nivå en cistern har nått
dödvolym. Preem AB behöver veta när en cistern når dödvolym för att kunna planera in leveranser - så att en cistern inte går tom. Dödvolym är den volym som finns under sugledningen, det vill säga där sugledningen inte har möjlighet att pumpa upp mer drivmedel. Detta för att inte förse kunden med vatten och föroreningar som kan befinna sig i cisternens botten.
Frågeställning: Hur kan Preem AB beräkna när en cistern ska nå dödvolym?
Problem: Cisternerna brukar fyllas på med jämna mellan rum, men detta kan ha en negativ
påverkan då vissa cisterner aldrig utnyttjar sin fulla kapacitet
Frågeställning: Hur kan Preem AB optimera leveransplaneringen så att cisternerna utnyttjar
sin fulla kapacitet?
1.3 Syfte
Syftet med studien var att visa hur ny funktionalitet kan optimera Preem ABs lagerhanteringssystem, detta genom att besvara frågeställningarna i föregående rubrik. Detta projekt inleddes på grund av att Preem AB såg möjligheter till förbättringar av deras system. Studien kan bidra till ekonomisk gynnsamhet, då arbetskraft kan sparas och planering kan optimeras.
1.4 Mål
Projektets mål var att skriva en teknisk rapport samt att leverera kravspecifikationer och prototyper angående hur funktionaliteten kan skapas. Kravspecifikationerna ska fungera som en beskrivning av hur och varför funktionaliteten ska implementeras. Rapporten är en beskrivning av alla processer som krävdes för att kunna implementera funktionaliteten.
Det som överenskommits med projektägaren är att en samling av kravspecifikiationer och prototyper som beskriver hur funktionaliteten kan utvecklas ska levereras. Preem AB ska kunna ta nytta av vårt arbete och applicera det på deras system. Denna studie ska kunna användas för de som letar efter utvecklandet av ny funktionalitet för ett lagerhanteringssystem.
Följande är vad som ska åtgärdas och implementeras:
10
1.5 Metod
Projektet inleddes med en utbildning där målet var att alla medverkande skulle få en tydligare inblick i det existerande problemet. Vår arbetsmetod bestod av att samla information genom interna föreläsningar av anställda från Preem AB samt en extern föreläsning som Preem AB försedde oss med. Föreläsningarna från Preem AB förväntades vara den största källan för information. De interna föreläsningarna gav oss en överblick över alla processer som ingick för att hålla reda på varulager. Den externa föreläsningen var från MCD AB - denna föreläsning var till för att hjälpa oss förstå MCD:s roll i det hela, det vill säga vilka delar av varulagret de hade ansvar för.
För att tillfredsställa Preem AB och inte ta vatten över huvudet så skapades en MoSCoW-lista (se avsnitt 3.1.3) [2]. Denna lista specificerar vad som måste, bör, kan och inte kommer att göras. Listan skapades iterativt med regelbundna avstämningar med Preem AB för att gemensamt komma fram till en överenskommelse som passar båda parter.
1.6 Avgränsningar
Hela projektet är uppdelat i tre arbetsområden - dessa är databashantering, utveckling av funktionalitet och utveckling av det grafiska användargränssnittet. Denna studie kommer att avgränsas till att enbart undersöka utvecklandet av ny funktionalitet.
Rapporten fokuserar på processerna som följande system tillhandahåller: ● mcdMonitorII - Mjukvara som samlar och bearbetar data från pejlen. ● Nucleus - Kassasystem som bearbetar transaktionsdata m.m.
● Forcourt-server - Dator som sköter dialogen med exempelvis banken.
● Lagerkontroll - En webbapplikation skapad av Preem för att hålla reda på cisternvarulagret genom att sammanställa data från pejl och leverantör.
Ännu en avgränsning är att studien genomförs med en begränsad tidsrymd på 400 timmar.
1.7 Disposition
● Kapitel 2 - Teori - De teoretiska aspekterna granskas i detta kapitel, så som alla komponenter som tillsammans utgör systemet, och även bakgrundsinformation angående IT-system i allmänhet.
● Kapitel 3 - Metod - Metoderna som används i examensarbetet och forskningsmetodik granskas i detta kapitel.
● Kapitel 4 - Sammanställning av data - I detta kapitel kommer den befintliga datan analyseras för att sedan kunna avgöra våra möjligheter i utvecklandet av funktionalitet. ● Kapitel 5 - Analys - Här kommer problemformuleringarna ytterligare att förklaras -
11 ● Kapitel 6 - Resultat - Här kommer våra leverabler att presenteras och lösningarna till
problemen som står i fråga sammanställas.
Kapitel 7 - Diskussion - I detta kapitel diskuteras de val som gjordes, exempelvis varför vissa
12
Kapitel 2 Teori
Detta kapitel nämner information som är väsentlig för läsaren att erhålla för att förstå resten av rapportens innehåll. Här beskrivs alltså de teoretiska aspekterna som tagits till hänsyn samt litteraturstudien som utfördes.
2.1 Företagsinformation
Preem AB har en mängd olika system för att hantera drivmedelsvarulagret, vilket innebär att det finns data att hämta från olika system. Här beskrivs de system och de anläggningar som är mest väsentliga för denna studie [3].
13
2.1.1 Raffinaderier
Preem AB äger två raffinaderier i Sverige, där råolja bearbetas för att få fram drivmedelsprodukter. Efter bearbetningen exporteras drivmedelsprodukten till olika länder inkluderat Sverige. Båda raffinaderierna producerade tillsammans 18 miljoner ton drivmedel under 2014. [4] [5]
2.1.2 Depåer
Preem AB äger sju depåer runt om i landet, dessutom har Preem AB också tillgång till 14 andra depåer genom allianssamarbeten. Depåerna används för att lagra stora mängder drivmedel. Tankbilarna hämtar drivmedel från depåerna för att sedan kunna leverera det till drivmedelsanläggningarna. [6]
2.1.3 Drivmedelsleverantör
Hoyer är företaget som transporterar drivmedel mellan depåerna och drivmedelsanläggningarna. När drivmedlet har levererats skickas en faktura för mängden drivmedel som levererats. För att vara säkra på att Hoyer levererat rätt mängd drivmedel görs avstämningar mellan vad Hoyer sagt de levererat och vad Preem AB egentligen mottagit. Dessa avstämningar görs m.h.a system som mcdMonitorII och Preems webbapplikation Lagerkontroll.
2.1.4 Drivmedelsanläggningar
Preem äger mer än 600 drivmedelsanläggningar (2015). Dessa anläggningar är avsedda för privatbilister och tung trafik. På varje anläggning finns ett antal olika system och komponenter, som tillsammans är avgörande för lagerhanteringssystemet. Information angående cisternnivåförändring, köphistorik, leverans m.m. erhåller systemen som befinner sig på en av drivmedelsanläggningarna.
Cisternerna på anläggningarna
14 Figur 2.2: Hur en horisontell cisterns komponenter integreras med respektive system
15 Figur 2.3: Olika volymmått och deras innebörd
Nominell volym: Volym som tillverkan har angivit. Faktisk volym: Hur mycket cisternen faktiskt rymmer.
Effektiv volym: Den totala volym som kan utnyttjas; alltså den mellan överfyllnadsskyddet och
dödvolymen.
Lagervolym: Volym som finns i cisternen.
Dödvolym: Volym som är under sugledning och därmed inte kan utnyttjas.
Bruksvolym: Återstående volym som kan användas; alltså Lagervolym - Dödvolym.
Tomvolym: Volym som kan fyllas utan att aktivera överfyllnadsskydd; alltså Effektvolym -
Lagervolym.
2.1.5 SÅIFA
16
2.1.6 Huvudkontoret
På huvudkontoret arbetas det huvudsakligen med hantering av drivmedelsvarulagret. Systemen SiteInfo och Lagerkontroll är de system som används för att hantera leveranser, rapporteringar, dagsavstämningar m.m. För tillfället är det två anställda på Preem AB som har ansvar att upptäcka ovanligheter i deras lagerhanteringssystem.
2.2 Befintliga system
Dessa befintliga system utgör tillsammans lagerhanteringssystemet [7].
Figur 2.4: Hur alla komponenter/system kopplas ihop i en drivmedelsanläggning [4]
2.2.1 Nucleus
På varje drivmedelsanläggning finns en dator (Nucleus) som är igång dygnet runt. Denna dator har i uppgift att köra mcdMonitorII. Den har även ansvaret att köra annan mjukvara, som dock inte är relevant för denna studie.
2.2.2 Forcourt-server / PoS
17 som ska betalas, m.m. Forcourt-servern har alltså ansvaret för i princip all dialog då en kund tankar.
2.2.3 Commandern
Commandern är det system som först behandlar pejlens mätningar. Commandern är väldigt speciell då den är byggd så att den inte kan skapa en gnista, då detta möjligtvis kan orsaka en explosion då pejlen är placerad inne i en cistern.
2.2.4 mcdMonitorII
mcdMonitorII är den mjukvara som samlar in data från pejlen. mcdMonitorII kommunicerar inte direkt med pejlen utan via Commandern. Data som Commandern mottager översätts och formateras om till lämpligt format, så som grafiska objekt, av mcdMonitorII. Därefter skickas data till SiteInfo, för att sedan vidarebefordras till systemet Lagerkontroll där anställda på Preem AB kan behandla mätningarna. Detta system är avgörande för framtagande av funktionalitet angående drivmedelsvarulager, eftersom det är det enda systemet som direkt behandlar drivmedelsvarulagret.
2.2.5 Lagerkontroll
Detta system är en webbapplikation skapad av Preem AB för att hålla reda på cisternvarulagret. Information från SiteInfo och från leverantören sammanställs här för att kunna granskas och bearbetas. Preem AB använder detta system för avstämning av cisternvarulagret. Detta system var inte i så stort intresse för oss, men data som webbapplikationen visar kan fortfarande vara intressanta.
2.2.6 SiteInfo
SiteInfo är mcdMonitorII:s presentationssystem, som används för nivåövervakning. Data som SiteInfo har tillgång till är angående varulager i drivmedelsanläggningar. Preem skickar även viss data till transportören (Hoyer) för att de ska kunna planera de mest effektiva rutterna utan att drivmedel tar slut på någon anläggning.
SiteInfo är ett bra verktyg för presentation av data men denna studie är fokuserad på funktionalitet, så detta system var inte så gynnsam för vår studie.
2.3 Data
18 Ett program (som innehåller funktionalitet) kan ses som en funktion där utdata är en funktion av indatan [8].
Utdata = Program(Indata)
Dataobjekt är alltså centrala för utvecklandet av funktionalitet.
2.3.1 Filformat
Med filformat avses den interna strukturen en datafil har. En fil kan innehålla många olika typer av information och kan därmed lagras på olika sätt.
CSV
Den data som fanns tillgängligt levererades av Preem AB i fil formatet CSV (Comma Separated Values) [9]. Detta är ett gammalt sätt att lagra data på där data lagras i form av texfiler. Dessa filer kan ses som en tabell i en databas, där en rad motsvarar en rad i en tabell och ett kommatecken motsvarar en ny kolumn. Att lagra data på detta vis kanske inte är mest effektivt men är dock väldigt lätthanterligt då datan lagras som text.
2.4. Programmeringsparadigm
Inom utveckling av funktionalitet finns det olika idéer och läror angående organisation och struktur. Det är därför programmeringsspråk ska stödja flera programmeringsparadigmer. Ett programmeringsparadigm är en övergripande teori kring hur funktionalitet bör organiseras och struktureras. Varje paradigm stöder en uppsättning av begrepp som gör det bäst anpassat för ett visst problem [10].
För denna studie valdes objektorienterad programmering då den fungerar bäst för större program och är den paradigm Preem AB använder.
2.5 Programmeringsspråk
Programmeringsspråk är ett språk som människor använder för att utveckla funktionalitet. Datorernas grundspråk kallas maskinkod och består av ettor och nollor, som datorns centralprocessor direkt kan tolka. Olika programmeringsspråk har tagits fram för att kunna översätta läsbar kod bestående av siffror och tecken till maskinkod.
19
Kapitel 3 Metod
Metoderna som användes för att ta uppnå produktmålen granskas i detta kapitel.
3.1 Förstudie
Här beskrivs de metoder och tillvägagångssätt vi använde oss utav för att åstadkomma resultaten som Preem AB önskade. Vid arbetets inledning definierades vad som förväntades av oss; nämligen att utveckla tydliga kravspecifikationer för ny funktionalitet samt prototyper till utvald funktionalitet.
Frågeställningarna innehåller ordet “hur” – det innebär att det finns utrymme att inhämta kunskap inom det utvalda forskningsområdet. Studien är av explorativt syfte då den kräver att ett helhetsperspektiv inom problemområdet måste skapas. Då problemområdet kan vara brett så användes olika informationssamlingstekniker för att inhämta information vid explorativa studier [11]. Dessa informationssamlingstekniker förklaras i nedanstående rubriker.
3.1.1 Fallstudie
En fallstudie innebär en extensiv studie av ett fall. Fallstudier används när undersökaren behöver en djupare insikt i ett fall. Ett fall kan exempelvis vara en händelse, ett företag, eller en arbetsprocess [12].
För detta arbete genomfördes en övergripande studie av olika fall av samma natur. Lagerhanteringssystemet brister i funktionalitet och detta är problemet som står i fokus, men det finns olika fall att ha i åtanke. För att ge sig på detta arbete har forskningsstrategin innefattat både kvalitativa samt kvantitativa strategier – detta en lämplig strategi då problemet är brett [13]. Den kvantitativa datan insamlades för att få en tydlig förståelse över vilken data som var avgörande för utvecklandet av ny funktionalitet. Den kvalitativa datan användes för att ge oss idéer om vad som kunde behövas appliceras i lagerhanteringssystemet. Det gav alltså underlag för lösningsförslag och rekommendationer. Vår fallstudie bestod av interna föreläsningar, en extern föreläsning och regelbunden dialog med projektansvarige.
Interna föreläsningar
För att få en tydligare överblick över alla komponenter som tillsammans utgör lagerhanteringssystemet försedde Preem AB oss med interna föreläsningar.
Extern föreläsning
20 utvecklaren redan stött på togs upp och diskuterades. Ett problem var att utvecklaren inte kunde få tillgång till viss data, som Preem AB helt enkelt inte kunde producera.
Dialog med projektansvarig
För att försäkra om att arbetet var på rätt väg, utfördes avstämningsmöten varje vecka. Den kvantifierbara datan inhämtades på begäran – önskemål om data gjordes för att sedan erhållas av projektansvarige.
Genom dessa dialoger valdes följande funktionalitet att implementeras:
● Para ihop leveransrapporter från pejlen och Hoyer m.h.a. annan data än vad som används för tillfället [bilaga A].
● Ta reda på cisternernas dödvolymsnivå [bilaga B]. ● Optimera leveransplanering [bilaga C].
3.1.2 Datainsamling
Att veta vilken data som fanns tillgänglig var avgörande i vårt fall, eftersom utvecklandet av funktionaliteten som tidigare nämnts beror på den data som finns att arbeta med [8]. Fallstudien resulterade i information angående den data som fanns tillgänglig.
3.1.3 Avgränsning i arbetet
För att avgränsa arbetet skapades en MoSCoW-lista. MoSCoW är en arbetsmetod som används i mjukvaruutveckling för att nå en gemensam överenskommelse med intressenten om prioriteringen av vad som ska levereras [2]. Nedan presenteras vår MoSCoW-lista:
Prioritering Beskrivning
Måste (eng. Must) Leverera en kravspecifikation för funktionalitet av tekniskt intresse som ska ingå i det nya systemet. Den funktionalitet vi ska arbeta med presenteras i bilaga A och i bilaga B.
Bör (eng. Should) Tillsammans med kravspecifikationen kan exempelvis en del exempelkod eller pseudokod för utvalda delar av funktionaliteten levereras.
Skulle kunna (eng.
Could) Skapa prototyp(er) av utvald funktionalitet.
Kommer inte (eng.
21
3.2 Projektprocessen
Här beskrivs de metoder som användes för det faktiska genomförandet av projektet. Det syftar på hur projektet utfördes, planerades och strukturerades.
3.2.1 Agil utveckling
Grundtankarna bakom agil utveckling bygger på att göra kunden och användaren nöjd med det som utvecklas genom ett mycket nära samarbete under hela utvecklingstiden, med täta och regelbundna möten mellan utvecklare och beställare/mottagare. För att komma fram till funktionaliteten som skulle implementeras krävdes nära samarbeta med kunden. Därför, och på grund av fler faktorer, valdes agil utveckling.
Fördelen med ett agilt arbetssätt är främst att förändrade krav under utvecklingens gång är acceptabelt vilket är väldigt vanligt framkommande i projektarbeten. Ofta så ger förstudien inte alla svar och det kan behöva kommas på förbättringar/förändringar under arbetets gång.
Iterativ planering
Att planera iterativt betyder att arbetet sker i cykler och detta för att få en så bra produkt som möjligt. De olika cyklerna bestod av fallstudie, analysering och implementation.
3.2.2 Parprogrammering
Parprogrammering (eng. pair programming) är en programutvecklingsteknik där två programmerare jobbar tillsammans vid en gemensam dator. Den ena, föraren, skriver kod medan den andra, navigatören, granskar varje kodrad när den matas in. De två programmerarna växlar ofta mellan rollerna [14].
Under granskningen planerar navigatören också den strategi som ska användas, kommer på idéer till förbättringar och funderar över problem som kommer att behöva lösas senare. Detta förfarande ger föraren möjlighet att fokusera all sin uppmärksamhet på att göra klart den aktuella uppgiften, med navigatören som skyddsnät och guide.
Parprogrammering är en teknik inom agil programvaruutveckling som blir allt vanligare i industrin, då en av många fördelar är att kostnaderna drastiskt kan sänkas på grund av att det framkommer mindre problem med programmen [15]. Metoden valdes på grund av de positiva effekter som framkommer då den används. Genom användningen av metoden parprogrammering kan team bli mer samspelta, dela kunskap och effektivt hantera problem som skulle ta betydligt längre tid om det utfördes enskilt [16].
Virtuell parprogrammering
22 över en fjärransluten parprogrammerings IDE (eng. Integrated development environment) plugin. Denna plugin heter GitHub och används främst för versionshantering men kan användas för virtuell parprogrammering.
3.3 Systemdokumentation
3.3.1 Kravspecifikation
För att kunna påbörja en implementation skapades först kravspecifikationer för de funktioner som skulle utvecklas. Funktionerna var utvalda tillsammans med projektägaren, och kravspecifikationer skapades för att tydligt visa de specifikationer som de olika funktionerna kommer att ha. Genom att skapa kravspecifikationer eliminerades möjligheten att implementera något som redan fanns eller som inte behövdes – då kravspecifikationerna granskades av projektägarna innan de fick ett godkännande.
Kravspecifikationerna är alltså de krav på utförande, funktioner m.m. som kunden ställer på varan eller tjänsten. [18]
3.3.2 UML
UML (Unified Modeling Language) är ett objektorienterat språk som används för modellering av alla typer av system. UML användes för att ge en tydlig överblick över hur funktionen kommer att användas. Genom att skapa en modell av systemet blir det enklare att förstå och bygga det. [19]
3.4 Systemmiljö
3.4.1 IDE (Integrated development evironment)
Den utvecklingsmiljö (IDE) som användes under projektet var NetBeans. Detta användes för att implementera och testa den funktionalitet som togs fram. NetBeans är ett kostnadsfritt datorprogram som innehåller en textredigerare, kompilator m.m. som tillsammans underlättar vid programmering.
3.4.2 GitHub (Versionshantering)
GitHub är en online-tjänst för mjukvaruutveckling som använder versionshanteringssystemet
Git. Under projektet integrerades NetBeans med GitHub. Då en integrering skapas kan all källkod
23
3.4.3 Java
24
Kapitel 4 Sammanställning av data
Då fallstudien var genomförd var det tydligt om vart ifrån datan skulle inhämtas. I detta kapitel beskrivs den insamlade datan och analyseras utifrån vilket som var användbart för de framtagna funktionerna.
4.1 Insamlad data
Den data som kunde användas var det som Preem AB kunde leverera. Datan erhölls genom att uppfölja transaktioner, leveranser, lagerändringar och andra datakällor.
Data från MCD, angående nivåförändring överförs flera gånger per dag, till skillnad från Forcourt Servern som skickar transaktionsdata en gång per dag – vid midnatt. Datan överförs som en rapport med alla transaktioner sammanfattade, på så sätt kan data filtreras utefter behov. Data från leverantören (Hoyer) överförs när en leverans avslutats. All data överföring kan dock fördröjas på grund av allmänna tekniska problem i deras system. Den data som överförs samlas och bearbetas i mjukvarusystemen Siteinfo och Lagerkontroll.
4.1.1 Kvalitativ data
Föreläsningar med Preem AB:
● Allmän bakgrund om Preem AB ● Integration och databas
Föreläsning med MCD: ● mcdMonitorII ● Pejl
● Cistern ● SiteInfo
Veckomöten med handledare hos Preem AB.
4.2 Användbart kvantitativt data
25
Para ihop omatchande rapporter m.h.a. annat data än vad som används för tillfället
Data från drivmedelsanläggningarna Data från Hoyer (Leverantörsdata)
Från MCD Från Forcourt Server Varukod (bensin, etanol,
diesel m.m) Anläggningsinformation
(total volym,
anläggningsnummer, m.m)
Transaktionshistorik Storlek för leveransen i antal liter
Cisternnivå (pejlvärde) Temperatur (ej tillgänglig nu)
Cistern - och grupp nummer Tid punkter för start och slut
Temperatur Tankbilens nummer
Tidpunkt Tankbilens chaufför
Ta reda på cisternernas dödvolymsnivå
Data från drivmedelsanläggningarna
Från MCD Från Forcourt Server
Anläggningsinformation (total volym,
anläggningsnummer, m.m) Transaktionshistorik
26
Optimera leveransplaneringen
Data från drivmedelsanläggningarna Data från egen implementation Data från Hoyer (Leverantörsdata)
Från MCD Från Forcourt
Server Eventuell dödvolymsnivå för
respektive cisternerna Varukod (bensin, etanol, diesel m.m) Anläggningsinformati on (total volym, anläggningsnummer, m.m)
Transaktionshistorik Storlek för leveransen
i antal liter
Cisternnivå
(pejlvärde) Datum och tidpunkt
27
Kapitel 5 Analys
I projekt är det viktigt att rätt arbetsmetod används samt att reflekterar därefter över om metoden bidragit till rätt resultat. Lagerhanteringsystemet har många möjligheter till att utvecklas ännu mer än vad som förslagits i denna studie – i detta kapitel analyseras de funktionerna som valdes att implementeras.
5.1 Kravspecifikation för utvald funktionalitet
Innan någon implementation påbörjades, skulle en kravspecifikation för varje funktion att skrivas. Att skapa kravspecifikationer har många fördelar, framförallt är den till för att precisera problemformuleringen. En kravspecifikation ska försöka ge alla inblandade en klar bild över projektmålet.
Kravspecifikationen ska innehålla information om funktionalitetens format (hur den ska implementeras), funktion (vad den utför) och övrig information som kan vara av intresse för funktionaliteten i fråga. En kravspecifikation ska stödjas med motsvarande prototyper och/eller pseudokod. För att skapa tydliga kravspecifikationer skapades en mall, som används i bilaga A, B och C.
De nya funktionerna som valdes att implementeras och analyseras beskrivs nedan.
Para ihop omatchande rapporter m.h.a. annat data än vad som används för tillfället
Leveranser sker regelbundet, oftast under kvällstid. Hur ofta en tankbil levererar beror på hur mycket anläggningen förbrukar. När en påfyllning påbörjat, rapporterar både pejlen och Hoyer in denna information till SiteInfo. Informationen angående tiden för leverans som pejlen ger ska stämma överens med vad Hoyer rapporterat in. SiteInfo är systemet som har till uppgift att försöka para ihop de två rapporterna, dock är inte alltid så att båda rapporter kommer in samtidigt. I det nuvarande systemet måste personalen själva para ihop leveranser som inte kommit in samtidigt. Därför ska en funktion skapas som kan para ihop två rapporter m.h.a. annan data som finns tillgängligt. Den data som tänkts användas för att para ihop rapporterna är volymen och temperaturen. Temperaturen av drivmedlet som levereras dokumenteras inte för tillfället, därför kommer denna funktion ta reda på om volymen, chaufför och om
28 Figur 5.1: Två rapporter som skiljer sig i tid men stämmer överens i både volym och temperatur (om 8000 liter av
8 graders drivmedel blandas med 5000 liter 7 graders drivmedel kommer sluttemperaturen bli ~7,6 grader (termodynamikens nollte huvudsats))
Figuren nedan visar hur problemet tänkts lösas om temperaturen även var angiven i leverantörsrapporten.
Figur 5.2: Grafisk presentation över lösningsförslaget för matchning av rapporter
Ta reda på cisternernas dödvolymnivå
29 Denna funktion fungerar endast om cisternen har nått dödvolym vid något tillfälle, detta för att det är endast vid de tillfällena transaktionsavböjelser kan bero på dödvolym. Om en cistern inte nått dödvolym kan inga slutsatser angående när den når dödvolym dras. För att avgöra om en cistern inte nått dödvolym tas det lägsta historiska värdet för volymen för den cisternen och jämförs med det teoretiska värdet för dödvolym – om värdena skiljer sig åt för mycket (2-5%) kan slutsatsen om att cisternen aldrig nått dödvolym dras.
Figur 5.3: Grafisk presentation över lösningsförslaget för att hitta dödvolym
30
Figur 5.4: Nivåförändrings historik för anläggningen 46507 cistern 1 (De små nivåökningarna kan bero på
drivmedlet som befinner sig i sugledningen faller tillbaka till cisternen)
31 Figur 5.5: Transaktionhistorik för anläggning 46507 cistern 1
I exemplet ovan utreddes en cistern som inte var sammankopplad med andra cisterner. Om cisternen var sammankopplad ställs ännu ett krav för att kunna försäkra om dödvolym har nått. Kravet är att drivmedelsnivån för de sammankopplade cisternerna måste vara detsamma, däremot kan sugledningarna befinna sig på olika platser.
Optimera leveransplaneringen
32 Figur 5.6: Grafisk presentation över lösningsförslaget för optimering av leveransplaneringen
5.2 Modellering av utvald funktionalitet
Före implementationen påbörjas, är det till fördel att först göra en modell av hur problemet ska lösas. Modeller används inom ingenjörskonst för att beskriva och representera olika slags objekt och system. Dessa modeller användes som verktyg för att förstå, beräkna och kontrollera funktionsflödet.
5.3 Prototyper
När en kravspecifikation och en modell för en funktion producerats, samt att indatan samlats in, är det relativt enkelt att skapa en prototyp. Om kravspecifikationerna är omfattande har det mesta ofta tagits i åtanke så som, risker, teoretisk lösning m.m. Prototyperna är en motsvarighet av modellerna – skillnaden är att prototyperna förklarar lösningen i form av kod. Prototyperna skapades för att ytterligare bevisa hur problemformuleringarna kan besvaras.
33
Kapitel 6 Resultat
I detta kapitel presenteras resultatet samt leverablerna. Här ska arbetet även sammanställas samt visa en lösning till problemet som är i fråga.
6.1 Kravspecifikation
Kravspecifikationerna som presenterats i bilaga A, B och C har till uppgift att besvara frågeställningarna, vad som behövs ha i åtanke och varför funktionaliteten behövs. Detta är en leverabel som projektägaren kräver för att de ska få en idé på hur en lösning kan se ut. Kravspecifikationen ska alltså räcka för att uppfatta problemet och för att få en lösningsidé angående hur problemet kan lösas.
6.2 Modeller
Modellerna är till för att ge en bättre överblick över hur problemet tänkts lösas. De skapades för att styrka kravspecifikationerna genom att beskriva flödet funktionaliteten tänkt ha. Nedan visas aktivitets diagram för de funktioner som valdes att utredas.
6.2.1 Para ihop omatchande rapporter m.h.a. annat data än vad som används för tillfället
34 Figur 6.1: Flödet för att jämföra om leveransrapporterna stämmer överens med pejlmätningarna
6.2.2 Ta reda på cisternernas dödvolymsnivå
35 Figur 6.2: Flödet för att hitta dödvolymsnivå
6.2.3 Optimera leveransplaneringen
36 Figur 6.3: Flödet för att optimera leveransplaneringen
6.3 Prototyp
37 Vi skapade endast en färdig prototyp, det var för att hitta dödvolymsnivån i cisterner. Att endast en prototyp skapades var på grund av tidsbrist – lösningsförslag i form av pseudokod skapades dock för alla funktioner. Prototypen är ett fungerande program som beräknar dödvolym på det sätt som förklarats i kapitel 5 och i bilaga B. Som tidigare nämnts kunde dödvolymsnivån inte bestämmas om en cistern aldrig nått den nivån. Se figur 6.4.
Anläggning: 14352
Lägsta nivån för cistern 1 är 71.6mm Sun Oct 05 17:58:58 CEST 2014 Lägsta nivån för cistern 2 är 161.0mm Tue Aug 26 12:52:01 CEST 2014 Lägsta nivån för cistern 3 är 534.6mm Mon Oct 06 11:36:48 CEST 2014 Lägsta nivån för cistern 4 är 550.4mm Mon Oct 06 11:40:07 CEST 2014 Det är dödvolym för cistern 1 vid 71.6 mm
Dödvolym kan inte hittas för cistern 2 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 3 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 4 p.g.a inkomplett data Anläggning: 16571
Lägsta nivån för cistern 1 är 305.4mm Mon Apr 13 08:03:12 CEST 2015 Lägsta nivån för cistern 2 är 360.1mm Mon Feb 09 22:08:28 CET 2015 Dödvolym kan inte hittas för cistern 1 p.g.a inkomplett data
Dödvolym kan inte hittas för cistern 2 p.g.a inkomplett data Anläggning: 36780
Lägsta nivån för cistern 1 är 160.3mm Mon Jun 16 20:49:11 CEST 2014 Lägsta nivån för cistern 2 är 97.0mm Tue Aug 12 18:20:01 CEST 2014 Lägsta nivån för cistern 3 är 302.1mm Tue Jul 15 20:59:18 CEST 2014 Dödvolym kan inte hittas för cistern 1 p.g.a inkomplett data
Dödvolym kan inte hittas för cistern 2 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 3 p.g.a inkomplett data Anläggning: 46113
Lägsta nivån för cistern 1 är 722.3mm Tue Mar 17 18:19:29 CET 2015 Lägsta nivån för cistern 2 är 1040.7mm Sat May 02 07:52:38 CEST 2015 Lägsta nivån för cistern 3 är 502.1mm Thu Dec 04 21:06:27 CET 2014 Lägsta nivån för cistern 4 är 1017.0mm Sat May 02 08:08:19 CEST 2015 Lägsta nivån för cistern 5 är 108.5mm Wed Apr 15 09:16:42 CEST 2015 Dödvolym kan inte hittas för cistern 1 p.g.a inkomplett data
Dödvolym kan inte hittas för cistern 2 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 3 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 4 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 5 p.g.a inkomplett data Anläggning: 46507
38 Dödvolym kan inte hittas för cistern 2 p.g.a inkomplett data
Dödvolym kan inte hittas för cistern 3 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 4 p.g.a inkomplett data Anläggning: 52325
Lägsta nivån för cistern 1 är 331.8mm Thu Aug 21 17:15:50 CEST 2014 Lägsta nivån för cistern 2 är 144.5mm Wed Jul 02 20:11:27 CEST 2014 Lägsta nivån för cistern 3 är 569.1mm Sat Aug 16 14:09:14 CEST 2014 Lägsta nivån för cistern 4 är 573.5mm Thu Jan 29 06:13:21 CET 2015 Lägsta nivån för cistern 5 är 575.9mm Thu Jan 29 06:15:22 CET 2015 Dödvolym kan inte hittas för cistern 1 p.g.a inkomplett data
Dödvolym kan inte hittas för cistern 2 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 3 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 4 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 5 p.g.a inkomplett data Anläggning: 53555
Lägsta nivån för cistern 1 är 71.7mm Mon Oct 27 19:28:35 CET 2014 Lägsta nivån för cistern 2 är 139.5mm Mon Jul 28 10:39:56 CEST 2014 Lägsta nivån för cistern 3 är 130.4mm Mon Jul 28 10:43:01 CEST 2014 Det är dödvolym för cistern 1 vid 71.7 mm
Dödvolym kan inte hittas för cistern 2 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 3 p.g.a inkomplett data Anläggning: 59465
Lägsta nivån för cistern 1 är 362.7mm Thu Apr 16 23:47:26 CEST 2015 Lägsta nivån för cistern 2 är 89.5mm Wed Feb 04 10:26:23 CET 2015 Lägsta nivån för cistern 3 är 79.7mm Tue Apr 14 08:20:29 CEST 2015 Lägsta nivån för cistern 4 är 407.4mm Sat Feb 21 07:23:20 CET 2015 Lägsta nivån för cistern 5 är 443.4mm Wed Apr 29 15:10:06 CEST 2015 Dödvolym kan inte hittas för cistern 1 p.g.a inkomplett data
Dödvolym kan inte hittas för cistern 2 p.g.a inkomplett data Det är dödvolym för cistern 3 vid 79.7 mm
Dödvolym kan inte hittas för cistern 4 p.g.a inkomplett data Dödvolym kan inte hittas för cistern 5 p.g.a inkomplett data
39
Kapitel 7 Diskussion
Detta kapitel är försedd för att kritisera samt styrka de val som gjort.
7.1 Metodval
Att diskutera kring arbetsmetoderna har en stor betydelse eftersom att arbetsmetoderna har påverkan på resultatet.
7.1.1 Förstudie Fallstudie
Fallstudien var en given process som krävdes för att utföra detta projektarbete. Under denna fallstudie inhämtades nödvändig kunskap för att få en ökad förståelse av Preem ABs lagerhanteringssystem.
Datainsamling
Den data som fanns tillgängligt var tillräckligt för att kunna besvara problemformuleringarna, dock så kunde den nya funktionaliteten optimeras om annat data fanns tillgängligt.
Avgränsningar i arbetet
MoSCoW listan skapades för att begränsa och prioritera arbetet. Detta underlättade planeringen och projektprocessen. Att prioritera arbetet på detta sätt kan vara en bra strategi men detta kan även leda till att andra delar försummas.
7.1.2 Projektprocessen Agil utveckling
40
Parprogrammering
Parprogrammering tillämpades främst för att projektutövarna skulle ha koll på all koden som skrevs. Om ena projektutövaren hade för sig att skriva kod kunde den andra granska koden för att bidra med synpunkter, rekommendationer e.t.c. Metoden kan vara svår att tillämpa då granskaren måste se varje kodrad som matas in. Då projektutövarna inte kunde granska varje kodrad som skrevs så sparades en ny version av koden vid varje uppdatering. På detta sätt kunde koden granskas i efterhand.
7.1.3 System dokumentation Kravspecifikation
Kravspecifikationerna användes framförallt för beskriva och precisera den nya funktionaliteten som togs fram. Då funktionaliteten i vårt fall kunde besvara problemformuleringen var det viktigt att tydligt dokumentera funktionsflödet. Kravspecifikationerna gav alla inblandade en klar bild av hur funktionaliteten skulle implementeras och kunde därmed försäkra om att projektarbetet gick i rätt riktning. En stor fördel var möjligheten att under projektets kunna gå tillbaka till dokumentet för att försäkra om att arbetet gick i rätt riktning.
UML
Att skapa modeller med hjälp av UML var väldigt gynnsamt och rekommenderas starkt. Modellerna är riktiga, konsekventa, enkla att förmedla till andra och även enkla att ändra. UML används i stor utsträckning inom industrin och är en väletablerad samt beprövad teknik. [20] Med hjälp av UML undvek vi att börja programmera för tidigt, inte förrän modellerna var framtagna påbörjades programmering.Ännu en fördel med UML är att det inte är företagsägt och är därmed fritt att använda.
7.2 Samhälleliga och etiska aspekter
41
7.3 Förslag till vidare forskning
Ett förslag för vidare forskning är att följa implementeringsprocessen som beskrivs i kravspecifikationerna och applicera det i systemet – detta för att utreda om funktionaliteten höjer effekten av lagerhanteringssystemet. Även att djupare studier utförs, studien bör minst omfatta 30 högskolepoäng, eftersom att det är svårt att få grepp om ett lagerhanteringssystem där möjligheter till ny funktionalitet är stor.
7.4 Slutsats
De resultat som framtagits är lösningsförslag på hur den nya funktionaliteten kan implementeras. Om Preem AB implementerar den funktionalitet som tagits fram kommer lagerhanteringen få ökad effektivitet Detta genom att eliminera den arbetskraft som förbrukas för att hålla reda på felaktiga leveranser, minska mängden onöjda kunder genom att förhindra att dödvolym uppstår och kunna utnyttja hela cisternen kapaciteten – genom att optimera leveransplaneringen. I bästa fall kan Preem AB eliminera all tid som går åt att para ihop inkompletta leveranser samt eliminera att dödvolym uppstår i någon cistern.
En faktor med stor inverkan på funktionalitetens framgång är hur programmet implementeras. Vid implementering bör man ta hänsyn till att funktionaliteten som togs fram var ett gemensamt beslut mellan Preem AB och studenterna – vi fick inspiration från de anställdas perspektiv och tankar. Genom ett sådant arbetssätt kan det skapas en känsla av delaktighet och påverkan, vilket leder till att de anställda lättare kan acceptera och uppskatta förändringarna.
42
Källförteckning
[1] Marknad och Försäljning, Om Preem, http://preem.se/om-preem/om-oss/vad-vi-gor/marknad-och-forsaljning/
[2] MoSCoW method, http://en.wikipedia.org/wiki/MoSCoW_method
[3] A. Åhlström, Handledare för KEX jobb i Preem AB, Stockholm, 19-01-2015 Föreläsning april 2015.
[4] Europas Modernaste Raffinaderier, Om Preem, http://preem.se/om-preem/om-oss/vad-vi-gor/raff/
[5] Preem årsredovisning 2014
[6] Preems Depåer, Om Preem, http://preem.se/om-preem/om-oss/vad-vi-gor/depaer/ [7] Dag Hultgren, Huvudutvecklaren för MCDMonitorII från MCD AB. ”Kandidatarbeten hos Preem” 2015, Föreläsning 1 april.
[8] Aaby, Anthony. 2004. Introduction to Programming Languages. [Online]. Tillgänglig vid: http://www.emu.edu.tr/aelci/Courses/D-318/D-318-Files/plbook
[9] Y. Shafranovich, okt-2005. Common Format and MIME Type for Comma-Separated Values
(CSV) Files, Network Working Group,. [Online]. Tillgänglig vid: www.ietf.org/rfc/rfc4180.txt.
[Åtkomstdatum: 08-apr-2015].
[10] Peter Van Roy. 2009-05-12. Programming Paradigms for Dummies: What Every
Programmer Should Know. info.ucl.ac.be. Page 10. [Online]. Tillgänglig vid:
https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf.
[11] Patel, R., & Davidsson, B. 2011. Forskningsmetodikens grunder: Att planera, genomföra
och rapportera en undersökning. Lund, Sweden: Studentlitteratur.
[12] Gerring, J. 2007. Case Study Research. Cambridge: Cambridge University Press. [13] Tufte, P. A., & Johannessen, A. 2002. Introduktion till samhällsvetenskaplig metod. Malmö: Liber.
[14] Williams, Laurie. 2001. Integrating Pair Programming into a Software Development
43 [15] Cockburn, Alistair, Williams, Laurie. 2000. The Costs and Benefits of Pair Programming. Boston, USA
[16] Ulf Rask. 2013-06-19. Effektiv parprogrammering i utvecklingsorganisation. [Online]. Tillgänlig vid:
http://www.citerus.se/effektiv-parprogrammering-i-utvecklingsorganisationer/#conversion-0
[17] Flor, Nick. 2006. Globally distributed software development and pair programming.
Communication of the ACM, 49, 57–58.
[18] Guide för att skriva en bra kravspecifikation, http://www.kravspecifikation.se/mall-exempel
[19] Guide och information angående UML diagram, http://www.uml-diagrams.org/ [20] Umeå universitet, föreläsning om UMLs fördelar,
44
Bilagor
Bilaga A. Kravspecifikation för “Para ihop omatchande rapporter m.h.a.
annat data än vad som används för tillfället”
A1. Bakgrund
Leveranser sker regelbundet, oftast under kvällstid. Hur ofta en tankbil levererar beror på hur mycket anläggningen förbrukar. När en påfyllning påbörjat, rapporterar både pejlen och Hoyer in denna information till SiteInfo. Informationen som pejlen ger ska stämma överens med vad Hoyer rapporterat in. SiteInfo är systemet som har till uppgift att försöka parsa ihop de två rapporterna, dock är inte alltid så att båda rapporter kommer in samtidigt. Därför ska en funktion skapas som kan matcha två rapporter utefter viss information.
A2. Funktionella krav
“Anläggningar med försenad rapporter(påfyllning syns i systemen men är ej rapporterad av tankbil, vice versa) ska matchas ihop m.h.a. av annat data än vad som används för tillfället”
I det nuvarande systemet måste personalen själva para ihop rapporter som inte kommit in samtidigt. Funktionen ska automatiskt kunna para ihop försenade rapporter från Hoyer eller tvärtom genom att kontrollera dessa rapporter utifrån:
● Anläggnings nummer ● Tidpunkt
○ start och sluttid för leveranser enligt pejlen ○ start och sluttid för leveranser enligt Hoyer ● Storlek för leveranser i antal liter
● Temperatur (ej tillgänglig för tillfället) ● Cisterngrupp
● Cistern
A2.1 Orsak av problem
Problemet kan uppstå av följande händelser:
● Tankbilens chaufför har inte rapporterat i tid
● Leveransen påbörjade strax innan midnatt, men rapporten kommer in först i nästa dag ● Rapporten är ihop slagna(flera rapporter i en och samma rapport)
● Leveransrapporten från Hoyer stämmer inte överens med vad pejlen säger
A2.2 Händelseflöde/exekveringsflöde
45 nämnts ovan. Informationen avgör om rapporterna motsvarar varandra eller inte. Om de
motsvarar varandra ska dessa två rapporter sammanfogas. Därefter ska ett meddelande till relevant person skickas, för att sedan kunna godkänna denna leverans.
A2.3 Data
A2.3.1 Indata
● Anläggnings nummer ● Tiden
○ start och sluttid för leveranse enligt pejlen ○ start och sluttid för leveranse enligt Hoyer ● Storlek för leveranser i antal liter
● Temperatur (ej tillgänglig för tillfället) ● Cisterngrupp
● Cistern
A2.3.2 Utdata
● Ihopslagna rapporter utifrån resultatet av den analytiska matchningen
A3. Dokumentation
A3.1 Teoretisk lösning
1. Hämta in leveransinformation från pejlen och Hoyer. Starttid, sluttid, storlek o.s.v 2. Hämta ytterliga leveransinformation så som temperatur och, chaufför numret. 3. Beräkna vad temperaturen bör vara efter leverans, m.h.a. energiprincipen. 4. Jämför informationen och kontrollera om de stämmer överens
5. Om de stämmer överens, slå ihop de två rapporterna och meddela relevant personal
A3.2 Implementation A3.2.1 Psedokod
set Object PejlRapporter{
46
set Object HoyerRapporter{
set anläggningnummer
set cisternnummer set sterttid;
set sluttid; set volym;
set temperatur (ej tillgängligt nu); set varu;
}
void function paraRapporter(){
set pejlInfo = läsa in leveransrapport från pejlen i formad av PejlRapporter; set hoyerinfo = läsa in leveransrapport från Hoyer i formad av HoyerRapporter;
//Beräkna temperaturen då leverans sker m.h.a. termodynamikens nollte huvudsats och jämför //om det stämmer överens med vad Hoyer rapporterat in.
if hoyerinfo.anläggningnummer är lika med pejlInfo.anläggningnummer { if hoyerinfo.cisternnummer är lika med pejlInfo.cisternnummer { if hoyerinfo.varu är lika med pejlInfo.varu {
if hoyerinfo.volym / pejlInfo.volym < 5% eller hoyerinfo.volym - pejlInfo.volym = ± 200 liter{
dessa två rapporter stämmer överens;
return;
}
//Om endast volym inte stämmer överens
47 }
//Oftast är det volym som inte stämmer överens, d.v.s. volym skiljer sig mer än 5% eller 200liter void function kontrollPejladVolym(pejlInfo){
set nivåHistorik = läsa in nivå historik för pejlInfo.cisternnummer set teoretiskbalansHistorik = den teoretisk balansens historik för pejlInfo.anläggningnummer.cisternnummer
//analysera den teoretisk balansens historik efter leveransen men volym värde från pejlen
if nivåHistorik stämmer överens med den teoretisk balansensen{ pejlen har rätt volym;
}
if nivåHistorik stämmer inte överens med den teoretisk balansensen{ sätta in Hoyers volym värde;
if nivåHistorik stämmer överens nu med den teoretisk balansensen{ Hoyer har rätt volym, pejlen räknad fel;
}
48
Bilaga B. Kravspecifikation för “Ta reda på cisternernas dödvolymsnivå”
B1. Bakgrund
En sugledning i en cistern når inte ända ner i botten av cisternen - för att den inte ska suga upp vatten och orenheter till kunder. Den volym som sugledningen inte når kallas då för dödvolym. Preem AB vill undvika att nå dödvolym, på grund av kunder inte kan tanka då. Sugledningen i alla cisterner kan ha olika längder och informationen angående detta finns inte tydligt dokumenterat. Exempelvis kan en sugledning nå drivmedlet som ligger 10cm ovanför botten av en cistern, medans en annan sugledning når 20cm.
B2. Funktionella krav
“Cisternernas dödvolym ska presenteras till relevant personal”
Denna funktion tar reda på ett teoretiskt värde för vilken nivå dödvolym uppstår i en cistern. Målet är att skapa en lista som innehåller förhållandet mellan cisterner och dess dödvolym.
B2.1 Orsak av problem
● Sugröret som pumpar drivmedel till kund är olika placerade ● På grund av service av cisterner omplaceras sugledningarna
A2.2 Händelseflöde/Exekveringsflöde
Denna funktion ska bara behövas exekveras en gång för att ta reda på dödvolymen på de cisterner som någonsin nått dödvolym. Då den exekveras går den igenom de olika stegen som förklaras i punkten “teoretisk lösning” - funktionen ska returnera en lista som visar förhållandet mellan en cistern och dess dödvolym.
B2.3 Data B2.3.1 Indata ● Nivåförändring ● Anläggningsinformation ● Cisterninformation ● Transaktionshistorik B2.3.2 Utdata
● En lista med ett teoretisk värde för varje cistern
B3. Dokumentation
49 För att ta reda när en cistern når dödvolym tar vi först reda på den historiskt lägsta volymen cisternen någonsin nått.
Figur b.1: Historiskt lägsta volym
Sedan jämförs den lägsta volymen med det teoretiska värdet för dödvolym. Preem AB beräknar det teoretiska på följande sätt: DTeoretisk = Faktiska volym * 0.05. Om volymerna inte skiljer så mycket åt kan antagelsen om att cisternen nått dödvolym dras. För att försäkra om att cisternen nått dödvolym tar vi reda på om det har inträffat något köp, fast inte slutfört under tiden tills nästa nivåförändring, som förmodligen kan vara en leverans.
Lösningsförslaget i form av en punktlista: ● Jämför lägsta nivån med DTeoretisk
○ Om värdet ligger långt ifrån DTeoretisk, ex. 20 cm ovanför då antas att DTeoretisk inte är måttet för dödvolym
○ Om värdet ligger i närheten av DTeoretisk kan antagandet att dödvolym uppstår vid det måttet
● Ta reda på försäljningshistorik vid detta tillfälle
○ Om köp har inträffat och all drivmedel har gått till kunden
■ Ensamstående Cisternen: cisternen har inte nått dödvolymsnivå, problem med pejlen
■ Sammankopplade cisternerna: kontrollerar om nivå ändras i den andra cisternen. Om ja, den första cisternen har nått dödvolymsnivå.
○ Om köp inträffar fast inte slutförts (cisternern inte har tillräckligt med drivmedel) kan antagandet att cisternen nått dödvolym dras.
50 Om punkterna stämmer överens i den ordning som angivits för att nå dödvolym, noteras detta genom att uppdatera värdet som är angivet som dödvolym för den utredda cisternen.
Denna funktion fungerar endast om cisternen har nått dödvolym vid något tillfälle, detta för att det är endast vid de tillfällena transaktionsavböjelser kan bero på dödvolym. Om en cistern inte nått dödvolym kan slutsatsen när dödvolym uppstår inte tas fram. För att avgöra om en cistern inte nått dödvolym tar man reda på det lägsta historiska volymen för en cistern och jämför det med det teoretiska värdet för dödvolym - om de värdena skiljer sig för mycket kan man dra slutsatsen om att cisternen aldrig nått dödvolym.
B3.2 Implementation B3.2.1 Psedokod
set dödvolymsnivåHistorisk; set dödvolymsnivåFaktisk;
set historikArray[] = läsa in nivåhistorik;
set transaktionsHistorik[] = läsa in transaktionshistorik;
set dödvolymsLista = en lista med samtliga dödvolymsnivå för alla cisternerna i alla anläggningarna;
/* sortera arrayen som innehåller nivåhistoriken i storleksorning. Välja ut den lägsta nivå,kontrollera även om det värdet är giltigt
*/
void function lägstNivå{
sortera historikArray[] efter storlek; while !kontrolleraVärde(historikArray[x])
x += 1;
dödvolymnivåHistorisk = historikArray[x];
jämföra dödvolymsnivåHistorisk med dödvolymsnivåTeoretisk; beräknaDödvolym(dödvolymsnivåHistorisk);
}
/*Kontrollera om värde är giltigt, alltså inte värde som är för låg eller felaktig värde */
boolean function kontrolleraVärde(x){ if x är mindre än dödvolymsnivåTeoretisk
return false;
if x är mycket mindre än den teoretiska balansen
return false;
51
/*Kontrollera om den lägsta giltiga nivån är den faktiska dödvolymsnivån */
void function beräknaDödvolym(dödvolymsnivåHistorisk){ set startPunkten = dödvolymsnivåHistorisks tidpunkten; set stopPunkten = nästkommande nivåförändrings tidpunkten;
kontrollera i transaktionshistorik[];
if det ha inträffat något köp, fast inte slutfört mellan startPunkten och stopPunkten{
if ja{
dödvolymsnivåHistorisk är den faktiska dödvolymsnivån
uppdateraDödvolymsLista(dödvolymsnivåHistorisk);
}
if nej{
Analysera tidigare historik om det brukar finnsa köp under denna period if ja, cistern kan ha nått dödvolymsnivån (kanske en bemannad station,
kunden blev meddelad att drivmedel är slut)
uppdateraDödvolymsLista(dödvolymsnivåHistorisk);
}
}
if köp har inträffat och all drivmedel har gått till kunden {
if cisternen är ensamstående, dödvolymsnivå har inte nått, problem med pejlen
if cisternen är sammankopplad{
if nivån i den andra cistern har minskats{
den första cisternen har nått dödvolym;
uppdateraDödvolymsLista(dödvolymnivåHistorisk);
}
if nivån i den andra cistern har inte minskats,
problem med pejlen i båda cisternerna;
}
} }
/*Uppdatera listan med alla dödvolymsnivån */
void function uppdateraDödvolymsLista(dödvolymsnivå){
52
/*Expotera listan med alla dödvolymsnivån /*
53
Bilaga C. Kravspecifikation för “Optimera leveransplanering”
C1. Bakgrund
Cisternerna grupperna brukar fyllas på med jämna mellan rum, detta kan ha en negativ påverkan då vissa cisternerna grupper aldrig utnyttjar sin fulla kapacitet - se figur c1 för att få en överblick över hur det kan se ut. För att utnyttja kapaciteten behövs bättre planering angående när en leverans ska ske till en viss cistern se figur c2 för att få en överblick över hur det önskas att se ut.
Figur c.1: Cistern nummer 2 på anläggningen 46113 som endast använd sig av hälften av hela kapaciteten
Figur c.2: En idealisk graf för en cistern som utnyttjar sin kapacitet
54
C2. Funktionella krav
“Optimera leveransplanering”
Denna funktion ska beräkna när en cistern eller fler sammankopplade cisterner bör fyllas på genom att beräkna vad cisternerna förbrukar i genomsnitt. Genom funktionaliteten “Ta reda på cisternernas dödvolymsnivå” går det att avgöra när en cistern bör fyllas på innan den når dödvolym.
C2.1 Orsak av problem
● Leverantörerna vet inte när en cistern planeras nå dödvolym
● Planeringen är satt utifrån en geografiska ståndpunkt där leverantören åker till de anläggningar den befinner sig närmst.
C2.2 Händelseflöde/Exekveringsflöde
Denna funktion ska även bara behövas exekveras en gång per dag för att ta reda på när en leverans bör ske. Funktionen ska returnera en lista som visar förhållandet mellan en cistern och vid vilken nivå den bör fyllas på. Denna lista ska kunna användas av leverantören för att
optimera leveransplaneringen och därmed undvika att en cistern når dödvolym.
C2.3 Data
C2.3.1 Indata
● Anläggningsnummer och cisternnummer ● Transaktionshistorik
● Dödvolymsnivå
C2.3.2 Utdata
● En lista som visar förhållandet mellan en cistern och vid vilken nivå den bör fyllas på. Denna funktion tar endast reda på när en cistern planeras gå tom - m.h.a. av detta resultat kan optimerade planeringar göras för att utnyttja en cisterns fulla kapacitet.
C3. Dokumentation
C3.1 Teoretisk lösning
● Ta reda på de cistern grupper som behöver optimeras genom att: ○ Räkna ut medelvärdet för nivån innan leverans
○ Jämföra medelvärdet med den totalavolym gruppen kan ha
● Analysera försäljningshistoriken, och ta reda på hur mycket drivmedel som säljs i genomsnitt för respektive veckodag under en period (ex. ett år).
● Vid slutet av varje dag ska detta funktionen kontrolleras om drivmedel som finns kvar räcker till de två kommande dagar
○ Ta reda på återstående drivmedel: drivmedelkvar
