RUP och UML som process

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 assurance² (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

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.