Genomförbarhetsstudie

En genomförbarhetsstudie genomförs för att avgöra om ett informationssy-stem är möjligt att införa med de organisatoriska resurser och begränsningar som finns i verksamheten. För att bedöma denna möjlighet krävs en uppfatt-ning om informationssystemets tilltänkta funktionalitet, användbarhet och nytta (Beynon-Davies, 2009). En analys görs även av existerande system och dess krav samt eventuella problem med att uppnå dem. Ett eller flera alterna-tiva förslag tas fram där en rekommenderad lösning föreslås med en funkt-ionell beskrivning (Avison & Fitzgerald, 2006).

2 Traditionell systemutvecklingsprocess även kallad vattenfallsmodellen. Innehåller faser för genomförbarhetsstudie, systemanalys, systemdesign, implementering, utvärdering och un-derhåll.

Pigni et al (2006) belyser åtta viktiga steg för en lyckad genomförbarhets-studie:

1. Formation av projektgrupp. Ett utav de första stegen i nästan alla pro-jekt är att utse propro-jektgruppens medlemmar.

2. Kontext-analys. Därefter kan projektgruppen studera projektets kon-text för att fastslå om den är intra-organisatorisk eller inter-organisa-torisk. Intressenter och deras påverkan på projektet identifieras och dokumenteras.

3. Målformulering. En RFID-implementation kan ha en stor påverkan på en leveranskedja. Därför är det viktigt att dokumentera projektets mål. Sänkta kostnader, ökad innovation, förbättrad kvalitet, säkerhet och servicenivå är exempel på mål som skall dokumenteras och i de fall det behövs även prioriteras.

4. Hindersprövning. Nya tekniska tillämpningar kan ha teknisk, social och ekonomisk påverkan (Battezzatti & Hygounet, 2003). Dessa kan ha påverkan på projektet och måste därför dokumenteras och finnas med i åtanke vid ett teknikval.

5. Processanalys som går ut på att modellera hela leveranskedjan, både hur den ser ut före och efter en förmodad implementation.

6. Teknikval. Modelleringen av verksamheten antyder vilken teknologi som är bäst lämpad för införande. Här väljs all teknologi som skall användas inom leveranskedjan. Det kan exempelvis vara RFID-tag-gar, läsare och skrivare, antenner, servrar, pc-klienter, dataanslut-ningar, operativsystem, databaser, informationssystem.

7. Kostnads/nytto-analys är ett fundamentalt steg eftersom det kan vara avgörande om projektet skall verkställas eller ej. Både ekonomiska och icke-ekonomiska aspekter måste beaktas från alla parter. Fördelar jämförs gentemot kostnader och beroende på leveranskedjans omfatt-ning kan detta steg bli väldigt tidskrävande och omfattande eftersom varje aktörs förutsättningar måste beaktas.

8. Slutgiltiga påpekanden. Efter kostnads- och fördelsanalysen bör man gå igenom all data som framställts och bedöma risker och kritiska element. Detta för att slutligen bestämma om projektets fortlevnad.

De fyra första stegen ger en bra översikt på leveranskedjan och dess gränser. Processanalys fokuserar på leveranskedjans nuvarande processer och hur det skulle se ut efter en implementation. Efter detta följer en teknologisk utvärde-ring. Steg sju och åtta resulterar i en utvärdering för projektets påverkan. Hu-vudsyftet med genomförbarhetsstudien är enligt Pigni et al (2006) att verifi-era genomförbarheten för att fatta ett beslut om projektet skall genomföras.

4.3.2 Kravanalys

Arlow & Neustadt (2009) menar att kravhantering utförs i början av ett pro-jekt för att ge en bild av vad propro-jektet ska uppnå. Syftet är att upptäcka och besluta om vad systemet skall göra, uttryckt i en övergripande kravspecifi-kation. Detta bekräftas även av Beynon-Davies (2009) som menar att denna fas innehåller tre sammanhängande aktiviteter:

 Definition av krav på systemet från intressentgrupper

 Analys av krav som innebär förhandling och beslut om viktiga krav

med olika intressenter

 Kravspecifikation som innebär en representation av krav

Information samlas in genom dels genom intervjuer med intressenter (som exempelvis ledning och operativ personal), direkta observationer och genom att söka information inom användningsområdet (Avison & Fitzgerald, 2006). Arlow & Neustadt (2009) menar att en kravspecifikation är en specifikation över vad som skall införas. Det finns två typer av krav: funktionella krav som beskriver vad systemet ska erbjuda och icke-funktionella krav som definierar systemets egenskaper eller begränsningar. Kraven bör för att vara tydliga och senare kunna identifieras anges med enkelt format som innehåller ett unikt nummer, nyckelordet ”ska” och en redogörelse för en funktion.

Kraven skall sedan ges en prioritet relativt till alla andra krav. Ett vanligt sy-stem för tilldelning av prioritet är genom kriterier för MoSCoW, där värdena M (Must have), S (Should have), C (Could have) och W (Want to have) defi-nierar prioritet enligt tabell 3.2 (Arlow & Neustadt 2009).

Prioritet Beskrivning

Must have Tvingande krav som är grundläggande för systemet

Should have Viktiga krav som kan utelämnas

Could have Krav som är frivilliga (förverkliga om tid finns)

Want to have Krav som kan vänta till senare releaser

Tabell 4.2, Beskrivning av prioritering genom MoSCoW enligt Arlow & Neustadt (2009)

Arlow & Neustadt (2009) förespråkar användning av användarfall (Use Case) som en del i kravhantering för att komplettera och förtydliga kraven. Pigni et al (2006) menar att denna typ av notation används för att modellera vad ett system ska göra, snarare än hur det ska göras. Användarfall är nära besläk-tade med scenarier. Ett scenario är ett exempel på vad som händer när någon interagerar med systemet. Användarfall är funktioner som systemet utför på uppdrag av, och för att leverera nytta för särskilda aktörer. Beynon-Davies (2009) menar att en aktör kan vara en person, organisation eller annat system som interagerar med systemet. Användarfall beskriver systemets beteende

och tas fram genom att betrakta hur varje aktör samverkar med systemet (Ar-low & Neustadt 2009).

Ett användarfallsdiagram är enligt Pigni et al (2006) en bild av aktörer, an-vändarfall och relationer dem emellan. Det ger en överblick av systemet, vad som finns utanför det och den funktionalitet systemet ska tillhandahålla.

Figur 4.2, Användarfallsdiagram exempel enligt Arlow & Neustadt (2009)

En användarfallsspecifikation är en detaljerad vy över det tidigare användar-fallsdiagrammet. Arlow & Neustadt (2009) förespråkar en enkel och effektiv standard skriven på ett strukturerat språk enligt tabellen nedan.

Namn: Ett beskrivande namn för användarfallet

ID: Unikt nummer för identifiering och sammankoppling i diagram Kort beskrivning: Summerar användarfallets mål och den affärsnytta

som levereras till dess aktörer.

Primära aktörer: De aktörer som utlöser användarfallet

Sekundära aktörer: De aktörer som interagerar med användafallet

efter det har utlösts

Förutsättningar: Förutsättningar för systemet som måste vara

upp-fyllda innan användarfallet startar.

Huvudflöde: Stegen i ett användarfall listas i ett flöde av händelser

som utförs. Nyckelordet OM används för avvikelser från flödet.

Resultat: Det tillstånd systemet har efter att användarfallet genomförts. Alternativt flöde: Alternativt flöde som kan fånga upp fel, avbrott eller

alternativa vägar för huvudflödet.

4.3.3 Systemdesign

Traditionellt sätt innebär konstruktion av en programvara tre relaterade pro-cesser, programmering, testning och dokumentation. Dessa aktiviteter varie-rar beroende på om utvecklingen är baserad på ett köpt programvarupaket eller är skräddarsydd. Konstruktion med ett programvarupaket innebär att färdiga mjukvarukomponenter används för att bygga hela eller delar av ett informationssystem. Enligt Beynon-Davies (2009) består konstruktion av informationssystem av fyra lager:

1. Användargränssnitt genom att konstruera inmatningsformulär, me-nyer och rapporter.

2. Struktur och applikationslogik genom att ange integritetsbegräns-ningar och element för bearbetning.

3. Transaktionslagret som behandlar funktioner för uppdatering i syste-met

4. Datahanteringslagret som skapar datastrukturer för att lagra informat-ion.

Då det i denna studie endast handlar om anpassning av befintlig programvara för handdator och läsare tillsammans med förberedande anpassning av före-tagets affärssystem för att kunna ta emot information presenteras här endast en övergripande del av systemutveckling som behandlar design av användar-gränssnitt och databasstruktur.

Design av systemet innebär dels design av de automatiserade delarna av sy-stemet, såväl som de manuella (Avison & Fitzgerald, 2006). Denna fas till-handahåller en systemspecifikation som fungerar som ett utkast till kon-struktionen av systemet (Beynon-Davies 2009) och innehåller information om:

 Input och output till systemet i form av information, och hur den

sam-las in

 Processer som konverterar input till output

 Struktur över data

 Säkerhetsaspekter

 Plan för test och implementering (Avison & Fitzgerald, 2006).

Vid design av ett användargränssnitt bör användare definieras tillsammans med de uppgifter de ska utföra. Beynon-Davies (2009) menar att ett använ-dargränssnitts kvalitet kan mätas i termer för hur enkelt det är att lära, hur enkelt det är att minnas utförda aktiviteter och hur effektivt det är att an-vända. Det ska dessutom hindra användaren från att göra fel och tillfreds-ställa användaren i den meningen att den lämnar dem subjektivt nöjda med att använda det. För att uppnå denna kvalitet bör en meningsfull terminologi

som användaren är förtrogen med användas tillsammans med en konsekvent design av valmöjligheter. Användaren bör även ges återkoppling för de val han gör.

Den kravspecifikation som tidigare gjorts utifrån intressenters krav beskriver de data som ska samlas in och behandlas i informationssystemet. Det bör även klargöras hur data ska användas och lagras i en databas. Anpassningar som görs till en ny eller befintlig databas bör dokumenteras genom en design av databasen (Connolly & Begg, 2009). En av de största svårigheterna med design av databaser är att utvecklare och intressenter tenderar att tolka data på olika sätt. För att uppnå en precis förståelse av vilken typ av data som an-vänds och hur den anan-vänds behövs en modell för kommunikation som är icke-teknisk och fri från tvetydigheter. Connolly & Begg (2009) förespråkar ett ER-diagram (Entity-Relationship) med UML-notation. De finns flera olika typer av notationer som används för ER-diagram även om det finns en allmän enighet om vad varje koncept betyder. ER-diagram identifierar viktig data kallad entiteter och samband dem emellan. Därtill adderas detaljer kring vilka egenskaper och begränsningar entiteterna har. En entitet kan även beskrivas som en grupp av objekt som existerar i ”verkligheten” med samma egen-skaper. Samband beskrivs genom verb och kan vara av tre olika typer:

 Ett-till-ett-samband (1:1) där en entitet av ett slag kan höra ihop med

en entitet av ett annat slag.

 Ett-till-många-samband där en entitet av ett slag kan höra ihop med

flera entiteter av ett annat slag.

 Många-till-många-samband där en entitet kan höra ihop med flera

en-titeter av ett annat slag åt båda håll (Connolly & Begg, 2009) .

Fredholm (2006) menar att en viktig del av en RFID-lösning är att företagets affärssystem kan ta emot, bearbeta och skicka vidare informationen som kommer från taggen. Det kan därför behövas en del anpassningsarbete för att en integration till företagets affärssystem ska vara möjlig.

4.3.4 Test

I processen för framtagning av ett informationssystem bör olika tester ge-nomföras för att säkerställa att det fungerar på ett effektivt och förväntat sätt. Tester kan göras på hela systemet som en enhet, eller efter integration med andra system. Tester utförs normalt i sekvens och några tester kan även utfö-ras under implementeringsfasen (Beynon-Davies 2009). Det finns ett antal olika tester som kan utföras innan ett system tas i bruk:

 Systemtest innebär test på systemet som helhet för att utvärdera syste-mets enlighet med de specificerade kraven.

 Integrationstest testar de olika modulerna tillsammans för att

expo-nera fel i gränssnittet och i samspelet mellan integrerade komponen-ter.

 Enhetstest innebär att varje komponent testas individuellt för att

sä-kerställa att de fungerar korrekt som en enhet

Pignt et al (2006) föreslår att testning av teknikval ska genomföras tidigt i projektet genom fältstudier för att utvärdera tekniken i dess rätta miljö.

För att kvalitetssäkra och inte spendera onödiga summor pengar på att åter-kalla produkter förespråkar både Pigni et al (2006) och Cadle & Yeates (2008) testning utav en del av helheten. För bästa effekt rekommenderas test-ning av de antagna och förväntade resultaten som gjordes under genomför-barhetsstudien. Testningen bör ske i en mindre skala än hela leveranskedjan. Vilket ger en bättre förståelse för helheten och kan på så sätt användas för att stärka genomförbarhetsstudien. Ett exempel på detta är om det skall hantera flera produkter, då kan man genomföra testningen på en utvald produkt. Detta kan då användas för att finjustera utrustningen i ”verkligheten”. Även om RFID-taggar och läsare hela tiden blir bättre, så kan omgivande faktorer på-verka taggens läsbarhet (Pigni et al, 2006).

4.3.5 Implementering

När systemet konstruerats följer en systemimplementering, eller systemle-verans, vilken involverar leverans av informationssystemet till den omgiv-ning där det ska användas. Systemimplementering innehåller två delar, en teknisk systemimplementering och en social systemimplementering.

Teknisk systemimplementering involverar förvärv och installation av mjuk-vara såsom operativsystem, databashanterare och applikation, samt hårdmjuk-vara såsom datorer eller andra typer av enheter och nätverk. Om systemet ska er-sätta ett tidigare system krävs även en dataöverföring av den information som finns lagrat i systemet. Även testning bör förekomma i detta skede för att ge acceptans åt den nivå av prestanda som systemet tillhandahåller. Social systemimplementering innebär att rätt användare är identifierade, utbildade och får stöd i användandet av den nya teknologin. Även här återfinns testning i form av acceptanstester. Support och utbildning av användare kan utföras av utvecklare av systemet eller med hjälp av handledning genom en manual (Beynon-Davies, 2009).

Beynon-Davies (2009) menar att systemimplementering kan utföras på tre skilda sätt. Genom direkt konvertering, parallell implementering eller med hybrid implementering.

Direkt konvertering innebär att det nya systemet direkt ersätter det gamla systemet, utan överlappning. Det kan gälla ett datoriserat system eller ett sy-stem av mänskliga aktiviteter som blir ersatt av ett nytt.

Parallell implementering innebär istället ett mer försiktigt tillvägagångssätt där de både det gamla informationssystemet och det nya körs parallellt under en period. Detta underlättar mottagandet och lindrar eventuella inkörnings-problem med det nya systemet som efter en tid beslutas att fullt ut ersätta det gamla.

Hybridimplementering karaktäriseras av att speciella moduler eller kompo-nenter stegvis introduceras i systemet och ersätter gamla moduler. Detta in-nebär att effekterna av implementeringen blir ”mjukare” då de fördelas mer jämt över tid (Beynon-Davies, 2009).

Avison & Fitzgerald (2002) föreslår att en utvärdering bör göras som ett sista steg i systemutvecklingsprocessen då systemet är i drift. Syftet är att under-söka om det uppfyller de antagna kraven från kravanalysen och att den förut-sagda kostnaden inte har överstigits. Utvärdering av systemet kan i sin tur leda till förändringar och vidareutveckling av systemet.