School of Mathematics and Systems Engineering Reports from MSI - Rapporter från MSI

System Development with RUP and

Prototyping

- a case study towards the pharmaceutical industry

Tutor: Sadaf Salavati Authors: Giovanni Hanselius,

Andreas Tharnstrom Emanuel Turesson

October 2009

MSI Report 09063 Växjö University ISSN 1650-2647 SE-351 95 VÄXJÖ ISRN VXU/MSI/IV/E/--09063/--SE

Abstract

School of Mathematics and Systems Engineering Reports from MSI - Rapporter från MSI

Systemutveckling med RUP och

Prototyping

- en fallstudie mot läkemedelsbranschens produktionslinjer

Handledare: Sadaf Salavati Författare: Giovanni Hanselius,

Andreas Thärnström Emanuel Turesson

October 2009

MSI Report 09063 Växjö University ISSN 1650-2647 SE-351 95 VÄXJÖ ISRN VXU/MSI/IV/E/--09063/--SE

Titel: System Development with RUP and Prototyping

a case study towards the pharmaceutical industry

Authors: Giovanni Hanselius, Andreas Tharnstrom, Emanuel Turesson

Cours: IV9003 – Bachelor De

gree Project, 15 p Instructor: Sadaf Salavati

Examinator: Birgitta Fagerstrom Kareld

Date: 2009-06-02

Language: Swedish

This paper intends to examine whether the system development methods Rational Unified

Process (RUP) and Prototyping can complement each other and how they can be combined.

We have also examined how they work in practices and how Unified Modeling Language

(UML) and Prototyping is able to visualize and secure the requirement list for process

management in the pharmaceutical industry.

The Case Study in this paper is done alongside a pharmaceutical company in Sweden. In the

pharmaceutical business are several papers based systems are used for documentation with

manual confirmation. The company has, of today, no control if the confirmations are done

during or after the manufacturing process. By definition of Good Manufactoring Practice1

(GMP) this is a violation against the pharmaceutical production. To find all the requirements

the users demand on a system, both observations and interviews have been used.

Keywords: RUP, Prototyping, UML, Systemdesign, Requirement specification,

Reqiurement gathering, System development, Case Study.

1 http://www.emea.europa.eu/Inspections/GMPhome.html

Sammanfattning Titel: Systemutveckling med RUP och Prototyping - En fallstudie

mot läkemedelsbranschen

Författare: Giovanni Hanselius, Andreas Thärnström, Emanuel Turesson

Kurs: IV9003 - Examensarbete på kandidatnivå, 15hp

Handledare: Sadaf Salavati

Examinator: Birgitta Fagerström Kareld

Datum: 2009-06-02

Språk: Svenska

Denna uppsats avser att undersöka om systemutvecklingsmetoderna RUP och Prototyping kan

komplettera och kombineras med varandra. Vidare avser uppsatsen att undersöka hur de

fungerar i praktiken men också hur UML och Prototyping kan visualisera och säkra kravlistan

för processtyrning inom läkemedelsindustrin.

Fallstudien som denna uppsats innehåller är gjord på ett läkemedelsföretag i Sverige. Vid

tillverkning av läkemedel användes olika former av pappersbaserad dokumentation som

signeras manuellt. Företaget har idag bland annat ingen kontroll över om signeringen utförs

under eller efter tillverkningen och enligt GMP strider detta mot de regler och lagar som styr

läkemedelstillverkningen. För att hitta de krav användarna ställer på ett

kontrollstyrningssystem har både observationer och intervjuer utförts på plats.

Nyckelord: RUP, Prototyping, UML, Systemdesign, Kravspecifikation,

Kravinsamling, Systemutveckling, fallstudie.

Executive Summary�

Vid systemutveckling är kravinsamling och iterationen med beställaren mycket viktig.

Iterationer är också en viktig del av prototyputvecklingen. När prototyper utvecklas och testas

på användarna framkommer ofta frågor eller problem, utifrån dessa diskussioner och tester

utvecklas en ny prototyp. Systemutveckling omfattar även utveckling av informationssystem

och det finns olika modeller, metoder och beskrivningstekniker som är till hjälp och

vägledning för utvecklare. RUP är en välkänd metod som utvecklats för att skapa en högre

stabilitet. Uppsatsen undersöker hur RUP och Prototyping kan komplettera och kombineras

med varandra.

Fallstudie

Vid tillverkning av läkemedel används olika former av dokumentation där man steg för steg

kan se de olika momenten i processen. Dessa steg beskriver oftast mängden av vilka råvaror

som krävs och den tid som delstegen i processen kräver. Om ett moment ska godkännas måste

en operatör signerar detta för att påvisa att allt har gått rätt tillväga. Vissa delsteg som signeras

kräver att en dubbelsignatur utförs. Detta förfarande kräver att två operatörer befinner sig på

plats under den tid då delstegen utförs och bestäms av GMP. Företaget har idag ingen

tillfredsställande kontroll över de olika produktionslinjerna, i vilken fas produkten befinner

sig och om tillverkningsföreskrifterna är rätt ifyllda. Det befintliga informationssystemet är

idag pappersbaserat vilket försvårar kontrollen på vad det är som sker i processen. Missar i

dokumentationen leder ofta till utredningar om vad, hur och varför dessa uppstod vilket i sin

tur får ekonomiska följdverkningar. Genom att föra in ett kontrollsystem i produktionslinjerna

ges möjlighet för ansvariga på andra avdelningar att få insyn i processerna i nära på realtid.

Det har på företaget gjorts en observation och intervjuer för att komma fram till de krav som

ställs på ett kontrollstyrningssystem. Det framkom under observationen och intervjuerna att

det saknades struktur och kontroll inom tillverkningen. Det framgick att vissa steg i

dokumentationen kunde hoppas över och att signering utfördes i efterhand.

Rekommendation

Själva digitaliseringen är tänkt att ske genom att det pappersbaserade arbetet ersätts med en

digital portabel skärm som är kopplat mot systemet. Det digitala systemet bör byggas upp

efter hur det ser ut idag så att det känns igen av de som använder det. Dock måste det styras

enligt de lagar som krävs för tillverkning av läkemedel. Om de portabla skärmarna tas i bruk

ska det byggas in kontrollpunkter som skapas utefter produktionens delmoment. Dessa

delmoment i produktionen kräver visst förfarande för att vara godkända enligt

produktionskraven. Som det är idag tas genvägar för att få produkten klar.

I digitaliserade lösningar som kontrollerar och förhindrar eftersignering måste samtliga steg

vara ifyllda för att kunna gå vidare till nästa delmoment. Alternativa lösningar för att komma

ifrån dubbelsigneringar kan vara att låta systemet utföra dessa genom övervakning av alla

moment och styrning av maskiner. Detta är beroende på vad GMP tillåter för när och hur

signeringar ska utföras.

 

Förord�

Vi vill börja med att tacka vår handledare Sadaf Salavati för hennes stora stöd och

engagemang.

Vi vill tacka företaget för att vi fick utföra observationer och intervjuer inom deras

tillverkningslinje. Samt ett stort tack till alla respondenter som ställde upp med intervjuer,

testning av prototyp och enkätundersökning.

Innehållsförteckning  1  Inledning ........................................................................................................................... 11 

1.1  Bakgrund ................................................................................................................... 11 

1.2  Problemdiskussion ..................................................................................................... 13 

1.3  Syfte ........................................................................................................................... 14 

1.4 Frågeställning ................................................................................................................. 14 

1.5 Avgränsningar ................................................................................................................ 14 

1.6 Målgrupp ........................................................................................................................ 14 

1.7 Ordlista ........................................................................................................................... 14 

1.8 Disposition ...................................................................................................................... 16 

2 Metod och tillvägagångssätt .................................................................................................. 17 

2.1 Metodansats .................................................................................................................... 17 

2.2 Allmänt om metoder ....................................................................................................... 17 

2.3 Kvantitativ metod ........................................................................................................... 18 

2.4 Kvalitativ metod ............................................................................................................. 18 

2.5 Observationer .................................................................................................................. 20 

2.6 Prototyping ..................................................................................................................... 21 

2.6.1 Prototyping och kravinsamling ................................................................................ 22 

2.6.2 Prototypmodeller ...................................................................................................... 22 

2.7 Fallstudie ........................................................................................................................ 22 

2.8 Validitet och Reliabilitet ................................................................................................. 23 

2.9 Reliabilitet ...................................................................................................................... 24 

3 Teoretisk bakgrund ................................................................................................................ 25 

3.1 The Rational Unified Process ......................................................................................... 25 

3.1.1 Rational Unified Process och Best Practices ........................................................... 25 

3.1.2 Iterativ utveckling .................................................................................................... 25 

3.2 Kravhantering ................................................................................................................. 26 

3.2.1 Typer av kategorisering och krav ............................................................................ 28 

3.2.2 Prioritering av krav .................................................................................................. 28 

3.2.3 Funktionella krav ..................................................................................................... 29 

3.2.4 Icke-funktionella krav .............................................................................................. 29 

3.3 Komponentbaserad arkitektur ......................................................................................... 29 

3.3.1 Visuell modellering .................................................................................................. 30 

3.3.2 Verifiering av kvaliteten .......................................................................................... 33 

3.3.3 Hantering av mjukvaruuppdatering ......................................................................... 34 

3.4 RUP och dess struktur .................................................................................................... 34 

3.5 RUP och UML som process ........................................................................................... 37 

3.6 Prototyping ..................................................................................................................... 37 

3.6.1 Allmänt om prototyping ........................................................................................... 38 

3.6.2 Prototyping och iterationer ...................................................................................... 38 

3.6.3 Prototyping och metoder .......................................................................................... 39 

4 Empiriskt ramverk ................................................................................................................. 41 

5 Empiriskt resultat .................................................................................................................. 42 

5.1 Observation - av granuleringsprocessen ......................................................................... 42 

5.2 Intervju ............................................................................................................................ 42 

5.3 Modellering .................................................................................................................... 44 

5.4 Prototyping ..................................................................................................................... 47 

5.5 Enkät ............................................................................................................................... 47 

5.6 Prototyp – Omarbetning utifrån enkätresultatet ............................................................. 49 

5.7 Mailintervju .................................................................................................................... 51 

6 Analys och slutsats ................................................................................................................ 53 

7 Diskussion och reflektion ...................................................................................................... 56 

7.1 Kritik av genomfört arbete ............................................................................................. 58 

7.2 Framtida lösning och utveckling .................................................................................... 58 

8 Referenser .............................................................................................................................. 60

Bilagor 

Bilaga A - Minnesanteckningar från observation 

Bilaga B - Detaljerad beskrivning av observation 

Bilaga C - Intervjufrågor 

Bilaga D - Kravspecifikation

Bilaga E - Första skiss på prototyp version.1.0 

Bilaga F - Andra utgåva av prototyp 1.1 

Bilaga G - Tredje utgåvan av prototyp version 1.2 

Bilaga H - Första sidan av prototyp 1.1 

Bilaga I - Tillverkningsföreskrift över granuleringen 

Bilaga J - Enkätunderlag för Prototyp V.1.1 

Bilaga K - Sammanställning enkätfrågor 

Bilaga L - Mailintervju 

Figurförteckning

Figur 3:1 Vattenfallsmodellen .................................................................................................. 26 Figur 3:2 RUP:s iterativa och stegvis ökande process ............................................................. 26 Figur 3:3 UML Use Case diagram ........................................................................................... 31 Figur 3:4 UML klassdiagram ................................................................................................... 32 Figur 3:5 UML aktivitetsdiagram ............................................................................................ 33 Figur 5:6 Klassdiagram över prototypen .................................................................................. 44 Figur 5:7 Use Case diagram över prototypen ........................................................................... 45 Figur 5:8 Aktivitetsdiagram över prototypen ........................................................................... 46 Figur 5:9 Första skissen på prototyp ........................................................................................ 47 Figur 5:10 Version 1.1 av prototypen ...................................................................................... 49 Figur 5:11 Version 1.2 av prototypen ...................................................................................... 50 Figur 5:12 Version 1.1 av prototypen ...................................................................................... 50 Figur 5:13 version 1.2 av prototypen ....................................................................................... 51 

Tabellförteckning

Tabell 2:1 Relevanta situationer för olika forskningssituationers strategier ............................ 23 Tabell 3:2 Typer av kategorisering och krav FURPS+ ............................................................ 28 Tabell 3:3 MoSCoW modellen enligt. ..................................................................................... 29 Tabell 3:4 Workflow and Phases ............................................................................................. 34 Tabell 5:5 Enkät sammanställning för prototyp V.1.1 ............................................................. 49 

11

1 Inledning 

Detta kapitel ger en bakgrund till uppsatsens ämnesområde samt en redogörelse för problem,

frågeställning och syfte. Vidare beskrivs vad systemutveckling är. Därefter följer en

redogörelse av problembakgrunden till varför fallstudien har gjorts. Här beskrivs målgrupp

och avgränsningar som gjorts samt hur uppsatsen är disponerad.

1.1 Bakgrund 

Systemutveckling 

Att arbeta med systemutveckling kan också kallas utveckling av informationssystem. Det

finns olika hjälpmetoder som utvecklarna kan använda sig av, dessa är modeller, metoder,

beskrivningstekniker och verktyg. De olika modellernas funktioner är att i stora drag ge en

översikt över utvecklingen och att beskriva vad det är som ska göras och av vem. Detta kan

kallas för ett ramverk.

Avison & Fitzgerald (2002) menar att metoderna är ett sammanhängande och systematiskt

tillvägagångssätt för att angripa ett problem. Metoderna guidar utvecklarna i vilka steg som

skall tas, samt hur stegen skall framställas och varför stegen är viktiga i själva utvecklingen.

Avison & Fitzgerald (2002) menar också att metoderna inte alltid uppfyller utvecklarnas

behov och att flera av metoderna är teoretiska produkter och fungerar därför inte alltid som

det är tänkt.

Metoderna är beskrivande och pekar på vilket sätt som ett problem ska lösas. Metoderna är

mer detaljerade och beskrivande än vad modellerna är. De olika modellerna kan i sig

innehålla ett flertal olika metoder. Beskrivningstekniker kan beskrivas som ett recept där det

beskrivs ingående vad det är som skall göras, exempelvis kan en beskrivningsteknik vara

olika modelleringar som Unified Modeling Language (UML) och Entity - Relationship (ER)

modellering. De olika verktygen är mer rent fysiska hjälpmedel som exempelvis dator, penna

och papper osv. (Andersen, 1994). Avison & Fitzgerald (2002) menar att RUP är en av de

metoder som utvecklats för att skapa en högre stabilitet.

12

Vid användande av prototyper inom systemutveckling är målet att fastställa att systemet

kommer motsvara användarnas önskemål och krav. Prototypen bör i möjligaste mån visa hur

kommunikationen mellan människa och maskin ser ut och hur det kommer att fungerar då

informationssystemet tas i bruk.

Iterationer är en viktig del av prototyputvecklingen. När prototyper utvecklas och testas på

slutanvändarna framkommer ofta frågor eller problem och utifrån dessa diskussioner och

tester utvecklas en ny prototyp. Detta sätt att arbeta kan hålla på under en längre tid och kan

komma innefatta många olika versioner innan den är färdig och lever upp till de uppsatta

kraven (Andersen, 1994).

När ett informationssystem utvecklas finns det flertalet olika sätt att angripa problemen på, ett

sätt är livscykelsmodellen. Syftet med denna modell är att genom analyser ta fram de krav och

önskemål som ställs på systemet. Detta arbete sker innan själva systemet börjar utvecklas. Vid

många fall av utveckling används livscykelmodellen och det anses av många vara den som är

mest framgångsrik. Viktigt att påpeka är att denna modell är en av flera olika modeller som

existerar inom systemutvecklingen (Andersen, 1994). Goguen, J A. & Linde, C (1993) menar

att den huvudsakliga frågan inom kravanalysen är tillvägagångssättet för att ta reda på vad

användarna verkligen behöver. Många undersökningar visar att stora projekt misslyckas på

grund av en bristande kravanalys. Dessa brister beror oftast på sociala, politiska och kulturella

faktorer.

 Fallstudie 

Enligt NN ska det vid tillverkning av läkemedel används olika former av dokumentation där

man steg för steg kan se de olika momenten i processen. Dessa steg beskriver oftast mängden

av de råvaror som krävs och den tid som dessa delsteg i processen kräver. Om ett moment ska

godkännas måste en operatör signera detta för att påvisa att allt har gått rätt tillväga. Vissa av

de delsteg som behöver signeras kräver att en dubbelsignatur görs vilket bestäms av GMP.

Detta förfarande kräver att två operatörer befinner sig på plats under den tid delstegen utförs.

Denna kritiska del av processen har vållat stora problem då den inte följs av operatörerna och

i många fall är anledningen till detta, bekvämlighet. Själva signeringen av processen brukar

göras i slutet när produkten är färdig istället för i varje delsteg som sig bör. Detta förfarande

får inte lov att ske enligt god GMP och strider mot de regler och lagar som styr

13

läkemedelstillverkningen. Dessa ständigt återkommande problem resulterar ofta i

avvikelserapporter där ett antal timmar går åt för att granska fel och att försöka komma fram

till var och hur det blev fel. Detta kostar företagen stora summor pengar och är något som bör

förhindras. Egentligen är det stora problemet att alla vet var problemen ligger men ingen tar

tag i detta.

Hanteringen av dokumentationen är idag pappersbaserad och idén är att effektivisera

dokumentationen av tillverkningsföreskrifterna i produktionen genom en digitalisering av

datahanteringen. Tillverkningsföreskriften är en form av dokumentation där operatörerna

skriver in vad som händer i processens olika delsteg, exempel på vad som ska dokumenteras

är datum, signaturer, vikter och olika kommentarer.

1.2 Problemdiskussion  

Leventis, P & Tomazic, A (2002) har i sin undersökning kommit fram till att RUP inte är

heltäckande när det gäller prototyputveckling. Leventis, P & Tomazic, A (2002) anser att det

saknas tydliga riktlinjer för hur man ska tillämpa prototyper inom denna

systemutvecklingsmetod. Det krävs goda kunskaper om vad prototyputveckling innebär i och

med att RUP lämpar sig för systemutvecklare och förklarar därför inte begreppen

prototyputveckling och systemutveckling etc. Andersen (1994) beskriver att vid utvecklingen

av informationssystem bör vissa moment ha gjorts innan utvecklingen börjar. Bland annat bör

problem och möjligheter ha identifierats och blivit analyserade. Utifrån informationen som

framkommit vid analysen bör dessa problem och möjligheter angripas på olika sätt beroende

av vad det är som ska lösas.

Idag har företaget ingen kontroll över de olika produktionslinjerna, vilken fas produkten

befinner sig eller om tillverkningsföreskrifterna är rätt ifyllda. Det befintliga

informationssystemet är idag pappersbaserat vilket försvårar kontrollen på vad det är som sker

i processen. Missar i dokumentationen leder ofta till utredningar om vad, hur och varför dessa

uppstod vilket i sin tur får ekonomiska följdverkningar. Genom att införa ett kontrollsystem i

produktionslinjernas processer ges möjlighet till ansvariga på andra avdelningar att få insyn

på de pågående processerna i nära på realtid. Ett införande av ett system kan hjälpa operatören

som står i själva processen i form av informations återföring som hela tiden talar om vilka

steg som är aktiva.

14

1.3 Syfte 

Denna studie ämnar undersöka om systemutvecklingsmetoderna RUP och Prototyping kan

komplettera varandra och kombineras. Vi vill också undersöka hur de kan fungera i praktiken

och hur UML och Prototyping kan visualisera och säkerställa kravlistan för kontrollstyrning i

tillverkningsprocesser inom bland annat läkemedelsbranschen.

1.4 Frågeställning 

På vilket sätt kan systemutvecklingsmetoderna RUP och Prototyping kombineras och

komplettera varandra i praktiken?

Är kravinsamling utifrån RUP ett bra tillvägagångssätt för att uppnå en prototyp?

o På vilket sätt kan då kravlistan säkerställas för kontrollstyrning vid

tillverkningsprocessen inom läkemedelsbranschen?

Inom vilka ramar är RUP och Prototyping lämpliga metoder inom systemutveckling?

1.5 Avgränsningar  

Inom RUP kommer studien fokusera på designdelen vilket innebär att studien kommer gå

igenom stegen kravhantering, komponentbaserad arkitektur, visuell modellering, verifiering

av kvaliteten. Denna studie kommer inte arbeta med de första stegen i RUP som är

projektledning, analys av omgivning eller affärsmodellering. Vidare kommer det endast att

arbetas med flödena i Inceptionfasen för att sedan gå över till Prototyping. Vidare kommer

fokus att ligga på de olika stegen i själva tillverkningsprocessen, därför kommer valet av

process att ligga på granuleringssteget.

1.6 Målgrupp 

Denna studie riktar sig till företagets ledning, dess anställda samt personer och organisationer

som är intresserade av systemutveckling och effektivisering av kontrollstyrning.

1.7 Ordlista 

Tillverkningsprocess 

Extrudering - Är ett delsteg i tillverkningsprocessen där råvaran genomgår en

förändring från granuleringsfasen. Är steget efter granulering.

Granulering - Det initierande steget i processen där torra råvaror blandas med någon form av vätska.

15

Siktning - Produkten delas upp i godkänd eller icke godkänd slutprodukt

genom att siktas i en rad olika filter.

Torkning - Steget efter extrudering där produktens vätska avlägsnas för

att möjliggöra dragering som innebär att en vätska sprutas på

preparatet som bildar ett hölje.

QA - Quality Assurance. Den avdelning på företaget som ansvarar för företagets produktkvalitet.

Systemutveckling   

Fas - Systemutvecklingsmodeller sägs bestå av olika faser, vilket innebär

att man delar upp utvecklingsarbetet i olika områden för att få ett

mer strukturerat arbete.

Iteration - Iteration är detsamma som upprepning och påminner mycket om

loopar. Skillnaden är att iterationer är obestämt antal upprepningar

som sker inom faserna.

Kravinsamling - Den aktivitet där krav som slutanvändare ställer på det framtida

systemet samlas in. Vanligtvis är detta den första aktiviteten vid

systemutveckling.

MoSCoW - Ett sätt att klassificera krav enligt Must have, Schould have,

Could have och Want have.

RUP - Rational Unefied Process. Systemutvecklingsmodell för design och

implementering av IT-system.

Slutanvändare - De som kommer att använda det färdiga systemet.

16

UML - Unified Modeling Language. Objektorienterat notationsspråk för

modellering av system.

1.8 Disposition  

Uppsatsen är disponerad som följer.

Kapitel 1 - Inledning

Behandlar de inledande delarna som bildar grunden för uppsatsen. I kapitlet kan man följa

våra tankar och idéer och hur de fördes samman till den utformning som bildade kärnan för

det fortsatta innehållet i uppsatsen.

Kapitel 2 – Metod och tillvägagångssätt

Detta kapitel redogör hur forskningen har gått till samt vilka metoder som finns men även

vilka av dessa metoder som studien använder sig av.

Kapitel 3 – Teoretisk bakgrund

Detta kapitel beskrivs den teoretiska bakgrunden som är relevant för ämnet. Här beskrivs

tidigare forskning inom ämnet.

Kapitel 4 – Empiriskt ramverk

Detta kapitel redogör genomförandet av det empiriska arbetet i uppsatsen.

Kapitel 5 - Resultat

I detta kapitel redovisas resultatet utifrån syfte och frågeställningar.

Kapitel 6 - Analys och slutsats

I detta kapitel analyseras resultatet utifrån det teoretiska och empiriska ramverket vilket i sin

tur leder till slutsatser.

Kapitel 7 – Diskussion och reflektion

I det här kapitlet diskuteras resultatet med anknytning till frågeställningarna och vad

resultaten betyder i stort. Här kommer våra reflektioner över arbetet att redovisas. Vidare

behandlas framtida forskningsmöjligheter och hur man kan arbeta vidare med resultatet.

17

2 Metod och tillvägagångssätt 

I metodavsnittet motiveras de metodval som gjorts samt hur arbetet är upplagt. Vidare

beskrivs ett antal metodansatser och forskningsmetoder rent generellt för att ge läsaren en

uppfattning om olika grundläggande begrepp.

2.1 Metodansats 

Genom att utgå från syftet med arbetet och genom att ta hänsyn till de föreskrifter som

tillverkningen av läkemedel kräver, måste en del ställningstaganden göras. Den metodansats

som valts för att nå fram till syftet med studien inbegriper flera steg och metoder. För att få

fram de krav som ställs på kontrollstyrningssystemet har metoder så som observationer,

intervjuer, enkäter och utveckling av en prototyp använts. För att styrka de teorier och

frågeställningar, men även vårt resultat har mailintervjuer utförts på företag som arbetar med

systemutveckling. Metoderna RUP och Prototyping används för att på ett effektivt sätt ta

tillvara på kravlistan och användarnas önskemål.

Det förfarande som har använts under arbetets gång är att en första kravspecifikation

utvecklades utifrån en observation som skedde på företaget. Denna kravspecifikation

kompletterades sedan med ett intervjuunderlag. Efter detta steg skapades en första skiss av

prototypen som presenterades för kravställarna vilket ledde till ytterligare kompletteringar på

kravspecifikationen. När de färdiga kompletteringarna på kravspecifikationen var utförda

skapades en ny version av prototypen med html kod. Denna prototyp testades av kravställarna

som samtidigt utvärderade prototypen via en enkät. Utifrån enkätresultatet utvecklades sedan

en ny version av prototypen. Då vi har utvecklat en del egna illustrationer saknar dessa figurer

och tabeller källhänvisning.

2.2 Allmänt om metoder 

Både den kvalitativa och den kvantitativa metoden är två olika vetenskapliga metoder som

kan användas för att utföra en studie. Enligt Holme & Solvang (1997) är det viktigt att valet

av metod bestämmer vad det är som ska klarläggas i det specifika problemområdet som

forskaren har valt att undersöka. Den kvalitativa metodens mål är att gå på djupet och

metoden bygger enligt Bryman (2001) på det sätt forskaren uppfattar eller tolkar den

insamlade informationen. Dessa metoder går att använda tillsammans då det inte finns något

konkurrensförhållande mellan dem och de kan därför stärka varandras svagheter till ett mer

solidare metodangrepp (Holme & Solvang, 1997).

18

2.3 Kvantitativ metod 

Den kvantitativa metodens mål är till för att se det som undersöks i ett brett perspektiv. Denna

metod ombildar informationen till siffror och mängder som sedan kan användas för statistiska

analyser. När den kvantitativa metoden används görs generaliseringar som med viss säkerhet

beskriver olika uppfattningar och åsikter i en grupp. Vidare är det viktigt att den som

använder metoden har ett jag - det - förhållande till undersökningen. Alltså måste denne hålla

avstånd till det undersökande objektet för att i möjligaste mån inte påverka resultatet (Holme

& Solvang, 1997).

Enkäter 

Det är av stor betydelse på det sätt en enkät läggs upp enligt Holme & Solvang (1997). När

en enkät ska besvaras gör respondenten detta på egenhand med så lite inflytande som möjligt

av forskaren, detta för att denna så lite som möjligt ska påverka resultatet. När en enkät

lämnas ut är det viktigt att formuläret inte är för stort, ostrukturerat eller har ett oklart språk.

Ledande frågor bör undvikas och dessa frågor måste påverka så lite som möjligt.

Tillvägagångssätt

När framtagning av prototyp är klar kommer användarna att få möjlighet att testa prototypen.

Efter testningen ska de erbjudas att få svara på en enkät. Syftet är att på ett mätbart sätt kunna

avgöra om informationssystemet erbjuder användarna de kontroller och hjälpmedel som de

strävar efter eller om prototypen behöver vidareutvecklas. Enkäten kommer att utgöra ett

underlag till vårt resultat för att säkerställa och vidareutveckla kraven.

2.4 Kvalitativ metod 

Hermeneutiska vetenskapstraditionen är en humanistisk riktning där man studerar, tolkar, och

försöker förstå de filosofiska grundbetingelserna för människans existens genom språket

(Patel & Davidson, 1994). Enligt Holme & Solvang (1997) finns det fyra grundprinciper som

en forskare bör ha i beaktande när undersökningar görs, dessa är:

I. Närhet till undersökningsenheterna. Med detta menas att möten ska ske rent fysiskt

och genom en relation som växt fram med tiden. Om undersökningen görs på detta sätt

kan forskaren få fram saklig information om personens vardag vilket leder till att

detaljer framkommer som kan beskrivas ingående.

II. Riktig och sann återgivning. Med detta menas att forskningsresultatet ska beskrivas så

19

objektivt som möjligt.

III. Forskningsresultatet ska vara tillräckligt beskrivande och ingående så att förståelsen

för de olika förhållandena framkommer tydligt.

IV. Citat som återger individernas egna ord ska finnas med så att förståelsen för

forskningsresultatet ska återge den sanna innebörden.

Meningen med dessa punkter enligt Holme & Solvang (1997) är att återge en så verklig

skildring som möjligt av de strukturer, handlingsmönster och sociala situationer som funnits

vid undersökningstillfället. Bryman (2001) menar att en kvalitativ forskningsstrategi är

induktiv och det innebär att man drar generella slutsatser utifrån empirisk fakta.

Tillvägagångssätt

Efter utförd observation och sammanställning av tillverkningsföreskrift samt ett första utkast

på en kravlista kommer intervjuer att utföras. Detta görs för att fastställa att alla stegen i

tillverkningsprocessen är rätt men även att säkerställa och komplettera kravlistan. Kravlistan

kommer att uppdateras med hänsyn till de uppfattade synpunkter som framkommer under

intervjuerna. Studien kommer inte att presentera varje individs svar var för sig på grund av det

ringa antalet anställda och företagets storlek, därför har samtliga personer och svar

anonymiserats.

 Intervjuer 

Enligt Trost (2005) används kvalitativa studier då syftet med studien är att hitta eller

dokumentera varierande handlingsmönster. Vidare beskriver Trost (2005) att kvalitativa

intervjuer i huvudsak utmärks av att frågorna är enkla, raka och utan hypoteser och utifrån

dessa frågor blir svaren komplexa och innehållsrika.

När en kvalitativ intervju genomförs används inga standardiserade frågemallar. Detta görs för

att den som forskar inte ska styra resultatet för mycket. Det är av stor vikt att de personer som

undersöks får fram sina egna uppfattningar och tankar. De bör i största möjliga utsträckning få

styra utvecklingen själva av intervjun, dock inom ramarna för frågeställningen (Holme &

Solvang 1997).

20

 

2.5 Observationer 

Observationer är en teknik för att samla in krav. Detta är en användbar teknik som innebär att

observatören sitter med och observerar användaren i dennes miljö. Fördelar med observation

är att det inte kräver genomgripande förberedelser och att det är möjligt att upptäcka både

normala, förväntade och oväntade krav. Nackdelar med denna metod kan dock vara att

irrelevant information samlas in (Eriksson, 2007). Enligt Andersen, Erling S & Schwenke, E.

(1998) kan observationer ske på två sätt, antigen öppet eller dolt. När en öppen observation

sker är det ett måste att den observerade vet vad det är som ska undersökas och varför. Den

dolda observationen har fördelen att forskningseffekten försvinner då de undersökta inte beter

sig annorlunda än de brukar.

Tillvägagångssätt

För att få en större förståelse för situationen på läkemedelsföretaget och vad de förväntar sig

av systemet kommer en öppen observation på plats vid företagets processlinje att utföras.

Frågor som framkommer under observationen kommer att ställas till den aktuella operatören.

Efter observationen kommer alla steg i processen att sammanställas och ett första utkast på en

kravlista kommer att utformas utefter den data som insamlats.

Observationstekniker 

När observationer inom ett område sker kan detta utföras på flera olika sätt. De två vanligaste

sätten att utföra observationer på är att använda strukturerade eller ostrukturerade

observationsmetoder. Mellan dessa två observationsmetoder finns det ett flertal olika

varianter.

Den strukturerade observationsmetoden innebär att själva problemområdet är så precist

beskrivet att det framstår klart och tydligt vad det är som ska undersökas. Det ostrukturerade

angreppssättet innebär att observationen inleds utan att observatören har förutbestämda

händelser att utgå från, alltså att observeringen sker i en miljö med ett utforskande syfte (Patel

& Davidson, 1994).

Wisén & Lindblom (2004) beskriver att observationer har både för och nackdelar. Styrkorna

med observationer är att de ger direkt information som annars skulle vara svår att finna.

21

Observationer ger en ögonblicksbild som visar hur saker ser ut för tillfället och leder ofta till

att nya situationer hittas vilket leder vidare till nya infallsvinklar. De har också fördelen att

kunna komplettera intervjuer och enkäter, därmed kan materialet bindas samman. Svagheter

med observationer är enligt Wisén & Lindblom (2004) att tolkningssvårigheter uppstår när

informationen ska tydas.

2.6 Prototyping 

Prototyping är enligt Andersen, Erling S (1994) att en prototyp utvecklas innan produkten

börjar produceras och genom att arbeta på detta sätt skapas möjligheter att testa produkten

innan implementering.

Vid användning av prototyper inom systemutveckling är målet att fastställa att systemet

kommer att motsvara användarnas önskemål och krav. Prototypen bör i möjligaste mån visa

hur kommunikationen mellan människa och maskin ser ut och hur den fungerar då

informationssystemet tas i bruk. En prototyp inom systemutveckling måste visa hur de

funktionella egenskaperna fungerar. De rent tekniska funktionerna behöver i detta stadium

inte ligga i fokus, prototypen behöver exempelvis inte klara av många användare eller hård

belastning då det inte är det som testas i detta läge (Andersen, 1994).

Att använda sig av prototyputveckling ger ett flertal möjligheter för utvecklarna och

intressenterna som i ett tidigt stadium kan testa funktionaliteten, att hitta svagheter och att

testa prestanda och utseende på prototypen  (Gulliksen & Göransson, 2002).  Fördelar med

Prototyping är att alla på ett enkelt sätt kan förstå prototypen och en nackdel med UML-

diagram är att de kan vara svåra att tolka på grund av deras abstrakta utformning. Det finns

åtskilliga sätt att utveckla prototyper, bland annat kan pappersskisser och html modeller

användas (Eriksson, 2007).

Tillvägagångssätt

Utifrån kravlistan och tillverkningsföreskriften samt de synpunkter på design och

funktionalitet som framkommer, utvecklas en prototyp för att på ett förhållandevis enkelt sätt

presentera ett förslag på hur en lösning skulle kunna se ut. Prototypen kommer att utvecklas

med den vertikala modellen och med hjälp av html kod på grund av dess enkla struktur som

ger en snabb utveckling och visualisering.

22

2.6.1 Prototyping och kravinsamling  

Enligt Andersen (1994) är Prototyping ett snabbt sätt att utveckla system på. Att det går

snabbt är dock inte huvudargumentet för att använda prototyputveckling, dock kan detta bli en

positiv bieffekt. Huvudargumentet med Prototyping är att på ett snabbt och effektivt sätt ta

fram kraven på systemet vilket leder till en snabbare hantering av att eventuella problem eller

brister rättas till.

2.6.2 Prototypmodeller 

Gulliksen & Göransson (2002) menar att det finns tre olika typer av prototyper:

I. Den vertikala prototypen lägger ton på mindre delar av systemet. På detta sätt kan man

i ett tidigt stadium testa både funktionalitet och gränssnitt för den aktuella delen.

Denna prototypmodell är den som är mest realistisk att använda då tanken är att den

ska spegla hur verkligheten ser ut.

II. Den horisontella prototypen syftar till att ta fram en komplett prototyp av systemet.

Denna prototypmodell tar fram ett gränssnitt helt utan funktionalitet eller data.

Modellen erbjuder en bra inblick i hur det kompletta systemet kommer att se ut och

fungera då användbarheten är möjlig att utvärdera.

III. Den scenariobaserade prototypen påminner till viss del av den vertikala men istället

för att lägga vikten på en viss del systemet ligger fokus mer på hur en arbetsuppgift

ska utföras. Denna prototypmodell ger möjligheter att utveckla olika lösningar på

redan etablerade kriterier som t.ex. att systemet ska vara översiktligt och lättanvänt.

2.7 Fallstudie 

Yin (2003) menar att användning av fallstudier lämpar sig bäst när karaktären på frågorna

som ska besvaras är av typen ”hur” och ”varför”. Yin (2003) beskriver metoden fallstudie

som en forskningsstrategi och att den utgörs av empiriska undersökningar som har till syfte att

studera en aktuell situation i dess verkliga sammanhang. Genom att använda fallstudie är den

som mest användbar då gränserna mellan situationen och sammanhanget är svåra att tyda.

Patel & Davidson (1994) anser att fallstudien är ett verktyg för undersökningar av vissa

avgränsade grupper och där fallet kan vara en enskild individ, en samling individer, ett företag

eller liknande. Fallstudien används ofta för att beskriva processer eller förändringar.

23

Fallstudiens informationsinsamling  

Det finns flera källor för att insamla information. Yin (2003) beskriver att det i huvudsak

finns fem, vilka är experiment, observationer, analys av arkiverat material, historiskt

perspektiv och Case Study. Tabellen nedan illustrerar typiska situationer för varje strategi.

Tabell 2:1 Relevanta situationer för olika forskningssituationers strategier (Yin, 2003 Sida 5). 

Vidare menar Yin (2003) att observationer är en metod som kräver att den sker på plats där

själva fallstudien utförs. Här kan exempelvis möten, arbetet i arbetsprocessen,

integrationsaktiviteter osv. studeras. Yin (2003) beskiver också att det finns den fysiska

artefaktsmetoden som innebär att tekniska anordningar, verktyg, instrument eller andra

fysiska bevis används som datainsamlingskälla.

2.8 Validitet och Reliabilitet 

I vetenskapliga sammanhang används termen validitet för att beteckna det man kan kalla

giltighet och reliabilitet för att beteckna pålitlighet. Dessa två grundläggande kriterier har

valts att kallas trovärdighet och äkthet. Att innefatta äkthet i resultatet innebär att forskningen

säkerställs i enlighet med reglerna som finns. Resultatet skall rapporteras till de delaktiga

respondenter vilket ger möjligheten att bekräfta att den som har intervjuat har uppfattat deras

verklighet som den är. Detta kallas för respondentvalidering (Bryman, 2001).

24

2.9 Reliabilitet 

Holme & Solvang (1997) menar att reliabilitet innebär hur representativ en studies resultat är.

Det är även ett mått på vilken grad en undersökningsmetod ger samma resultat vid olika

tidpunkter med samma förhållanden. Ju mer likt resultatet är andra resultat som undersökts

desto högre representativitet har det enskilda resultatet. Detta ger en hög extern reliabilitet.

Bryman (2002) menar att intern reliabilitet innebär att alla i forskarlaget är överens om hur de

ska tolka en studies resultat.

 

 

 

 

 

 

 

25

3 Teoretisk bakgrund 

Teoriavsnittet tar upp det som tidigare har skrivits inom ämnet och som passade in på de

aspekter som studien behandlar. Teorin har även som syfte att förankra det valda

ämnesområdet.

3.1 The Rational Unified Process 

Systemutvecklingsmetoden RUP är en mjukvaruutvecklingsprocess som går igenom en

mjukvaras alla utvecklingsfaser. RUP är framtaget och marknadsfört av Rational Software.

Målet med processen är att utveckla en mjukvara som når upp till kundens förväntningar

genom att hålla sig till de satta målen vad gäller budget, tid och kvalitetskrav (Kruchten,

2000).

3.1.1 Rational Unified Process och Best Practices   

Enligt Kruchten (2000) fångar RUP upp ”Best Practices” inom den moderna

mjukvaruutvecklingen. Då RUP fångar upp ”Best Practices” kan metoden användas av en

mångfald organisationer som bedriver projekt. Många företag har idag fått upp ögonen för

vad RUP har att erbjuda vad gäller en väldefinierad och väldokumenterad

mjukvaruutveckling.

3.1.2 Iterativ utveckling   

När en ny mjukvaruprocess ska initieras och utvecklas med hjälp av RUP går den igenom

olika faser. De olika faserna är kravinsamling, design, test och utvärdering som sker repetitivt

tills målen är nådda och implementering kan ske av mjukvaran. Avison & Fitzgerald (2002)

anser att en kravinsamling inte kan ske fullt ut i början av ett projekt, därför krävs en

återkommande insamling. Detta förfarande kallas för en iterativ process. Klassisk

mjukvaruutveckling följer ett mönster som är indelad i olika faser som kallas

vattenfallsmodellen, (se figur 3:1 nedan. Illustrerad med inspiration från Boody, D. Boonstra,

A. Kennedy, G (2005)). I denna modell går man igenom kravanalys, systemdesign,

modultestning, subsystemtestning och systemtestning. Enligt Kruchten (2000) finns det en

brist med vattenfallsmodellen då den skjuter fram risker som kan ha uppstått i tidiga faser av

processen. Att inte lösa problemen i ett tidigt skede kan leda till kostsamma konsekvenser och

att projektet inte håller sig inom tidplanen eller att projektet läggs ned.

26

Figur 3:1 Vattenfallsmodellen Illustrerad med inspiration från (Boody, D. Boonstra, A. & Kennedy, G 2005 s.230). 

 

För att undvika dessa problem kan en annan modell användas som enligt Kruchten (2000) är

mer flexibel och använder sig av iterationer som är stegvis ökande (se figur 3:2 nedan). Denna

modell ger utvecklarna möjligheten att i ett tidigt skede identifiera de risker som kan uppstå

och kan därmed ta hand om felen/riskerna på ett effektivare sätt. Eriksson (2007) menar att

denna typ av utveckling ger en snabbare återkoppling från användarna vilket leder till ett

system som bättre lever upp till organisationens krav.

Figur 3:2 RUP:s iterativa och stegvis ökande process (Mälardalens Högskola). 

3.2 Kravhantering  

För att arbeta med systemutveckling och leverera ett resultat som håller sig inom tid- och

kostnadsramar som har rätt kvalitet krävs det en kravhanteringsprocess. Inom RUP är

27

kravhantering något som påbörjas i ett tidigt skede och pågår sedan under hela

utvecklingsprocessen (Eriksson, 2007).

Under kravinsamlingen fastställs kraven som systemet ska uppnå. Goguen, J A. & Linde, C

(1993) anser att den huvudsakliga frågan inom kravinsamling är tillvägagångssättet för att ta

reda på vad användarna verkligen behöver. Många undersökningar visar att stora projekt

misslyckas på grund av en bristande kravanalys. Dessa brister beror oftast på sociala, politiska

och kulturella faktorer. Goguen, J A. & Linde, C (1993) menar vidare att det vid utveckling

av datorbaserade system i många fall saknas en ”Social Science ”som innefattar sociologi,

psykologi, lingvistisk och antropologi.

Enligt Kruchten (2000) är krav ett tillstånd som ett system måste uppnå. Avison & Fitzgerald

(2002) anser att en vision av vad systemet ska uppnå tas fram med funktionella och icke

funktionella krav. Här kan problem uppstå i och med att dessa krav är dynamiska och kan

förändras under projektets gång. Samtidigt som systemet utvecklas, utvecklas också

användaren och omgivningen och därmed kraven på systemet. RUP omfattar tre aktiviteter

vid aktiv kravhantering: värdering, organisering, begränsningar och dokumentering av

systemets funktionalitet. Kruchten, (2000) menar att kravhantering enligt RUP:s

tillvägagångssätt kan ge fördelar som:

I. Effektivare kravhantering.

II. Motsägelser upptäcks på ett tidigt stadium.

III. Krav kan prioriteras, filtreras och spåras.

IV. Kommunikationen är baserad på fastställda krav.

Goguen (1993) menar att sociala, politiska och kulturella problem är de vanligaste

svårigheterna vid kravinsamling. Vidare anser Gougen (1993) att detta inte tillhör

kravanalysens kunskapsområde utan bör istället ligga på ledning och interpersonell

kompetensnivå. Vissa anser dock att sociala frågor inte borde ha något med kravprocessen att

göra över huvudtaget. Det finns tre huvudsakliga grupper som involveras i en kravprocess

och där problem kan uppstå och dessa är: kunden, kravgruppen och utvecklarna. Gougen

(1993) anser också att det är viktigt att fastställa vilka som ska använda systemet och vad

systemet ska tillföra användarna. Det kan uppstå problem då användare saknar kunskap och

erfarenhet av att hantera ett nytt system. Vidare finns risker och hinder som innebär att företag

och organisationer har känslig information som kravgruppen inte får ta del av. Ett system kan

28

också leda till att personal blir överflödig vilket skapar oro i gruppen. Ytterligare en risk för

systemets utveckling är vid de situationer kravgruppen vet att systemet är ostabilt trots att

ledningen driver på och trots påpekande av bristerna.

Enligt Eriksson (2007) påverkar en bristande kravhantering på systemets kvalitet negativt. I

de fall kravinsamlingen sker på ett felaktigt sätt kan det bli stora konsekvenser som leder till

ett system som inte blir färdigt i tid och att kostnaderna överstiger utsatt budget. Gougen

(1993) menar att utvecklare har en stor fördel med att ha kontinuerliga diskussioner och

direktkontakt med slutanvändarna.

3.2.1 Typer av kategorisering och krav  FURPS+ är en typ av kategorisering som bland annat används inom RUP för att beskriva

vilka krav ska samlas in och dokumenteras (Eriksson, 2007). Se beskrivning nedan:

Functionality Funktionalitet

Usability Användbarhet

Reability Tillförlitlighet

Performance Prestanda

Supportability Underhållbarhet

+ Designrestriktioner

Tabell 3:2 Typer av kategorisering och krav FURPS+ (Eriksson 2007 sid.40). 

När kravinsamlingen är slutförd menar Arlow & Neustadt (2005) att kravhantering kan

effektivseras betydligt genom att organisation av kraven läggs upp i olika typer. Kraven kan

delas in i funktionella och icke funktionella krav. Genom kvalitetsattribut menar Eriksson

(2007) att icke funktionella krav kompletterar de funktionella kraven.

3.2.2 Prioritering av krav 

Varje krav har ett attribut med ett beskrivande namn och värde som ger extra information om

kravet, denna information kallas metadata. För att få överblick av de krav som bör prioriteras

är MoSCoW modellen, (se tabell 3:3 nedan) en användbar metod (Arlow & Neustadt, 2005).

29

Must have Obligatoriska krav som är grundläggande för att systemet.

Should have Viktiga krav som kan uteslutas

Could have Valfria krav (genomförs om det finns tid)

Want have Krav som kan vänta till senare versioner av systemet

Tabell 3:3 MoSCoW modellen enligt (Arlow & Neustadt 2005 sid.59). 

Arlow & Neustadt (2005) beskriver att MoSCoW-metoden ger samtliga krav ett

prioritetsattribut som kan ha värdet enligt ovanstående modell.

3.2.3 Funktionella krav 

Eriksson (2007) anser att funktionella krav beskriver vad systemet ska göra och vilka

funktioner systemet ska genomföra. I de funktionella kraven specificeras in- och utdata, t.ex.

att det ska vara möjligt för användare att både mata in och spara data.

3.2.4 Icke‐funktionella krav 

Icke-funktionella krav beskriver systemets restriktioner och hur de ska fungera (Arlow &

Neustadt, 2005). Eriksson (2007) poängterar vikten av att identifiera de icke funktionella

kraven i ett tidigt stadium, på grund av att det är betydligt svårare att lägga in dem i efterhand

samt att det kostar både tid och pengar.

Eriksson (2007) beskriver att Icke-funktionella krav kan delas in i fyra olika kategorier som

är användbarhet, tillförlitlighet, prestanda och underhållbarhet. Kraven innefattar bland annat

att de ska vara mät- och utvärderingsbara samt att de kan testas.

I. Användbarhet handlar om hur lätt det är för användaren att lära sig använda systemets

funktioner. Exempel på krav kan vara att användaren inte ska behöva använda musen i

systemet, eller att design och användargränssnitt ska vara konsekvent utformat.

II. Tillförlitlighet handlar om att specificera felfrekvensen med allvarlighetsgraden.

III. I kategorin prestanda ställs krav på hur lång transaktionsfrekvensen bör vara som

baserar sig på hur stor mängd data som skickas under en viss tidsenhet.

IV. Underhållbarhet handlar om att systemet ska vara enkelt och kostnadseffektivt att

underhålla och förvalta. Ett av de primära kraven är att systemet ska underlätta

testning och felsökning.

3.3 Komponentbaserad arkitektur 

Ett system som är under utveckling måste enligt Kruchten (2000) ses från en rad olika

perspektiv. Exempel på dessa är beställare, slutanvändare, programmerare, analytiker osv.

30

Alla som är involverade i utvecklingsarbetet har en annorlunda syn på hur systemet ser ut

under de olika stadier som systemutvecklingen går igenom. För att ta hand om dessa problem

på ett effektivt sätt anser Kruchten (2000) att systemets arkitektur är en viktig del.

Enligt Kruchten (2000) är det viktigt att använda en arkitektur under systemutveckling. Detta

möjliggör återanvändning av komponenter och kan i sin tur ge ekonomiska vinster. Vidare

beskrivs det att det blir lättare att upptäcka beroenden mellan mjukvara och hårdvara och att

det förenklar uppdelningen av arbetsmoment mellan olika systemutvecklare. Detta leder till

att befintliga komponenter återanvändas med nyutvecklade och på så sätt utnyttjas resurserna

effektivare. Genom att kombinera en arkitektur med en iterativ process utvecklas dess

komponenter vid varje iteration som i sin tur kan evalueras och testas mot de insamlade

kraven (Kruchten, 2000).

För att säkerställa de insamlade kraven menar Avison & Fitzgerald (2002) att utvecklarna bör

använda sig av analys och design. Vidare menar Avison & Fitzgerald (2002) att analysdelen

är ett logiskt synsätt på systemet till skillnad från designdelen som använder resultatet av

analysen och anpassar den till arkitekturens gränser och de icke-funktionella kraven.

3.3.1 Visuell modellering 

Systemutveckling är inte bara kodning utan kräver planering och insamling av krav. Vid

systemutveckling är det, enligt Jacobsen, Booch & Rumbaugh (1999) nödvändigt att

utvecklarna använder ett modelleringsspråk. Detta görs för att en kontakt ska upprätthållas för

att få kontroll på vad som sker mellan olika utvecklingsgrupper och för att förvalta

beställarens krav och önskemål. För att förverkliga detta kan notationsspråket UML användas.

Det finns ett flertal olika områden där UML kan användas. Enligt Arlow & Neustadt (2005)

förknippas UML först och främst med objektorienterad systemutveckling. UML har som

funktion att visualisera hur ett program ska se ut och fungera med hjälp av olika diagram. I

UML 2.0 existerar fjorton diagram som är strukturella diagram eller beteendediagram.

Strukturella diagram har som syfte att visa hur ett system kommer att se ut i förhållande till ett

beteendediagram som visar olika arbetsflöden.

För att förstå hur ett system ska utvecklas måste det göras mer abstrakt med hjälp av olika

modeller. Modellering hjälper systemutvecklarna och underlättar visualisering, specificering,

31

konstruktion och dokumentering av systemets struktur och beteende (Kruchten, 2000). UML

är en ritning över systemets processer och funktioner som låter utvecklarna visualisera

resultatet för andra involverade parter i utvecklingsgruppen. Visualiseringen sker med hjälp

av UML:s olika ikoner och diagram där delar av systemet, användare och informationsflöden

demonstreras (Jacobsen, 1999).

UML är ett vanligt förekommande språk när olika semantiska notationer över ett system ska

skapas. Modelleringen visar hur ett system ska se ut och vad det ska göra men inte hur

funktionerna ska lösas (Jacobsen, 1999). För att lösa detta är RUP enligt Kruchten (2000), en

bra metod som fungerar som en guide över hur de olika diagrammen ska användas.

Use Case används för att identifiera, klargöra och organisera systemkrav samt beskriva

systemet utifrån användarens perspektiv. Symbolerna beskriver hur olika aktörer

kommunicerar med systemet. Symbolerna som visar hur interaktionerna sker består bland

annat av ovaler, systemgränser, aktörer och relationspilar. Aktörerna står utanför

systemgränsen för att påvisa relationen mellan aktör och systemgräns, andra former av

aktörer kan vara olika hårdvaror. I Use Caset nedan beskrivs funktioner som är av värde för

användaren (Arlow & Neustadt, 2005).

Figur 3:3 UML Use Case diagram 

32

Vid konstruktion av ett klassdiagram finns det flertalet element som ska beaktas. Enligt Arlow

& Neustadt (2005) konstrueras en klass som en rektangel och delas in i tre olika kolumner.

Namnet på klassen placeras alltid överst. Attribut och egenskaper beskrivs längst ned och

visar tillhörande metoder. Relationer skapas genom att de kopplas samman (se figur 3:4).

Figur 3:4 UML klassdiagram 

Vid utveckling av ett aktivitetsdiagram utgår diagrammet från en startposition som

symboliseras med en fylld cirkel. Pilarna ska representera olika övergångar mellan de olika

tillstånden. Aktivitetsdiagrammet avslutas med en cirkel som är delvis fylld och detta för att

indikera att aktiviteten är avslutad (Arlow & Neustadt, 2005) (se figur 3:5).

33

Figur 3:5 UML aktivitetsdiagram 

3.3.2 Verifiering av kvaliteten 

Inom RUP har alla som är involverade i utvecklingen av ett nytt system ansvar för kvaliteten

på systemet. Enligt Kruchten (2000) ska fokus ligga på två områden, produktkvalitet och

processkvalitet. Produktkvaliteten säkerställer kvaliteten på själva produkten som utvecklas

samt dess element. Dessa element kan exempelvis vara komponenter, subsystem, arkitekturer

etc. Processkvaliteten kan mätas med hur själva implementeringen av produkten har

genomförts, dokumentationens kvalitet, diagrammen och de olika Use Casen. Eriksson (2007)

anser att meningen med Use Case är att hitta och beskriva systemets olika aktörer. För att hitta

alla aktörer och funktioner som kommer att användas kan detta göras genom arbete i

workshops och användandet av Use Cases vilket har som syfte att samla in olika krav. I

Workshops bör det finnas aktörer som är representativa intressenter. Systemets beställare bör

finnas med från början och kan inta rollen att iaktta och kommentera de krav som har

utvecklats. Det finns både för och nackdelar med Use Cases, en fördel är att kraven

identifieras på systemet. Men det är också bra på ett visuellt plan för att överbrygga problem

och kommunikation mellan beställare och leverantör. Nackdelarna med Use Cases anses av

Genilloud & Wegmann (2000) vara möjligheten att påvisa multiplicitet. Detta hindrar

utvecklarna att visa hur många aktörer som interagerar med systemet. Utifrån de krav som

identifierats utvecklas ett Use Case. Meningen är att visa hur olika operationer ska fungera

och hur de är kopplade till olika aktörer i systemet. En aktör är någon som använder systemet,

men som inte är en del av det.

34

3.3.3 Hantering av mjukvaruuppdatering 

Tillvägagångssättet vid en mjukvaruuppdatering varierar beroende av om systemet är en

utveckling från grunden, en in-house lösning eller om det bara är en uppdatering av själva

mjukvaran (Avison & Fitzgerald, 2002). Under utvecklingen av mjukvaran ändras

kontinuerligt de krav och mål som har satts på systemet. Ändringarna sker i varje iteration

under processens gång och skapar på så sätt problem för utvecklarna som jobbar med

produkten för tillfället. Enligt Kruchten (2000) underlättar RUP-processen att hålla

mjukvaruuppdatering under kontroll och se till att alla involverade i systemutvecklingen är

synkroniserade.

3.4 RUP och dess struktur 

RUP är indelat i fyra faser som ett projekt går igenom där varje fas avslutas med en milstolpe.

I varje fas sker iterationer och efter varje iteration skapas en grund av projektets status där alla

artefakter är granskade och godkända för att nästa iteration ska kunna påbörjas. När projektet

fortlöper förändras arbetsbördan på det arbete som sker i de olika faserna. En av de stora

fördelarna med RUP enligt Arlow & Neustadt (2005) är den målbaserade inriktningen istället

för den leveransbaserade inriktningen.

 

Tabell 3:4 Workflow and Phases (Arlow & Neustadt 2005 s.38) 

Inceptionfasen 

Det övergripande målet med Inceptionfasen att uppnå enighet mellan alla berörda intressenter

(Kruchten, 2000). Arlow & Neustadt (2005) menar att i denna fas fastställs möjligheterna och

35

riskerna med att genomföra projektet. Detta kan innebära att teknologi kan behöva testas för

att säkerställa företagets krav. Kruchten (2000) anser att fasen innehåller en beskrivning på

vad som ska och inte ska vara med i systemet/produkten.

Vidare menare Kruchten (2000) att de väsentligaste aktiviteterna i fasen är att formulera

projektets omfattning och de viktigaste kraven för att nå fram till en slutprodukt. Genom en

prioritering av Use Cases kan de mest centrala funktionaliteterna identifieras och definieras.

Artefakter i denna fas är att visionsdokumenten ska beskriva intressenternas behov och den

gemensamma visionen för projektet samt en produktdefinition och systemkrav. Enligt Arlow

& Neustadt (2005) stäms första milstolpen av i slutet av Inceptionfasen. Om intressenterna är

överens om systemets omfattning, kostnads- och tidsuppskattning, samt att prioriteringar,

risker och att utvecklingsprocessen verkar trovärdig kan projektet fortlöpa. I annat fall menar

Kruchten (2000) att projektet antingen bör avbrytas eller omarbetas grundligt innan det tillåts

fortsätta in i nästa fas.

Elaborationsfasen 

Denna fas avser att arbeta fram en stabil och tillförlitlig arkitektur baserad på de arkitektuella

och betydelsefulla Use Casen (Kruchten, 2000). Enligt Arlow & Neustadt (2005) är det

primära målet med Elaborationsfasen att skapa en kör- och testbar arkitektur som bygger på

den specificerade arkitekturen. Dock menar Arlow & Neustadt (2005) att detta inte ska

beaktas som en prototyp utan snarare som en första utgåva av det önskade systemet. Kruchten

(2000) anser att de primära målen är att, för kravställarna, demonstrera att projektets

arkitektur stödjer visionen inom rimliga kostnader och att projektet följer tidsplanen.

Use Case modellen är i detta skede till 80 procent färdig och samtliga aktörer har blivit

identifierade och de flesta Use Case beskrivningar är under utveckling. De krav som är icke

funktionella kompletteras också. I slutet av elaborationsfasen stäms andra milstolpen av mot

att det finns en stabilitet i både krav och arkitektur, samt att de största riskerna har blivit

identifierade och eliminerade. Om projektet ska leva vidare måste iterationsplanerna för nästa

fas kontrolleras. Detta för att se till att de är tillräckligt detaljerade och trovärdiga och

kravställarna ska vara eniga om att visionen kommer att uppnås under rådande

omständigheter (Kruchten, 2000).

36

Konstruktionsfasen 

Kruchten (2000) anser att syftet med konstruktionsfasen är att bygga produkten enligt de

kriterier som satts upp i de två tidigare faserna. Under denna fas ska alla återstående

funktioner för komponenter och applikationer vara integrerade och testade. Arlow & Neustadt

(2005) menar att ett nyckelproblem inom denna fas är att behålla integriteten av systemets

arkitektur. Det finns annars risk för att systemet blir instabilt vilket kan leda till att

servicekostnaderna ökar. De primära målen är enligt Kruchten (2000) att optimera och planera

resurserna för att undvika dubbelarbete sam att hålla leveransplanerna för de releaser som

planerats.

För att samtliga milstolpar ska anses vara uppnådda måste fasen resultera i en produkt som

kan integreras mot avsedda plattformar samt att användarmanual och beskrivning av den

nuvarande releasen utförs (Arlow & Neustadt, 2005)

Under konstruktionsfasen utvecklas en betaversion av systemet/produkten och i slutet av

fasen stäms tredje milstolpen av mot att produkten är tillräckligt stabil och mogen för att

överföras till användarna samt att intressenterna är redo att implementera systemet (Kruchten,

2000).

Transitionfasen 

Denna fas initieras när testningen av betaversionen är klar och systemet är färdigutvecklat

(Arlow & Neustadt, 2005). Syftet med fasen är enligt Kruchten (2000) att leverera produkten

till slutanvändarna, vilket vanligtvis resulterar i nyutveckling, nya releaser, problemrättningar

eller att uppskjutna funktioner slutförs. Kruchten (2000) menar att buggar, implementation

och tester fastställs och beroende på vilken typ av produkt som utvecklas variera fasen från

väldigt enkla till mycket komplexa.

I slutet av fasen stäms den fjärde milstolpen av och de viktigaste frågorna som ska besvaras är

om användarna är nöjda och om utfallet stämmer överrens med förväntningarna. Vid den här

tidpunkten avgörs det även om målen är uppfyllda och om en nyutvecklingscykel ska påbörjas

(Kruchten, 2000). Arlow & Neustadt (2005) menar att fasen innehåller moment som att rätta

till eventuella brister, förbereda användarna för uppstartandet av det nya systemet och att

utarbeta en användarmanual. När alla tester är gjorda, alla mål är uppfyllda och allt har blivit

37

godkänt införs systemet. Det är inte förrän beställarna använder systemet aktivt som det anses

vara färdigt.

3.5 RUP och UML som process 

RUP är en iterativ och inkrementell process vilket innebär att den är uppdelad i olika faser där

ett visst antal iterationer sker tills de satta målen för den specifika fasen är nådda. Varje

iteration kan ses som ett litet miniprojekt där en grupp utvecklare dagligen går igenom dessa

faser. Allt eftersom systemet utvecklas och produkten växer förflyttar man sig mellan de olika

faserna som RUP består av. För att lyckas med detta menar Jacobsen (1999) att det måste

finnas kontroll över de olika stegen i iterationerna genom planering av hur iterationerna ska

genomföras.

Framgångsrika iterationer bygger på hur de olika modellerna i de förra iterationerna

avslutades. Efter att varje iteration har avslutats resulterar det i förändringar i modellerna.

(Jacobsen, 2000). Utvecklarna börjar med att varje iteration identifiera och specificera de

relevanta Use Casen för att skapa en design med den valda arkitekturen. Därefter

implementeras designen i komponenterna för att jämföras med de krav som sattes i Use Caset.

Om målen är nådda påbörjas nästa iteration. Enligt Jacobsen (2000) finns det många fördelar

med att använda sig av iterationer. Dessa är:

I. Hela projektet är indelat i mindre projekt där varje iteration blir ett begränsat

riskmoment om de uppsatta målen inte skulle uppnås. Det är med andra ord bara en

liten del av projektet som behöver arbetas om.

II. Risker uppdagas tidigare i RUP än andra metoder vilket underlättar produktens

frisläppande på marknaden.

III. Utvecklingen snabbas upp då själva processen är mer resultatinriktad.

IV. Det är lättare att anpassa utvecklingen av systemet om kraven skulle ändras under

tiden.

3.6 Prototyping 

Innebörden med Prototyping är enligt Andersen, Erling S (1994) att en prototyp utvecklas

innan en produkt börjar produceras. På detta sätt finns möjligheten att testa produkten innan

den släpps för implementering.

38

3.6.1 Allmänt om prototyping 

Syftet med prototyper enligt Gulliksen & Göransson (2002) är att erbjuda utvecklare och

intressenter en överblick över hur ett färdigt system skulle kunna se ut och fungera innan det

är färdigutvecklat. Genom att använda prototyputveckling ges det ett flertal möjligheter för

utvecklare och intressenter, som i ett tidigt stadium kan testa funktionaliteten, hitta svagheter

och testa prestanda samt utvärdera utseendet på prototypen. Enligt Andersen (1994) är inte

huvudsaken med en prototyp att vara helt identisk med hur slutprodukten ska se ut. Dock är

det viktigt att de delar som ska provas ut är så lika som möjligt.

Enligt Eriksson (2007) är den stora fördelen med prototyper att alla kan förstå dem. Många

användare har svårigheter att första olika modeller som exempelvis kravspecifikationer. För

att användare ska kunna förstå en prototyp finns det olika sätt att visualisera dem. Bland annat

kan pappersskisser, html-modeller och PowerPoint användas. Det finns ett flertal olika

program och tekniker för utveckling av prototyper, dessa har både sina för- och nackdelar.

Program som är gjorda för utveckling har fördelen att prototypen ser ut som en riktig

programvara med riktiga funktioner. Men detta kan för användarna bli för verkligt och risken

finns att de tror att det är en färdig produkt som inte behöver vidareutvecklas. Fördelar med

pappersskisser är att de första prototyperna inte ser ut som äkta vara och att den kan förändras

rent grafiskt på plats. Senare i utvecklingsarbetet är det en bra idé att gå vidare till ett

utvecklingsprogram för prototyputveckling och att arbeta om pappersskissen till en

fungerande prototyp som är navigeringsbar.

Meningen med att utveckla system med Prototyping är att under hela utvecklingen ha en nära

kontakt med beställarna för att kunna genomföra utvärderingar av olika prototyper som kan

vara i databasform eller i pappersform. På detta sätt erhålls en snabbare och effektivare

återkoppling och kan i ett tidigt stadium upptäcka brister och fel som kan leda fram till förslag

på förändringar (Gulliksen & Göransson, 2002).

3.6.2 Prototyping och iterationer  

Iterationer är en viktig del av Prototyping. Iterationer finns som en konsekvens av att

utvecklare av informationssystem inte är tillräckligt duktiga på att hitta rätt krav inom

området. När prototyper utvecklas och testas på användarna framkommer ofta frågor eller

problem och utifrån dessa diskussioner och tester utvecklas nya prototyper. Detta sätt att

arbeta kan hålla på under en längre tid och kan komma att innefatta många olika prototyper

39

innan den är färdig och lever upp till de satta kraven (Andersen, 1994).

3.6.3 Prototyping och metoder  

När prototyper började användas på 1970- talet, var inställningen att prototyper endast skulle

vara till för att prova ut de viktigaste egenskaperna i systemet och sedan kasseras. Dessa

prototyper användes och utvecklades på detta sätt för att ta reda på vilket system användarna

ville ha, men också för att arbeta fram kravspecifikationer. Kravspecifikationerna utvecklades

sedan med hjälp av olika modelleringsmetoder tills den klara driftversionen var klar. Idag har

synen på prototyper förändrats och de olika utvecklingsverktygen används för att på ett

strukturerat arbetssätt ta fram prototyper på ett snabbt och effektivt sätt. Dessa

utvecklingsverktyg gör att prototypen kan byggas ut till klara driftversioner. Prototyperna

kasseras då inte efter olika tester och iterationer som har gjorts för att utveckla systemet

(Andersen, 1994).

För att arbeta mer effektivt med Prototyping beskriver Andersen (1994) att man behöver

avgöra om det område som projektet handlar om lämpar sig för utveckling med prototyper.

För att avgöra detta finns olika metodsteg som hjälper till med besluten och om det framgår

att prototypframställning inte passar bör alternativa lösningar användas. I stort sett består

prototyputveckling av fyra olika delsteg.

Identifiera de centrala behoven

Detta metodsteg görs för att identifiera verksamhetens krav och användarnas behov på det

system som ska utvecklas. Detta steg inleds med att en verksamhetsanalys utförs som inriktar

sig på de centrala behoven och inte på att ta fram en heltäckande beskrivning. Det som den

första verksamhetsanalysen syftar till är att identifiera de centrala behoven som sedan leder

vidare till den första prototypen som omfattar de viktigaste delarna av systemet.

Verksamhetsanalysen ger information om vilka funktioner som ska finnas med i den första

prototypen (Andersen, 1994).

Utarbeta den första prototypen

Detta metodsteg syftar till att den första prototypen utvecklas. Den första prototypen måste

vara så utarbetad att den ska kunna simulera systemets viktigaste uppgifter. Detta leder till en

diskussion med användarna om vad som behöver förbättras eller förändras. Den första

prototypen ska inte vara för omfattande utan bör fokusera på de viktigaste funktionerna och

40

mindre på utseendet av systemet (Andersen, 1994).

Demonstrera och diskutera förbättringar

Detta metodstegs syfte är att utvärdera och omarbeta de redan satta kraven på systemet. I detta

steg måste användarna av systemet vara med och testa prototypen och genom diskussioner

arbeta fram vad som behöver förändras. Det finns vissa frågor som både användare och

utvecklare bör ställa sig. Dessa är: Gör prototypen vad användarna kräver? Kommer arbetet

att underlättas? Om inga synpunkter framkommer är risken stor att den är misslyckad och

utvecklarna bör ställa sig frågan om vad som är fel på prototypen. Senare i utvecklingsarbetet

kommer andra frågor in i bilden. Några av dessa är; finns särskilda idéer eller förslag som bör

prövas? eller vad kan göras för att förbättra interaktionen mellan människa och maskin

(Andersen, 1994).

Införa förbättringar

I detta metodsteg utvecklas en ny prototyp utifrån de förslag och idéer som framkom från den

första prototypen. Viktigt i detta steg är att de förändringar som ska utföras åtgärdas fort och

om det är möjligt göras på plats då användarna finns med. Vid snabba åtgärder som sker på

plats finns möjligheten att upptäcka brister direkt och när korrigeringar görs kan dessa ändras

tillbaka eller anpassas med en gång. Dessa förändringar kan ta ganska lång tid vid de tidiga

prototyperna då de kan ha många problem som måste åtgärdas. Ju fler prototyper som

utvecklas desto mer inriktas arbetet på detaljer och då arbetet fokuserar på om var ett fällt

eller en linje ska finnas tyder det på att arbetet närmar sig slutet på iterationerna . Syftet med

detta metodsteg är att utföra ytterligare iterationer. Detta görs tills dess att prototypen anses

leva upp till de krav som användarna ställer på det färdiga systemet (Andersen, 1994).

41

4 Empiriskt ramverk  

Här presenteras det empiriska materialet för fallstudien. Fallstudie 

I och med sekretessbelagda tillverkningsföreskrifter och känslig information kommer vi

generalisera och anonymisera företaget och därför nämner studien varken namn eller roller på

de undersökta objekten. Bryman (2001) menar att de grundläggande etiska aspekterna inom

vetenskapliga undersökningar är att den är frivillig och att den innehåller integritet och

anonymitet för de företag och individer som blir inblandade i forskningen.

Informationsflöde och problem 

Det som är det största problemet för organisationen är flödet av information mellan

produktionsavdelningen och övriga avdelningar. Detta problem uppstår då all hantering av

data sker i pappersformat och all information som fyllts i av operatören förs in i det befintliga

informationssystemet i vid ett senare tillfälle. Detta moment görs oftast vid dagens slut men

vid enstaka fall kan det ta flera dagar innan det görs. När informationen försenas och inte

kommer in i systemet i tid och då övriga avdelningarna väntar på informationen kan

produktionen stanna upp innan dataflödet har återställts.

Vid läkemedelsproduktion krävs det att en produkt ska uppnå en viss kvalitet för att få släppas

på marknaden. Detta innebär att både dokumentationen som sker i produktionslokalen är rätt

ifylld och att preparatet når de kvalitetskraven som är satta. Att denna del av dokumentationen

sköts på ett korrekt sätt är oerhört viktig då informationen ligger till grund för

logistikavdelningens beräkningar för när nästa leverans ska kunna ske. Quality assurance2

(QA) roll i företaget är att godkänna processer samt att granska produkten efter de

tillverkningsföreskrifter som produktionsavdelningen har använt sig av vid tillverkning av

läkemedlet. Detta jobb sköts idag helt manuellt och kräver oftast att två eller tre personer

granskar tillverkningsföreskrifterna vilket leder till ett onödigt svårt och tidsödande moment i

produktionen. När avvikelser uppstår belastas företaget både ekonomiskt men även i form av

att resurserna används på ett ineffektivt sätt.

2 Avdelningen som har hand om läkemedelskvaliteten

42

5 Empiriskt resultat  

I detta kapitel redovisas resultatet utifrån våra syften och frågeställningar. Kapitlet börjar

med att presentera resultatet av observationen, för att därefter gå vidare med intervju,

modellering, enkät och prototypresultat.

5.1 Observation ‐ av granuleringsprocessen  För att få en bättre förståelse för situationen på läkemedelsföretaget och vad de förväntar sig

av systemet gjordes en observation av processen där en operatör gick igenom tillverkningen

steg för steg (se bilaga A). Med hjälp av observationsunderlaget skapades en bild av hur

systemet kan se ut utifrån tillverkningsföreskriften (se bilaga I) samt hur de olika stegen

utförs. En mer detaljerad observationsbeskrivning finns i bilaga B.

Det visade sig snabbt att själva tillverkningsförfarandet led av en del brister. All

dokumentation och signering är helt pappersbaserad samt att signeringar sker i efterhand.

Oftast brukar inte operatören lämna produktionslokalen för att få tillverkningsföreskriften

signerad utan lämnar tillverkningsföreskriften för signering först när processen är avslutad.

Vid en del tillfällen var operatören tvungen att lämna produktionslokalen för att få specifika

delar av tillverkningsföreskriften signerad. Vid ytterligare ett tillfälle när det skulle ske en

dubbelsignatur kunde signeringen inte ske då operatören inte var godkänd för dubbelsignering

av processen. Otaliga minuter gick åt vilket inte bara drabbade operatören i fråga utan även de

som var tvungna att lämna sina processer. Under något tillfälle skrev operatören fel datum och

var tvungen att korrigera sitt misstag. Observationen visade tydligt att kontrollen är en viktig

del och återkommande moment i processen. Operatören måste exempelvis kontrollera att det

är rätt preparat, rent i maskinen från föregående preparat, rätt etiketter, rätt fukthalt och

temperatur etc. Efter varje steg och kontroll måste signering utföras av operatören.

5.2 Intervju 

Intervjuerna bekräftade framför allt att företaget inte har någon direkt kontroll över de steg och

signaturer processen kräver, även dubbelsignaturer och den pappersbaserade dokumentationen är

ett primärt problem.

Arbetssättet är idag relativt föråldrat och anses omständligt då allt fylls i på papper som sedan

lämnas vidare till nästa station. Det förekommer många onödiga avvikelser på grund av att

43

operatörerna glömmer att dubbelsignera eller att det görs i efterhand.

Dokumentationen innehåller många steg och upprepningar. Intervjun visar att flertalet fyller i

dokumentationen rent rutinmässigt och det är ofta då avvikelserna uppstår. Ett önskemål som

visade sig komma från flera var någon form av avläsningsdisplay eller elektroniska signaturer

för att undgå ifyllande av papper, signeringar och upprepningar. Det framgick att det är möjligt att

hoppa över steg i dokumentationen vilket ansågs kritiskt:

”Jag tycker det är väldigt kritiskt att de som jobbar med och har

produktansvar eller releasansvar inte kan se om det är någon som har

hoppat över någonstans. För att man kan hoppa över det och ändå fylla i

det i efterhand för den här spårbarheten”.

Det innebär att en lösning inte ska ge någon möjlighet att gå vidare i produktionen om alla

steg inte är korrekt ifyllda.

Avvikelser hanteras idag genom att personer i fabriken granskar metoderna för att avvikelser

inte ska uppstå. Är något fel i dokumentationen måste det meddelas omgående att det har

gjorts fel så att respektive operatör som har skapat avvikelsen kan i efterhand signera med sin

signatur. Om dessa personer inte är tillgängliga eller finns på plats blir det automatiskt en

avvikelse.

Avvikelser kan enligt de tillfrågade minimeras genom att minska det monotona arbetet.

Ytterligare en anledning till att avvikelser uppstår är momenten då dubbelsignering måste utföras

och operatören måste leta upp en annan godkänd operatör för att kontrollera och signera.

”Det sitter väldigt många människor och jobbar med det och lägger

mycket tid och kraft på granskningen idag. De kollar så att alla signaturer

är där alla etiketter är och så vidare. Där hade man kunnat vinna en

massa tid på att ha ett bättre system så att man slipper kontrollera lika

mycket som mer eller mindre kanske kontrollerar sig själv vad det gäller

signaturer och så vidare”.

Det framkom tydligt att de grundläggande problemen inom tillverkningsprocessen är att

44

dokumentationen är pappersbaserad och att både enskilda- och dubbelsignaturer kan ske i

efterhand vilket försvårar spårbarheten. Det framkom att avvikelser är både tid- och

kostnadskrävande.

5.3 Modellering  

Innan utvecklingen av prototypen med html, modellerades systemet med hjälp av UML.

Modelleringen baseras på kravspecifikationen (se bilaga D) som framställdes utifrån

observationer och intervjuresultatet samt tillverkningsföreskrifterna (se bilaga I). Efterhand

som prototypen ändrades omarbetades även modellerna. De olika modellerna ska ge ett

underlag och visualisera hur systemet ska fungera.

Klassdiagram 

Klassdiagrammet nedan beskriver relationerna mellan klasserna. Arbetare är klassen som

diagrammet utgår ifrån. Klasserna Operatör, Administratör och Samordnare är en

specialisering av klassen Arbetare som beskriver de olika roller en arbetare kan ha inom

produktionen. Klassen Arbetare har en relation till Tillverkningsföreskriften som är uppdelat i

delsteg. De klasser som har administratörsrättigheter är klasserna Administratör och

samordnare (se figur 5:6).

Figur 5:6 Klassdiagram över prototypen 

 

45

Use Case diagram 

Use Case-diagrammet nedan beskriver hur de olika aktörerna interagerar med

kontrollsystemet. Aktören Operatör är den som befinner sig i produktionen. Administratören

är den som kontrollerar användarkonto samt har möjlighet att editera dokumentationen. QA-

aktören har möjlighet att ändra direkt i receptet samt göra textförändringar i det digitala

gränssnittet.

Figur 5:7 Use Case diagram över prototypen 

 

 

 

46

Aktivitetsdiagram 

Aktivitetsdiagrammet nedan visar de olika delsteg som en operatör kan välja vid

produktionsstart. Efter valt delsteg kan inloggning ske, därefter hämtar systemet temperatur,

fukthalt och datum som fylls i automatiskt. Operatören signerar uppgifterna och systemet

hämtar ny information som signeras av operatören vilket i sin tur leder till nya steg som

kräver systemets första dubbelsignering.

Figur 5:8 Aktivitetsdiagram över prototypen 

47

5.4 Prototyping 

Den första prototypen skapades utifrån kravspecifikationen och tillverkningsföreskrifterna och

är endast en skiss (se figur 5:9, för större bild se bilaga E). Andra prototypen utvecklades

sedan vidare enligt kravspecifikationen och UML modelleringen som baserades på

observationen och intervjuerna. Den andra prototypen är uppbyggd med html kod och

visualiserar tillverkningsföreskriften och de olika stegen i tillverkningsprocessen. På första

sidan har användaren möjlighet logga in samt välja olika tillverkningssteg (se bilaga H).

Figur 5:9 Första skissen på prototyp 

För att användarna inte ska få möjlighet att eftersignera eller gå vidare i processen utan att

signera alla steg ligger en kontroll som meddelar att alla fält måste vara ifyllda för att stegen

skall kunna valideras. När samtliga steg är signerade kan en slutsignering utföras för att gå

vidare till nästa steg i tillverkningen (se bilaga G).

5.5 Enkät 

När utvärderingen av andra prototypen utfördes fick nio personer som arbetar vid

tillverkningsprocessen testa prototypen och fick därefter fylla i en enkät som bestod av sex

frågor (se bilaga J).

Enkäten visade att respondenternas första intryck på prototypen var positiv (se tabell 5:5).

Dock framkom det vissa otydligheter på den första sidan. Otydligheterna ansågs vara på

flikarna där det stod preparat. Det framkom också att meddelanderutan ansågs vara något

otydlig.

48

På frågan som gäller hur prototypen uppfyller kontrollen av processen svarade en av

respondenterna följande:

”Ja signeringen som bockas i efter varje steg plus en slutsignering när

alla steg är utförda ger en bra överblick och kontroll”.

Majoriteten av respondenterna anser att denna lösning kan spara tid och man slipper spring

fram och tillbaka i korridorerna.

”Man spar mycket med tid med denna lösning genom att klicka istället för

skriva sin signatur om och om igen”

Samtidigt visar resultatet i denna fråga att en tredjedel av de tillfrågade att prototypen inte

kommer att ge några större eller inga tidsbesparingar.

På frågan om huruvida en sådan här lösning skulle hjälpa till att lösa problematiken kring

dubbelsignering tycker de flesta att det skulle fungera bra eller mycket bra. Vidare tycker

majoriteten att strukturen, layouten och att arbetsgången fungerar bra och en av

respondenterna skrev denna kommentar:

”Bra uppdelat av själva tillverkningsföreskriften, lätt att förstå och följa.”

På frågan som behandlar användarvänligheten av prototypen var svaren spridda mellan dåligt

och mycket bra då det senare var vad majoriteten svarade. Det framkom vid undersökningen

att det fanns vissa brister i överblicken av prototypen, bland annat framkom det att rubriker i

gränssnittet var svåra att se. Vidare framkom det att det blir en del arbetande i prototypen men

att den kan underlätta. En av respondenterna menar att:

”Det är mycket klickande men jag föredrar det istället för att skriva

signatur för hand.”

49

Tabell 5:5 Enkät sammanställning för prototyp V.1.1 

Enkäten visade att helhetsintrycket på den första versionen av prototypen var positiv. Ingen av

respondenterna ansåg att prototypen var mycket dålig och endast 1 procent tyckte att den var

dålig. Sammanställningen (se bilaga K) visar att 11 procent av respondenterna tyckte att

prototypen varken var bra eller dålig, 55 procent tyckte den var bra och 33 procent tyckte att

prototypen var mycket bra.

5.6 Prototyp – Omarbetning utifrån enkätresultatet 

Utifrån enkätresultatet omarbetades en tredje prototyp som innehåller följande förbättringar.

Preparatflikarna och meddelanderutan som ansåg otydliga i den andra prototypen

omarbetades (se figur 5:10 och 5:11)

Figur 5:10 Version 1.1 av prototypen 

Fråga 1 Fråga 2 Fråga 3 Fråga 4 Fråga 5 Fråga 6

1. Mycket dålig 0 0 0 0 0 0

2. Dålig 0 0 0 0 1

3. Varken bra eller dålig 1 0 3 0 0 1

4. Bra 7 8 3 3 6 3

5. Mycket bra 1 1 3 6 3 4

0123456789

Antal respondenter

Enkätunderlag för prototyp V.1.1

50

Figur 5:11 Version 1.2 av prototypen 

Enkäten visade att översikten blir bättre om man avskiljer rubrikerna och de olika stegen (se

figur 5:12 och 5:13 nedan)

 

Figur 5:12 Version 1.1 av prototypen 

51

Figur 5:13 version 1.2 av prototypen 

5.7 Mailintervju 

En mailintervju utfördes för att få möjligheten att stärka de påståenden och resultat som

framkommit (se bilaga L). Mailintervjun skickades till fem olika företag som arbetar med

systemutveckling och av dessa fem fick vi in endast en respondent.

Respondenten arbetar som mjukvaruarkitekt på ett branschledande företag inom design och

utveckling av mobila plattformar. Personen har övervägande teoretiska erfarenheter av RUP

och relativt omfattande erfarenheter av Prototyping.

Respondenten anser att Prototyping och RUP mycket väl kan kombineras och att Prototyping

är lämplig när det exempelvis finns en osäkerhet på de tekniska lösningarna.

På frågan inom vilka ramar/projekt som RUP och Prototyping lämpar sig inom systemutveckling

menar personen att:

”RUP är mest lämpat för utveckling av programvaruintensiva system.

Prototyping kan användas för alla typer av system och även för t.ex. icke

programmerbara system.”

52

Avslutningsvis anser personen att RUP inte ställer några krav på Prototyping och att Prototyping kan

kombineras med vilken utvecklingsmetod som helst, samt att RUP bör kombineras med andra

utvecklingsmetoder.

53

6 Analys och slutsats  

Detta kapitel kommer utifrån det empiriska och teoretiska kapitlet svara på de

frågeställningar som studien ämnar ge svar på.

På vilket sätt kan systemutvecklingsmetoderna RUP och Prototyping

kombinera och komplettera varandra i praktiken?

RUP som systemutvecklingsmetod är en bra metod för att skapa mindre system. Den första

Inceptionfasen används för att utföra en kravinsamling och för att ta tillvara på intressenternas

krav och önskemål. Prototyping inom RUP är en relativt liten del av metoden i

Inceptionfasen. Respondenten anser att:

”Prototyping och RUP kan mycket väl kombineras. De principer och tekniska

lösningar man är osäker på, kan lämpligen prototypas”

Genom användning av RUP skapades en kravlista som stämde överens med de krav företaget

ställde på systemet. Då RUP är en iterativ process och bygger på täta avstämningar med

intressenterna anses metoden skapa en högre stabilitet och utveckling. Utvecklingen sker efter

de insamlade kraven som tas fram tillsammans med utvecklare, intressenter och

slutanvändare. Fördelen med användning av RUP är att de iterativa stegen fastställer kraven

på ett system utan att vara insatt i hur organisationen fungerar (Avison & Fitzgerald 2000).

Prototyping är ett bra och effektivt sätt att visualisera ett system. Prototyping är även en bra

metod då intressenterna har möjligheten att styra utvecklingen av prototypen. För att lyckas

med Prototyping krävs ett nära samarbete med beställaren men kanske ännu viktigare är

slutanvändarna. Detta gäller inte bara Prototyping utan även RUP vad gäller kravinsamling

för dess andra faser och flödessteg.

RUP är en relativt långsam utvecklingsmetod och Prototyping är en snabbare metod. Då

Prototyping är en snabb metod passar den bra att ha som komplement i RUP:s enskilda faser.

RUP:s kravinsamlingsprocess är en långsam och iterativa process som lägger en bra grund för

Prototyping. Efter att kraven sammanställts påbörjades prototyputvecklingen genom en första

skiss där en del av kraven realiserades. Slutanvändarna var mycket positiva till den framtagna

prototypen då den var lätt att förstå. En tydlig sak som framkom vid kombination av

54

metoderna var att Prototyping snabbt skapade en visualisering av kraven.

Vårt resultat visar tydligt att de båda metoderna RUP och Prototyping kan kombinera och

komplettera varandra på ett bra sätt. Metoderna säkerställer att kravinsamlingen är korrekt och

genom visualisering av kraven med en prototyp kan vem som helst oavsett bakgrund, kultur,

utbildning etc. läsa och förstå innebörden av systemet och dess funktioner.

Är kravinsamling utifrån RUP ett bra tillvägagångssätt för att uppnå en

prototyp?

Med hjälp av RUP:s noggranna tillvägagångssätt vad gäller kravinsamling läggs en bra och

stabil grund för kommande faser och flöden i RUP, vilket även gäller Prototyping. Genom

användning av Prototyping har en visualisering av systemet framställts. Detta utfördes med

hjälp av testning mot slutanvändarna där dessa fick fylla i en enkät för att säkerställa de krav

som togs fram i RUP:s Inceptionfas.

På vilket sätt kan då kravlistan säkerställas för kontrollstyrning vid

tillverkningsprocessen inom läkemedelsbranschen?

RUP förespråkar flera olika kravinsamlingsmetoder, dessa kan vara observationer, intervjuer,

enkäter och dokumentationer. För att säkerställa kraven som arbetades fram utifrån

observationen utfördes intervjuer, därefter kompletterades kravlistan. För att säkerställa den

omarbetade kravlistan utvecklades en prototyp som testades och utvärderades genom en

enkätundersökning varefter förändringar gjordes på prototyp och kravlista. För att säkerställa

läkemedelsprocessens regler och krav användes dokumentation från företaget, som i detta fall

var deras tillverkningsföreskrifter. Prototypen utvecklades efter dokumentationens utseende

så att slutanvändarna känner igen sig i utformningen av gränssnittet och de olika momenten i

arbetsprocessen.

UML är ett notationsspråk för visualisering av systemets olika delar, främst för utvecklarna.

En prototyp är mer överskådlig för slutanvändare och för de som saknar kunskaper inom

systemutveckling. Genom användning av UML har modelleringen förankrat kraven och

samtidigt skapat en tydligare bild över hur systemets relationer, funktioner och dataflöden

fungerar.

55

Inom vilka ramar är RUP och Prototyping lämpliga metoder inom

systemutveckling?

RUP lämpar sig inom de flesta områden men framförallt för projekt som sträcker sig över en

längre tidsperiod. Prototyping är mer lämpligt för att snabbt och enkelt visualisera systemets

komponenter och funktioner.

”RUP är mest lämpat för utveckling av programvaruintensiva system.

Prototyping kan användas för alla typer av system och även för t.ex. icke

programmerbara system”

RUP kan använda sig av prototyputveckling redan i första fasen, men då endast som

rekommendation och endast som en grov skiss. Respondenten anser att RUP inte ställer några

krav på Prototyping och att Prototyping kan kombineras med vilken utvecklingsmetod som

helst, samt att RUP bör kombineras med andra utvecklingsmetoder. Svårigheter med RUP

kan vara att visualisera koncept för användare och beställare och risken finns att olika krav

och önskemål kan missas. Genom att involvera metoden Prototyping från projektstarten ökar

möjligheten till att fånga in de rätta kraven och önskemålen, detta då det är enkelt för alla

inblandade parter att förstå en prototyp, men även att förvalta all information på ett effektivt

sätt. Vidare är Prototyping en snabbare utvecklingsmetod än vad RUP är och hinner med fler

och snabbare iterationer inom RUP:s första Inceptionfas.

 

 

 

56

7 Diskussion och reflektion 

Det här kapitlet diskuterar resultatet med anknytning till frågeställningarna och vad

resultaten betyder i stort. Här kommer våra reflektioner över arbetet att redovisas. Vidare

behandlas framtida forskningsmöjligheter och hur man kan arbeta vidare med resultatet.

För att skapa ett bra och stabilt system måste det finnas en bra grund att stå på i form av en

utvecklingsmetod. Genom att använda en eller flera metoder kan man upprätta en klar

kommunikation mellan de inblandade parterna. För att möta beställarens krav och önskemål

på systemet måste vissa åtgärder vidtas, i teorin framgår det att kravinsamling är ett

tillvägagångssätt för att ta reda på vad användaren behöver. Vidare framkommer det att vissa

projekt misslyckas på grund av bristande kravinsamling. Dessa brister beror ofta på olika

sociala, politiska och kulturella faktorer. Det finns en rad olika insamlingsmetoder som kan

vara observationer, intervjuer, och enkäter osv. Kraven på systemet varierar lika mycket som

det finns avdelningar på ett företag och personer som jobbar i dem, alla har en egen

uppfattning om hur det ska se ut och vad det ska göra. Det är viktigt att komma fram till de

gemensamma målen för problemområdet och se till att de viktigaste kraven identifieras.

För vår del var observation och intervju ett mycket bra sätt att samla in krav på. Det var

mycket förmånligt att i ett tidigt skede få en god kontakt med företaget vilket gjorde att vi

kunde utföra både observation och intervjuer på plats. Det vi upplevde vid intervjun var att en

del av respondenterna hade olika syn på syftet med systemet. Majoriteten tyckte att de fick

kontroll och ett fåtal ansåg att det blev en form av övervakning. Därför upprättades en god

kommunikation för att klargöra för slutanvändarna vad som är grundidén med systemet.

För att samla in kraven var vi tvungna att sätta oss in i tillverkningsprocessen. Observation

var ett bra tillvägagångssätt för att få insikt i tillverkningsprocessen samt för att samla in de

första kraven på systemet. Vid observationen fick vi möjlighet att ta del av

tillverkningsföreskrifterna vilket ytterligare stärkte kravens tillförlitlighet mellan observation

och de krav som framkom. För utveckling av prototypens gränssnitt användes

tillverkningsföreskriften som mall för att efterlikna den nuvarande dokumentationsmallen.

Då RUP är en tung och avancerad systemutvecklingsmetod krävs det att utvecklarna måste ha

57

goda förkunskaper inom metoden. För att nå upp till denna kunskapsnivå finns det en hög

inlärningströskel för att på ett effektivt sätt utnyttja dess verktyg. Insamlandet av krav till

systemet gjordes med hjälp av RUP och dess första fas, Inceptionfasen, och kraven stämdes

av mot beställarnas önskemål efter varje iteration.

Den första skissen (se bilaga E) över systemet gjordes i Inceptionfasen och lade grunden för

systemets användargränssnitt. När kraven och den första prototypen hade skapats lämnades

RUP som metod för att ersättas med Prototyping. För att få en tydligare visualisering av

systemet än vad RUP:s grova skiss i Inceptionfasen erbjuder valde vi att använda metoden

Prototyping, vilket resulterade i att två nya versioner utvecklades.

Vid en jämförelse av RUP och Prototyping är iterationer en lika viktig del i båda metoderna.

För att säkerställa att alla inblandade parter arbetar mot samma mål är enkätundersökningar en

effektiv metod. I vår studie säkerställde enkäten att prototypen motsvarar de krav som ställts.

Vi förväntade oss ett resultat som visar att metoderna RUP och Prototyping kan kombinera

och komplettera varandra. Genom att ha fått förmånen att utföra en fallstudie har det gett oss

möjligheten att använda oss av metoderna i praktiken och på så vis fått värdefulla erfarenheter

om hur utvecklingsmetoderna kan kombineras och användas i verkligheten samt hur kraven

förvaltas. Metoderna säkerställer att kravinsamlingen är korrekt genom visualisering av

kraven med en prototyp. Detta är också något som vi kommer att ta med oss i framtida

arbeten.

Reflektion 

Under de första veckorna av planeringen av uppsatsen fanns många oklarheter om vad vi

skulle undersöka samt vilket ämne som skulle undersökas, tills vi kom fram till att utföra en

fallstudie och undersöka olika systemutvecklingsmetoder. Vi har insett vikten av att en

grundlig kravinsamling utförs och att en god kommunikation med beställaren upprätthålls. Vi

har även kommit fram till att det aktuella företaget är i behov av en förändring i

dokumentationen för att underlätta kontrollstyrningen inom tillverkningsprocessen. Vi blev

positivt bemöta av företaget och dess anställda vilket gjorde arbetet ännu roligare och

intressantare.

58

7.1 Kritik av genomfört arbete 

Hade vi fått göra om studien från början hade vi i ett tidigare skede försökt få in svar från

personer som arbetar med de olika utvecklingsmetoderna. Vi utförde mailintervjun i ett sent

skede vilket ledde till att vi endast fick ett svar. Fler svar hade kunnat stärka vårt resultat

ytterligare. Vi skickade mailintervjun till fem olika företag som arbetar med systemutveckling

och fick endast svar från en respondent. Vi hade också kunnat utveckla mailintervjun och

förklarat mer ingående vad vi anser med RUP och Prototyping och i vilket

användningsområde vi arbetar med metoderna.

Enkäterna skulle ha kommit ut tidigare, ytterligare en enkätundersökning skulle då ha kunnat

utföras på tredje versionen av prototypen som då också skulle ha kunnat utvärderas genom

testning.

Vid sammanställningen av enkäten visade det sig att endast ett fåtal skrivit kommentarer. De

som vi fick var mycket givande men hade vi haft mer tid hade vi kunnat styrka vikten av att

lämna kommentarer och understyrka att det är viktigt för både vårt resultat och

vidareutvecklingen av prototypen. Vissa intervjuer gav oss så mycket som vi önskade. Det vi

hade kunnat göra var att förtydliga frågorna och syftet med intervjun.

Vi har under arbetets gång fokuserat mycket på fallstudien och lösningen för systemet vilket

har lett till att mindre fokus har lagts på de övriga delarna av arbetet. Vi hade gärna haft mer

tid för att arbeta med utvecklingsmetoderna och utveckla prototypen ytterligare, och fått in ett

större antal svar på mailfrågorna som ställdes till olika företag som arbetar med metoderna.

Detta hade gett oss ett underlag som styrkt vårt resultat ytterligare samt ökat förståelsen för

hur metoderna kan fungera tillsammans. Vi hade velat utveckla en självvärdering av RUP och

Prototyping och reflekterat på en djupare nivå över hur det är att lära sig och arbeta med

utvecklingsmetoderna.

7.2 Framtida lösning och utveckling 

Som tidigare nämnts är kravinsamling en viktig del för att ge en stabil grund till systemet. I

och med att både RUP och Prototyping arbetar med iterationer och täta avstämningar med

beställaren kan kraven arbetas fram i ett tidigt skede. Vidare kan en prototyp snabbt tas fram

och utvärderas i samarbete med beställaren. Om systemet i framtiden ska utvecklas är det en

59

fördel att kombinera RUP och Prototyping för att snabbt kunna göra avstämningar med

beställaren med hjälp av prototypen. En intressant fråga som dykt upp under arbetets gång är

hur resultatet hade sett ut om vi endast arbetat med RUP eller Prototyping. Hur hade

skillnaden på resultatet sett ut?

Resultatet av mailintervjun kan i framtida undersökningar ge svar på varför svarsfrekvensen

var så låg. Är det så att de inte arbetar på detta sätt eller har de tillfrågade företagen låtit bli att

svara. Om företagen inte arbetar på detta sätt kan det innebära möjligheter till framtida

undersökningar om varför det inte görs.

I intervjuerna framgick det att NN är positiv till utvecklingsarbetet och ser gärna en framtida

utveckling av prototypen. NN nämner också ett önskemål om att kunna göra en integrerad

lösning med maskinerna, samt att varierande mätningar ska kunna utföras. På ett eventuellt

morgonmöte kan det beslutas vilka operatörer som ska arbeta tillsamman under dagen. Det

innebär att de kan följa varandras processer och göra sig förberedda på varandras

dubbelsignaturer och se varandras processsteg.

I framtiden ska produkten kunna anpassas till alla produktionslinjer inom företaget. Systemet

bör inte vara begränsat till läkemedelsindustrin utan ska kunna anpassas till vilken industri

som helst som har produktionslinjer. Observationen påvisar att stora delar av kontrollerna i

tillverkningsprocessen är tvingade att utföras rent fysiskt. Det är omöjligt för systemet att

övervaka dessa kontroller, dock kan systemet underlätta själva signeringen och hindra att inga

eftersigneringar utförs. När det ska ske dubbelsignaturer måste de olika operatörerna se

varandra och vad som sker i själva produktionslokalen. För att lösa detta problem kan en

videokamera användas för att upprätta en videolänk mellan operatörerna som ska

dubbelsignera.

Själva digitaliseringen är tänkt att ske genom att det pappersbaserade arbetet ersätts med en

digital portabel skärm som är kopplat till systemet. Det digitala systemet bör byggas upp

enligt hur det pappersbaserade ser ut idag så att det känns igen av användarna. Dock måste

det utvecklas enligt de regler som krävs för tillverkning av läkemedel. För att säkerställa att

all data som skapas finns lagrad korrekt krävs det att det sker enligt de föreskrifter som styr

digital dataförvaring.

60

8 Referenser  

Tryckta referenser Andersen, Erling S. (1994). Systemutveckling - principer, metoder och tekniker. Lund, Studentlitteratur. Andersen, Erling S. & Schwenke, E. (1998). Projektarbete – en vägledning för studenter. Lund, Studentlitteratur. Avison, David. & Fitzgerald, Guy. (2006). Information systems developmen - methodologies,techniques & tools. Berkshire, McGraw – Hill Education. Boody, David. Boonstra, Albert. & Kennedy, Graham. (2005). Managing Information Systems – An Organisational Perspective. Totenham - Prentice Hall. Bryman, A. (2001) Samhällsvetenskapliga metoder. Malmö: Liber Ekonomi. Eriksson, Ulf. (2007). Kravhantering för IT-system. Studentlitteratur. Gulliksen, J. & Göransson, B. (2002) Användarcentrerad systemdesign, Lund, Studentlitteratur. Holme, I. & Slovang, B. (1997) Forksningsmetodik. Om kvalitativa och kvantitativa metoder, J. Arlow, I. & Neustadt. (2005)UML2 and the Unified Process 2nd Ed., Addison-Wesley, Lund: Studentlitteratur. Patel, R. & Davidson, B. (1994) Forskningsmetodikens grunder. Lund: Studentlitteratur Trost, J. (2005). Kvalitativa intervjuer. Lund: Studentlitteratur. Yin, R, K. (2003). Case study research: Design and methods. London: Sage Publications Wisén, J. & Lindblom, B. (2004). Effektivt projektarbete, sjunde upplagan. Stockholm: Norstedt Juridik AB.

61

Vetenskapliga Artiklar

Goguen, J A. & A. Linde, C. (1993) “Techniques for requirements elicitation”.

http://www.cs.brown.edu/courses/cs190/2007/documents/restricted/goguen.pdf

Goguen, J A. (1993) “Social Issues in Requirements Engineering”.

http://citeseer.ist.psu.edu/cache/papers/cs/827/http:zSzzSzwwwcs.

ucsd.eduzSzuserszSzgoguenzSzpubszSz..zSzpszSzsissues.pdf/goguen93social.pdf

Leventis, P & Tomazic, A. (2002) ”Tillämpning av prototyper i Rational Unified Process”.

Handelshögskolan vid Göteborgs universitet Institutionen för informatik

http://gupea.ub.gu.se/dspace/bitstream/2077/1330/1/40050-x_leventis-tomazic_IA7400.pdf

Internetkälla

Mälardalens Högskola, Ekonomihögskolan. (Inget publicerings datum finns)

http://www.eki.mdh.se/uppsatser/seminarie/.../kurshemsidor_vt07/informatik/ei0760/OH/S2_UML_UP_

H06.pdf Hämtad 2009-06-02.

 

 

Bilagor  

Bilaga A ‐ Minnesanteckningar från observation 

Detaljerad vy av granuleringsprocessen

1. Innan produktion påbörjas ska mätaren i korridoren som visar trycket i

tillverkningsrummet kollas så att det överrensstämmer med de angivna värdena i

tillvärkningsföreskriften. Värdena får inte understiga <5 i tryck. Detta för att det

konstant ska finnas ett övertryck i tillverkningsrummet så att dam och partiklar inte

ska kunna ta sig in. Om trycket inte ligger inom referensramarna får produktion inte

ske.

2. Gå in i tillverkningsrummet och kontrollera vilket preparat som var det senaste i

produktionslokalen. Detta kontrolleras i loggboken där man läser av satsnumret,

exempel på ett sådant kan vara LD123 (LD relaterar till år och månad).

3. Kontrollerna så att inga rester från föregående preparat finns kvar i

tillverkningsrummet.

4. Gå till uppställningsrummet där de olika råvarorna finns och hämta den produkt som

har det efterföljande satsnumret som kollades i punkt 2. Kör produkten till

tillverkningsrummet. Kontrollera alla etiketterna på kaggarna mot loggbokens

satsnummer innan produktion sker.

5. Kontrollerna så att rätt sorts skyddsutrustning används i samband med produktion.

Kräver att 2 operatörer signerar.

6. Mät fukthalten i rummet och temperaturen. Detta ska föras in tillverkningsföreskriften

och signeras för att kunna spåra fel om dessa uppkommer och har ingen egentlig

betydelse för produktionen.

7. Kontrollera städningsdatumet i loggboken.

8. Ifall våtrengöring har utförts notera datumet i tillverkningsföreskriften i samband med

att produktionen körs igång första gången efter rengöring. Ifall torr rengöring har skett

notera kampanj i tillverkningsföreskriften om produkten kan köras i kampanj. Detta

varierar från produkt till produkt.

9. För in det föregående satsnumret i tillverkningsföreskriften som tillverkades senast i

tillverkningsrummet för att verifiera att rätt satsnummer följer föregående preparat.

10. Två operatörer måste signera i tillverkningsföreskriften för att satsning av råvarorna

får ske. En operatör övervakar vad den andra gör.

11. Häll i råvarorna i maskinen. Konstrollera inställningarna på maskinen och kör enligt

anvisningarna i tillverkningsföreskriften. I detta fall ska råvaran blandas 10 minuter.

Inställningarna på maskinen ska vara 109 varv/minut samt hackarhastighet 1.

12. Signera tillverkningsföreskriften med dubbelsignatur.

13. Ta bort etiketterna från kaggarna och klistra in dem i den angivna sidan i

tillverkningsföreskriften.

14. Under tiden råvaran blandas ska vätska vägas upp. Mängden preparat kontrolleras i en

tidigare tillverkningsföreskrift och förs in i den nya. Kärlet för vattnet förs upp på en

våg. Kärlet ska tareras (nollställer kärlets vikt på vågen) för att få fram tre värden på

etiketten. Brutto, Tara och Netto. Detta för att mer exakt kunna påvisa att vägningen är

korrekt. En terminal matas in med det satsnumret och kodnummer. Exempel på

satsnummer kan vara LD 123 och kodnummer kan vara 412130 för preparat. I

samband med att vätska vägs upp kontrolleras temperaturen så att de stämmer överens

med anvisningarna i tillverkningsföreskriften i detta fall mellan 12-25 grader Celsius.

Etiketten skrivs ut, kontrolleras och signeras av 2 operatörer. Endast behöriga på

produktionslinjen får signera etiketter eller i tillverkningsföreskriften. Etiketten

klistras fast på kärlet.

15. Vattnet satsas in i maskinen detta steg tar 5 minuter. Inställningarna på maskinen ska

vara 109 varv/minut samt hackarhastighet 1, detta görs efter den första blandningen på

10 minuter.

16. Efter att vattnet har blivit satsat stängs maskinen av och locket öppnas. Kanterna i

maskinen ska skrapas då produkt fastnar lätt och inte blandas som den ska. Detta steg

upprepas tre gånger till a två minuter. Sista upprepningen ska hackverktyget användas

på läge 1 i 30 sekunder. Alla stegen ska signeras av operatören.

17. Vågterminalen programmeras med rätt satsnummer och kodnummer. En kagge körs

upp på vågen och tareras. Granulatet töms ut i kaggen och maskinen skrapas ren.

18. Vikten från etiketterna skrivs in i tillverkningsföreskriften samt att min och max

gränserna för preparatet räknas ut. I detta fall är det (preparat+preparat+preparat-1kg)

och (preparat + preparat + preparat). Summan ska skrivas utan decimaler, avrundas

uppåt och föras in i tillverkningsföreskriften.

19. Klistra den signerade etiketten på kaggen som förs vidare till nästa steg i

tillverkningsprocessen. Ingen signering krävs i detta steg.

Bilaga B ‐ Detaljerad beskrivning av observation 

Innan operatören satte igång med tillverkningen av produkten kontrollerades en

tryckluftmätare som satt i korridoren i anslutning till rummet. Värdet som lästes av måste

stämma överens med det angivna värdet som står i tillverkningsföreskriften. I detta fall var

värdet en bra bit över godkänt så operatören godkände det första steget för att påbörja

produktionen. Enligt operatören är detta steget väldigt viktigt då trycket i rummet förhindrar

att partiklar från andra preparat letar sig in produktionslokalen och kontaminerar produkten.

Om trycket skulle vara under gränsvärdena i tillverkningsföreskriften får tillverkning i

rummet inte ske, så är även fallet om produktion redan sker i lokalen, den måste upphöra. När

detta steg är avklarat går operatören in i produktionslokalen för att kontrollera senaste

städning, senast körda preparat samt datum för städning och vem som har signerat städningen.

Dessa uppgifter finns nerskrivna i en loggbok. I samband med kontrollen såg operatören även

till så att det inte fanns preparat från föregående tillverkning i rummet då det kan leda till en

kontaminering. När denna kontroll var avklarad och godkänd gick operatören till en

uppställningsplats för råvaror. Genom att gemföra informationen i loggboken med vad som

står på råvarubehållarens etiketter, kan rätt råvara hämtas till rätt tillverkningsföreskrift.

Råvarubehållarna transporteras till produktionsrummet där ytterligare en kontroll utfördes av

operatören för att säkerställa etiketternas och tillverkningsföreskriftens samhörighet. Innan

produktionen startade kontrollerads skyddsutrustning av två operatörer som i sin tur krävde att

båda signerade tillverkningsföreskriften. När det var klart kontrollerades luftens temperatur

samt fuktighet vilket fördes in i tillverkningsföreskriften.

Detta görs för att kunna eliminera arbetsmiljön som felande länk ifall det skulle uppstå

problem med slutprodukten. Senast körda preparat samt det datumet som lokalen städades

fördes in i tillverkningsföreskriften. För att förbättra spårbarheten ifall något skulle gå fel förs

föregående preparats satsnummer in i tillverkningsföreskriften, detta för att kunna påvisa

vilka produkter som har varit i produktionslokalen ifall någonting skulle hända som t.ex. dålig

kvalitet eller att en kund har farit illa av preparatet. Informationen som förs in i

städningskolumnen varierar från preparat till preparat då vissa produkter kan köras i kampanj.

Kampanj innebär att samma preparat körs i större mängder där våtrengöring sker vanligtvis en

gång i veckan. Där emellan sker en torr rengöring efter varje avslutad sats.

När operatören skulle hälla i råvarorna i maskinen var han tvungen att leta upp en operatör för

att få en dubbelsignatur så att rätt råvara och mängd användes i processen.

När insatsningen var avklarad kontrollerades maskinens inställningar så att de stämde överens

med de angivna värdena i tillverkningsföreskriften även dessa inställningar krävde en

dubbelsignatur. Etiketterna på råvarubehållarna togs bort och fördes in i

tillverkningsföreskriften på den angivna sidan.

Under tiden råvaran blandades, vägdes den mängd preparat som står angiven i en tidigare

tillverkningsföreskrift. Kärlet för preparat stod på en våg som var ansluten till en terminal där

preparatnamn, satsnummer samt kodnummer var inprogrammerat. Information om kärlets tara

kunde även skrivas in för hand eller genom att tarera kärlet när det stod på vågen innan

vätskan hälldes i. I samband med att operatören vägde upp preparatet togs säven temperaturen

så att det stämmer överens med anvisningarna. Etiketten som skrevs ut i detta steg,

kontrollerades av två operatörer, som sedan klistrades fast på kärlet. Under tiden hade

torrblandningen av råvaran avslutats och insatsningen av preparatet kunde påbörjas. Efter ett

visst antal minuter avbröt operatören processen för att skrapa maskinens kanter.

De efterföljande stegen bestod av en upprepning av föregående steg med enda skillnaden på

sista som hade en hackare som kördes i ett visst antal sekunder. Efter att steget var avslutat

tömde operatören ut preparatet i en produktbehållare som stod tarerad på vågen och maskinen

skrapade ren. Innan detta skedde programmerades vågterminalen med rätt preparatnamn,

satsnummer och kodnummer. All information som fanns på den uttryckta etiketten skrevs in i

tillverkningsföreskriften där även minimigränserna och maxgränserna räknades ut. Tillsist

klistrades etiketten fas på produktbehållaren som transporterades ut ur produktionslokalen

vidare till nästa del av processen.

 

 

 

 

  

Bilaga C ‐ Intervjufrågor  Intervju 1 Fråga 1 Hur tycker du att arbetssättet fungerar idag?

Fråga 2 Vad anser du kan förbättras i processen?

Fråga 3 Hur hanteras avvikelser idag?

Fråga 4 Hur skulle man kunna minimera avvikelser?

Fråga 5 Vilken insyn skulle ni vilja ha i processen?

Fråga 6 Har du någon aning om hur resurskrävande granskiningen är idag?

Fråga 7 Vilka brister anser du att det finns idag?

Fråga 8 Vad anser du om dubbelsignaturer och elektroniska signaturer med

biometriska läsare?

Bilaga D ‐ Kravspecifikation  

Funktionella krav.

Inloggning

Prioritet Typ av

krav

För att få tillträde till systemet ska man logga in M F

Användarnamn och lösenord ska anges M F

Utloggning

Prioritet Typ av

krav

Utloggning sker efter 10 min inaktivitet M F

Utloggning sker när operatören ”kryssar” ner sidan eller genom

tryckning på utloggningsfunktionen.

M F

Operatör

Prioritet Typ av

krav

Ska kunna logga in. M F

Ska kunna välja preparat/tillverkningslinje M F

Ska kunna välja vilket delsteg i linjen som operatören ska jobba på. M F

Ska kunna mäta tryck och temperatur i tillverkningsrummet. M F

Ska kunna kontrollera och fylla i information i en loggbok för

respektive produkt och produktsteg

S F

Ska kunna signera de olika tillverkningsstegen med en elektronisk

signatur.

M F

Ska kunna skriva en kommentar om något inträffar under

produktionen.

M F

Ska kunna bjuda in en annan operatör i det aktuella

tillverkningssteget för dubbelsignering.

M F

Ska kunna fylla i den för tillfället gällande vätskemängden för den

produkt som för tillfället körs.

M F

Ska kunna föra in information om siktanalysen. M F

Ska kunna pausa i tillverkningsstegen. M F

Ska kunna kontakta systemadministratören om problem uppstår med

mjukvaran.

M F

QA

Prioritet Typ av

krav

Ska kunna se vad som sker i produktionen steg för steg M F

Ska kunna göra ändringar i själva tillverkningsföreskriften M F

Ska kunna skriva ett meddelande i det första fönstret operatören

kommer till efter inloggning.

M F

Hjälpfunktion Prioritet Typ av

krav

Det ska finnas en sektion om hur systemet fungerar M F

Systemadministratör

Prioritet Typ av

krav

Systemadministratören ska kunna lägga in nya operatörsprofiler M F

Systemadministratören ska kunna ta bort operatörsprofiler. M F

Systemadministratören ska kunna kontaktas. M F

Icke funktionella krav

Språk

Prioritet Typ av

krav

Systemet ska vara helt och hållet på svenska. M IF

Databas

Prioritet Typ av

krav

Systemet ska ha en effektiv databasstruktur så att en effektiv

sökalgoritm kan genomföras.

M IF

Backup ska ske kontinuerligt M IF

Säkerhet

Prioritet Typ av

krav

Informationen i systemet ska ha kryptering. M IF

Vid eventuell uppdatering av systemet bör detta ske natt mellan

söndag och måndag.

M IF

Medlemmarnas tillgång till systemet ska vara begränsad. M IF

Informationen som för in i systemet ska inte kunna ändras av varken

administratören eller någon annan på företaget.

M IF

Bilaga E ‐ Första skiss på prototyp version.1.0 

Bilaga F ‐ Andra utgåva av prototyp 1.1 

 

 

Bilaga G ‐ Tredje utgåvan av prototyp version 1.2 

Bilaga H ‐ Första sidan av prototyp 1.1 

Bilaga I ‐ Tillverkningsföreskrift över granuleringen 

  

Bilaga J ‐ Enkätunderlag för Prototyp V.1.1 

Enkätunderlag för Prototyp V.1.1 Denna enkät ingår i vårt examensarbete på kandidatnivå på Matematiska och systemtekniska

institutionen vid Växjö universitet. Syftet med enkäten är att utvärdera och utveckla systemet efter

användarnas krav och önskemål. Om du känner att det är någon fråga du inte kan besvara så

hoppa över den och gå vidare till nästa.

Alla som svarar kommer att förbli anonyma.

Markera det alternativ som du anser vara det som passar dig bäst och lämna gärna en kommentar

efter varje svar.

Tack för din medverkan!

Mvh. Giovanni.H, Emanuel. T och Andreas.T

1. Vad är ditt första intryck av prototypen

1. Mycket dålig

2. Dålig 3. Varken bra eller dålig

4. Bra 5. Mycket bra

� � � � �

1 7 1

Kommentar:

- Bra med inloggningsfunktion.

- Något otydligt med preparat flikarna vad de står för.

- Tycker även att meddelande rutan är otydlig.

2. Tycker du att prototypen uppfyller kontrollen av processen?

1. Mycket dålig

2. Dålig 3. Varken bra eller dålig

4. Bra 5. Mycket bra

� � � � �

8 1

Kommentar:

- Ja signeringen som bockas i efter varje steg plus en slutsignering när alla steg är

utförda ger en bra överblick och kontroll.

3. Tycker du att denna typ av lösning sparar tid?

1. Mycket dålig

2. Dålig 3. Varken bra eller dålig

4. Bra 5. Mycket bra

� � � � �

3 3 3

Kommentar:

- Man spar mycket med tid med denna lösning genom att klicka istället för skriva sin

signatur om och om igen.

- Slipper spring.

4. Löser denna typ av lösning problemet med dubbelsignering?

1. Mycket dålig

2. Dålig 3. Varken bra eller dålig

4. Bra 5. Mycket bra

� � � � �

3 6

Kommentar:

5. Hur fungerar struktur på layout och arbetsgången i prototypen?

1. Mycket dålig

2. Dålig 3. Varken bra eller dålig

4. Bra 5. Mycket bra

� � � �

6 3

Kommentar:

- Bra uppdelat av själva tillverkningsföreskriften, lätt att förstå och följa.

6. Hur användarvänlig är prototypen?

1. Mycket dålig

2. Dålig 3. Varken bra eller dålig

4. Bra 5. Mycket bra

� � � � �

1 1 3 4

Kommentar:

- Det är mycket klickande men jag föredrar det istället för att skriva signatur för hand.

- Svårt att se vilka som är rubriker.

- Man får fylla på (i) allt.

Bilaga K ‐ Sammanställning enkätfrågor  

Fråga: 1. Mycket dålig

2. Dålig

3. Varken bra eller dålig

4. Bra 5. Mycket bra

1 1 7 1

2 8 1

3 3 3 3

4 3 6

5 6 3

6 1 1 3 4

Totalt

helhetsintryck %

1 % 11 % 55 % 33 %

Bilaga L ‐ Mailintervju 

Namn:

Roll/titel:

Vad är dina erfarenheter av RUP?

Mest teoretiska.

Vad är dina erfarenheter av Prototyping?

Ganska omfattande.

På vilket sätt anser du att RUP och Prototyping kan kombinera och komplettera varandra?

Prototyping och RUP kan mycket väl kombineras. De principer och tekniska lösningar man är osäker på, kan lämpligen prototypas.

Jag antar att ni i frågan avser någon typ av stegvis implementering och inte prototyping! ?

Inom vilka ramar/projekt anser du att RUP och Prototyping är lämpliga metoder inom systemutveckling?

RUP är mest lämpat för utveckling av programvaruintensiva system. Prototyping kan användas för alla typer av system och även för tex. icke programmerbara system.

Hur ställer du dig till detta påstående: Prototyping klara sig utan RUP men RUP klara sig inte utan Prototyping?

Eftersom man vid prototyping kan använda vilken utvecklingsmetod som helst stämmer del ett.

RUP ställer väl inte krav på prototyping så del två är falsk.

Om ni avser att man i systemutveckling bör kombinera RUP (och även andra utvecklingsmetoder) med prototyping, så stämmer det.

Obs bör inte måste!

Har du några andra synpunkter eller något du vill tillägga?

Eftersom prototyping kan betyda många saker bör den prototyping som avses beskrivas.

På samma sätt är kanske inte RUP allom bekant.

Matematiska och systemtekniska institutionen SE-351 95 Växjö

Tel. +46 (0)470 70 80 00, fax +46 (0)470 840 04

http://www.vxu.se/msi/