IT-systemutvecklingen är inte problemfri. Enligt Chaosrapporten, som visserligen är från 1995, var det endast 16,2 % av IT-projekten som ansågs lyckade. Således är det viktigt att utföra tester och utvärderingar både under utvecklingen av IT-system och vid redan utvecklade system. Även arbetsmiljölagen sätter krav på IT-utvecklingen. Användaren har rätt att påverka utvecklingen om systemet berör hans eller hennes arbetsuppgift. Av detta skäl är det viktigt att involvera användaren vilket görs i användartestet. I den heuristiska utvärderingen kan användaren användas som
utvärderare men eftersom metoden används för att spara pengar och därigenom inte bör ta de anställdas tid så är det något motsägande. Om fördelarna med den heuristiska metoden går förlorade kan ett användartest genomföras med samma ekonomiska resurser. I JMS fall är kostnaden för två anställda låg och därigenom kan de anställda deltaga utan att det kommer kosta JMS några betydande summor.
De anställdas motivation och förtroende för det framtida systemet stärks genom att de får ha en betydande roll i valet mellan systemen. Detta är något jag kan tänka mig underskattas av
verkställande chefer. Eftersom det är användarna som ska använda systemet finns det ingen poäng med att köpa in ett system som inte är användarens självklara val. Detta kan skapa missnöje som till viss del är onödigt då det är lätt att involvera användaren. Samtidigt kan det hävdas att användaren inte alltid vet bäst, detta kan jag hålla med om då de kanske inte ser hela bilden av situationen. Trots detta är det viktigt att få med sig användaren som bör vara positivt inställd till systemet. Jag vill inte påstå att manipulation är något som ska användas i någon större utsträckning men jag kan förstå om ansvarig ändå försöker få de anställda enade i riktning med besluttagarna. I JMS fall är ekonomin en viktig del i beslutet och de anställda har egentligen ingen inblick i vad de olika systemen kostar. Eftersom ekonomi i högsta grad har en betydande roll för beslutet kan det vara farligt att blanda in användaren om det uppstår en situation där användaren vill utveckla ITIS men verkställande chef anser att det kommer kosta för mycket. Då har de ansvariga involverat användaren men samtidigt inte handlat i samråd med användarens önskemål. Då kan användaren tappa förtroende för systemet och underminera chefens auktoritet. Det finns inga rätt eller fel och beroende på hur situationen ser ut får man se till den och handla därefter.
Den heuristiska utvärderingen är 25 518 kr billigare än användartesten vilket är relativt stor skillnad. Detta går i samma linje som teorin där Nielsens undersökning visar på att i större systemutvärderingar kan företagen spara upp emot 500 000 dollar. Systemvetaren Dan Kjellman uppskattar att ITIS skulle kosta runt 60 000 kr att utveckla och om användartesterna kostar 33 668
kr är det mer än hälften av utvecklingskostnaden. Den heuristiska undersökning kostar 8150 kr och är betydligt billigare och har därigenom en stor fördel som utvärderingsmetod. Kostnaden för användartestet kan diskuteras då jag själv och Magnus inte är några erfarna konsulter och därigenom antagligen har jobbat fler timmar med användartestet än vad en erfaren konsult hade gjort. Jag har dragit av fyra timmar som kompensation men det är svårt att uppskatta vad som är rimligt. Samtidigt är detta något som även påverkar den heuristiska utvärderingen.
Men varför väljer ansvariga personer användartester som testmetoder om de är mycket dyrare än en heuristisk utvärdering? För att få svar på frågan får man se till resultatet av undersökningen. I ett användartest mäts användbarheten utifrån användarna och därmed får det ett tillförlitligt resultat. En heuristisk utvärdering är däremot beroende på expertisen hos utvärderarna, en kvalificerad gissning som inte inger samma tillförlitlighet som ett användartest. Trots detta anser jag att den heuristiska utvärderingen fungerar bra. Den diskussion som följde i utvärderingen gav inte bara en inblick i den komplexa situationen JMS befinner sig i utan även en handlingsplan att utgå efter. De båda metoderna gav resultat som skiljde sig förvånansvärt lite från varandra. En sak som bör belysas är de mätbara parametrar som ett användartest genererar. Mätbara parametrar är bra, till exempel fungerar de bra i ett utvecklingsarbete rörande ett IT-system då systemutvecklarna kan göra förändringar och mäta resultatet av dessa och jämföra mot tidigare resultat. Detta kan i viss mån även appliceras i en heuristisk utvärdering, men eftersom den baseras på personers åsikter är resultatet inte lika tillförlitligt. Utvärderarna förändras över tid och är inte samma person vid de olika testtillfällena. Vidare kan man diskutera om det verkligen har någon betydelse då både system och personligheter utvecklas och det intressanta är egentligen om systemet är användbart eller inte. Trots att användartesterna hade mycket mätmaterial att diskutera blev det samma resultat som i den heuristiska utvärderingen. Det som skiljde diskussionerna åt var att den heuristiska
utvärderingsdiskussionen handlade mycket om förtroende hos användaren och den ekonomiska situationen, medan användartestdiskussionen behandlade vilket system som var lämpligast utifrån kraven och funktionerna. På det stora hela var resultatet mycket lika varandra. Om jag får sticka ut hakan kan jag påstå att den heuristiska utvärderingen var en korrekt gissning och användartestet var facit som bekräftade svaret. Från en kritisk vinkel borde jag ha börjat med den heuristiska
utvärderingen och sedan genomfört användartestet för att se om den kvalificerade gissningen var korrekt. Nu gjorde jag tvärtom och det kan ha påverkat resultatet eftersom jag redan hade en någorlunda uppfattning om resultatet i användartestet. Samtidigt försökte jag i den mån jag klarade av att inte påverka utvärderarna i den heuristiska utvärderingen. Men frågan är hur mycket jag omedvetet påverkade testpersonerna i den heuristiska utvärderingen.
Användartestet innehöll både en användarintervju och en enkät. Detta gjordes för att se vilken metod som passade bäst eller om båda metoderna ska användas parallellt. Jag ser ingen funktion i att använda en enkät så länge användardeltagandet inte gör att mängden deltagare utesluter intervjuer på grund av tiden det tar i anspråk. Ett användartest kan genomföras med eller utan instruktör och om en instruktör eller testledare inte används kan enkäter användas. I JMS fall kunde enkätfrågorna bäddas in i intervjun som då även möjliggör att man kan be respondenterna att motivera sina svar. Enligt Gulliksen m.fl. är det svårt att genomföra en enkät med fullgott resultat och det krävs ofta beteendevetenskapliga experter för att utveckla en bra enkät. Detta kan jag till viss del hålla med om men i JMS fall var frågorna enkla och de svar vi fick gav oss en bra inblick i vad testdeltagarna tyckte. Däremot tror jag att vi hade fått mer nytta av att bädda in frågorna och på sätt få en större bild av testdeltagarnas åsikter. När en enkät är av större karaktär och behandlar fler aspekter än vad jag behandlade i JMS fall ökar även svårighetsgraden på enkäten.
Det finns en viss oenighet kring hur många fel heuristisk utvärdering klara av att identifiera. Detta är något som främst berör systemutveckling och inte om situationen, som i JMS fall, är sådan att man väljer mellan tre olika system. Dock anser jag att den bör presenteras då den trots allt påverkar den heuristiska utvärderingens helhetssyn från branschen. Nielsens 75-95 % felidentifiering går inte i samma linje som de 44 % som Desurive, Kondziela och Atwood har fått fram. Detta beror enligt Joakim Snygg möjligtvis på ett visst eget intresse från Nielsen men även att utvärderarnas kunskap om användbarhet varierar. För att identifiera fler problem kan experter användas, men dessa kostar även pengar och är svårare att få tag i. En intressant aspekt är om siffrorna av undersökningarna hade varit liknande när situationen är som i JMS:s fall. Hur hade en expert resonerat i förhållande till mina utvärderare. Detta är något som vore intressant att forska vidare i. Det fanns en viss problematik runt att hitta personer som var villiga att ställa upp. Eftersom VD:n själv inte var delaktig i projektet fanns inte den outtalade auktoriteten som var nödvändig för att de anställda skulle känna sig tvungna att ställa upp. Samtidigt är det i viss mån förståligt då de
anställda fick använda en timme av sin arbetstid till att utvärdera IT-system istället för att avverka de åtaganden som de är tvungna att göra. Istället krävdes en viss övertalan och vi fick nöja oss med de personer som ville ställa upp. Dock är dessa fortfarande representativa för slutanvändaren. De två personer som deltog i den heuristiska utvärderingen valdes efter de kunskaper och erfarenheter de hade av användbar webbutveckling. Personerna var ur kostnadsperspektiv billiga samtidigt som de hade en viss erfarenhet inom ämnet. Jag anser inte dessa personer som experter men fortfarande invigda i ämnet.
Vidare kan oenigheten kopplas till hur trovärdig en heuristisk utvärdering verkligen är. Om det inte finns konsensus i branschen om hur bra en heuristisk utvärdering är finns det kanske fler problem med metoden som inte är identifierade och troligtvis behövs det mer forskning inom området och i synnerhet när situationen är som i JMS’s fall. En heuristisk utvärdering är utformad för att
identifiera problem och inte för att generera information om vilket system som är lämpligast utifrån ett specifikt fall. Detta utesluter inte metoden som ett bra redskap för en sådan situation då jag tror skillnaden är relativt liten. Däremot måste IT-chefer och andra verkställande personer se till metoden och skillnaden på att identifiera problem och diskutera vägval i form av systemutveckling eller systeminköp. Jag tror att en heuristisk utvärdering passar lika bra till att identifiera problem i systemutveckling som i att basera beslut om systeminköp. När utvärderarna identifierar problem får de också en inblick i systemen och vilket system som anses vara mest lämpligt utifrån krav och användbarhet. Samtidigt finns det möjligheter att informera om de ekonomiska aspekter där utvärderarna kan få en inblick i de resurser som finns till förfogande. Styrkan i den heuristiska utvärderingen ligger i diskussionen. Den diskussion som genererades i min undersökning var mycket givande och intressant. Därför tror jag att en heuristisk utvärdering är lämplig i en situation likt JMS, just för att problemet och valet borde diskuteras.
7 Slutsats
När ansvarig person sätts inför ett beslut om att investera i ett IT-system och måste utvärdera vilket system som ska köpas in eller utvecklas fungerar en heuristisk utvärdering bra. Ett fullständigt användartest är dyrare och resulterar i ett annat svar. Det är också svaret som avgör vilken metod som är lämplig. En välutförd heuristisk utvärdering genererar en diskussion som är mycket användbar medan ett användartest ger ett resultat om användbarhet som måste värderas och diskuteras ytterligare. I vår heuristiska utvärdering kom vi fram till en handlingsplan med tre olika vägar att välja, medan användartestet gav mig en rangordning av systemen i form av användbarhet. När situationen är sådan att de tre systemen är väldigt lika och uppfyller samma funktion kan ett användbarhetstest vara att föredra då det ger utvärderaren ett slutligt svar utan ytterligare
diskussion. Dock är situationen sällan så enkel och komplexiteten gör att en heuristisk utvärdering är bra då den ser till helheten och inte endast användbarheten samtidigt som metoden är billigare. Om resurser finns eller om investeringen är av större karaktär kan båda metoderna kombineras. Jag kan konstatera att även om heuristisk utvärdering endast är en kvalificerad gissning är metoden i min undersökning fullgod som utvärderingsmetod. Vidare anser jag att ytterligare forskning bör genomföras för att verkligen se till helheten och få mer klartext huruvida metoden fungerar eller inte.
Referenslista
7.1 Litteratur
Andersen, Erling S, 1994: Systemutveckling, Lund: Studentlitteratur
Befring, Edvard, 1994: Forskningsmetodik och statistik, Lund: Studentlitteratur Dalen, Monica, 2007: Intervju som metod, Malmö: Gleerups Utbildning AB Denscombe, Martyn, 2000: Forskningshandboken, Lund: Studentlitteratur
Dumas, Joseph S, Redish, Janice C, 1999: A practical guide to usability testing, Wiltshire: Cromwell Press
Eriksson, Ulf, 2007: Kravhantering för IT-system, Danmark: Studentlitteratur
Gulliksen, Jan, Göransson, Bengt, 2002: Användcentrerad systemdesign, Lund: Studentlitteratur Halvorsen, Knut, 1992: Samhällsvetenskaplig metod, Lund: Studentlitteratur
Hökenhammar, Peter, 2001: Integrerad Beställningsprocess vid Datasystemutveckling, Edsbruk: Akademitryck AB
Lunell, Hans, 2003: Fyra rundor med RUP, Lund: Studentlitteratur
Norman, Donald A, 1998: The Design of Everday Things, New York: Basic Book Nielsen, Jakob, 1993: Usability Engineering, San Diego: Academic Press
7.2 Artiklar
Fitcher Darlene, Maj/juni 2004: Heuristic and cognitive walk-through evaluations. Online Desurvire Heather, Kondziela Jim, Atwood Michael E 1992: What is gained and lost when using
methods other than empirical testing. ACM New York, USA
Tajakka Santto, 2004: ISO 9241-11, standarden för användbarhet. http://www.santai.nu/artiklar/iso.htm
Snygg Joakim, Kompromisser i användbarhetsutvärdering. http://people.dsv.su.se/~joak-sny/plugg/usab_test.pdf
7.3 Internet
2010-06-04: http://www.useit.com/papers/heuristic/heuristic_list.html 2010-07-26: http://verva.24-timmarswebben.se/master.html?http://verva.24-
timmarswebben.se/verksamhetsstod/webb/vl24/anv/default.htm 2010-07-26: http://www.ne.se/heuristik
7.4 Intervjuer
2010-07-02: Kjellman Dan, Systemvetare 2010-06-17: Inuse Consulting AB
8 Bilaga 1
Intranätet Microsoft Share point
1. Hitta Magnus Wigrups e-‐postadress.
2. Lägg till en stationär dator knuten till Johannes Karlsson. Datornamn: semodjohkar
Placering: Modemgatan (SEMOD) IP-‐nummer: 192.168.204
Leverantör: Mac Support Tillverkare: Apple Modell: iMac
Serienummer: 2383 OS: annat
3. Flytta Magnus Wigrups bärbara MacBook från Modemgatan (SEMOD) till Djäknegatan (SEDJA).
4. Radera den stationära dator som är knuten till Johannes Karlsson (den dator du lade till i uppgift 2).
ITIS
1. Hitta Ola Luthanders e-‐postadress.
2. Lägg till följande artikel och knyt till Ola Luthander (logga in med användarnamn: admin och lösenord: admin):
Typ: Kreditkort Modell: Visa
Artikelnummer: 4581 1234 1234 1234 Avdelning: Modemgatan
Notering: Kreditgräns 1 000:-‐
3. Ändra Ola Luthanders bärbara Delldators artikelnummer från 5674 till 1000 för att Ola lättare ska kunna komma ihåg det.
4. Ola Luthanders bärbara Delldator är numera för gammal för att användas. Radera denna ur systemet.
Hogia PA
1. Hitta Bo Hanssons mobiltelefonnummer.
2. Peps Persson har precis fått en ny bärbar MacBook Pro. Denna dator ska registreras, knuten till Peps, i Hogia PA.
3. Britt Spjut har missbrukat sin förmån med kreditkort och hennes kreditgräns ska därför sänkas från 10 000 kr till 5 000 kr. Redigera detta i systemet.
4. Ola Luthander har kört och krockat med sin Suzuki Swift, det blev skroten för den. Radera den ur systemet.