e-el Abstrakt. Erik Scholander Mikael Hedberg Marcus Grehag

Transkript

1 Institutionen för Informations Teknologi Uppsala universitet Användarcentrerad Systemdesign, 5 p HT 2005 Examinator: Inger Boivie Jan Gulliksen e-el Erik Scholander Mikael Hedberg Marcus Grehag Abstrakt. Uppsatsen beskriver kortfattat den process som beskrivs i Software for Use av Larry L. Constantine och Lucy A.D. Lockwood för att sedan använda den i ett fiktivt projekt. Projektet är att bygga ett system att hjälpa personer i sitt val av el-leverantör. Det presenteras vilka som förväntas producera vad i processen samt en övergripande tidsplanering.

2 Abstrakt Inledning Avgränsning Metod Kortfattad processbeskrivning Nyckelelement i ändningscentrerad design Processmodell Aktiviteter Modeller Inledande kravframtagning Uppgiftsframtagning Domänmodellering Användargränssnittsmodellering Implementationsmodellering Användarbarhetsutvärdering och utveckling Objektorienterad modellering Iterering Innehållsmässig utveckling Arkitekturell utveckling Utvärdering Miljöanpassning Stilutveckling Tidplanering Diskussion...11 Referenser

3 1. Inledning Vi vill beskriva, planera och diskutera processen för hur ett fiktivt IT-baserat system ska utvecklas. Detta system ska se till att kunder får det så lätt som möjligt i valet av el-leverantör genom att utveckla det på ett användarcentrerat sätt. Den utvecklingsprocess som användas är usage-centered design, utformad av Constantine & Lockwood. Uppsatsen redogör för de processer, aktiviteter, roller och levererbar data som förekommer, samt reflekterar över den valda processen i relation till det synsätt som förekommer i Gulliksen & Göranssons Användarcentrerad systemdesign. 2. Avgränsning Vi genomför inte själva systemutvecklingen utan tar bara fram en projektplan för det fiktiva projektet. Detta medför att vi inte levererar någon data i form av kravspecifikationer, användarfall, designdokument etc., utan endast beskrivit dessa och schemalagt arbetstid för dem i projektplanen. 3. Metod Vi har läst Constantine & Lockwoods bok Software for use och på så vis satt oss in i deras utvecklingsmetod för användningscentrerad design. Kapitel 4 består av en beskrivning av utvecklingsprocessen och dess beståndsdelar översiktligt. Därefter har vi applicerat denna metodik på det tänkta utvecklingsprojektet i kapitel 5-14 och skapat en projektplan. Denna projektplan innehåller alla viktiga moment, dess tidsaspekter och vem som ansvarar för dem. Slutligen diskuterar vi i kapitel 15 Constantine & Lockwoods metodik jämfört med det synsätt som förmedlas av Gulliksen & Göransson. Uppgiften som vi med utgång från litteraturen ska göra en projektplan för går ut på att ta fram ett system som gör det enklare för kunderna att välja elleverantör. Vi har utifrån detta gjort antaganden om att systemet skall utvecklas för att vara tillgängligt för alla privatpersoner med Internettillgång och ska fungera som en oberoende informationskälla i valet av elleverantör. 3

4 4. Kortfattad processbeskrivning 4.1 Nyckelelement i ändningscentrerad design Innan själva utvecklingsprocessen gås igenom kan det vara bra att vara medveten om de fem nyckelelement som Constantine & Lockwood har specificerat för användningscentrerad design. De skriver att användningscentrerad design innehåller fem stycken nyckelelement som tillsammans förbättrar användbarheten i system. Dessa element är: Praktiska design-riktlinjer Modelldriven designprocess Organiserade utvecklingsaktiviteter Iterativ förfining Mätning av kvalité Dessa nyckelelement kan vara bra att ha i bakhuvudet när man tar del av den användningscentrerade designprocessen. Även om dessa punkter inte alltid redovisas separat, så har det påverkat utformningen av de processer och aktiviteter som beskrivs nedan. 4.2 Processmodell Genomgående i Constantine & Lockwoods bok är den processmodell som visar utvecklingsprocessen med dess olika moduler eller aktiviteter. Den återkommer med jämna mellanrum och förklaras vartefter i boken. Figur 1 visar den slutliga kompletta processmodellen som innehåller hela det användarcentrerade synsättet. Detta är inte direkt någon metod, utan snarare en övergripande process som består av flertalet underliggande subprocesser som kallas aktiviteter. Detta ger ett ganska komplext intryck vi ska därför redogöra för modellens alla beståndsdelar. Till att börja med läses figuren av från övre vänstra hörnet diagonalt ner till högra hörnet, alltså i den riktning som tidspilen pekar. Varje rektangel utgör en delprocess eller aktivitet och dessa är placerade i kronologisk ordning efter tidspilen. Man kan se att flera aktiviteter utföra parallellt i den utsträckning det är möjligt. Rektanglarna går in i varandra för att symbolisera att det inte finns några skarpa gränser mellan aktiviteterna. Vidare så är vissa markerade med stjärnor, vilket betyder att användare kan vara inblandade i dessa processer, men det är inget måste. De rutade aktiviteterna markerar det basala och absolut nödvändiga grundpelarna i systemet. De skuggade aktiviteterna är inte centrala för just användningscentrerad design och kommer därför inte att behandlas lika ingående. 4

5 Figur 1. Processmodell över användningscentrerad design. 4.3 Aktiviteter Precis som vi beskrev i förra stycket så består det användningscentrerade systemet av flertalet aktiviteter. I detta stycke beskrivs dessa aktiviteter översiktligt för att ge en bättra bild av hela processen och dess komponenter. Man bör notera att mitten av figur 1 består av ett antal relativt kronologiskt ordnade aktiviteter som nu ska beskrivas. Parallellt med dessa löper även ytterliggare några aktiviteter som beskrivs därefter. Huvudprocessen inleds med tre stycken aktiviteter som syftar till att ta fram de grundläggande kraven för systemet. Den första aktiviteten är Collaborative Requirements Dialog. Denna kravdialog görs mellan utvecklarna och kunderna för att fastställa kraven för systemet som ska utvecklas. I detta steg kan även systemets framtida användare medverka. Därefter kommer Task Modelling som är en viktig grundpelare i användningscentrerad design. Syftet med denna aktivitet är att klargöra vilken typ av arbete som systemet ska stödja. Därför modellerar man arbetsuppgifter genom att plocka isär dem i deras beståndsdelar och strukturera upp dem. Samtidigt som man tar fram kraven och börjar rita upp hur systemet skall se ut så gör man en representation av hur systemet skall var uppbyggt, vanligtvis genom domänklassmodellen. Detta skapar en grund för utvecklingen för utvecklarna och kan förfinas genom den iterativa processen Architectural Iteration. Steget efter Task Modelling är Interface Content Modellering som står för användargränssnittets innehåll. I denna aktivitet ges en mer eller mindre abstrakt representation av användargränssnittets delar och interaktionen mellan dem. Oftast 5

6 modellerar man gränssnittets innehåll bara genom att rita klassiska pappersskisser. Går man vidare i processmodellen kommer man till Implementation Modelling, vars syfte är att ge utförliga prototyp- och designmodeller. Efterföljande Usability inspektion används för att testa användbarheten av i systemet genom att identifiera användbarhetsdefekter. Inspektioner går betydligt snabbare än vanliga tester och de kan utföras tidigare i utvecklingen. Aktiviteten förekommer på två olika platser i processmodellen, dels precis före implementeringen av systemet, dels direkt efteråt. Implementeringsfasen i sig består av två parallella aktiviteter: Concentric Construction och Architectural Iteration. Concentric Construction implementerar de s.k. essentiella användningsfallen (se 4.4). Vartefter som det kommer nya användningsfall implementeras de också, vilket gör att om man någon gång stoppar utvecklingen finns alltid de grundläggande funktionerna med i den senaste versionen. Architectural Iteration används för att kunna bibehålla den fungerande systemarkitekturen samtidigt som olika lager ändras och läggs till i programkoden. Vid varje iteration går programutvecklarna igenom strukturen på koden och dess grundläggande arkitekturbeslut. Detta görs för att kontrollera att den fortfarande duger och för att ev. förbättra delar av den. Parallellt med dessa tidigare modellerings- och designaktiviteter löper ytterliggare några aktiviteter. De två viktigaste är Operational Contextualization och Standards and Style Definition. Med hjälp av Operational Contextualization anpassar man systemets design till de förhållanden och den miljö där det verkligen ska användas. Att denna aktivitet går parallellt med utvecklingen kan ses som relativt radikalt för just denna metodik. Vanligtvis vägs användningsmiljöns egenskaper in väldigt tidigt i processen. Standards and Style Definition tar upp hur man ska använda de standarder och stildefinitioner som gäller i systemet. Istället för att besluta om dessa i början av utveckling, menar Constantine & Lockwood att man bör fortlöpande förbättra och förändra standarder och stilar under utvecklingsprojektets gång. 4.4 Modeller Användningscentrerar systemdesign innefattar totalt fem modeller som hjälper till att skapa en bild av användarna, deras arbete och användargränssnittet som ska stödja dem. De tre huvudmodellerna berör användarna, användning och arkitektur: role model relationen mellan användarna och systemet. task model strukturen på användarnas uppgifter. content model redskapen och materialet som användargränssnittet ska tillföra. Var och en av dessa modeller består i sin tur utav två delar: en samling av beskrivningar och en karta över dess inbördes relationer. För att göra designen komplett behövs två extra modeller: 6

7 operational model användningssammanhanget som systemet används i. implementation model den visuella designen av användargränssnittet samt beskrivning av dess funktion. För att skapa en bild av vilka användare som ska användare som ska nyttja systemet, skapar man ett antal användarroller och en karta med deras relationer. Därefter gör man en uppgiftsmodell i form av essential use cases och återigen en karta av deras inbördes relationer. De essentiella användningsfallen fungerar som mer abstrakta användningsfall, vilket gör dem mer flexibla mot förändringar av teknik och krav. För att ta reda på vilka redskap och materiel som behövs för att tillgodose dessa användningsfall använder man en interface context model tillsammans med en navigations karta som beskriver relationerna. Nästa steg är att anpassa designen till användningssammanhanget, vilket görs med hjälp av en operationsmodell. Till sist ger implementeringsmodellen ett konkret resultat i form utav en prototyp som visar hur det är tänkt att användargränssnittet ska se ut. Detta kan vara en pappersprototyp eller en mer komplex visuell designprototyp. Modellernas sammanhang kan överskådas i figur 2. Figur 2. Modellernas logiska samband. 5. Inledande kravframtagning Vi har valt att inleda analysarbetet med att ta fram de grundläggande kraven på systemet och vad det ska innehålla. Detta sker genom ett eller flera heldagsseminarier där experter inom området från konsumentverket och representanter från elbolagen tillsammans med utvecklarna för en diskussion om vad det tänkta systemet ska uppfylla. Anledningen till att inga personer som representerar elkunderna finns med i detta inledande skede, är att de inte har så stor kunskap om elbranschen och därmed inte så mycket att tillföra diskussionen. Kunderna har förmodligen heller aldrig använt något liknande system förut och vet nog därför inte riktigt vad dem vill ha. Då kan det 7

8 istället vara bra att ha med någon från konsumentverket som sitter inne med mer kunskap om ämnet och som också fungerar som en motvikt till leverantörernas intressen. Tanken är att minimera tidsåtgången för denna del så att man snabbt kan gå vidare och börja analysera användarna och deras behov. Informationen som produceras på seminarierna är tänkt att ge en grund för projektet och kommer att genomsyra alla kommande delar i utvecklingsprocessen. 6. Uppgiftsframtagning Denna fas i analysarbetet handlar som tidigare beskrivet om att analysera vilka slutanvändarna är, hur deras relation till systemet ser ut, samt vilka uppgifter som användarna utför och som systemet måste stödja. Därför blir det naturligt att de som faktiskt ska använda den färdiga produkten är med här och bidrar med sina åsikter. Precis som innan har vi tänkt att arbetet ska ske i seminarieform, fast uppdelat på två olika seminarieserier. I den första seminarieserien träffar utvecklarna endast personer som representerar kunderna och vid den andra seminarieserien byts kunderna ut mot personal från elföretagen. Vårt mål är att seminarierna ska resultera i så kallade user role models och essential use case models som senare är tänkta att fungera som input till designfasen av utvecklingsprocessen. En user role model är en abstrakt beskrivning av användarna i form av roller, där varje roll beskrivs utifrån alla aspekter (behov, intressen, förväntningar, beteenden och skyldigheter) som definierar dess relation till det tänkta systemet. En user role ska inte tolkas som en beskrivning av en specifik användare utan snarare som en beskrivning av en roll som kan spelas av flera användare. Essential use case models beskriver interaktionen mellan användarna och systemet. Essential usercases är till skillnad från konkreta användarfall inte teknikberoende och ser endast till den handlig som görs, inte i vilken kontext den sker. Detta gör att det är en större öppenhet för olika lösningar. 7. Domänmodellering Detta är en viktig del av konstruktionen, speciellt eftersom vi har valt att försöka undvika en arkitekturell iteration (se kapitel 10). I detta steg skapar vi specifikationer för hur interaktionen sker på programnivå. I kapitel 10 beskrivs objektorienterad programmering närmare. En grundläggande och framsynt planering krävs för att vi skall ha en god plattform att stå på för vår mjukvara. UML diagram är mycket användbart i detta område och många av dagens programmerare är mycket vana vid denna form av specifikation och passar bra för objektorienterad programmering. Det finns en väl framtagen standard för hur dessa UML diagram skall se ut. Dessa bör tas fram av programmerarna men behöver en god förståelse av hur systemet skall fungera innan de kan göra en bra planering som kan fungera väl för framtida utveckling. Det är därför viktigt att programmerarna finns representerade vid framtagningen av kravspecifikationen. 8

9 8. Användargränssnittsmodellering Efter att ha tagit fram användarroller och användarfall är nästa steg att ta fram en prototyp och användargränssnittsmodellering är ett första steg mot detta. Avsikten med detta är att skapa en navigering för hur systemet skall fungera. Software for Use menar att ett bra sätt är att skapa en abstrakt karta genom att tänka sig in i användarroller och användarfall och försöka se vilken information och funktioner som behövs var. Denna karta kan enkelt ritas upp genom post-it lappar på en tavla och pilar som visar svar- och händelseåterkopplingar. När man sedan har gjort en abstrakt karta över hur systemet skall se ut kan man skriva ner informationen i innehållslistor. Den här modelleringen passar perfekt till vår typ av projekt. Vi tror att anlita en expert på användbarhet skulle kunna hjälpa att få en välstrukturerad karta över hur systemet skall fungera och kunna spara in på kostnader i utvärdering- och utvecklingsfasen. Vi ser även brister i innehållslistorna och tror att ett UML diagram kan innehålla mer information och ge en bättre överblick över projektets kopplingar mellan olika delar. Vi kommer därför att spara ner vår användargränssnittsmodellering som ett, eller flera, UML diagram. 9. Implementationsmodellering Efter att ha bestämt vad som behövs innehållsmässigt blir nästa steg att skapa en första prototyp samt att bestämma hur användargränssnittet skall se ut. Constantine och Lockwood påpekar flera gånger att användandet av ikoner är starkt överanvänt och svårförståeliga ikoner ofta har en hög inlärningstid. Eftersom våra användare kommer ha en mycket begränsad inlärningstid för att inte hoppa över användningen måste den vara mycket intuitiv och lättförstådd. Väl valda ord som menyer och knappar kommer fungera bättre. 10. Användarbarhetsutvärdering och utveckling. Enligt Software for Use utvecklas programvara kontinuerligt även efter det att den släppts och det är viktigt med återkoppling och utveckling både i utvecklingsfasen och i förbättrigsfasen. Men hur implementerar man användarcentrerade designer och hur vidareutvecklar man mjukvaran efter det att den släppts? 10.1 Objektorienterad modellering Innan vi beskriver denna iterationsprocess behövs lite bakgrundsinformation om hur objektorienterad programmering fungerar. Objektorienterad programmering är utmärkt för projekt av större modell och det gör det lätt för flera programmerare att samarbeta. Utan att gå in allt för detaljerat in på objektorienterad programmering kan man säga att det är lätt att hålla programmet och gränssnittet separata. Programdelen byggs upp av klasser ifrån vilka man kan göra objekt, detta gör det enkelt att genom en noggrann planering i början modifiera funktioner i objekten samt lägga till funktionalitet utan att det påverkar andra objekt. Dvs programmet går tämligen lätt att stycka upp i delar som enkelt går att vidareutveckla individuellt utan att behöva ändra på andra delar. Ett problem är dock att allt eftersom objektorienterad programvara utvecklas gång på gång så är det troligt att det visar sig att den ursprungliga 9

10 arkitekturen för hur objekten interagerar inte längre. För att effektivt kunna utveckla mjukvaran vidare så måste man börja om från början med kodningen Iterering Metoden Constantine och Lockwood förespråkar bygger på en itereringsprocess som börjar med utvärdering för att sedan fortsätta med både innehållsmässig samt arkitekturell utveckling för att sedan avslutas med en utvärdering Innehållsmässig utveckling Angående den innehållsmässiga utvecklingen har Constantine och Lockwood verkligen en bra poäng. Man utvecklar programmet och lägger till nya features med användarfall eller användarroller i åtanke. Om ny funktionalitet läggs till är det troligt att de kanske inte kan användas fullt ut för att annan funktionalitet saknas om den nya funktionaliteten inte lagts till med ett syfte i åtanke. Om ny funktionalitet i stället läggs till i hela set med ett nytt användarfall eller användarroll i åtanke kommer funktionaliteten vara mer täckande, det underlättar även för marknadsföringen av produkten Arkitekturell utveckling Vi håller dock inte med om de fördelar som Constantine och Lockwood beskriver angående arkitekturell utveckling. De anser att istället för att behövs bygga om projektet från grunden efter mycket utveckling kan man kontinuerligt bygga om arkitekturen. Idén är god men den får oss ifrågasätta om författarna har utvecklat projekt på detta sätt, deras idé är inte heller underbyggd med någon forskning på området eller studier som skulle påvisa att detta skulle vara effektivt. Att kontinuerligt ändra arkitekturen skulle påverka koden i andra objekt drastiskt vilket skulle kräva att om man ändrar i ett objekt måste man kontrollera att alla andra objekt är kompatibla med de ändringar som gjordes i ett objekt. Det står i bjärt kontrast med ursprungsidén om objektorienterad programmering. Inte skulle det bara kräva att varje ändring i arkitekturen gör att all kod måste gås igenom, och därigenom förlänga tiden det tar för att lägga till nya funktioner, så skulle det även troligen öka risken för, och antalet, buggar avsevärt. Vi har därför valt att inte använda oss av Architectural Iteration Utvärdering Software for Use förespråkar användningen av expertutvärdering starkt och vi är benägna att tro att det är ett bra sätt att hitta fel. Vår första utvärdering kommer därför att ske med hjälp av 3 användbarhetsexperter som oberoende får utvärdera användbarheten för vårt system. Vi tror att de kommer att finna merparten av de brister som kan komma finnas i vårt system och efter att ha gjort de nödvändiga ändringarna kommer vi göra ett betatest. Användartester kan vara svåra att få bra feedback ifrån men då systemet inte kommer vara särskilt komplicerat tror vi att vi kommer att kunna få nödvändig feedback från 10

11 användare. Vidare kan en större betatestning testa skalbarhet och systemet under stress. Kontinuerligt kommer vi att söka hjälp från experter på det innehållsmässiga planet, dvs från konsumentverket. Detta för att försäkra oss om att standarden på den information vi ger ut kommer vara hög samt att vi kan använda det i marknadsföringssyfte. 12. Miljöanpassning Eftersom det tilltänkta systemet är tänkt att kunna användas av alla så måste vi även se till så att det är användbart för personer med annat modersmål än svenska och personer med handikapp, så som synskadade. Därför krävs det att systemet finns tillgängligt på flera språk samt att det är anpassat för att vara navigerbart för synskadade eller blinda. De synskadades riksförbund tror vi kan vara till stor hjälp i denna aktivitet. När det gäller att göra systemet tillgängligt på flera olika språk måste vi ta hjälp av översättare. 13. Stilutveckling Hemsidan för detta projekt måste utvecklas för att ge ett seriöst och oberoende intryck. För att se till att detta uppfylls behöver en god standard utvecklas och följas, all text måste även kontrolleras genomgående för att vara av en viss kvalitet. De som skriver in text som är synbar för användaren måste därför besitta vissa skriftliga färdigheter och får inte implementeras av vem som helst. Själva stildesignen av hemsida låter vi utvecklas av en design grupp och kommer utvärderas i utvärderingsfasen. 14. Tidplanering Vecka Inledande kravframtagning Uppgiftsframtagning Domänmodellering Användargränssnittsmodellering Implementationsmodellering Användarbarhetsutvärdering och utveckling. Miljöanpassning Stilutveckling Hjälpsystem 15. Diskussion Metoderna kan vid första anblick ses lika ut men vid närmare studie finner man flera skillnader. En övergripande skillnad är att Software for Use är användnings centrerad medan Användarcentrerad Systemdesign är användarcentrerad. Risken med att vara 11

12 för användningscentrerad är att man kan missa behoven hos användarna och kanske istället fokuserar för mycket på att lösa specifika uppgifter. En annan markant skillnad är datainsamling. Medan Constantine och Lockwood menar att det effektivaste sättet att inta information är genom inledande seminarier menar Jan Gulliksen och Bengt Göransson att man bör inta information från användarna genom studier, observationer och intervjuer hos användarna. En stor risk med att insamling genom seminarier istället för att studera användarna är att de berättar hur det är tänkt att de ska göra och inte hur de faktiskt gör. Genom studier av användarna kan man tydligare observera hur användarna använder systemet och se de problem som faktiskt finns. Processen skiljer sig något också, speciellt i den iterativa processen där Software for Use börjar med en stor datainsamling, gör en prototyp och förfinar sedan detta system genom utvärderingar och förslag. I Användarcentrerad Systemdesign är hela processen iterativ, från datainsamling till prototyp. Dessutom är skapandet av prototyper i sig självt en iterativ process. Vi tror att det kan vara farligt att inte låta användarna vara del i utformningen av den första prototypen såsom Constantine och Lockwood förespråkar. Båda processerna leder till att projekten byggs upp i lager men vi tror att den modell Constantine och Lockwood förespråkar lätt kan missa användarbehov eller eventuellt ny användargrupper. Jan Gulliksen och Bengt Göranssons modell gör en djupare användaranalys i varje iteration och får därigenom en bättre förståelse av användarnas behov, istället för att endast be användarna ge återkoppling och förslag till det nuvarande systemet. Kanske låser sig användarna fast i det nya systemet och kommer inte med out of the box -idéer. Detta producerar troligtvis ett bättre och mer användarvänligt system men kan också leda till ökade kostnader och implikationer för systemutvecklarna. Användarinvolvering i den iterativa processen är ett måste för återkoppling och utveckling, men mer djupgående användaranalys kan bli kostsamma. Kanske är den metod som Constantine och Lockwood ger en bra mjukstart för de som inte är vana att arbeta på ett användarcentrerat sätt. Men vi tror att den mer renodlade användarcentrerade utvecklings processen som Gulliksen och Göransson presenterar resulterar i bättre programvara. 12

13 Referenser Constantine, L. & Lockwood, L. Software for use 1999, USA: Addison Wesley, Inc. Gulliksen, J. & Göransson, B. Användarcentrerad systemdesign 2002, Lund: Studentlitteratur 13