Ytterligare ett nytt IT-system
Magnus Wigrup
Förord
Denna C-uppsats är det sista momentet jag utför i min utbildning Produktionsledare – Media på Malmö högskola. Det har varit en lärorik tid, framförallt under arbetet med C-uppsatsen där man för det första har höjt nivån på både lärande och slutprodukt och för det andra fått en inblick i arbetslivet då mycket av tiden har spenderats hos tryckerikoncernen JMS.
Jag vill även passa på och tacka samtliga personer som varit delaktiga i projektet: personalen på JMS som varit mycket tillmötesgående och hjälpsamma, min handledare Paul Lindström som har hjälpt mig och kommit med tips, Henriette Lucander och Asta Cepaite som hjälpt till med feedback på arbetet och sist men inte minst min samarbetspartner och numera kollega, Johannes Karlsson som jag har drivit projektet tillsammans med. Arbetet hade inte varit vad det blev utan er, så tack!
Sammandrag
Denna rapport avser att undersöka för- och nackdelar med att utveckla ett för ändamålet
specialanpassat system eller utnyttja de standardsystem, som i det aktuella fallet tryckerikoncernen JMS redan äger och använder. Genom en mer noggrann definiering av ickefunktionella krav på bland annat användbarhet har en specialanpassad prototyp framställts. I projektet användes metoder för kravinsamling som ledde till en kravspecifikation och i sin tur slutade med en färdig prototyp. Prototypen jämfördes med två standardsystem genom användartester och intervjuer. Prototypen visade sig leva upp till de krav som upptäcktes. Majoriteten av testpersonerna föredrog ett enklare avskalat system, vilket prototypen upplevdes som, före system med mycket information och funktioner. Med tanke på kostnaden rekommenderas dock JMS att försöka strukturera upp ett av de i företaget befintliga systemen och använda detta istället för att utveckla och implementera
ytterligare ett nytt system i företaget.
Nyckelord
Systemutveckling, kravspecifikation, kravhantering, kravinsamling, prototyp, användbarhet, användartest
Abstract
One more IT-system
This report intends to explore the pros and cons of developing a customized system or use the standard system, which in this case printing JMS Group already owns and uses. With a more accurate definition of non-functional requirements such as usability, has a custom-made prototype been built. The project used methods of requirements gathering that led to a specification and ended with a finished prototype. The prototype was compared with two standard systems through user testing and interviews. The prototype proved to live up to the requirements discovered. The majority of test subjects preferred a simpler clean system, which the prototype was, to systems with a lot of information and functions. Given the cost JMS was recommended to structure one of the systems that they already owns and uses instead of developing and implementing a new system further in the company.
Keywords
System development, specifications, requirements, requirements management, requirements gathering, prototype, usability, usability testing
Innehållsförteckning
1Inledning... 7
1.1
Syfte... 7
1.2
Avgränsningar ... 8
1.3
Målgrupp ... 8
1.4
Disposition... 9
2
Metod... 10
2.1
Iterativt arbete... 10
2.2
Intervjuer ... 10
2.2.1
Ostrukturerad intervju... 11
2.2.2
Strukturerad intervju ... 12
2.3
Verklighetsbeskrivning ... 12
2.3.1
Processbeskrivning ... 13
2.4
Workshops... 13
2.5
Prototyputveckling ... 14
2.6
Användartester... 14
2.6.1
Tänka högt-test ... 15
3
Teoretisk bakgrund... 16
3.1
Systemets intressenter ... 16
3.2
Användarfokus ... 16
3.3
Olika typer av krav ... 17
3.3.1
Funktionella krav ... 17
3.3.2
Ickefunktionella krav ... 17
3.3.3
Restriktioner i designen ... 19
3.3.4
Andra typer av kategorisering... 19
3.3.5
Normala krav ... 19
3.3.6
Förväntade krav ... 19
3.3.7
Sensationella krav ... 19
3.4
Att inte missa några krav... 20
3.5
Prioritera rätt... 20
3.5.1
Riskbedömning ... 20
3.5.2
Rangordning av krav... 21
3.6
Utvecklande av prototyper ... 21
4.1
JMS Mediasystem AB... 23
4.2
Vad ska systemet kunna göra? ... 23
4.2.1
Verklighetsbeskrivning genom ostrukturerade intervjuer ... 24
4.2.2
Ett drömsystem ... 26
4.2.3
Prototyputveckling med iterativt arbete och användartester... 26
4.2.4
ITIS mot Hogia PA och Microsoft Share Point... 29
5
Resultat ... 30
5.1
Jämförande användartest ... 30
5.1.1
Observationsresultat... 30
5.1.2
Intervjuresultat ... 31
6
Diskussion ... 33
6.1
Förarbete inför att utveckla ett nytt sytem... 33
6.1.1
Krav på användbarhet ... 34
6.2
Användbart eller många funktioner... 34
6.3
Vilket system lämpar sig för JMS? ... 35
7
Slutsatser ... 37
8
Referenslista ... 38
8.1
Litteratur... 38
8.2
Artiklar ... 39
8.3
Internetreferenser... 39
9
Bilagor ... 40
9.1
Bilaga 1... 41
9.2
Bilaga 2... 42
1 Inledning
Denna studie har gjorts i samband med ett projekt som genomförts på tryckerikoncernen JMS. Syftet med projektet var att få ökad kontroll över den IT-utrustning som finns inom företaget. Inför projektets start hade IT-ansvarige ingen vetskap om vilken utrustning som fanns på de olika anläggningarna och kontoren. Han efterlyste därför ett inventariesystem där man kan registrera utrustning och knyta denna till personer så att samtlig utrustning får en ansvarande. Detta ledde till starten av projektet som valdes att kallas ITIS (förkortning av IT-InventarieSystem).
Enligt en rapport av Exido (Edenström, 2009) misslyckas över 72 % av alla IT-projekt i Sverige under år 2008 och 2009. Eriksson (2007) påstår att av de IT-projekt som anses som misslyckade beror misslyckandet på bristande krav i 56 % av fallen och 27 % på brister i designen. Syftet med denna studie är dels att göra ett noggrant förarbete och utveckla en prototyp och dels att studera de system som redan används i företaget JMS för att se om dessa kan utnyttjas till att lösa samma problem. Om så stor andel av IT-projekt misslyckas, hur kan man undvika detta och kan man utnyttja de lyckade projekten till något mer än vad de var avsedda för från början?
Problemet på JMS var brist på tid och man hade ingen möjlighet att på IT-avdelningen utveckla eller ta fram krav för ett inventariesystem på egen hand. På grund av denna tidsbrist hade IT-ansvarig inte hunnit reflektera över vilka alternativ det fanns, vilka befintliga system som kan tänkas fungera som inventariesystem och vad det var de verkligen behövde på företaget. För att inte ITIS skulle bli ytterligare ett misslyckat IT-projekt beslutades det att endast ett noggrant förarbete skulle genomföras och att en prototyp skulle tas fram så att denne kunde jämföras med alternativa system.
1.1 Syfte
I samband med att IT-ansvarig på tryckerikoncernen JMS efterfrågade ett informationssystem för att få bättre kontroll över företagets IT-utrustning och licenser, påbörjades denna studie som undersöker huruvida det ur slutanvändarnas synvinkel är lämpligt att köpa in ytterligare ett system eller att försöka utnyttja något av de system som redan finns i företaget. För att komma fram till detta måste en kravspecifikation tas fram och det är ofta denna som orsakar misslyckande i IT-projekt (Edenström, 2009).
Ovan nämnda bakgrund ledde till följande forskningsfrågor:
• Fungerar prototypframställning och användartester för att samla in användbarhetskrav?
• Hur prioriterar slutanvändarna god användbarhet mot flera funktioner? • Föredrar slutanvändarna att arbeta med flera avskalade och mindre komplexa
informationssystem eller ett större, mer komplext och med många funktioner som fungerar på samtliga avdelningar?
• Vilket lämpar sig bäst för verksamheten i allmänhet, många för ändamålet anpassade system eller ett universalsystem?
I studien följs ITIS-projektet från första steg då beställaren gör en beställning, tills det att en färdigutvecklad prototyp framställs. Ofta är kraven på användbarhet vagt formulerade i IT-systembeställningar och studien ska även försöka undersöka varför det är så och hur man lättare kan ställa mer konkreta krav inom detta område.
1.2 Avgränsningar
ITIS-projektet avgränsades till att göra förarbetet inför implementeringen/utvecklingen av ett system. Att förädla den prototyp alternativt implementera ett nytt system innebar för mycket arbete och detta klargjordes i inledningen för beställaren, IT-ansvarig på JMS.
Projektet avgränsades till att innefatta IT-utrustning, programlicenser, systembehörigheter, lokalbehörigheter och övriga artiklar som kreditkort, firmabilar med mera. Det beslöts att lämna tryckpressutrustning utanför eftersom leverantörerna till denna redan tillhandahåller fungerande system för att ha kontroll över vad företaget äger, använder och när service behöver utföras.
1.3 Målgrupp
Denna studie riktar sig mot studenter och lärare på institutionen Medieteknik på Malmö Högskola, IT-, ekonomi- och personalansvariga på JMS och systemutvecklare som kan tänkas vara lämpliga för att förädla den prototyp som tagits fram.
1.4 Disposition
Denna rapport består av sju olika delar. Första delen, inledningen, innehåller bakgrund till arbetet, problemdefinition som sedan följs upp med en metoddel där de metoder och tillvägagångssätt som använts i studien beskrivs, motiveras och diskuteras. I den tredje delen presenteras befintliga teorier kring kravhantering och prototypframställning. Därefter kommer empiridelen där företaget JMS beskrivs och genomförandet av projektet presenteras. Resultatet av studien presenteras i femte delen och en diskussion som grundas på samtligt material ur rapporten finns i sjätte delen. Sist i rapporten presenteras de slutsatser som har kunnat dras utifrån studien.
2 Metod
De metoder som beskrivs nedan har egenskaper och styrkor som lämpat sig för denna studie och beskrivningen av dessa egenskaper är således också motiveringen till varför de använts. Samtliga metoder har tillämpats antingen enskilt eller i kombination med varandra.
2.1 Iterativt arbete
Genom att arbeta iterativt i systemutveckling gör man först en övergripande skiss på de
huvudfunktioner som systemet ska kunna utföra. Därefter förfinar man skisserna och samlar in nya krav för att så småningom implementera dessa i systemet eller i en prototyp. Arbetet sker således i cykler där slutprodukten förbättras och får fler funktioner och förändringar i varje iteration. (Eriksson 2007, s. 31)
I utvecklandet av ett nytt system lämpar sig ett evolutionärt iterationsarbete där prototyper tas fram för att ta reda på vad kunden vill ha och behöver, vilken teknik som behöver användas och vilken struktur systemet ska ha. (Lunell 2003, s. 122-123)
Denna metod valdes för att lättare kunna hantera förändringar och förbättringar under
utvecklandets gång. Genom att arbeta iterativt kan de nya kraven tillgodoses efterhand som de upptäcks. Att arbeta iterativt valdes istället för till exempel vattenfallsmodellen, där man arbetar med olika steg eller milstolpar. När ett steg har tagits går man vidare till nästa steg i motsats till att arbeta iterativt där man istället hela tiden går tillbaka och förbättrar samtidigt som man går framåt i utvecklandet (Lunell 2003, s.61). Eftersom det i ITIS skulle arbetas med prototyper och
användartester lämpade sig en iterativ arbetsform.
2.2 Intervjuer
En intervju är ett samtal mellan två personer (i vissa fall fler) i syfte att intervjuaren ska samla information som respondenten, det vill säga den som blir intervjuad, sitter inne med. (Ely m.fl. 1993, s. 66)
När der gäller att ta reda på åsikter och tyckande hos en samling människor är intervju en lämplig metodik. Det vanligaste tillvägagångssättet vid en intervju är att man frågar ut endast en respondent i taget, på detta sätt påverkas inte respondenten av andras närvaro och svar. (Ejvegård 2003, s. 47)
I en intervju är det inte bara orden i svaret som berättar vad respondenten tycker utan även kroppsspråk, tonfall och pauser förstärker och tydliggör svaren. Därför är en intervju mer flexibel än till exempel en enkät och respondenten har större möjlighet att motivera sina svar. (Bell 2000, s. 119)
Det finns några problem med intervjuer, till exempel är de tidskrävande. Både förarbetet och genomförandet och efterarbetet tar sin tid. Svaren kan också vara svårtolkade i vissa fall och tekniken är subjektiv vilket kan innebära skevheter i resultatet där intervjuaren tolkat svaren på sitt sätt. (Bell 2000, s. 119)
Om respondenten tillåter underlättar det att spela in intervjuer så att intervjuaren kan fokusera fullständigt på att ställa frågor och skriva ner hela intervjun i efterhand. Att anteckna under intervjun istället kan hämma respondenten och denne svarar kanske därför inte helt ärligt. Det kan dessutom bli svårt för intervjuaren att hinna anteckna vilket kan leda till mycket dödtid där respondenten väntar på nästa fråga. (Ejvegård 2003, s. 50)
2.2.1 Ostrukturerad intervju
En ostrukturerad intervju innebär att man inte har planerat och strukturerat upp intervjun i den utsträckning som vid en strukturerad intervju (se nedan). Istället är den ett samtal och diskussion mellan intervjuaren och respondenten i syfte att få en djupare inblick i hur respondenten upplever saker och få fram information som respondenten inte är helt medveten om från början. (Ely m.fl. 1993, s. 65-66)
Helt oförberedd och ostrukturerad bör dock inte denna typ av intervju vara. Förberedelser måste göras även här för att få igång intervjun men den är ostrukturerad i den bemärkelsen att strukturen formas under intervjuprocessen. (Ely m.fl. 1993 s. 66)
Ostrukturerade intervjuer ställer krav på intervjuarens förmåga att hålla intervjun till ämnet eftersom den annars blir onödigt tidskrävande och svårare att sammanställa. Därför bör intervjun styras så pass mycket att materialet blir relevant för undersökningen. (Eriksson 2007, s. 80) De ostrukturerade intervjuerna valdes för att få enskilda personers bild av problem och hur verkligheten såg ut i företaget enligt dessa. Metoden tillåter även att samtalet kan ta nya vägar genom följdfrågor och intervjun blir inte låst vid samma spår som strukturerade intervjuer. Eftersom det endast var två personer som var aktuella för dessa intervjuer fanns det tid och möjlighet att använda sig av ostrukturerade intervjuer. Frågorna som behandlades var hur
anställningsprocessen och inköpsprocessen av ny IT-utrustning gick till. Eftersom intervjuarna inte hade någon aning om hur dessa processer såg ut var det lämpligt att använda just ostrukturerad intervju så att följdfrågorna anpassades efter varje tidigare svar. De personer som deltog i dessa intervjuer var de som hade huvudansvaret för respektive process, det vill säga IT-ansvarig och personalansvarig.
2.2.2 Strukturerad intervju
En standardiserad och strukturerad intervju underlättar sammanställningen av svaren och den kan jämföras med en enkät. Denna typ av metod är lämplig när man ska intervjua flera personer för att upptäcka trender eller flera personers sammanställda åsikter. (Bell 2000, s. 121)
Vid strukturerade intervjuer bör frågorna vara likadant ställda till samtliga personer för att inte förutsättningarna ska skilja sig intervjuerna emellan. Därför ska intervjun vara väl förberedd och alla frågor klara och nedskrivna. Vid svårtolkade svar är det dock bra att ställa oplanerade följdfrågor så att inga feltolkningar görs vid sammanställningen av intervjun, intervjuaren bör säkerställa sig om vad det är respondenten menar. (Befring 1992, s. 68)
De strukturerade intervjuerna genomfördes för att få jämförbara svar på ett flertal personer. Svaren blir lättare att jämföra eftersom samtliga personer får samma frågor men svaren blir betydligt mer uttömmande än vid till exempel en enkät. Respondenterna i de strukturerade intervjuerna skulle bli högst 10 stycken. Ifall fler personer skulle ha deltagit i undersökningen, hade en enkät lämpat sig bättre för att effektivare kunna hantera den information som skulle samlas in. Metoden användes i samband med de användartester som genomfördes i studien för att få konkreta åsikter på vissa specifika delar och funktioner i systemen. Respondenterna till dessa intervjuer skulle arbeta med något system i vardagen och ha god datorvana samt ha utfört ovan nämnda användartester.
2.3 Verklighetsbeskrivning
En verklighetsbeskrivning i samband med systemutveckling görs för att systemutvecklarna ska vara medvetna om de problem som systemet förväntas lösa. Kunskap om situationen och verkligheten i den verksamhet som systemet ska utvecklas i, kan också vara till hjälp för att hitta lösningar på problemen. (Andersen 1994 s. 53)
Risken med beskrivningar är att de alltid har tolkats av den som gör beskrivningen och därför kan skilja sig från hur någon annans verklighet ser ut eller hur det är i själva verket. När
verklighetsbeskrivningar ska göras är det därför viktigt att vara källkritisk och helst inte förlita sig till en enda källa. (Andersen 1994 s. 50)
Denna metod användes för att dels få en överblick över företaget i sin helhet men även över de processer som skulle beröras av implementeringen av ett inventariesystem.
Verklighetsbeskrivningen är enligt Andersen (1994) ett obligatoriskt moment i förarbetet för ett systemutvecklingsprojekt.
2.3.1 Processbeskrivning
Att beskriva processer är en viktig del av verklighetsbeskrivningen och syftet är att beskriva hur det verkligen är och inte hur man önskar att det var. Görs inte detta framgår inte problem, flaskhalsar, onödiga moment, förbättringspunkter med mera. (Dicander Alexandersson m.fl. 2007, s.57-58) Att beskriva processer kan göras genom processkartor. I dessa används ett antal symboler som representerar aktörer, händelser, flöden med mera i processen. (Hoyle & Thompson 2003, s. 86)
Figur 1. De mest grundläggande symboler som används i processkartor visas här ovan. Ovalen
symboliserar infall från till exempel en beställare, leverantör eller process. De olika
symbolerna sammanbinds med pilar som förklarar flödesriktning. (Hoyle & Thompson 2003, s. 86)
2.4 Workshops
En av de vanligaste metoderna för kravinsamling är att arrangera workshops. Detta innebär att man samlar de intressenter som är aktuella för att tillsammans eller enskilt komma fram till vad det är man efterfrågar av systemet. (Eriksson 2007, s. 67)
Det finns många verktyg och metoder för att leda en lyckad workshop men det viktigaste är att alla deltagare är aktiva och får fram sina åsikter (Lafayette 2008). Till exempel kan man använda sig av rollspel, negativ idégenerering, drömscenarion och mindmapping för att få fram kreativa idéer under en workshop (Eriksson 2007, s.72-73).
Workshops tillämpades för att deltagarna skulle få en ny syn på problem och även upptäcka nya problem som de inte från början var medvetna om. Enligt Eriksson (2007) är detta en metod som lämpar sig vid utvecklande av skräddarsydda system, vilket var fallet med ITIS.
2.5 Prototyputveckling
Prototyputveckling är ett användbart redskap inom systemutveckling. System ska byggas för slutanvändaren, inte för systemutvecklaren eller beställaren, och med hjälp av en prototyp kan man enkelt testa, förbättra och testa igen, direkt på slutanvändaren. (Lin m.fl. 2005)
När man utvecklar prototyper försöker man efterlikna slutprodukten på de punkter som man vill testa men med enklaste och billigaste medel för att hålla kostnader och arbetstid nere. (Andersen 1994, s. 405)
I en förenklad version av slutprodukten är det lättare och billigare att göra ändringar. På så sätt är det möjligt att testa prototypen på slutanvändaren och göra de förändringar som krävs och därefter testa igen. (Lin m.fl. 2005)
Tillämpandet av prototyputveckling valdes för att på ett effektivt sätt kunna testa systemets design och simulerade funktioner på slutanvändarna utan några större kostnader i tid och pengar.
Slutanvändarna får också möjlighet att delta i utvecklandet genom att ge synpunkter på de prototyper som testas.
2.6 Användartester
Användartester utförs främst för att få konkreta bevis på beteende och agerande i realistiska situationer och inte för att ta reda på vad användaren tycker och anser. Testerna är nödvändiga eftersom användaren sällan kommer och berättar om problem och konstigheter av sig själv. (Molich 2000, s. 149)
Genom att låta utvecklandet ske med hjälp av användartester kan systemutvecklarna hitta de punkter och brister som ofta leder till frustration hos användarna. Handlar det om ett kommersiellt system, till exempel en webbshop, kan frustration leda till förlorade kunder. Är det ett internt informationssystem kan det leda till frustration hos de anställda och följden av detta kan bli sänkt arbetsmoral och dålig stämning. Vikten av god användbarhet är därför viktig i företag där
informationssystem används frekvent och för att uppnå detta måste slutanvändaren integreras i systemutvecklingen bland annat genom användartester. (Chisnell m.fl. 2008, s. 21-22)
När man tar fram underlaget för en användartest är det viktigt att uppgifterna är realistiska och typiska för arbetet som kommer att ske i systemet. Uppgifterna ska utgå från användaren och inte systemet och man bör därför inte titta på systemet när man utformar uppgifterna. (Molich 2000, s. 159)
Att genomföra användartester valdes för att kunna förbättra och anpassa prototyper ytterligare efter användaren. Eriksson (2007) menar att man omöjligt kan samla in alla krav på en gång. Genom användartester kan slutanvändaren ge medveten och omedveten feedback till utvecklarna.
2.6.1 ”Tänka högt”-test
En form av användartest är ett så kallat ”tänka högt”-test. Här får testpersonen (som bör vara en slutanvändare) ett antal uppgifter att lösa av en testledare. Under tiden som testpersonen löser uppgifterna ska denne hela tiden berätta hur den tänker och resonerar. Testet dokumenteras antingen genom filmning eller genom att anteckna direkt. Genom att ta del av testpersonens tankar under testet får testledaren reda på hur den resonerar och vad den förväntar ska hända i olika situationer. I de fall som förväntningarna inte stämmer överens med vad systemutvecklarna tänkte är det aktuellt att ändra till exempel design eller formulering. (Molich 2000, s. 150-153)
Genom att be testpersoner tänka högt kan utvecklarna studera hur användaren resonerar. Detta ger en mer verklig bild av hur användaren förväntar sig att systemet ska fungera även om denne tillfrågas personligen enligt Molich (2000). Denna metod valdes som komplement för de intervjuer som också skulle genomföras i samband med användartesterna.
3 Teoretisk bakgrund
I följande kapitel presenteras teorier kring hur en lyckad kravinsamling kan genomföras, indelning av krav, riskbedömning och prioriteringar. I ITIS-projektet lades stor del av kravinsamlingens fokus på prototyputvecklandet. Teorier kring detta presenteras sist i kapitlet.
Vid utveckling av IT-system är den vanligaste felkällan bristande krav (56 % av fallen). Brister i kravspecifikationen leder till fel som kostar pengar. Dessa fel blir dyrare och dyrare att åtgärda ju senare i utvecklingen de upptäcks. Ett sätt att undvika detta är att göra ett noggrant förarbete och kravinsamling där slutanvändaren hamnar i fokus. (Eriksson 2007, s. 19)
3.1 Systemets intressenter
För att kunna samla in krav till ett IT-system måste man först och främst veta vilka intressenterna är eftersom det är dessa som ställer kraven. Det är oftast de som har godast insikt i processer, rutiner, funktioner och avdelningar inom organisationen. Exempel på intressenter är användare, marknadsförare, kunder, kunders kunder, IT-arkitekter, Helpdesk, företagsjurister, utvecklare, driftorganisationer och andra system. Samtliga intressenter sitter inne med sin specifika kunskap och har därmed sina specifika krav. Det är därför av vikt att alla också kommer till tals någon gång under kravinsamlingen. (Eriksson 2007, s. 60-61)
3.2 Användarfokus
Genom att ta hjälp av slutanvändaren vid utveckling eller inköp av informationssystem blir
systemet anpassat efter vad det ska användas till och vem som ska använda det. Systemutvecklarna utgår i många fall ifrån sig själva för att hitta lösningar och idéer till system och missar då hur slutanvändaren i verkligheten tänker och använder sig av informationssystem. (Dickstein & Mills 2000)
I en studie av Barki & Hartwick (1994) involverades 59 slutanvändare i utvecklandet av ett system. De fick först under utvecklandet fylla i frågeformulär som handlade om i vilken grad de var
delaktiga i utvecklandet. När systemet var färdigutvecklat och implementerat i organisationen fick samma personer fylla i ett frågeformulär angående deras relation och användande av systemet. Resultatet av undersökningen visade att de som deltagit mest i utvecklandet kände ett visst
tillgodosetts. De visade också en större förståelse för hur systemet fungerade än de som inte deltagit lika aktivt. (Barki & Hartwick, 1994)
Att sätta användaren i fokus i utvecklandet av något nytt eller vid genomförandet av en förändring blir dessa ofta mer positivt inställda och har lättare att acceptera förändringen. Tillvägagångssättet medför också en positiv inställning till beställaren (till exempel verksamheten, företaget, ledningen, avdelningschef) från användarnas sida vare sig dessa är anställda eller slutkunder. (Dickstein & Mills 2000)
3.3 Olika typer av krav
Begreppet krav är inte alltid korrekt att använda i detta sammanhang då det inte behöver vara krav som onekligen måste uppfyllas. Krav är ofta mer eller mindre förhandlingsbara och prioriteras olika högt (Eriksson 2007, s. 23). Det går att göra olika indelningar av krav. Ett sätt är att skilja mellan funktionella och icke funktionella krav (Eriksson 2007, s. 40).
3.3.1 Funktionella krav
De funktionella kraven beskriver vilka funktioner systemet ska kunna utföra. Dessa funktioner innebär ofta att systemet hanterar indata och utdata. Indata innebär den information som användaren matar in och som lagras i databasen medan utdata är den information som visas för användaren. De funktionella kraven är ofta de mest konkreta och lättast att komma fram till eftersom de utgör grunden till det system som ska utvecklas. (Eriksson 2007, s. 41)
3.3.2 Ickefunktionella krav
Ickefunktionella krav beskriver hur systemet ska fungera. Dessa krav har betydelse för hur användaren uppfattar systemet och innefattar användbarheten, tillförlitligheten, prestanda och underhållbarheten. Även dessa typer av krav kostar mycket tid och pengar att åtgärda i efterhand. Brister i användargränssnittet kan till exempel innebära förändringar i hela systemet.
(Hökenhammar 2001, s. 65)
Användbarhet
Ett vanligt misstag är att kraven på användargränssnittet är utformade som till exempel ”systemet ska vara ändvändarvänligt”. Kraven på användbarheten bör vara minst lika väldefinierade och dokumenterade som exempelvis de funktionella kraven. Exempel på användbarhetskrav:
• Hjälp ska finnas för varje skärmbild
• Systemet ska efter 20 minuters utbildning vara förståeligt nog för att kunna utföra vissa funktioner.
• Skärmbilden ska kunna synas och läsas av på 3 meters avstånd. (Eriksson 2007, s. 43-44)
Användbarhet kan vara svårt att mäta och många vet inte hur de ska ställa krav på användbarhet. Om man definierar användbarhet till följande punkter blir det enligt Molich (2000) lättare:
• Lätt att lära sig • Lätt att komma ihåg • Effektivt att använda • Tillfredställande att använda • Bergripligt
Dessa fem punkter är alla mätbara och konkretiserar därför begreppet användbarhet och gör det lättare att ställa krav på denna punkt. (Molich 2000, s. 23)
Funktionaliteten ska inte begränsas av användbarheten, utan ska komplettera systemet menar Goodwin (1987). Ett informationssystem eller ett program ska först och främst byggas kring dess funktionalitet, det ska kunna utföra de uppgifter det är avsett för att klara av.
Enligt Sundström (2005) måste funktioner, länkar och knappar buntas ihop så att inte för mycket information träffar användaren direkt. Dessutom bör varje funktion ifrågasättas ifall de verkligen behövs då det visat sig att användaren oftast bara använder de huvudfunktioner som ett program eller ett system erbjuder. Om användaren möts av för mycket information och funktioner hittar inte denne vad den söker direkt och tenderar att lämna platsen för att söka information på annat håll. (Sundström 2005, s. 110-115)
Förutom de ovan nämnda finns det ett antal ickefunktionella krav som inte går in under de
kategorier som tagits upp. Detta gäller krav på , tillförlitlighet, prestanda, underhållbarhet (engelska för maintainability) säkerhet, skalbarhet, rättigheter, integritet, loggning, paketering och
3.3.3 Restriktioner i designen
Bortsett från de funktionella och ickefunktionella kraven kan beställaren ha krav på restriktioner i designen. Det kan till exempel innebära att man vill att systemet ska vara begränsat till ett
programmeringsspråk som man har kunskap inom i organisationen sedan tidigare och på så sätt underlättar underhåll av systemet. Ett annat exempel på designrestriktion är att
användargränssnittet ska följa företagets grafiska profil vad gäller färgval, typsnitt och layout. (Eriksson 2007, s. 51)
3.3.4 Andra typer av kategorisering
Kraven kan även delas in i tre kategorier med intressenterna som utgångspunkt. Dessa är de normala, förväntade och sensationella kraven. (Eriksson 2007, s. 54)
3.3.5 Normala krav
De normala kraven är de som beställaren och användaren är medvetna om och upplyser leverantören om. Dessa krav är de mest tydliga och lättaste att identifiera eftersom man är fullt medveten om dem. Skulle dessa krav bli uppfyllda blir beställaren nöjd och om de inte uppfylls blir beställaren missnöjd eftersom det är de krav som utgör syftet med själva systemutvecklingen. (Eriksson 2007, s. 54)
3.3.6 Förväntade krav
Som leverantör eller kravinsamlare kan de förväntade kraven vara svåra att upptäcka utan god insikt i organisationens rutiner, tidigare system och andra system i organisationen. De förväntade kraven är de krav som beställaren ser som så pass självklara att denne inte ens nämner dem för kravinsamlaren. Detta kan bero på att beställaren förväntar sig att kravinsamlaren redan ska känna till kraven eller att man tar det för givet och därför glömmer bort att informera om dessa. Dessa krav leder till missnöje om de inte uppfylls. (Hökenhammar 2001, s. 70)
3.3.7 Sensationella krav
Det kan finnas krav eller funktioner som man på beställarsidan inte vetat om på grund av hemmablindhet eller teknisk okunnighet men som extern konsult kan vara möjliga att upptäcka. Dessa krav hamnar i kategorin sensationella krav. Om man upptäcker ett sensationellt krav är det
alltid viktigt att ha beställarens godkännande så att systemet inte får onödiga funktioner som kostar tid och pengar och gör systemet mer komplext. (Eriksson 2007, s. 55-56)
3.4 Att inte missa några krav
Att samla in alla krav samtidigt är oftast ingen bra lösning. Det är lätt att krav missas och desto senare i utvecklingen ett krav upptäcks ju dyrare och svårare är det att tillgodose. För att minska risken av missade krav bör man därför arbeta iterativt med kravinsamlingen och
systemutvecklingen. (Eriksson 2007, s. 95-96)
Att arbeta iterativt innebär att man arbetar i cykler. För att kunna uppfylla de krav som upptäcks på vägen går man tillbaka när man har tillgodosett de första kraven, samlar in nya krav och
kontrollerar om det arbete man gjort hittills har fungerat. Genom iterativt arbete möjliggörs ett hänsynstagande till nya och förändrade krav under utvecklingen av systemet. (Eriksson 2007, s. 96) Kravinsamlingsmetoderna är inte kompletta utan måste kombineras för att inte några krav ska missas eller bli sent påkomna. Vissa av metoderna lämpar sig bättre än andra vid utvecklingen av olika typer av system och i olika typer av organisationer. Till exempel är det vid utveckling av små system med få användare lämpligt att anordna kortare workshops kombinerat med
prototypframställning. (Eriksson 2007, s. 97)
3.5 Prioritera rätt
Det är inte alltid alla krav går att uppfylla på grund av begränsad tid, budget eller att två krav är motsägande, det vill säga att uppfyllandet av det ena kravet leder till att det andra blir omöjligt att uppfylla. Därför är det viktigt att kunna prioritera bland kraven. (Eriksson 2007, s. 100)
3.5.1 Riskbedömning
Ett viktigt prioriteringsredskap är att identifiera de risker som finns med vissa krav. Till exempel att funktionerna är otillräckliga eller att användbarheten är bristande. Genom workshops kan
deltagarna i utvecklingen ge sin syn på vilka risker de ser och tillsammans rangordnar man de risker som identifierats. De rangordnas dels efter effekten av risken och dels sannolikheten av att de inträffar. På så sätt prioriteras de risker med störst åverkan och högst sannolikhet att inträffa och fokus läggs på att lösa just de krav som medför dessa risker om de inte uppfylls. (Eriksson 2007, s. 102-103)
För att undvika hemmablindhet kan personer som inte varit med i kravinsamlingen och planeringen delta i riskanalysen för att med friska ögon lättare kunna upptäcka förbisedda risker. Dessa
personer är med fördel dels från utvecklingssidan då dessa kan se de tekniska riskerna, och dels från beställarsidan eftersom dessa lättare ser risker i implementering och processer som berörs av systemet. (Jansson & Ljung 2004, s. 128)
3.5.2 Rangordning av krav
Att rangordna kraven är ett vanligt förfarande när det gäller att prioritera rätt. Det är om möjligt lämpligt att både personer från beställarsidan och leverantörssidan deltar i kravrangordningen eftersom beställaren har sina önskemål om vad de vill ha och hur mycket de vill betala medan man på leverantörssidan har det tekniska kunnandet för att se vad som är möjligt att genomföra och hur mycket tid och pengar som går åt. (Eriksson 2007, s. 104)
För att rangordna krav finns det ett antal metoder. Till exempel att varje mötesdeltagare får tre poäng vardera att dela ut till de krav de anser viktigast, samtliga krav får en viktighetsgrad på förslagsvis en tregradigskala och kraven kan kategoriseras i grupperna: skall finnas, bör vara med och bra att ha. (Eriksson 2007, s. 104-105)
När kraven prioriteras kan det visa sig att vissa krav inte är nödvändiga just nu men kommer att bli det i framtiden. Detta bör då noteras så att systemutvecklarna inte gör det svårt för sig ifall det blir aktuellt med en framtida uppdatering. (Eriksson 2007, s. 106)
Vid kravprioritering lämnas krav som inte är möjliga att prioritera utanför. Det är självklara krav som gör systemet meningslöst ifall de inte uppfylls. Till exempel kan ett ordersystem som saknar funktion för beställning inte fungera. Dessa självklara krav ska implementeras i systemet oavsett tid och kostnad eftersom det är dessa funktioner som utgör systemet. (Eriksson 2007, s. 109)
Lösningar på problem bör inte finnas med i kravspecifikationen eftersom utvecklaren då kan hindras från att välja den bästa lösningen. (Eriksson 2007, s. 42)
3.6 Utvecklande av prototyper
Förr interagerade systemutvecklarna med slutanvändarna enbart i inledningen av
systemutvecklingen för att förhöra sig om vilka krav dessa hade på systemet. Därefter fick inte slutanvändarna se något av systemet förrän det var en färdig produkt. Användbarheten utgick därför inte alls ifrån slutanvändaren utan från systemutvecklarna själva. På grund av detta blev flera
system svåra att använda och ansågs ofta som misslyckade. Med byggande av prototyper fick man feedback från slutanvändaren genom hela utvecklandet och systemets användbarhet blev helt anpassat till slutanvändaren. (Lin m.fl. 2005)
Ska funktioner testas i en prototyp bör inte mycket tid läggas på design eftersom detta blir onödigt kostsamt och testpersonen får även en känsla av att det är en färdig produkt och kan därför bli mer återhållsam vad gäller förändringar och kritik till prototypen. Det är viktigt att tydliggöra för testpersonen att det inte rör sig om en färdig produkt. Är det däremot designen som ska testas bör mindre tid istället läggas på funktionerna av samma anledning, att det blir onödigt kostsamt. Tid ska främst läggas på det som ska testas. (Molich 2000, s. 61-62)
Lunell (2003) delar upp prototyper i två typer: beteendeprototyper och strukturprototyper. Beteendeprototyperna simulerar funktionerna i ett system och används främst för att se hur
användare tolkar designen av användargränssnitt och visuell design. Strukturprototyper är endast en delfunktion av det stora systemet där utvecklaren testar hur till exempel koden för en funktion ska se ut. Lunell skiljer dessutom på undersökande prototyper och utvecklingsbara prototyper. De undersökande prototyperna används bara i undersökande syfte och kastas därefter bort, till exempel pappersprototyper. De utvecklingsbara prototyperna används genom utvecklingen av ett system och blir sedan implementerad i det färdiga systemet. (Lunell 2003, s. 234-235)
4 Empiri
I följande kapitel presenteras de undersökningar och verklighetsbeskrivningar som genomförts i studien. För att få bakgrund till undersökningarna presenteras först och främst företaget JMS Mediasystem AB kortfattat.
4.1 JMS Mediasystem AB
Tryckerikoncernen JMS Mediasystem är ett växande företag som under 2010 har utökats med två nya tryckerier, ett i Danmark och ett i Norge. I anslutning till huvudkontoret som ligger i Vellinge finns även ett av deras arkoffset- och digitaltryckeri. Koncernen har över 350 anställda som är fördelade på ett tjugotal produktionsanläggningar och kontor.
IT-ansvarig sedan september 2009 benämns som ”IT-ansvarig” i rapporten och det var han personligen som efterfrågade ett system för att öka kontrollen över IT-utrustning och
programlicenser i organisationen och knyta dessa till personer som ansvarar för respektive artikel. Han arbetar tillsammans med ytterligare en person som support- och servicearbetare av IT-system och IT-utrustning i företaget. De två använder därför samtliga informationssystem i företaget. Han och hans kollega tillsammans benämns i fortsättningen som ”IT-medarbetarna”.
Christina Norrman som är personalansvarig i JMS har också deltagit i ITIS-projektet, bland annat i de workshops och användartester som presenteras nedan. Christina arbetar i vardagen med
informationssystemet Hogia PA. I fortsättningen benämns Christina som ”personalansvarig”.
4.2 Vad ska systemet kunna göra?
För att kunna utveckla eller köpa in ett system som har god kvalitet krävs det att man gör en kravinsamling och hanterar dessa korrekt därefter. Det finns olika metoder för kravinsamling och olika typer av krav upptäcks i de olika metoderna. (Eriksson 2007, s. 17)
I utvecklingen av ITIS användes kravinsamlingsmetoderna verklighetsbeskrivning, ostrukturerad intervju, workshop och prototyputveckling.
4.2.1 Verklighetsbeskrivning genom ostrukturerade intervjuer
Att göra en verklighetsbeskrivning lyfter fram problemet som ska lösas och hjälper även till att förstå hur det kan lösas. (Andersen 1994, s. 50)I inledningen av ITIS-projektet genomfördes ostrukturerade intervjuer med IT-ansvarig för att samla grundläggande information om problemet, vilket enligt Eriksson (2007) är en vanlig metod som lämpar sig i intervjuer med få intressenter inblandade. I första intervjun samlades enbart information om problemet och tankar på hur IT-ansvarig hade förslag på att lösa det. Med denna grundinformation påbörjades en verklighetsbeskrivning genom en andra intervju med IT-ansvarig där företagsstrukturen klargjordes och utrustning som skulle behöva registreras diskuterades och dokumenterades.
För att kunna klargöra hur de, för ITIS, relevanta processer såg ut i företaget fortsatte verklighetsbeskrivningen genom ostrukturerade intervjuer med IT-ansvarig och även personalansvarig. Dicander Alexandersson m.fl. (1997) menar att genom dokumentation av samtliga aktiviteter i processen uppstår ofta idéer för att lösa problem och förbättra processen. De poängterar dock att det är viktigt att beskriva processen som den verkligen är och inte hur man önskar att den såg ut. Inköpsprocessen av ny IT-utrustning beskrevs av IT-ansvarig och dokumenterades skriftligt för att sedan överföras i en processkarta (se bilaga 2). Under denna ostrukturerade intervju dök flera krav upp som skulle vara lämpliga att applicera i systemet ITIS. Den ostrukturerade intervjun med personalansvarig fortlöpte på liknande sätt som den med IT-ansvarig. Beskrivningen dokumenterades, överfördes till en processkarta (se bilaga 1) och även här upptäcktes ett antal krav.
Nyanställning
Den aktör som har störst roll i nyanställningsprocessen är personalansvarig. Denna beskrivning tar vid när det är beslutat vem som ska anställas för vilken tjänst. Rekryteringsprocessen var inte aktuell för denna undersökning eftersom det inte påverkar den nyanställdas registrering i system och vilken utrustning den kommer att använda och ansvara för.
Personalansvarig börjar med att föra in anställningsavtalet i personalsystemet. Därefter tilldelas de behörigheter som tidomatkort, larmkort och nycklar. Om den nyanställda behöver någon form av IT-utrustning gör avdelningschefen en beställning som i sin tur går genom IT-ansvarig (se bilaga 2 för IT-inköp). IT-avdelningen får i samband med detta, information om den nyanställda och tilldelar denna de behörigheter den behöver för att komma åt de system som blir aktuella att
använda i anställningen. Löneansvarig informeras därefter och för in den nyanställda i
lönesystemet Axapta. Detta sker genom en direkt import från personalsystemet Hogia PA vilket innebär att man slipper skriva in information manuellt mer än en gång. Ifall den nyanställde ska ha mobiltelefon i arbetet så sköts detta av receptionisten. Se bilaga 1 för processkarta över
anställningsprocessen.
Inköpsprocessen
Inköp av IT-utrustning utförs alltid av IT-ansvarig. I de fall då inköpet överstiger 15 000 kr ska inköpet godkännas av tre aktörer: avdelningschefen som tar beslutet ifall den anställde ens behöver den efterfrågade utrustningen, IT-ansvarig som i princip endast ser till vilka produkter som är lämpliga för ändamålet och slutligen VD:n som tar det avgörande beslutet för om inköpet ska äga rum eller inte. Godkänns inköpet i alla tre stegen genomför IT-ansvarig en beställning. Artiklarna skickas sedan till JMS Vellinge, där IT-ansvarig är stationerad, för att förberedas för bruk. Nätverk konfigureras, program och virusskydd installeras. Därefter transporteras utrustningen till det kontor den ska brukas på med antingen någon inom företaget som har ärende till den aktuella platsen eller med bud om det är brådskande. Se bilaga 2 för beskrivning över inköpsprocessen.
Genom verklighetsbeskrivningarna upptäcktes främst krav av funktionell karaktär:
• Personer ska kunna läggas till och tas bort. Det ska innehålla namn, e-post, adress och anställning.
• Till personen ska man kunna knyta samtliga punkter på artikellistan.
• Sökning ska kunna göras på både artikel och person. Det ska gå att söka på flera sökparametrar samtidigt, till exempel tillverkningsår och tillverkare.
• Programvara ska kunna knytas till både dator och användare. • Utrustning ska kunna sättas på ”används ej”-status.
• Programvara ska kunna sättas på ”används ej”-status.
• Behörigheter till system ska kunna knytas till person och det ska anges vilken grad av behörighet som personen har.
• Nycklar och behörigheter till fysiska platser ska kunna knytas till person och en beskrivning på vilket område som personen har tillgång till ska beskrivas. • En ”övrigt”-kategori ska finnas där man kan registrera artiklar som inte passar in
4.2.2 Ett drömsystem
Att arrangera workshops är enligt Eriksson (2007) ett av de mest effektiva sätten att upptäcka omedvetna krav och problem. I detta projekt anordnades två workshops: ett med IT-ansvarig och ett med personalansvarig. De två workshoparna var upplagda på samma sätt. I enlighet med Andersen (1994) sätt att göra en förändringsanalys, ombads deltagaren att beskriva hur denne önskade att verksamheten skulle se ut i en drömvärld och hur ett informationssystem för IT-inventarier skulle se ut och fungera i denna drömvärld. Därefter diskuterades de problem och lösningar som kom fram, med utgångspunkt från den verklighetsbeskrivning som tidigare gjorts, för att sedan omvandla dem till realistiska krav i utvecklingen av ITIS. Dessa var av både funktionell och icke funktionell karaktär:
• Utskriftsfunktion (kravet är att man ska kunna få ut listor antingen på papper eller som till exempel PDF- eller Excel-fil).
• Systemet ska ha olika behörighetsnivåer, en läsbehörighet och en läs- och skrivbehörighet.
• Det ska vara möjligt att göra en så pass specificerad sökning att man får endast en sökträff.
• Information om anställdas utbildningar, försäkringsbolag och pensionsbolag ska vara möjligt att registrera på respektive anställd.
4.2.3 Prototyputveckling med iterativt arbete och
användartester
Andersen (1994) påpekar att det är svårare och mer kostsamt i både tid och pengar att åtgärda ett fel eller genomföra en ändring ju längre fram i arbetet man har kommit. Efter
verklighetsbeskrivningen och de intervjuer som hittills genomförts fanns tillräckligt med
information för att utveckla en enkel pappersprototyp som blev starten för det iterativa arbete som sedan genomsyrade en stor del av ITIS-projektet. Denna pappersprototyp, som kallades Prototyp 1.0 bestod av 7 stycken A4-papper där knapparna ledde till att en ny sida visades. Strukturen på systemet illustrerades genom denna prototyp och testades sedan på en användare: IT-ansvarig. Användartestet på pappersprototypen följdes upp med en intervju av ostrukturerad karaktär för att upptäcka fler krav och förbättringar hos prototypen. Vissa tidigare beslut bekräftades och vissa nya krav upptäcktes under denna intervju. I denna första iteration upptäcktes följande krav:
• Funktion för kvittens vid tillägg och ändringar av personers behörigheter och ansvarsartiklar.
• Funktion för avslut av personal där personens tillhörigheter automatiskt hamnar i ”används ej”-status.
• Lista på oanvända programlicenser.
• Punkt för när personen blev anställd samt för närmsta chef på profilsidan. • ”Lägg till ny”-knapp på de olika kategoriernas sidor.
• Tydligare benämning på behörigheter.
Dessa krav var samtliga av funktionell karaktär bortsett från andra punkten som innehöll drag av ickefunktionella krav (att personens behörigheter per automatik ändras till ”används ej”-status).
Prototyp 2.0
Med de nytillkomna kraven påbörjades utvecklandet av den första digitala prototypen, Prototyp 2.0 (se figur 2). Denna byggdes med HTML-kod och CSS-mallar som enligt Eriksson (2007) är ett smidigt sätt att bygga IT-systemprototyper. Prototyp 2.0 utgick från Prototyp 1.0 med de förändringar och kravanpassningar som tillkom efter första användartestet. Ett användartest genomfördes även på ansvarig i denna iteration och ett antal nya krav uppkom dels genom IT-ansvarigs önskemål och dels genom den observation som gjordes under testet:
• En kvittens ska skrivas ut när ändring eller tillägg har skett.
• Att ändringarna tydliggörs i ett utskrivet dokument men där de gamla behörigheterna står kvar.
• Hjälptexter på respektive sida så att man kan få en förklaring för vad det är man kan göra.
• E-postadresser under behörigheter. Folk kan vara ansvariga för flera e-postadresser.
• Bakåtknapp i ”lägg till”-delen.
Prototyp 2.1
I den tredje iterationen utvecklades Prototyp 2.1 och förbättring av layout och design utgjorde en stor del av denna uppdatering. Problemen i tidigare versioner var tydlighet med vad som dolde sig bakom vissa knappar och logiken i systemet verkade vara bristfällig då tveksamheter uppstod under vissa uppgifter. Ett försök till att lösa detta gjordes genom förändringar i menyer och indikatorer på var man befann sig i flerstegsprocesser. Användartestet av denna prototyp genomfördes på IT-ansvarig, personalansvarig och en IT-medarbetare. Genom de nytillkomna testpersonerna testades
systemet med nya ögon som inte påverkats av tidigare tester. Ytterligare några krav dök upp under detta test, både från testpersonerna och genom observation under genomförandet:
• Personnummer och adress bör vara dolt eftersom dessa är sekretessbelagda. • Ytterligare tydlighet för vad access/nycklar innebär.
• Processindikatorerna (1-2-3-bollarna i ”lägg till”-processen) bör vara klickbara och mer tydliga i vad de betyder. Man ska alltså kunna gå bakåt i processen.
• Knytknapparna tydligare. • Kreditgräns på kreditkort.
Figur 2. Denna figur visar hur layout och användargränssnittet har förändrats mellan iteration
4.2.4 ITIS mot Hogia PA och Microsoft Share Point
Efter testerna av Prototyp 2.1 påbörjades den fjärde och som kom att bli den sista iterationen. Andersen (1994) menar att iterativt arbete kan pågå i all oändlighet men någonstans sätter tidsbegränsningar och budget stopp. I takt med att antal nyupptäckta krav minskade efter varje användartest och att tiden började bli knapp togs beslutet att detta skulle bli den slutgiltiga prototypen: Prototyp 2.2 (sefigur 2).
För att kunna fatta beslutet ifall JMS ska göra en satsning på utvecklandet av ITIS eller inte samt för att undersöka huruvida användare ställer sig till olika typer av system, avskalade och enkla eller fullmatade med funktioner, genomfördes ett sista användartest på ITIS Prototyp 2.2 som jämfördes mot personalsystemet Hogia PA och intranätet Microsoft Share Point. Användartestet bestod av tre olika delar med fyra uppgifter vardera. I första delen testades intranätet, i andra ITIS och i tredje Hogia PA. De fyra uppgifterna i varje del var snarlika för att en rättvis jämförelse skulle kunna göras. Uppgift ett gick ut på att hitta information om en person, till exempel telefonnummer eller e-postadress. I andra uppgiften skulle testpersonen registrera en ny artikel i systemen och i tredje uppgiften redigera en artikel. Den fjärde uppgiften gick ut på att ta bort en artikel ur systemen. Med de fyra uppgifterna hade alla de grundfunktioner, som ett inventariesystem kräver, utförts.
Direkt efter användartestet genomfördes en intervju där testpersonerna fick svara på hur de ställde sig till olika system i sitt vardagliga arbete, hur de upplevde skillnader mellan de testade systemen och hur de resonerade kring avancerade system med många funktioner och enklare avskalade system som inte klarar av att utföra lika många uppgifter. Samma frågor ställdes till samtliga testpersoner men med olika följdfrågor beroende på vad testpersonen svarat. Intervjuerna spelades in för att sedan kunna kodas och sammanställas.
5 Resultat
I följande kapitel presenteras resultatet på de undersökningar som genomförts och som sedan ligger till grund för diskussion och slutsats i studien.
5.1 Jämförande användartest
I det slutliga användartestet jämfördes två i företaget existerande system (intranätet Microsoft Share Point och Hogia PA) samt den nyutvecklade prototypen ITIS Prototyp 2.2 mot varandra. Samtliga system levde upp till de grundläggande krav som beställaren angivit initialt i projektet vilket kontrollerats innan användartestet utfördes.
5.1.1 Observationsresultat
Av de tre systemen som testades var intranätet det system som tog längst tid i samtliga uppgifter (se figur 5.3). 3 av 6 personer efterfrågade sökfunktioner, med referenser till bland annat Hogia PA, i intranätet för att slippa leta genom långa listor. Mycket tid gick åt att leta efter knappar och länkar och tveksamheter dök ofta upp oavsett vad det var personerna skulle göra i intranätet.
I ITIS hade flera personer vid olika tillfällen problem med att förstå kategoriseringen. De var tveksamma till under vilken kategori man hittade vad. Sökfunktionen användes av 2 personer i uppgift 1. I uppgift 2 där man skulle lägga till en artikel stannade flera personer upp innan de förstod hur man knöt en person till den registrerade artikeln.
Hogia PA var snabbast att utföra uppgift 2-4. Det ska tilläggas att Hogia PA inte har lika många informationsfält att fylla i per artikel. Skrivtiden blev därför inte lika lång eftersom det i uppgift 2 inte fanns lika mycket att skriva jämfört med de andra två systemen. Sökfunktionen användes i varje uppgift av 3 av 6 personer.
Figur 3. Tabellen visar genomsnittstiden i minuter och sekunder för varje uppgift i respektive
system.
5.1.2 Intervjuresultat
I valet mellan att arbeta med ett stort system med många funktioner och flera små avskalade med färre funktioner föredrog 4 av 6 av testpersonerna att arbeta med ett stort system, 1 person föredrog ett stort med tydligt skilda avdelningar och 1 person föredrog flera mindre system. Samtliga personer såg fördelar och nackdelar med båda alternativen. Motiveringen till ett stort system lyder i samtliga fall att man vill slippa växla mellan flera olika program. Anledningen till att en person ville ha flera små system var att personen ansåg att man då inte behövde lära sig systemen utantill utan de skulle vara så pass enkla att man klarar av att hantera dem utan någon tidigare erfarenhet. 6 av 6 testpersoner prioriterade god användbarhet framför många funktioner i ett system. 2 personer kommenterade att de vill ha så många funktioner som möjligt utan att det går ut över användbarheten. 1 person påpekade att det inte finns någon nytta med ett system som har många funktioner om ingen vet hur man ska använda det.
4 av 6 personer upplevde inte att de lägger ner mycket tid på att lära sig de system de använder under sitt vardagliga arbete med motiveringen att de utför ungefär samma uppgifter varje dag och därför lärt sig att genomföra dessa utan problem. De övriga 2 testpersonerna kände att de får lägga ner mycket tid på att lära sig nya system. De två sistnämnda arbetar med fler än 3 system och får ofta lösa problem åt både sig själva och andra.
4 av 6 testpersoner kände inte att de använder för många system för att kunna arbeta effektivt. Dessa arbetar med 2-3 system i sitt vardagliga arbete. 2 personer upplevde att de har för många system och arbetar med 6-7 stycken, dessa två personer var IT-medarbetarna.
5 av 6 personer kände inte sig frustrerade inför att använda något av systemen i sitt arbete men vid fel och problem med system kände samtliga testpersoner frustration ibland. 1 person kände ibland frustration inför att använda intranätet Microsoft Share Point och undviker därför att använda det vid vissa tillfällen.
På frågan om testpersonen var mer positivt inställd eller negativt inställd till något av systemen efter testet svarade samtliga att de var mer negativt inställda till intranätet Microsoft Share Point eftersom det var rörigt, för många objekt som var synliga hela tiden och komplicerat att använda. Det fanns heller ingen välfungerande sökfunktion, vilket tre personer var vana att använda i systemen de arbetar med i vardagen, och efterfrågade därför detta även i Microsoft Share Point. Hogia PA och ITIS upplevdes av samtliga som mer positiva eftersom de var lättare att navigera i och mer överskådliga. En person påpekade att ITIS fungerade bäst i allmänhet att utföra de uppgifter som ingick i testet även om det inte alltid gick snabbast, detta var IT-ansvarig.
6 Diskussion
Vad kunde ha gjorts annorlunda? Varför blev resultatet som det blev? I följande kapitel diskuteras både resultat och utförande av studien. I denna del passar jag även på att presentera mina egna åsikter på vissa punkter.
6.1 Förarbete inför att utveckla ett nytt system
Enligt Eriksson (2007) beror mer än hälften av alla misslyckade IT-system på att kravinsamlingen varit bristfällig. Beställaren och kravinsamlaren har samlat krav och förhört sig med fel personer och vissa kravområden glöms helt och hållet bort. I den fas då beställaren till ITIS förmedlade vad det var han var ute efter hade han endast ett krav: att få bättre kontroll över den IT-utrustning som finns i företaget. Genom en verklighetsbeskrivning av företagets struktur, inköpsprocess av IT-utrustning, nyanställnings- och anställningsavslutsprocess lyckades vi få IT- och personalansvarige att hitta ett antal nya, lite mer detaljerade krav som de tidigare inte insett. Verklighetsbeskrivningen gjordes med hjälp av endast två personer, IT- och personalansvarig. För att hamna så nära
verkligheten som möjligt borde åtminstone ytterligare en person till per respektive process ha intervjuats. När endast en persons version av verkligheten behandlas är det större risk att denna hamnar längre ifrån den verkliga situationen (Eriksson, 2007).
Kraven som upptäcktes i samband med verklighetsbeskrivningen hade förmodligen inte upptäckts om inte de processer som sker vid anställningar och IT-inköp noggrant hade gåtts igenom,
tillsammans med IT- och personalansvarig. Samtidigt hade inte vi själva kunnat upptäcka dessa krav på egen hand. Redan här förändrades alltså beställarens krav. Projektet gick sedan vidare genom två workshops med IT-ansvarige respektive personalansvarige. I denna workshop fick de båda göra en beskrivning av hur systemet skulle se ut i en drömvärld. Både orealistiska och realistiska krav fick tas upp. I denna fas dök det upp ett antal krav som inte heller tidigare varit påtänkta. Genom att ge beställaren nya synvinklar på systemet och användandet kan de själva upptäcka krav som de från början inte varit medvetna om.
Processbeskrivningen hade beställaren om denne haft tid och kunskap kunnat göra på egen hand. Anledningen till att kraven vid beställningen ofta är otillräckliga för att utveckla ett lyckat IT-system verkar bero på en underskattning av det förarbete som ofta krävs inför inköp av ett nytt system. Det är en tidskrävande process men lönar sig förmodligen i längden precis som Andersen
(1994) menar, eftersom fel som måste åtgärdas kostar mer ju längre fram i utvecklandet man kommit.
6.1.1 Krav på användbarhet
Kraven på användbarhet är ofta svåra att formulera och blir inte sällan bättre formulerade än: ”Systemet ska vara lättanvänt”. Huruvida systemet får god användbarhet eller inte är i sådana fall helt och hållet upp till systemutvecklarens känsla. I denna studie upptäcktes att användarna förväntar sig att systemen ska bete sig som de system de redan arbetar med precis som Molich (2000) beskriver i sin studie på användbarhet för webben. Ett sätt att ställa mer konkreta krav på användbarheten är då att peka på system som man vill efterlikna vad gäller till exempel navigation, layout, kortkommandon med mera. Eriksson (2007) påpekar att det i kravspecifikationen inte ska finnas några lösningar på problem utan bara krav på vad som ska lösas eller uppfyllas. Både som kravinsamlare och som beställare upptäcktes flera fall där kraven egentligen var färdiga lösningar och därför fick problemet inte några alternativa förslag. Andersen (1994) menar att om lösningarna finns presenterade i kravspecifikationen får inte systemutvecklarna chans att lösa problemen utifrån sina kunskaper och färdigheter, det vill säga, de blir begränsade i utvecklandet.
Anledningen till att det är svårt att ställa ickefunktionella krav kan ha att göra med att man inte vet vilka krav som är rimliga att ställa. Beställaren vet till exempel inte vad som är rimligt vad gäller uppstartningstid för systemet eller hur snabbt det ska gå att genomföra en sökning. Dessa krav är lättare att ställa efter att man har testat systemet i form av till exempel en prototyp.
Prototyputveckling fungerade alltså i denna studie som metod för att ställa konkreta krav på just användbarhet och andra svårdefinierade områden. Eriksson (2007) menar att det inte går att samla in alla krav på en gång och detta styrks i denna studie då endast en bråkdel av kraven samlades in innan prototyputvecklandet påbörjades och dessa var huvudsakligen av funktionell karaktär. Ett sätt att ställa krav på användbarheten är att kräva en användarcentrerad utvecklingsprocess. Detta blir alltså inte ett krav på systemet i sig men tvingar åtminstone utvecklarna att sätta slutanvändarna i fokus under utvecklingsprocessen vilket i sin tur bör leda till ett användbart system.
6.2 Användbart eller många funktioner
Någonstans så måste antal funktioner i systemet möta användbarheten. Det går inte att ha oändligt med funktioner och samtidigt ha ett lättanvänt system som alla kan förstå. För att konkretisera
ytterligare krav på användbarhet kan det ifrågasättas huruvida man har möjlighet att utbilda och informera nya slutanvändare. Är det endast en slutanvändare har man kanske råd att genomföra en längre utbildning och det finns möjlighet att bygga ett mer komplext och avancerat system. Är däremot systemet riktat mot konsumenter på internet finns det ingen möjlighet överhuvudtaget att utbilda slutanvändarna och systemet måste därför fungera så pass enkelt att man förstår det på egen hand.
6.3 Vilket system lämpar sig för JMS?
Genom att göra det slutliga användartestet på personer med olika befattningar i verksamheten upptäckte vi att de hade olika synsätt på om de upplevde att de hade för många system eller inte. Ekonomi-, personal- och lönemedarbetarna satt med 2-3 system vardera och utförde samma uppgifter varje dag medan de två IT-medarbetarna i sin tur använde samtliga system i företaget, vilket var 7-8 stycken. Så länge IT-medarbetarna har kontroll över de system som finns är det lättast om man använder de flera avskalade systemen som är speciellt lämpade för sin sak istället för att försöka sträva efter att ha så få system som möjligt med samtliga funktioner samlade på ett och samma ställe. Det hade kanske hjälpt IT-medarbetarna men försvårat för övriga personer som arbetar med någon form av informationssystem, detta visade sig inte minst i det slutliga
användartestet där samtliga personer hade svårt för att hantera Intranätet Microsoft Share Point som är av den typ av system som är fyllt till bredden av funktioner för att det ska passa till många typer av verksamheter.
Ett av problemen som IT-ansvarig upplever hos JMS idag är att man har för många separata system som inte samverkar. Att investera i utvecklandet av ITIS till ett fungerande system kanske löser problemet med att på ett enkelt sätt få kontroll över IT-utrustningen men kan orsaka problem på andra områden, till exempel måste personalansvarig göra ändringar i ytterligare ett system varje gång någon i personalen nyanställs, slutar eller förflyttas. Att försöka utnyttja de system som redan finns i företaget och bli bra på dessa ger IT-medarbetarna kontroll över utrustningen och mer lätthanterlig situation vad avser antal system att sköta. Även om Microsoft Share Point fick sämst resultat i undersökningen så är det ett system som har stor potential på grund av sin dynamik att anpassas efter sitt användningsområde. Genom att se över Microsoft Share Point, som idag upplevs som rörigt av de personer som medverkat i användartesten, kan många av dess funktioner och information rensas upp och struktureras om för att göra det lättare att använda. Detta medför att, som Sundström (2005) hävdar, användaren snabbare hittar de funktioner och den information som denne söker.
Att använda Hogia PA som IT-inventariesystem hade inte fungerat lika bra som ITIS och Microsoft Share Point då det saknar funktioner för att tillgodose många av de krav som arbetats fram under projektets gång. Det har god användbarhet men är inte lämpat för inventarier utan för
personalhantering, vilket det fungerar alldeles utmärkt för.
IT-ansvarig upplevde att ITIS var bäst lämpat för uppgifterna i testet. Detta kan bero på dels som Barki & Hartwick (1994) menar att personer som aktivt deltar i utvecklandet av systemet utvecklar känslor i form av ägandeskap och tillfredställelse samt att förståelsen för hur systemet ökar eller på grund av som Dickstein & Mills (2000) menar att systemet utvecklats efter slutanvändarens medvetna och omedvetna krav och därför passar denna person bäst. En kombination av de båda teorierna är enligt mig mest sannolik. ITIS utvecklades efter de krav som successivt upptäcktes och är därför väl anpassat för sitt ändamål men IT-ansvarigs känslor för systemet stärktes genom att han har varit med i utvecklandet och kände därför en viss delaktighet och ägandeskap i ITIS. För att genomföra en förändring eller implementering av ett nytt system är det enligt båda teorierna fördelaktigt att involvera slutanvändarna i så stor grad som möjligt.
7 Slutsatser
I de undersökningar som genomförts i denna studie visade det sig att 85 % av de tillfrågade prioriterar god användbarhet före många funktioner.
Vi kan dra slutsatsen att användaren föredrar ett system som är lättanvänt men innehåller så pass många funktioner utan att det går ut över användbarheten. Detta förändras med tiden som
användaren arbetar med systemet. Har man arbetat mycket med ett system och vant sig vid det har användaren en betydligt lägre toleransnivå för vad som är god användbarhet. Fortsatta
undersökningar på hur man implementerar system gradvis för att hålla denna toleransnivå under kontroll skulle vara intressanta och användbara.
Vid kravinsamlingen till systemet är det främst de funktionella kraven som hamnar i fokus. Användbarheten passerar snabbt förbi i ett önskemål om att ”systemet ska vara användarvänligt”. Slutsatsen som kan dras av detta är att användbarhet är viktigt enligt användaren men det är samtidigt svårdefinierat för många och man vet oftast inte vad det är man efterfrågar när man önskar god användbarhet. Detta ställer höga krav på kravinsamlaren som måste se vad god användbarhet innebär för de aktuella slutanvändarna. Genom prototypframställning och användartester har man en fungerande metod för att få fram krav på användbarhet. Genom att se över intranätet Microsoft Share Point och reducera informationen och antal
funktioner i detta system skulle det fungera som ett fullgott inventariesystem på JMS. Eftersom det är ett system som redan finns och används i företaget blir detta också det billigaste alternativet. ITIS som var speciellt utvecklat för IT-inventarier hos JMS hade löst problemet med att få kontroll över IT-utrustningen i företaget men hade orsakat problem på andra områden eftersom det hade tillkommit ytterligare ett system i organisationen. Att man har för många system i företaget upplever IT-medarbetarna som ett problem redan idag.
8 Referenslista
Nedan listas de källor som använts i rapporten. Källorna är indelade i kategorierna litteratur, artiklar och internetkällor.
8.1 Litteratur
Andersen Erling S 1994, Systemutveckling – principer, metoder och tekniker 2:a upplagan, Studentlitteratur Lund
Befring Edvard 1992, Forskningsmetodik och statistik, Studentlitteratur Lund
Bell Judith 2000, Introduktion till forskningsmetodik 3:e upplagan, Studentlitteratur Lund Chisnell Dana & Rubin Jeffrey 2008, Handbook of Usability Testing: How to Plan, Design and Conduct Effective Tests, John Wiley & Sons, Inc. Kanada
Dicander Alexandersson Marianne, Almhem Lars, Rönnberg Katarina & Väggö Björne 1998, Att lyckas med Processledning upplaga 2:6, Liber Malmö
Ejvegård Rolf 2003, Vetenskaplig metod 3:e upplagan, Studentlitteratur Lund
Ely Margot 1993, Kvalitativ forskningsmetodik i praktiken – cirklar inom cirklar, Studentlitteratur Lund
Eriksson Ulf 2007, Kravhantering för IT-system, Studentlitteratur Lund Goodwin Nancy S 1987, Functionality and usability, ACM New York USA
Hoyle D & Thompson J 2003, Processinriktat ledningssystem för kvalitet, SIS Förlag AB Stockholm
Jansson Tomas & Ljung Lennart 2004, Projektledningsmetodik, Studentlitteratur Lund Lunell Hans 2003, Fyra rundor med RUP, Studentlitteratur Lund
