Systemstöd för inregistrering av lastbilar

(1)

Systemstöd för inregistrering av lastbilar

Av:

Sulayman El Far

Panorama bild över truckstop

Examensarbete Industriell Produktion

(2)

(3)

Examensarbete

Systemstöd för inregistrering av lastbilar System support for registration of trucks

Godkänt

2012-mån-dag

Examinator

Bengt Lindberg

Handledare

Jerzy Mikler

Uppdragsgivare SSAB

Kontaktperson

Joakim Noren

Sammanfattning

Idag har det blivit allt mer populärt att implementera systemlösningar i företag. Därför har det blivit allt viktigare med strukturerade utvecklingsprocesser för företag. SSAB har idag ett problem med att lastbilar anländer direkt till produktionen där det uppstår köer både inom och utanför. Detta leder till att lastbilar ställer sig på platser som inte är avsedda för parkering vilket kan ställa till besvärliga situationer. Det som är tänkt med det här projektet är att använda existerande truckstop vilket idag endast används för chaufförer som vill vila upp sig, till att utveckla en ankomstregistrering system. Dit ska lastbilar anlända till direkt för att

ankomstregistrera sig och invänta sin tur.

Målet med examensarbete är att identifiera och utforma kravspecifikation till projektet för att ha dem bästa förutsättningarna till ett smidigt arbete. Resultatet av undersökningarna blev en mer strukturerat kravspecifikations system för att ta reda på mer tydligt funktionernas krav. Exempel på verktyg som användes var UML; activity based diagram och use case diagram. Dessa gjorde det möjligt att visuellt forma bygget på papper för att sedan utifrån dem strukturerat skriva kravspecifikation. För att sedan validera bygget gjordes acceptans tester vilket endast testades på en labbmiljö för att systemet inte hann implementeras.

Dessa hade till syfte att redan tidigt i projektet upptäcka potentiella fel samt validera bygget för att dubbelkolla att kundkraven möts. Slutsatsen är att användningen av dessa verktyg ger positiva resultat i form av förbättrad kommunikation mellan projektmedlemmarna eftersom när ett system visualiserats blir den enklare att specificera kraven. Det blev även bättre samarbete och en ökad förståelse för hur förarbetet kan leda till mindre slöserier både i tid och pengar.

(4)

(5)

Abstract

Today it has become increasingly popular to implement systemsolutions in company's.

Therefore, it has become increasingly important with structured development processes. SSAB today has a problem with the trucks arriving directly to production where queues occur both inside and outside. This leads to the trucks standing in places not intended for parking, which can cause troublesome situations. The goal of this project is to use the existing truck stop, which today is used only for drivers who want to rest up.

To develop an arrival registration system. There trucks should arrive directly to register their arrival and wait for their turn. The aim of the thesis is to identify and design the specifications for the new system in order to have the best conditions for a effective work. The results of the investigations became more structured requirement specifications to determine more clearly the functional requirements. Examples of tools used was UML; activity-based diagrams and use case diagrams. These made it possible to visually shape the construction and then based on those, structurally write the specifications. Then to validate the building was made acceptance tests, which only tested in a lab environment that the system could not be implemented. These were intended to early in the project detect potential errors and validate the construction to double- check that customer requirements are met.

The conclusion is that the use of these tools provide positive results in terms of improved communication between team members because when a system visualized it becomes easier to specify requirements. Even a better collaboration was noticed and increased understanding of how the preparatory work could lead to less wastage of both time and money.

(6)

(7)

FÖRORD

För det första vill jag börja med att säga det verkligen har varit ett nöje att arbeta med detta projekt. Det har både varit tidskrävande och utmanande men i slutändan fått mig att utvecklas både personligt och professionellt. Men trots allt har det ändå varit värt allt slit efter att ha sett det fantastiska resultatet och fått möjligheten att arbeta med otroligt duktiga personer.

Jag vill rikta mitt tack till min handledare i SSAB Joakim Noren, som har varit med mig sen dag ett och försett mig med vägledning samt den hjälp som jag behöver. Joakim var väldigt stöttande och hjälpsam vid dem stunderna som behövdes.

Vill även rikta ett stort tack till min handledare i KTH Jerzy Mikler. För att ha tagit sin tid till att hjälpa mig med rådgivning när jag behövt hjälp. Men även den stora uppgiften med att läsa genom min rapport och gett mig feedback.

Slutligen vill jag uttrycka min glädje över vad jag har åstadkommit med detta arbete och hoppas att det är en bra läsning.

Sulayman El Far KTH, 09/2016

(8)

(9)

Innehåll

1. INTRODUKTION 1

1.1 Bakgrund/Problemdefinition 1

1.2 Målformulering 1

1.3 Lösningsmetod 1

1.3.1 Litteratur 1

1.3.2 Genomförande av intervjuer inom företaget. 2

1.3.3 Projektgrupp 2

1.3.4 Avgränsningar 2

2. TEORETISK REFERENSRAM 3

2.1 Ellen 3

2.2 Proview 4

2.3 Processkarta UML 5

2.4 Kravspecifikation 6

2.4.1 Funktionella krav 8

2.4.2 Icke funktionella krav 8

2.5 Systemvalidering 10

3. RESULTAT 11

3.1 Nulägesanalys 11

3.2 Processkarta 13

3.3 Integrationer mellan systemen 14

3.4 Kravspecifikation 16

3.4.1 Funktionella krav 17

3.4.2 Icke funktionella krav 27

3.5 Testspecifikation 29

4. DISKUSSION 30

5. REFERENSER 32

6. BILAGOR 35

(10)

(11)

1. Introduktion

I inledningen kommer det att presenteras bakgrund till själva problemet, målformuleringar för detta projekt, lösningsmetoder som kommer att användas och avgränsningarna.

1.1 Bakgrund/Problemdefinition

Nuvarande situation för lastbilstrafik avseende avgående transporter med produkter från utlastningen i Oxelösund fungerar inte tillfredställande idag. Det uppstår köer med lastbilar inom och utanför SSAB:s område på platser som inte är avsedda som uppställningsplatser för lastbilsekipage. SSAB behöver minimera risken för att olyckor och skador uppstår med lastbilstrafiken inom och utanför närområdet till anläggningen. Upp till 40 lastbilar per dygn lastar färdiga produkter och drygt 2 200 in och ut passager sker genom vakten varje dygn inräknat alla fordon som passerar SSAB:s huvudport.

Under 2014 färdigställdes en truck stop ämnat för lastbilar och förare som skall hämta färdiga produkter hos SSAB. Det finns en uppställningsplats och en byggnad på platsen ämnad för lastbilsekipage och förare. För att projektet ska införas så korrekt och smidigt som möjligt har en projektgrupp skapats med syfte att vara med och påverka i systembygget. SSAB skall arbeta för en säker arbetsplats med tydliga instruktioner och processer för medarbetare, entreprenörer samt transportörer inom och i närhet till SSAB:s anläggning i Oxelösund. Förutom att det finns i SSAB:s eget intresse att se till att transporter på området sker säkert ställer Arbetsmiljöverket krav på att förare med tunga fordon följer de

säkerhetsföreskrifter som gäller på området.

Genom att ha god styrning och kontroll på flödet in av lastbilar så ökas möjligheten till en god arbetsmiljö och minimerande av risker med transporter in och ut från SSAB:s anläggning. Därför är tanken att chaufförerna ska åka direkt till truckstop där en terminal kommer att befinna sig för ankomstregistrering med hjälp av systemet Proview.

1.2 Målformulering

Syftet med detta projekt är att införa en ny arbetsprocess med nytt systemstöd för ankomstregistrering för SSAB:s transportörer och förare.

Projektet skall se till att det nya verktyget kan administrera och styra in och utflödet av transporter(lastbilar) vid SSAB Oxelösund.

Uppdraget innebär att:

1. Definiera verksamhetens krav och ta fram en kartläggning av processen.

2. Skapa en rutinbeskrivning som ligger till grund för kravspecifikation och aktiviteterna i processen för IT systemens funktionalitet samt integration.

3. Validering av systemet för att kontrollera om kundkraven är bemötta.

1.3 Lösningsmetod

Nedan kommer det nämnas vilka lösningsmetoder som användes för att utföra projektet

1.3.1 Litteratur

(12)

Litteratur kommer att användas för att beskriva hur systemen fungerar. Dem systemen som förklaras närmare är Ellen vilket används idag. Även Proview vilket är det nya systemet som kommer integreras med Ellen. Detta för att få en djupare inblick på hur dem kan integreras på bästa sätt. Litteratur kommer att undersökas i form av internet, vetenskapliga artiklar från databaser och böcker.

1.3.2 Genomförande av intervjuer inom företaget.

Projektgruppen bestod av flera viktiga personer i gruppen som spelade stor roll för införande av det nya systemet Proview. Samtliga personer som skulle påverkas intervjuades och fick sin syn på vad som var viktigt för projektets framgång. Dessa synpunkter kommer ligga i underlag för utformningen av

rutinbeskrivningarna och integrationerna mellan systemen. Intervjuerna kommer att hållas semi strukturerat för att även ta reda på information som inte håller sig till mallen.

1.3.3 Projektgrupp

I projektet kommer det ingå en projektgrupp där samtliga personer har en viktig roll för

systemimplenteringen. All personal inblandade har till uppgift att se till att deras krav för nya systemet uppfyller deras behov. Syftet med projektgruppen är att påbörja systemimplementeringen och kunna påverka systembygget. Examensarbetets roll blir att tillföra gruppen en tillräcklig förundersökning som hjälper till gruppen att kunna samarbeta på ett effektivt sätt och föra enklare kommunicering mellan medlemmarna likt projektledning. Därför kommer flera möten hållas där ändringar diskuteras.

1.3.4 Avgränsningar

Uppdraget omfattas av transporter för färdiga produkter som bokas via leveranssystemet.

Det som inte kommer att tas upp i uppdraget är:

 Själva byggnaden av truckstopet kommer att vara oförändrad.

 Ingen infrastruktur kommer att ändras i produktionen.

 Examensarbetet kommer ej blanda sig i med programmeringskodning

(13)

2. Teoretisk referensram

Förundersökningen som låg till grund för projektet. I detta avsnitt ingår systemen som SSAB använder idag samt det nya som kommer att börja användas. Dessutom vilka metoder som ska användas för att utforma kravspecifikationerna har beskrivits utifrån projektets perspektiv.

2.1 Ellen

I slutet av 1900 talet uppstod det ett behov av att utveckla leveranssystemet. Detta beror på att antalet individanpassade plåtar började öka vilket krävde mer information om plåten än vad det nuvarande leveranssystemet kan hantera. SSAB började producera och marknadsföra höghållfasta stål som är mer kvalitativa än vanlig standard stål. Detta har lett till att distributionen har fördelats mellan många kunder med små order som kan bestå av flera olika produkter. Dessa olika produkter kan bestå av olika

egenskaper på plåten som t.ex. tjocklek, bredd som beställts.

Det traditionella leveranssystemet kunde inte hantera den stora mängden information som skulle tillföras vilket är varför en utökning av systemet behövdes. Kravet för det nya systemet var att kunna

administrera externämnen, lager plåt och övrigt gods. SSAB behövde ett informationslagringssystem som inte påverkas av förändring från organisationen, arbetssättet eller teknologin. Detta för att kunna behandla det nya systemet som en central databas vilket leder till att det inte behövs utveckla nya system eftersom informationen lagrad där inte kommer att ändras och att det kommer bli möjligt att lägga till information. Därav det nya systemet ELLEN, syftet med den är att optimera utnyttjande graden av ytan i produktionen genom att minska om plock och hantering för avgående material samtidigt att det ska vara ett system som inte behövs revideras utan bara kan tilläggas. Anledningen till det är att ELLEN är kopplad till många olika system vilket gör det ännu viktigare att behålla strukturen samma så att dataflödet inte blir påverkad. Skulle den bli påverkad kommer många olika system att behöva justeras vilket helst ska undvikas.

Så här ser dataflödet ut idag genom ELLEN:

Figur 1 Visar dataflödet mellan ELLEN och andra system.

Leveranssystemet fungerar som ett samarbete mellan ELLEN, Transportföretagets system och KSD KSD är ett dokumenthanteringssystem som även kan hantera support och funktionalitetsändringar. När en plåt är färdigtillverkad måste den bli tilldelad ett avgångsnummer. I det här avgångsnumret står det specificerad vilken sorts plåt det är med all nödvändig information. När detta är klart kommer EDI

(14)

kommunikation ske till transportbolagens system. EDI står för Electronic Data Interchange och är ett elektroniskt kommunikationssätt mellan företagen som har till syfte att sköta processen smidigare, billigare och enkelt. Till företag som inte har EDI skickas informationen även ut till KSD som är ett dokumenthanteringssystem och då får företagen mejl via Advice Note som fungerar genom KSD.

2.2 Proview

SSAB har idag ett styrsystem som är egenutvecklad. Detta är det första öppna styrsystem i världen och har tillverkats tillsammans med Mandator [9]. Från dess att den har utvecklats, tills idag har den blivit ett förbättrat system som är en billig integrerad lösning som fungerar på vanliga datorer förutsatt att den har Linux operatör system.

Det vanligaste sättet ett Proview systemet fungerar på är att den består av en styrsystemdator och flera operatör stationer. När det installeras operatörstationsdatorer är det enkelt att tillämpa HMI system på dem, vilket står för Human-Machine interface. Det är en display som låter användaren kommunicera med styrsystemet som den är kopplad till vilket gör att det kan kontrolleras flera antal styrsystem från flera anläggningar. Eftersom konfigurationen av Proview är grafisk kan den använda en grafisk PLC- redigerare för programmering med språk som t.ex. C, C++, Java och FORTRAN.

Proview är ett så kallat soft-PLC, vilket innebär att installationen av mjukvaran kan ske i vilken dator som helst. Eftersom den kan agera som PLC från vilken position som helst, medföljer stora fördelar.

Som att det inte finns begränsningar för antalet PID-loopar, PLC program och I/O enheter systemet kan köras med. Det enda som står i vägen är din dators kapacitet eftersom desto fler program som körs samtidigt blir det stora belastningar på datorns operativsystem. Flera olika sorters I/O-system kan implementeras i Proview p.g.a. det höga stödet för nivåspråket och öppna källkods programmering som körs i Linux. Detta sker genom att skapa klasser i Proviews bas system och enheterna konfigureras där i olika instanser. Flera olika sorters in och utsignaler som kommer från systemet genom olika former, inom SSAB sker det genom buss eller i form av kommunikationsprotokoll. Några exempel är PSS9000, Profibus, Modbus, TCP etc [9].

SSAB behöver idag använda Proview för det nya truckstop systemet där chaufförerna kommer att ankomstregistrera sig. För att detta ska funka behövs det PLC koder som sköter ankomstregistreringen och layouten i terminalen. En terminal som är installerad på plats kommer att vara kodad från ett styrsystem inuti SSAB, när en chaufför anländer finns det en skärm som ska styras med touch knappar istället för tangentbord. Huvudstegen som sker i registreringen är att först ska det finnas stöd för olika språk i systemet, vartefter scanning av körkortet och acceptering av säkerhetsföreskrifterna som gäller.

När det är klart ska det ske inskrivningen av avgångsnummer där information fås angående plåtarna som ska plockas upp från produktionen. Om lastningen är godkänd kommer chauffören att få en plats i kön och inväntar sin tur som kommer dyka upp när det är ledigt.

(15)

2.3 Processkarta UML

Unified Modeling Language [13] är ett verktyg som först initierades av gruppen Object Management Group [10]. Douglas menar att UML är ett rikt verktyg som används både för mjukvaru- och

systemutveckling och det har även blivit” de facto” standard för dessa användnings områden. Det finns flera anledningar till detta, det första är simpelheten av programmet som gör det enkelt att lära sig och relativ intuitivt. Andra anledningen är att UML är väl definierat och modellerna skrivna kan bli verifierade, modellerna använda inuti är standardiserade och lätta att känna igen. Den tredje och sista anledningen är att det finns stor verksamhet inom UML vilket innebär att få support för modellbyggande blir mycket enklare eftersom du kan visa modellen som du designat för rutinerade UML användare eller be om att få en skapad.

Modellering är en essentiell del i stora programvaror projekt och till och med ett hjälpsamt medium till små projekt också [13]. Enligt UML så genom att modellera ett projekt kan säkras det att

funktionaliteten är korrekt och att kundens behov är bemötta. För när ett komplext system ska

implementeras kan det vara svårt att hålla kolla på alla krav och ändringar som kommer att ske. När en modell finns kommer det att bli enklare att få en bra överblick över projektet och förstå dess omfång.

Undersökningar visar att stora IT projekt har en hög sannolikhet att misslyckas, det är till och med så att sannolikheten att möta alla krav, hålla tidsplanen och inom ramarna för budgeten är mindre än att projektet ska lyckas [13]. Vilket gör att varje verktyg som används för att öka risken till ett lyckat projekt är en mycket bra förmån som bör tas tillvara på och UML är ett verktyg som visualiserar designen och ser till att kraven är uppfyllda innan projektmedlemmarna börjar koda.

I UML 2.0 definieras tre olika bas diagram och dessa tre är uppdelade vidare till 13 andra diagram också som används beroende på vilket projekt som finns. I SSAB:s projekt kommer endast Behavior Diagram att användas för att beskriva truck stop systemet. Det är för att kunna enklare förklara hur processen vid ankomstregistrering kommer att gå till och få en övergripande bild.

Figur 2 Vilka olika diagram finns inom UML

I detta projekt kommer två olika diagram att användas för att beskriva system användingen och framtida lösningen.

Use Case diagram: Detta diagram kommer i SSAB:s fall vara användbart för att visa hur

bokningssystemet fungerar idag. Efter utvärdering av samtliga diagram och valdes Use Case främst eftersom diagrammet visar tydlig bild av interaktionen mellan externa aktörer och system. För att bokningssystemet kan bli komplext är det viktigt att måla upp nuläget på ett simpelt och lättförståeligt sätt. [13]

•Class Diagram

•Object Diagram

•Component Diagram

•Composite structure Diagram

•Package Diagram

Structure diagram

•Use Case diagram

•Activity diagram

•State Machine Diagram

Behavior diagram

•General behaviour diagram

•Sequence Diagram

•Communication Diagram

•Timing Diagram

•Interaction Diagram

Interaction Diagram

(16)

Activity Diagram: Aktivitets diagram är ett användbart verktyg för att beskriva dynamiska funktioner i systemet. Anledningen är dess funktioner att kunna länka parallella aktiviteter och beskriva

sekvenserade funktioner. En aktivitets diagram kan beskriva flera system samtidigt och fånga informationsflödet mellan dem vilket är varför den är ett passande verktyg i just detta projekt. SSAB behövde ett verktyg som visualiserar hur det nya systemet kommer att fungera på en nivå som går att förklara för både teknisk och icke insatta personer.

2.4 Kravspecifikation

” Ett krav beskriver en förutsättning eller förmåga vilken systemet bör stödja” [14]. När ett systems byggs så gör det utifrån ett visst antal krav. Dessa samlas vanligtvis genom behovet av användarna och kan skrivas ner i form av kravhantering. Enligt Jelena görs detta i syfte för att minimera antalet problem som kan komma att få effekter när det nya systemet byggs. Kraven som samlas i ett formellt dokument kallas för kravspecifikation. Där samlas alla krav som kommuniceras genom kunder, användare,

kravhanterare etc.

Kravhantering behövs nu mer än alltid. Med den snabbt ökande och växlande teknologin idag leder till ökad konkurrens. [15]. Här menas att förr i tiden när teknologin inte var så utvecklad som den är idag så var inte kravhantering ett lika stort måste som idag. T.ex. hade den första mobilen som utvecklades inte lika många funktioner som idag. Det räckte med att den kunde ringa för att kunderna skulle bli nöjda. Däremot idag så har mobilerna en stor konkurrensmarknad där utvecklingen är enorm, för att kunderna ska bli nöjda ska mobilen ha tillgång till kamera, wifi, ökad processor etc.

Genom att inte ha kravhantering kan ett stort system byggas utan att kunderna krav uppfylls. Enligt [15] ” However well the system may appear to work at first, if it is not the system that users want or need, then it will be useless”. Detta leder till att kravhantering har blivit ett kvalitehanterings verktyg.

Kvalité innebär inte att köp av den dyraste produkten i marknaden, utan det är att det uppfyller kundernas krav vilket bevisas enligt citatet ovan. Typiska problem

För att kravhanteringen ska se på ett smidigt sätt krävs det att ett strukturerat tillvägagångssätt kravspecifikationen. Problemet som kan uppstå är att det enkelt händer att något krav förbises som visar sig vara viktig att ta med [14]. Figuren nedan visar hur en process kan se ut när kraven

sammanställs på ett strukturerat sätt

(17)

ha funktionen att ringa. Sen finns det icke-funktionella kraven där det beskrivs hur systemet ska se ut så att den blir enklare att förstå för slutanvändaren. Där är det viktigt att den inte har någon teknisk specifikation som t.ex. hur stor mobilen ska vara för att den enklare ska passa in i fickan. Det är egentligen svårt att tyda skillnaden på kraven än vad det borde vara. Ett krav som är tillhör säkerhet kan uppfattas som icke funktionellt krav men senare när allt är utvecklad mer i detalj visar det sig i själva verket vara ett funktionellt krav. Det här visar att kraven inte är självständiga och visar sig vara bundna till andra krav också.

(18)

2.4.1 Funktionella krav

Enligt standarden för system och programvarutekniken så definieras funktionella krav som:

1. Ett krav som identifierar vad en produkt eller process måste klara av att producera kravspecifikationen och eller resultat.

2. Dessutom måste kraven kunna specificera en funktion eller systemkrav som måste kunna utföras. [8]

Det finns andra hjälpsamma definitioner som finns för att ge en bättre syn hur funktionella krav ska utformas mer exakt. Det nämns två olika definitioner från både Kossiakoff och Buede som ser ut på det här sättet [7].

” These refer largely to what the system should do. These requirments should be action orented and should describe the tasks or activities that the system performs during it’s operation” [5].

“Functional requirements relate to specific functions (at any level of abstraction) that the system must perform while transforming inputs into outputs. As a result, a functional requirement is a requirement that can be associated with one or more of the system’s outputs” [6]

Från dessa definitioner som är dem mer populära inom systemutveckling och design texter kan funktionella krav egenskaper beskrivas följande:

1. Definierar vad systemet borde göra.

2. Vara resultat orienterat.

3. Beskriva uppgifter och aktiviteter

4. Vara associerade med transformationer av input och outputs.

Sättet hur dessa krav utformas beror oftast på vilken sorts mjukvara som utvecklas, slutanvändarna och generella hanteringen av företaget när kraven skrivs. När kraven skrivs på slutanvändarnas nivå så blir det mer abstrakt och kan förstår mycket enklare. Däremot krävs det att kraven är mer specifika om den skrivs för att beskriva systemfunktionerna, dess input, output, undantag etc. Ett exempel som

Sommerville använder för att beskriva skillnaderna på olika nivåerna funktionella kraven är genom patient dokument för mentala hälsoproblem:

1. Användaren ska kunna se tider för alla besök till alla klinker.

2. Systemet ska varje dag generera för varje klinik, en lista för patienter som ska förväntas ska besöka för samma dag.

3. Varje personal som använder systemet ska kunna identifieras med hennes 8 siffriga arbetsnummer. [1]

Det går att se hur dessa funktionella krav skiljer sig från varandra, detta exempel har tagits från en riktig kravspecifikations dokument för att exemplifiera nivåskillnaderna. Första alternativet är specificerat för användaren där det simpelt visar vad för funktion användaren ska förvänta sig av

(19)

början. [1]

2.4.2 Icke funktionella krav

Icke-funktionella krav är som namnet tyder, krav som ej har med funktioner på systemet att göra. Det betyder att specifikationerna inte direkt är relaterade till systemkraven där användaren kan användaren blir påverkade. Utan dem tillhör systemegenskaper som beskriver dess egenskaper som till exempel

"pålitlighet, respons tid och lager tillgänglighet [1]. Enligt standarden för system och programvara definieras icke funktionella som: "A software requirement that describes not what the software will do but how the software will do it. Syn: design constraints, non-functional requirement. EXAMPLE software performance requirements, software external interface requirements, software design constraints, and software quality attributes. Nonfunctional requirements are sometimes difficult to test, so they are usually evaluated subjectively"[8].

Icke funktionella krav är oftast mer kritiska än vissa individuella funktionella krav, för

systemanvändarna kan arbeta på alternativa sätt för att uppnå funktionella kraven. Däremot om kan ouppfyllda icke funktionella krav se till att hela systemet blir oanvändbart. Till exempel om ett

flygplanssystem inte skulle uppfylla sina pålitlighets krav som tillhör denna kategori kommer den ej få tillåtelse att flyga. Att hitta vilket funktionellt krav tillhör en specifik komponent i systemet brukar inte vara några svårigheter, däremot det är mer komplicerat att relatera till ett icke-funktionellt krav. [1].

Det finns tre aspekter som kan komplicera aspekter som gör det svårare vilka är:

1. Icke-funktionella krav kan vara "subjektiva", beroende på vilken person som interpreterar kan dessa bli tolkade på olika sätt. Eftersom dessa krav ofta är beskrivna kortfattat och abstrakt kan det bli värre.

2. Icke funktionella kan även vara "relativa". Ett visst system kan interpretera kraven beroende på vilket sätt den ska användas. Dessutom kan uppfyllanden ske på annorlunda sätt än det som är tänkt för att förbättra lösningarna. Därför är det viktigt att vara öppensinnad och inse att det ej finns en generell lösning.

3. Den tredje aspekten som kan orsaka problem beskrivs som "interaktiv". Eftersom det redan är konstaterat att ett icke-funktionellt krav kan påverka hela systemet. Uppfyllanden kan därför både förbättra och försämra systemet.

Genom dessa aspekter kan det konstateras att Icke-funktionella krav har en viktig roll i systembygget och måste beaktas försiktigt [7]. Sommerville menar att problemet uppstår oftast från början när funktionerna är vagt beskrivna av beställarna och lämnar systemutvecklarna ifrågasättande. Om vi använder samma sjukhusexempel så kan det se ut så här: "Systemet borde vara enkelt att använda av personalen och vara organiserat på ett sätt att fel i systemet är minimerat". Som det märks är det väldigt vagt sätt att beskriva hur systemet ska vara uppbyggt, det finns inget som är mätbart för att få ett tillräckligt med underlag för att visa resultat. Utan den kan istället beskrivas på det här sättet:

"Personalen ska kunna använda systemets alla funktioner efter fyra timmars träning. Efter träningen, ska misstagen inte ligga på mer än två per timmes användning." På det här sättet menar Sommerville att kraven är mycket definierade och kan bearbetas på ett enklare sätt för att uppfylla beställarens krav.

(20)

2.5 Systemvalidering

System validering validering har till syfte att visa att systemet håller sig till kraven som är uppsatta och möter kundens krav. [1]. Enligt Sommerville menar han att när ett nytt system byggs är det viktigt att veta att den funkar som den ska innan monteringen av hårdvarorna sker för att spara både tid och pengar. Eftersom en ändring som sker medan systemet byggs eller efter färdigbyggande leder vanligtvis till mycket större förlust av pengar. Detta kan jämföras med när det planeras att konstruera en ny bil, om det visar sig att bilen inte håller sig till kundkraven t.ex. att motorn bränner mer bensin än vad den borde kommer hela bilen att behöva skrotas som byggdes samt att gruppen måste dra sig tillbaka till och utföra designändringar. Därför är det viktigt att ha en process där det är tydligt vilka steg som behöver dubbelkollas innan start av systemkonstruktionen sker. Enligt [1] finns det fem olika checkningar som är bra att gå igenom vad gäller dokumenteringen.

1. ”Validity checks”: Ibland räcker det inte med att ett system kan utföra vissa funktioner, utan genom en mer utförlig analys och tänkande är det möjligt att tänka ut nya som kan spela en stor roll för att systemet ska lyckas. För om kunden kommer med önskemål om hur systemet är tänkt att byggas kan företaget som har ansvar tillföra flera idéer eftersom dem har mer erfarenhet av system.

2. ”Consistency checks”: Kraven i dokumenten ska inte hamna i konflikt med varandra så att om ett krav uppfylls ett annat kommer att påverkas. Om så är fallet borde kraven återupptas och undersökas ytterligare.

3. ”Completeness checks”: Slutanvändaren ska kunna dra nytta av alla funktioner som systemet är tänkt att användas på. Detta ska göras genom att inkludera alla kraven för att få med alla funktioner i systemet.

4. ”Realism check”: När alla krav är uppsatta ska en realitets check inom existerande teknologi som finns inom företaget granskas så att det inte blir mer än vad som kan hanteras. När en funktion som är väldigt komplicerad tillkommit kan det krävas en bättre teknologi än vad som finns i företaget och det skulle kräva omfattande förändringar att på kort sikt försöka införa nya teknologin vilket måste utvärderas om det är värt eller inte. Granskningar ska även ske inom budgeten och tidsplanering för konstrueringen av systemet. Det är lätt hänt att projekt drar över både tid och budget eftersom oväntade händelser kan inträffa som gör att tiden drar över vilket också resulterar i form av pengaförlust.

5. ”Verifiability”: För att undvika potentiella missförstånd med kunderna är det bra att kraven är nedskrivna. Om kraven inte skulle vara dokumenterade kan det enkelt hända att ett system byggs som kunden inte hade tänkt sig, för att en viktig funktion glömdes bort eller att kunden ändrar sig under arbetets gång. När kraven är uppnådda kan det visas genom att göra en testmiljö där demonstration utförs för att bevisa systemets funktionalitet.

Kravspecifikation är en kritisk fas i systemutvecklingsprocessen och ser till att kvalitén på bygget ökar.

Nyliga studier visar att industrier har blivit medvetna om att använda metodiska och väluttänkta tekniker för att uppfylla dokumenteringskraven [2]. Författaren menar att på grund av många olika tekniker som finns ute i marknaden har det blivit allt svårare att hitta en passande teknik som uppfyller företagets mål.

Det är även viktigt att nämna kravspecifikationen inte endast är ingenjörens roll utan hela företaget måste bli inblandade för att få så bra resultat som möjligt. Dvs. Från arbetarna till cheferna måste bli involverade och att dem kan ha unika synpunkter på systemet för positiva förbättringar. [3]

(21)

3. RESULTAT

Utifrån metoderna som beskrevs ovan har dem implementerats i projektet. Specifikationerna har gjorts på systemet och blivit presenterade nedan i texterna.

3.1 Nulägesanalys

Bokningssystemet i SSAB fungerar på ett sätt där när råvaran är bearbetad och klar så blir den tilldelad ett avgångsnummer och blir placerad i produktionen. Den här informationen skickas vidare till

transportbolaget via EDI kommunikation samtidigt som informationen går till KSD. Transportbolaget har till uppgift att tilldela avgångsnummer till lastbilarna som åker till SSAB:s produktion för att

transportera plåt. Eftersom transportbolagen kan se plåtarnas information som destination, vikt mm. kan dem avgöra på vilket sätt lastbilarna kan åka samtransport för att spara tid och pengar.

När lastbilarna ankommer till Oxelösund åker chaufförerna direkt till vakten där ankomsten registreras.

Chauffören ska ange sitt registreringsnummer, legitimation samt avgångsnummer. Utan ett godkänt avgångsnummer är det inträde ej tillåtet vilket i dagsläget skapar frustration i arbetet. Eftersom en chaufför som ej talar svenska eller engelska inte har koll på avgångsnummer kan kommunikationen med vakten bli problematisk. Vakten skriver ut lastningslista till chauffören och ger vägbeskrivning om så behövs.

Det finns två olika platser inom SSAB där lastbilar plockar upp sin transport. Den ena är torrlasten som är inomhus där plåten inte får påverkas av regn eller andra väderförhållanden vilket är varför dem lastas på inomhus. Sedan den mer vanliga transporten utomhus som är mer vanlig än torrlast. Personalen lastar på enligt anvisning från lastningslistan samt vilken plats i kön som chauffören befinner sig i.

Figuren nedan visar vart lastningsområden befinner sig i produktionen.

Figur 4 vart i produktionen lastningen sker

När detta är klart återstår att rapportera klarlastningen hos vakten som samlar ihop olika dokument som chauffören får ta med sig. En fraktlista där all information står angående lasten. Bl.a. plåtarnas totalvikt för att kontrollera att det inte blir för mycket för lastbilen att hantera samt destination för plåtarna.

För att beskriva systemet på mer övergriplig nivå har ett Use-Case diagram upprättat där följande aktörer och system visar hur processen går till:

(22)

Figur 5 är ett Use-case diagram för systemet inom SSAB

Figurerna utanför rutan representerar dem externa faktorerna som påverkar systemet. Rutorna innan är aktiviteterna som sker och linjerna innebär att aktör initierar en händelse i systemet. Däremot är

streckade linjerna informationen som följer med aktiviteten därav ”Include” texten som står mellan. Use- Case diagrammet valdes att beskriva systemet eftersom specifika användningar för den är att beskriva interaktionen mellan aktörer och system.

(23)

3.2 Processkarta

Modellering:

Ett activity based diagram valdes för att konstruera den nya processbeskrivningen för

ankomstregistreringen. Detta för att den ska beskriva systemet och dess dynamiska funktioner under processen. Anledningen till varför Activity diagram valdes utöver dem andra är att den som namnet antyder, beskriver flödet från en aktivitet till en annan. Den är mest lämplig för att modellera

aktivitetsflödet av ett system men även till ett annat system vilket är varför den behövs i detta projekt som kommer att knyta ihop flera system.

Diagrammet skrev med i åtanken att använda den som stöd för under projektets gång och skapas utifrån kraven för att visualisera systemet. Genom en visualiserings stöd får samtliga medarbetare i projektet en bättre förståelse vilket därmed förhoppningsvis ska leda till förenkling av systemutvecklingen.

Figur 6 är ett activity based diagram för hur systemet kommer att fungera efter systemimplementeringen

Dem nya ändringar som har gjorts är framförallt vid ankomstregistreringen. Lastbilarna kommer att få instruktioner att anlända direkt till truck stopet som är placerad ca 5 min från produktionen.

När chaufförerna är anlända i truckstoppet kommer en skärm befinnas där för att registrera sin ankomst.

Detta kommer fungera som en bilbesiktning fast med mer omfattande process. Varje chaufför måste få med sig en kod med bokningen som kommer meddelas genom transportföretagen för att få tillträde till stugan. Meningen med det här nya systemet är att det ska bildas ett kösystem i truckstoppet istället för utanför vakten. För att när ankomstregistreringen är klar kommer chauffören automatiskt att hamna i kön och få vänta på sin tur. När det är dags kommer en stor display som är placerad utanför stugan blinka registreringsnumret för lastbilen som står på tur att komma in.

(24)

3.3 Integrationer mellan systemen

Kontroll av data

Truckstopp Registrering

Regnr + avgångar

Avgångsinfo och status

Ellen skickar tillbaks kö info Chafför godkänner

Köinfo

Ellen sätter ankomstid truckstopp

Bil ankommer vägbom

Ellen sätter verklig ankomstid Ellen skickar tillbaks

kö info

Bil färdiglastad Ellen sätter Lastning

klar Ellen skickar tillbaks

kö info

Bil ankommer vakten för utpassage Vakten överlämnar

dokument och sätter verklig avgångstid Ellen skickar tillbaks

kö info Ellen skriver ut

lastningslista

Ellen skriver ut dokument i vakten

Figur 7 Integrationen mellan systemet och vilken sorts information som överförs

Ingen programmering skulle ingå i projektarbetet men ett informationsflöde mellan systemet

konstruerades för att visa informationsflödet. Till detta behövdes personerna ansvariga för respektive område, Sven för Proview samt Björn och Ingegärd för som har koll på ELLEN. Eftersom integrationen påverkade all kommunikation mellan truckstoppet och Ellen har ett schema gjorts för att visualisera hur flödet kommer att fungera. Truckstoppet representerar Proview som har nya displayer och skärmar som både tar och skickar iväg information som behövs till ELLEN. Den här informationen har gjorts utefter

(25)

Chauffören kommer nu att få vänta på sin tur i truckstoppet. Inuti stugan kommer det finnas en liten skärm som innehåller kölistan. Den kommunicerar med Ellen genom att den uppdaterar listan hela tiden beroende på kön inne i produktionen. Eftersom streckkoden följer med kommer den att skannas för att ta reda på vart i produktionen och vilket steg lastbilen befinner sig i. Första etappen är att streckkoden kommer att skannas vid ankomsten av vakten, då registreras ankomsttiden för lastbilen. Sedan när lastbilen väl är inne så väntar den på sin tur att få lastas, vilket när den väl är de kommer statusen att ändras till att lastningen är klar. Detta kommer medfölja att fraktdokumenten som nämndes vid

funktionsbeskrivningarna börjar skrivas ut hos vakten. Det sista steget blir utcheckningen som sker vid vakten vilket i samband med detta överlämnas fraktdokumenten till chauffören. Vakten kommer nu sätta en avgångstid till Ellen som rapporterar detta i Proview och skickar upp nästa lastbil som står på tur.

Detta schema visade sig vara viktigt för systemutvecklingsarbetet eftersom utefter denna kunde samtliga medlemmar i projektet använda den som mall när programmeringen ska skrivas. Vid varje möte

diskuterades schemat och vilken information som ska överföras. Därmed var mötena mycket mer produktiva eftersom alla fick reda på vad som behövde göras på ett strukturerat sätt. Det som annars riskerar att hända är att det pratas om massa punkter i projektet men missar att programmera en viktig funktion vilket kan leda till att det blir om arbete eller missförstånd. Det märktes snabbt under projektets gång att det kan snabbt bli krångligt att utföra arbetet som planerat från början och kan behöva justeras.

Som till exempel ankomstregistreringen var planerat att chaufförerna skulle knappa in sina

avgångsnummer först för att sedan godkänna säkerhetsföreskrifterna på slutet. Men det upptäcktes att programmeringen blev smidigare att ta det på omvänt ordning eftersom skanningen och verifikation och säkerhetsföreskrifterna inte behövde någon dataöverföring från ELLEN.

(26)

3.4 Kravspecifikation

För att bygget av systemet PROVIEW ska ske så smidigt och klart som möjligt utfördes en

kravspecifikation. Som nämnts tidigare av Sommerville är det ett sätt att uppfylla beställarens krav utan konstigheter. För det som kan ske när systembygget är att någonting ej fungerar som önskats och då är det bra att ha kraven nedskrivna på papper.

Dokumentering av systemkrav är en process där den som är ansvarig skriver ner kraven i ett dokument.

Användar- och systemkraven borde vara klara, tydliga och enkla att förstå. Både funktionella och icke- funktionella krav borde vara beskrivna så att det är förståeligt på ett övergripligt sätt. Detta innebär att kravspecifikationerna borde bara utformade genom att skriva det i ett naturligt språk som det kallas inom systemutveckling. Alltså i form av simpla tabeller, former och diagram.

För att beskriva kravspecifikationen inom det nya systemet för SSAB kommer ett strukturerat naturligt språk användas. En mall som används inom alla funktionaliteter för systemet. Inom denna form kommer information att skrivas som tidigare beskrevs att Sommerville är viktiga för att veta hur systemet

kommer att fungera. Dess data har samlats in med hjälp av projektgruppen, baserat på modellen som utfördes har den som är ansvarig för funktionen fått redogöra hur processen går till och vilka krav som ska ställas på systemet.

Information som kommer att besvaras är:

1. Ansvarig: Vem som är ansvarig för denna etapp. För att denna

2. Initieras av: Vilken händelse ser till att initiera att denna funktion triggas igång.

3. Beskrivning: Händelseförloppet kommer att beskrivas under denna rutan.

4. Ingående termer/information som behövs i processen: Vad för information måste den som utför processen kunna tillhandahålla för att gå vidare.

5. Utgående termer/information från processen: Information som tas emot när det är klart.

6. Krav på förmåga i systemet: Här beskrivs specifikt vad för vad systemet ska klara av och inte hur. För som nämnts tidigare ska en kravspecifikation beskriva vad systemet ska utföra och inte hur. Utifrån dessa krav kommer det nya systemet att konstrueras och ta hänsyn till.

(27)

3.4.1 Funktionella krav

Boka Transport

Registrera ankomst

Ansvarig: Transport koordinator

Initieras av: Produkterna klara för leverans i Ellen

Verksamhetsregler: - Behörighet till att beställa transporter och avropa transport - Regler för hur vi skapar en bokning, lastbärartyper, länder,

transportbolag m.m.

Beskrivning: Kontroll i arbetskö om material finns klart för bokning av transport, Specificering av avgång görs efter regelverk både manuellt och med systemstöd, när avgången är färdigspecificerad Godkänns avgång och trans går till Transportbolag som har Edi kommunikation med oss.

Trans går samtidigt till dokumenthanteringssystemet KSD, för

Transportbolag som inte har Edi kommunikation med oss skickas mejl med Advice Note via KSD. I undantagsfall skickar

Transportkoordinatorn mejl med bokningsuppgifter till utsedd transportör.

Ingående

termer/information som behövs i processen:

- Färdigt material för leverans till kund - Avtalsunderlag för transportbolag att välja

Utgående

termer/information från processen:

- Bokningsinformation eller Advice note

- Tillägg i bokningsinformation är portkod och prioritet (ELLEN)

Krav på förmåga i systemet

- Skicka EDI transaktion till Transportbolag - Lagra bokningsinformation (för datalager)

- Frisläppa avgångar på icke EU-land för hämtning(Ellen)

Ansvarig: Förare

Initieras av: Lastbil kommer till SSAB

(28)

Verksamhetsregler: - Hantera flera språk för anvisningar till förare - Krav på avgångsnummer

Beskrivning: Föraren går in i truckstopet och ankomstregistrerar sig i en av datorerna (2 st.) som finns tillgängliga för ankomstregistrering.

Föraren anger språk.

Föraren anger sedan det/de avgångsnummer som skall lastas.

Destinationen och land visas.

Om avgångsnummer är OK så får föraren tillåtelse att gå vidare till nästa skärmbild.

Ingående

- Språkval

- Avgångsnummer

Utgående

- Destination - Land

- OK-Godkänd att påbörja nästa process.

- Systemet skall klara av 15 språk:

- Systemet skall kontrollera att föraren anger ett giltigt avgångsnummer.

- Reservrutiner i vakten ifall systemet ej skulle fungera.

Meddelanderuta i PROVIEW om möjligt ”System not available, go direct to gate”

(29)

Verifiera säkerhetsföreskrifter och scanna körkort

Ansvarig: Förare

Initieras av: Lastning tillåten

Verksamhetsregler: - Förare innehar körkort

Beskrivning: Föraren identifierar sig genom att scanna/läsa av sitt körkort.

Föraren måste verifiera och godkänna att denne är informerad och har förstått säkerhetsföreskrifter på SSAB:s område.

Föraren anger registreringsnummer på dragbilen och släp.

Ingående

- Körkort

- Säkerhetsföreskrifter

- Registreringsnummer (bil och släp).

Utgående

- OK-Godkänd att påbörja nästa process.

- Hantera inregistrering av körkort och godkännandet av föreskrifter (informationen rensas efter viss tid?)

(30)

Skriva ut lastningslista och köranvisning

Ansvarig: Föraren

Initieras av: Verifiera säkerhetsföreskrifter och scanna körkort Verksamhetsregler: - N/A

Beskrivning: Föraren trycker på funktionen i systemet för att visa och skriva ut lastningslista. Om det finns en avvikande köranvisning (torrtransport eller långgods) visas det på skärmen och kan skrivas ut.

Vid behov kan även chauffören visa och skriva ut en köranvisning på skärmen.

Ingående

- Avgångsnummer

Utgående

- Lastningslista - Köranvisning - Vikt

- Längd och bredd på plåt - Streckkod

- Karta

- Torrtransport vägvisning Krav på förmåga i

systemet

- Systemet skall skriva ut lastningslista på skärm och papper.

- Lastningslista med streckkod till bom skall skrivas ut automatiskt

- Valbart i systemet att skriva ut en karta

- Kontrollera att antal bilar på SSAB:s område är endast exempelvis 12 bilar åt (köhantering) gången och att lastningstid erhålls då utpassagesignal ges från vakten. Justerbar siffra

- Hantera upphämtning inom tidsfönster och ge en ”slot” tid för

(31)

Ansvarig: Förare och vaktpersonal

Initieras av: Skriva ut lastningslista och köranvisning Verksamhetsregler:

Beskrivning: En skärm ute på truck stop ska visa vilken bil som kallas genom att visa registreringsnumret. Endast skärmarna inomhus visar kölistan ifall man vill se dem.

Ingående

- Hur många bilar som finns inne för lastning.

- Vilken bil som ska kallas.

Utgående

- Registreringsnumret på bilen som kallas.

- Kölista på en av skärmarna inuti stugan på truck stopet.

- Uteskärmen ska få plats med tre bilar.

- Blinka tills bilen är registrerad i vakten sen försvinna från skärmen.

- Visa kön på truck stop i PROVIEW för vakten

(32)

Kontroll ok att passera

Lasta

Ansvarig: Väktare

Initieras av: Erhållit lastningstid

Verksamhetsregler: - Föraren skall ej åka till SSAB innan lastningstid erhålls.

Beskrivning: Föraren kör fram till SSAB:s huvudport. Kontroll sker att lastbil är godkänd att passera. Bommen öppnas och föraren åker till

lastningsplatsen.

Ingående

- Läsa av streckkod som skrivs ut med lastlistan

Utgående

- N/A

- Systemet godkänner endast streckkod med lastningstid att passera.

- Ankomsttid skall rapporteras till Ellen systemet från PROVIEW

Ansvarig: Godshanterare

Initieras av: Kontroll OK att passera (åker genom huvudport) Verksamhetsregler: - Godshanterare lastar bil efter kösystem.

(33)

Scanna pallar

Rapportera lastning klar Utgående

- N/A

- Se kö av bilar vid truckstopet (se ankomst tidsfönster) - Visa ankomna bilar på SSAB:s område(Ellen)

Initieras av: Lasta

Verksamhetsregler: - Scanner skall användas Beskrivning: Pallar scannas vid lastning av bil.

Ingående

- Palletikett med streckkod

Utgående

- Pall lastad flagga scannad sätts på pallnumret

- Fungerande nätverk

Initieras av: Scanna pallar

Verksamhetsregler: - Kontroll att allt material är med fysiskt och systemmässigt Beskrivning: Godshanteraren sätter lastning klar i systemet per avgång.

Ingående

- När alla avgångar kopplade till registreringsnumret har fått lastning klar skickas transaktion till KSD för utskrift av dokument i vakten.

(34)

Samla ihop fraktdokument

Signera fraktsedlar Utgående

- Dokument skrivs ut i vakten.

- Dokument för icke EU land lämnas i vakten av transportkoordinatorn.

- Fungerande nätverk.

- Egen utskrifts kö för vakten vad gäller fraktdokument.

- Transaktion till KSD skall ske då alla avgångar fått lastning klar för att hålla ihop alla dokument till samma bil.

Ansvarig: Väktare

Initieras av: Rapportera lastning klar Verksamhetsregler: - N/A

Beskrivning: (Dokument skrivs ut när lastbil är färdiglastad) Väktare samlar ihop samtliga fraktdokument per bil.

Ingående

- Fraktsedlar - Advice Note - Packing List Utgående

- N/A

(35)

Passera ut genom huvudport

Registrera avgångstid

som behövs i processen: - Tulldokument Utgående termer/information

från processen:

- Fraktsedlar - Tulldokument Krav på förmåga i systemet - N/A

Ansvarig: Förare

Initieras av: Signera fraktsedlar Verksamhetsregler: -

Beskrivning: Föraren kör ut genom till SSAB:s huvudport. Bommen öppnas och föraren åker ut genom grinden.

Ingående

- N/A

Utgående

- N/A

Ansvarig: Väktare

Initieras av: Passera ut genom huvudport Verksamhetsregler: -

Beskrivning: Väktare registrerar avgångstid i Ellen.

Ingående

- Avgångsnummer

(36)

Utgående

- Registreringsnummer

Systemet skall ge signal att släppa in nästa lastbil på SSAB:s område för att lasta.

(37)

3.4.2 Icke funktionella krav

Bildskärmslayouter - Se bilaga Språkmatris

- Skapa en språkmatris där alla ord som används i layouterna finns tillgängliga och översatta till alla utvalda språk.

- Dessa språk är:

o Engelska o Tyska o Polska o Svenska o Ungerska o Rumänska o Bulgariska o Serbo-Kroatiska o Czechiska o Ryska o Finska o Turkiska Svarstid vid bildbyte

- Svarstiden mellan bild byten vid ankomstregistreringen ska ske> 1 sekund efter att man har fyllt i information som krävs på den bilden man är på.

Storlek och färger

- Storleken ska bestämmas enligt hur mycket utrymme man behöver för en standard touch display.

Detta för att enkelt kunna mata in information med fingrarna och tillräckligt med utrymme mellan bokstäverna.

- Färgerna ska bestå av samma färger som ankomstregistreringen i receptionen. Dvs. flesta färgerna ska bestå av vit, svart och grå.

Två terminaler

- Två displayer ska finnas tillgängliga att registrera sig på när man kommer in i stugan. I samma station ska det finnas en skrivare för att tillhandahålla lastningslista och köranvisningar. Syftet med två är att undvika långa köer och ifall en blir ur funktion ska den andra vara tillgänglig tills den som ej fungerar är reparerad.

Printer med stort pappersfack, a4

- Inuti pulpeten ska det finnas utrymme som är tillräckligt stor för en printer. Printerns storlek ska vara beroende av att den kan innehålla ett stort pappersfack för att minska antalet gånger besök det behövs fylla på med papper.

Touch screen

- Ett tangentbord ska finnas tillgänglig hela tiden på nedre delen av rutan. När man trycker på den raden man vill ska skrivmarkeringen som blinkar dyka upp och då kan man knappa in sin information genom touch-tangentbordet.

- Ändra språk på tangentbordet?

Tangentbord som kommer upp och ned och knapp som kan döljas med en knapp.

(38)

Förenklad användning

- Systemet ska innehålla ca 12 olika språk som är valbara från början av ankomstregistreringen.

Detta för att underlätta registreringen åt chaufförerna som kan fullfölja alla steg smidigare med sitt eget språk.

- Det ska vara enkelt för chaufförerna att följa stegen, det innebär undvika mycket text på layouterna och visa simpla layouter.

Kapacitet

- När 12 bilar är inne i produktionen ska man få vänta på sin tur tills det finns ledig plats.

- Varje chaufför kan ha flera avgångsnummer vilket innebär att systemet ska kunna klara av flera Reservrutiner

- Vid olycksfall som resulterar till ett ej fungerande terminal på något sätt ska det vara möjligt att använda tidigare rutiner. Det betyder att vakten återtar ansvaret med manuell registrering av chaufförer åtminstone tills systemet är reparerat och fullt fungerande.

Display

- Blinkning av registreringsnumret av den stora displayen utanför stugan, för att tydligt visa vem som står på tur.

Finnas tillräckligt med plats att visa flera bilar samtidigt

(39)

3.5 Testspecifikation

När systemen är konstruerade och redo att testas behövs det en ett sätt som används för att validera bygget. Eftersom systemet inte hann implementeras fick det göras i en labbmiljö istället vilket ändå är bra för som det har nämnts tidigare är det bäst att undvika implementering av hårdvara innan det är säkert allting fungerar som det ska. För det så behövdes det ett utrymme i företaget som har stöd för systemtest. Dem funktioner som skulle testas är främst dem nya implementeringarna som förklaras var för sig hur dem ska testas och hur det gick till enligt bilagorna för testspecifkationerna. Dessa är:

Portkod:

Ett nytt portkodssystem skulle implementeras till truckstoppet. Utmaningen var att kommunicera den på ett smidigt sätt till chaufförerna som inte ska behöva åka/ringa till vakten för att ta reda på siffrorna. Den nya dosan ska registrera dem nya portkoderna som kommuniceras från Ellen, efter att giltighetstiden är slut ska koderna vara ogiltiga.

Ankomstregistreringen:

Kravet på ankomstregistreringen är att den ska innehålla 12 olika språk för chaufförerna.

Dessutom för att ankomstregistreringen ska vara giltig behövs det att registreringsnumret för bil och (optionellt) släp ska kunna fyllas I. Avgångsnummer ska kontrolleras både först av systemet om den existerar, sedan ska chauffören få information om lasten för att kontrollera att den stämmer. Säkerhetsåtgärder ska finnas med som skanning av körkort och verifikationstext att man läst och förstått reglerna som gäller inom SSAB.

Utskrift:

Efter att ankomstregistreringen är klar ska skrivaren testköras också. Där ska man säkerställa att rätt lastlista skrivs ut till chauffören samt att en streckkod tillkommer för att komma igenom vakten. Karta ska vara tillgängligt att skrivas ut vid begäran vilket innehåller köranvisningar både till produktionen och inom.

Display:

Detta test gäller för displayerna som ska användas I detta projekt. Två små displayer ska

monteras innanför stugan, den ena ska ha ett bildspel där säkerhetsinformationen visas. Den ska hela tiden vara igång och hela bildspelet ska inte ta längre tid än några minuter. Den andra displayen bredvid ska visa köinformationen, bl.a. antal bilar inne i produktionen och statusen på lastningen. En sista display ska monteras utanför truckstoppet som är tänkt att vara större än dem andra två för att visa vems tur det är att åka in. Den har till uppgift att blinka registreringsnumret som kommuniceras från Proview för att visa chauffören att det är dags.

(40)

4. Diskussion

För att lyckas med projektet var uppgiften att utforma en systemlösning för att skapa ett kösystem som inkommande lastbilar kan använda sig av. Detta för att undvika bildning av kö utanför SSAB som är potentiellt farligt. Målet som beskrevs innan är att reda på och utforma kravspecifikationerna samt processbeskrivningar som behövdes för att projektet ska utföras så smidigt som möjligt. Dessa krav ska sen både verifieras och valideras vilket är en stor del av projektet för att kunna ta reda på från början om projektgruppen missat något eller om en funktion behöver konstrueras om.

Verktygen som valdes att beskriva systemet med var Use-case diagram i UML. Anledningen till att den valdes gentemot andra verktyg är att den visar vilka aktörer som påverkar systemet vilket kan vara båda interna och externa. Vilket passade det här systembygget bra eftersom i det här fallet interagerar både system och personer. Sedan för att beskriva framtida systemlösning användes Activity based diagram. Den beskrev smidigt och effektivt hur processen kommer att se ut när den är implementerad.

Genom att ha strukturerat arbetat fram kravspecifikation kunde de redan tidigt i projektets gång reducera möjligheten till misstag genom validering av processen. Det som märktes är en

förbättrad kommunikation mellan projektmedlemmarna vilket ledde till samarbete inom

konstruering av systemen. Eftersom när samtliga projektmedlemmar kunde förstå systemen blev det enklare att integrera systemen mot varandra.

Det som behövdes när kravspecikationerna skrevs är en genomgång med samtliga inblandade.

Enligt Sommerville skulle det ta lång tid att

Däremot det som händer är att projektet tar längre tid än väntat när problem dyker upp som måste tas itu med. Eftersom systemen inte hann implementeras blev den enda möjligheten att validera systemet någorlunda genom att bygga en labbmiljö där simulering av systembygget kunde ske inom vissa funktioner. Ett exempel på funktion som projektet hade planerat innan var att använda avgångsnumret som portkod till truckstopet. Detta för att kommunicera ut koden mycket enklare till chaufförer som blandar ihop alla olika siffror som finns i informationslistan.

Men när det upptäcktes att dosan endast kunde hantera 4 siffrig sifferkombination och kunde endast hantera ett visst antal portkoder fick kraven ändras.

Tyvärr kunde inte acceptanstesterna utföras på systemet p.g.a. att den inte hann byggas färdigt.

Därför är det svårt att veta om den verkligen hade bra nytta eller inte men det positiva är ändå att dessa användes vid labbsimulering som vägledning på hur systemet ska fungera.

Ibland kan det uppstå frågetecken kring huruvida viktigt det är med kravspecifikations process.

Både medlemmar och projektledaren kan försöka tvinga fram en snabb lösning och försöka implementera det direkt för att få snabba resultat. Detta leder vanligtvis till mer skada än nytta.

För att bedöma om projektet var lyckat eller inte behövdes det svaras på flera frågor, som: ”Hur dessa verktyg påverkade projektet?”, ”kunde andra verktyg användas för att få ett bättre

resultat?” etc. Till en början märktes det att både viktiga och mindre viktiga detaljer upptäcktes när processkarta, Use-case diagram och rutinbeskrivningarna användes. Detta gjorde att projektet kunde utföras smidigare under uppstarts fasen. Men eftersom projektet inte hann bli klart i tid blev det uppenbart att det fanns brister som det märktes av under projektets gång.

(41)

(42)

5. REFERENSER

[1] Sommerville, I. (2011). Software engineering (9. ed., International ed.). Harlow: Addison- Wesley.

[2]Jiang, L., Eberlein, A., & Far, B. (2008). A case study validation of a knowledge- based approach for

the selection of requirements engineering techniques. Requirements Engineering, 13(2), 117- 146.

[3]Jiang L, Eberlein A, Far BH (2005) Combining requirements engineering techniques—

theory and case study. In: ECBS 12th IEEE international conference on the engineering of computerbased systems, Greenbelt, April 2005

[4] Adams, K. (2015). Non-functional Requirements in Systems Analysis and Design (Topics in Safety, Risk, Reliability and Quality). Cham: Springer International Publishing.

[5] Kossiakoff, A., Sweet, W. N., Seymour, S. J., & Biemer, S. M. (2011). Systems engineering principles and practice (2nd ed.). Hoboken: Wiley.

[6] Buede, D. M. (2000). The engineering design of systems: Models and methods. New York:

Wiley.

[7] Adams, K. (2015). Non-functional Requirements in Systems Analysis and Design (Topics in Safety, Risk, Reliability and Quality). Cham: Springer International Publishing.

[8] ISO/IEC/IEEE 21450:2010(E). (2010). IEEE.

[9] Proview Team (2013), Fakta om Proview, http://www.proview.se/

[10] Douglass, B. P. (2006). Real Time UML Workshop for Embedded Systems. Elsevier Science .

[11] Holt, J. (2004). UML for Systems Engineering: watching the wheels (2nd Edition). London, United Kingdom: Sciencedirect.

[12] Jon, S. (2001). Troubled IT Projects Prevention and Turnaround. London: The institution of

(43)

(44)

(45)

BILAGA A: EXTRA INFORMATION 6. Bilagor

Ankomstlayout

(46)

(47)

(48)