E-val. Användningscentrerad systemdesign enligt Constantine & Lockwood. UPPSALA UNIVERSITET Uppsala

Transkript

1 UPPSALA UNIVERSITET Uppsala Användarcentrerad systemdesign, 5p. Projektuppgift ACSD Handledare: Stefan Blomkvist m.fl. Grupp 1: Anna Engbom, Pernilla Gürbüz, E-val Användningscentrerad systemdesign enligt Constantine & Lockwood

2 2 Innehållsförteckning Inledning 3 Systemdesign. 3 Aktivitetsmodellen för användningscentrerad design 3 Uppdrag E-val 6 Projektplan. 6 Samarbetskravsdialog 7 Domänmodellering 7 Uppgiftsmodellering.. 7 Gränssnittsinnehålls modellering... 7 Implementations modellering Användbarhetsinspektion.. 8 Koncentrisk konstruktion.. 8 Arkitektonisk iteration.. 8 Operationell kontextualisering. 8 Hjälpsystem och dokumentation 9 Standards och stildefinitioner. 9 Tidsplan. 9 För- och nackdelar.. 10 Källförteckning 11

3 3 Inledning Denna projektuppgift inleds med en koncist och övergripande beskrivning av den användningscentrerade process som beskrivs i Software for use av Constantine & Lockwood. Därefter följer en beskrivning av hur vi skulle planera genomförandet av ett användarcentrerat projekt, E-val, i enlighet med ovanstående litteratur. Till sist beskrivs för- och nackdelar med processen som framförs i Software for use, i relation till vårt projekt. Systemdesign Processerna inom användarcentrerad och användningscentrerad systemdesign skiljer sig åt på ett större sätt än vad namnen urskiljer. Användarcentrerad systemdesign är en process i vilken användare, mätbar användbarhet och iterationer står i fokus genom hela utvecklingsprocessen. Speciellt är en aktiv användarmedverkan viktig för att få ett användbart 1 system. Användningscentrerad design däremot är en modellbaserad utvecklingsprocess som inriktar sig på användningen av systemet, dvs. hur systemet på bästa sätt kan vara ett stöd i användarnas arbete. Användarna är inte lika delaktiga eftersom dessa anses försvåra och göra utvecklingen av systemet mindre effektivt. Aktivitetsmodellen för användningscentrerad design Constantine & Lockwood beskriver denna användningscentrerade process som följaktligen inriktar sig på att utveckla mer användbara system som skall underlätta arbetet för användaren. Denna modelldrivna designprocess involverar användarna endast under vissa delar av processen. Modellen består av olika aktiviteter och dessa utförs i den ordning och omfattning som lämpar sig bäst för det aktuella projektet. Dessa kan utföras parallellt eller överlappa varandra, alternativt kan det förekomma projekt där en del aktiviteter är överflödiga, i andra fall kanske samtliga är nödvändiga. Användningscentrerad design erbjuder sålunda en flexibel modell som hjälp vid utvecklingen av system vilka underlättar användarens målhantering. Författarna har åskådliggjort denna modelldrivna process genom en aktivitetsmodell för användningscentrerad design, figur 2-2. Denna figur skall läsas snett uppifrån och ner, från vänster till höger. Användarmedverkan är markerad med stjärna. En kortfattad beskrivning av denna process ges nedan. 1 ISO

4 4 Samarbetskravsdialog (Collaborative Requirements Dialog) är en specialiserad konversation och förhandling mellan utvecklare, användare och klienter för att upprätta kraven för systemet som ska konstrueras. Resultatet blir en kravspecifikation som modifieras under processens fortlöpande aktiviteter. Uppgiftsmodellering (Task Modeling) är kärnan i en användningscentrerad designprocess. I denna aktivitet skapas en modell av vilka uppgifter som systemet skall stödja. Detta kan göras genom användarrollsmodeller och olika användarfall. Domänmodellering (Domain Modeling) utvecklar en representation av alla interrelaterade koncept och konstruktioner i applikationsdomänen i form av en domänklassmodell. Domänmodelleringen upprättar en ordlista för systemet och dess operationer. Gränssnittsinnehållsmodellering (Interface Content Modeling) organisation av användargränssnitt på en abstrakt nivå. Implementationsmodellering (Implementation Modeling) process för skapandet av en detaljerad design och för att göra prototyper av användargränssnittet. Användbarhetsinspektion (Usability Inspection) testning, inspektion och granskning är tre olika sätt att utvärdera användbarheten i systemet. Det finns metoder som inkluderar användarna medan andra förfaringssätt inte gör det. Koncentrisk konstruktion (Concentric Construction) en aktivitet för att utveckla fungerande system i lager, dvs. varje ny funktionalitet implementeras i prioritetsordning. Denna aktivitet är parallell med arkitektonisk iteration.

5 5 Arkitektonisk iteration (Architectural Iteration) en iterativmetod för att upprätthålla en bra mjukvara vartefter fungerade lager adderas till systemet. Operationell kontextualisering (Operational Contextualization) målet med denna är att anpassa designen till de faktiska operationella villkoren och miljön i vilket systemet ska utvecklas. Eftersom detta är användningscentrerad design börjar man här med uppgiftsmodelleringen och sedan anpassas användargränssnittet till den aktuella användarmiljön. Objektstrukturerad design (Object Structure Design) Objektorienterat arbetssätt. Hjälpsystem och dokumentation (Help System and Documentation) Aktuell under hela utvecklingsprocessen. Dokumentationen är nedskrivna beslut som fattas under processen och hjälpsystemet är ett sätt att i förtid kontrollera vad användarna kan behöva hjälp med, var de kör fast osv. De essentiella användningsfallen som har producerats tidigare är här en god källa. En manual produceras, samt hjälpfunktioner inne i systemet. Standards och stildefinitioner (Standards and Style Definition) Aktuell parallellaktivitet under hela utvecklingsprocessen. Dessa uppstår från kravspecifikationen och från systemets eventuellt redan tidigare utvecklade designmönster. Viktigast är dock att inte börja med standardisering av systemet innan det är klart vad systemet skall kunna utföra. Denna aktivitet riskerar annars att förbises eller att komplicera till processen i onödan.

6 6 Uppdrag E-val Valmyndigheten har gett oss i uppdrag att planera ett användarcentrerat projekt för att utveckla ett framtida system som klarar av genomförandet av val med hjälp av modern informationsteknik och telekommunikation. Inför en kommande konsultupphandling planeras hur detta projekt skall kunna genomföras. Vid planering av detta projekt skall följande beaktas: Olika typer av val skall kunna genomföras: EU-val, riksdagsval, val till kommun och landsting, folkomröstningar och lokala omröstningar. Extremt hög användbarhet eftersom alla röstberättigade måste kunna genomföra sitt val, antingen traditionellt eller med det nya systemet. Säkerheten valfusk på grund av tekniska brister får under inga omständigheter förekomma. Flexibilitet olika teknikplattformar som möjliggör olika sätt att rösta med olika perioder för röstning. Extremt många användare, teknisk personal, valarbetare och röstare. Se exempelvis röstberättigade 2 till val vid riksdags-, landstingsfullmäktig- och kommunfullmäktigvalen nedan. Röstberättigad vid riksdags-, landstingsfullmäktig- och kommunfullmäktigvalen är svensk medborgare, som har fyllt eller fyller 18 år senast på valdagen, är upptagen i röstlängd samt är folkbokförd i landet. Utlandssvensk har rösträtt endast till riksdagen och är svensk medborgare, har fyllt eller fyller 18 år senast på valdagen, någon gång varit folkbokförd i Sverige och är upptagen i röstlängd. Medborgare i någon av Europeiska Unionens medlemsstater (unionsmedborgare) samt medborgare i Island och Norge har rösträtt till landstings- och kommunfullmäktigvalen under samma förutsättningar som svenska medborgare. Övriga utländska medborgare har rösträtt i landstings- och kommunfullmäktigvalen om de har varit folkbokförda i Sverige tre år i följd före valdagen. Projektplan Denna projektplan är ett exempel på hur den användningscentrerade process som beskrivs i Constantine & Lockwood kan användas för projektet E-val. Förutom utvecklare, designers, användare och representanter från valmyndigheten, finns under hela processen en projektansvarig och en användbarhetsdesigner närvarade. Nedan kommer en översiktlig figur med de aktuella aktiviteterna i vår process. visar att aktiviteten involverar användare. Läses på samma sätt som Constantine & Lockwood aktivitetsmodell ovan. 2

7 7 Domänmodellering Samarbetskravsdialog Operationell Kontextualisering Uppgiftsmodellering Grässnittsinnehållsmodellering Implementations modellering Användbarhetsinspektion Koncentrisk konstruktion Arkitektonisk iteration Användbarhetsinspektion Hjälp- System Och Dokument Standards och stildefini- Samarbetskravsdialog Arbetet inleds med konversation mellan utvecklare, användare, och en ledningsgrupp från valmyndigheten för att upprätta kraven för systemet som ska konstrueras. Resultatet blir en kravspecifikation som modifieras under processens fortlöpande aktiviteter. Domänmodellering Modellerar verksamheten, förutsättningar och metoder undersöks. Utvecklar en domänklass modell. Domänmodelleringen upprättar en ordlista för systemet och dess operationer. Utvecklare, designers, ledningsgruppen och användare är inblandade. Uppgiftsmodellering Uppgiftsmodelleringen beskriver hur en uppgift utförs stegvis. Scenarios, essentiella användningsfall och användningsfallsdiagram skapas. De essentiella användningsfallen skapas utefter kravspecifikationen. Användningsfallsdiagrammen ger en tydligare bild av de uppgifter (identifiering/in- utloggning, rösta etc.) som systemet skall klara av. Denna aktivitet involverar utvecklare, designers, användare och ledningsgruppen. Genom att kartlägga uppgiftsstrukturen som användarna skall klara av framkommer också de säkerhetsåtgärder (mot valfusk, systemunderhåll, felhantering etc.) som måste vidtas. Dessa behandlas utförligt och dokumenteras vidare i aktiviteten Hjälpsystem och dokumentation. Gränssnittsinnehålls modellering Organisation av användargränssnitt sker här på en abstrakt nivå. Det viktiga här är att inte låsa sig vid för mycket detaljer kring gränssnittets utseende. Papper, post-it lappar, whiteboard tavlor eller annat som finns till hands används för att göra enkla skisser. Post-it lappar kan

8 8 vara att föredra eftersom dessa lätt kan omflyttas och på så vis ge möjlighet till nya synvinklar på hur upplägget av informationen skall vara. Inga grafiska detaljer eller beslut görs om det slutgiltiga gränssnittet. Slutprodukten i detta skede består av abstrakta beskrivningar av interaktionsmiljöernas uppbyggnad, innehåll och deras inbördes relationer. Designers, utvecklare, användare och ledningsgruppen samarbetar under detta stadium. Implementationsmodellering Olika teknikplattformar genomgås och granskas av utvecklarna. En detaljerad design skapas och prototyper görs av användargränssnittet, designers och utvecklare gemensamt. Denna aktivitet itereras kontinuerligt med användarna genom användbarhetsinspektionen. Iterationen avslutas när kompletta interaktionsmiljöer har skapats. Användbarhetsinspektion Användarna testar systemet under observation av utvecklarna och designers så att användbarhetsproblem kan upptäckas. Här sker inspektion av att kravspecifikationen efterföljs. Dokumentation i form av utvärderingsresultat produceras. Även beslut om flera iterationer skall genomföras tas här. Tidsutrymme finns för högst fyra iterationer, det ultimata är att få iterera till dess systemet är perfekt. Detta är dock i princip omöjligt pga. skenande kostnader och att tidsfrister löper ut. Koncentrisk konstruktion Genomförs parallellt med arkitektonisk iteration. Varje inkrement lägger till eller förbättrar funktionalitet till systemet. Detta sker i prioritetsordning och ansvaras av utvecklaren. Det är lättare att ha kontroll, förstå och testa systemet när det byggs upp en bit i taget. Arkitektonisk iteration Denna aktivitet är nödvändig att köra parallellt med koncentrisk konstruktion, för att det skall vara möjligt att upprätthålla en bra mjukvara vartefter fungerade lager adderas till systemet. Systemet förblir lätthanterligt och effektivt vad gäller uppdatering och systemunderhåll. Kostnaderna blir annars för höga om hela systemet måste göras om helt vart fjärde år när det är val eller vid annan omröstning som sker däremellan. Utvecklaren ansvarar även för denna aktivitet. Operationell kontextualisering I denna aktivitet anpassas designen till de faktiska operationella villkoren och miljön i vilket systemet ska utvecklas. Hur dessa villkor och miljö kommer att se ut är i projektets början omöjligt att veta. Detta är något som kommer att växa fram under processens gång. Viktigast är de facto att man kan lägga sin röst och således inte om färgerna i gränssnittet matchar. Det spelar heller ingen roll om systemet utvecklas i en mycket fashionabel miljö systemet, ty om

9 9 användaren inte kan identifiera sig får han inte rösta. Denna aktivitet sköts tillsammans av utvecklare och designers. Hjälpsystem och dokumentation Denna är en viktig aktivitet som är aktuell under hela utvecklingsprocessen. E-valet har ett extremt högt krav på säkerheten valfusk får pga. tekniska brister under inga omständigheter förekomma. Utvecklare har här till sin hjälp användare som de kan observera. Användaren utför vissa uppgifter som utvecklaren dokumenterar. En manual i pappersformat skapas med stegbeskrivningar av systemets funktioner. Även en användbarhetsguide med de aspekter som är viktiga för användaren skapas. De essentiella användningsfallen som har producerats tidigare är här en god källa. Standards och stildefinition Är en aktiv parallellaktivitet under hela utvecklingsprocessen. Dessa uppstår från användbarhetskraven i kravspecifikationen och ur valmyndighetens eventuellt redan tidigare utvecklade designmönster. I samråd med utvecklare, designers och användare skall dessa utvärderas. Tidsplan Detta är en översiktlig planering av tidsåtgången av projektet. Erfarenhetsmässigt så brukar inte den planlagda tiden räcka till. v. 1 3 Samarbetskravsdialog v. 2 4 Domänmodellering v Operationell kontextualisering v Uppgiftsmodellering v Gränssnittsinnehålls modellering v Implementations modellering v Användbarhetsinspektion v Standards och stildefinition v Koncentrisk konstruktion v Arkitektonisk iteration v Hjälpsystem och dokumentation v Användbarhetsinspektion

10 10 För- och nackdelar Vi har i vårt projekt utgått ifrån Constantine & Lockwood på vissa punkter, detta till trots skulle vi vilja göra lite fler modifikationer. Aktiv användarmedverkan saknas och användarna är inte ens involverade i alla aktiviteter. Constantine & Lockwood har valt detta tillvägagångssätt eftersom de anser att användarna inte besitter all nödvändig kunskap som krävs i vissa aktiviteter, t.ex. i gränssnittsinnehållsmodelleringen. Själva utvecklingsprocessen tar säkert kortare tid, vilket betyder lägre kostnader för ett system som till mycket hög grad infriar användarnas önskemål med uppgiften. Detta arbetssätt har tyvärr stora brister såsom bland annat tråkig layout, dålig feedback och ringa hjälpfunktioner. För att komma tillrätta med dessa problem väljs istället en användarcentrerad process till projektet. I vårt fall får vi då istället modifiera om processen något. Arbeta inkrementellt genom hela processen och inte bara i implementations modelleringen. Detta medför att brister upptäcks på tidigare stadium och kan rättas till utan någon större ekonomisk förlust. Detta är mycket viktigt i vårt E-val projekt enär säkerheten är extremt viktig. Utan inkrementell utveckling riskerar brister i systemet upptäckas för sent. Dessa kan då vara omöjliga att åtgärda med resultat av att projektet måste starta från början. Kontinuerliga användbarhetsinspektioner hade gett ett mer användarcentrerat system utan att för den delen blanda in användarna i så hög grad att de hade försenat projektet allt för mycket. Vi anser att flera sådana här inspektioner bara skulle ha gjort systemet mer användbart. Till slut skulle vi också vilja ta med riskanalysen som Gulliksen och Göransson tar upp i boken Användarcentrerad systemdesign. Denna analys saknas helt som en egen aktivitet i Constantine & Lockwood, men med hänsyn till att vårt projekt är så stort och kostsamt vore det en trygghet för projektet och de inblandade aktörerna om ett sådant dokument skapades. Projektets deltagare reagerar mindre panikartat om de tidigare gått igenom olika tänkta problemscenarios och dess lösningar. Något positivt om Constantine & Lockwood är de essentiella användningsfallen i vilka fokus ligger på vad användaren försöker uppnå, inte hur. Detta sätt att skriva användningsfall ger fler sätt att lösa problemen eftersom man slipper fastna i sitt tankesätt.

11 11 Källförteckning Constantine, Larry L. & Lockwood Lucy A.D; Software for use - A practical guide to the models and methods of usage-centered design, ACM Press, New York Gulliksen Jan, Göransson Bengt; Användarcentrerad systemdesign, Studentlitteratur, Lund 2002.