Uppsala Universitet, Användarcentrerad systemdesign 5p HT04. ebegravning, grupp 7. ebegravning.

Transkript

1 ebegravning Uppsala Universitet HT2004 Användarcentrerad systemdesign 5p. Ett arbete av Mattias Baecklund maba6803 Johan Herdegård johe0261 Viveka Sjöblom visj8680 1/ 10

2 Innehållsförteckning Förkortningar...3 Kortfattad beskrivning av den användarcentrerade processen...3 Collaborative requirements dialogue...3 Domain modeling...4 Task modeling...4 Interface content modeling...4 Implementation modeling...4 Usability inspection...4 Projektplan...5 Projektbeskrivning...5 Förutsättningar för portalen...5 Kravdialog...5 Användarmodellering...6 Centrumroller...7 Användarrollsdiagram...7 Uppgiftsmodellering...8 Innehållsmodellering...8 Visuell design...9 Användbarhetsinspektion...9 Dokumentation och hjälp...10 Tidsplan...10 För och nackdelar i tillvägagångssättet...10 Fördelar:...10 Nackdelar: / 10

3 Förkortningar SFU, Software For Use av Lucy A.D Lockwood och Larry L. Constantine RUP, Rational Unified Process ACSD, Användarcentrerad systemdesign av Jan Gulliksen och Bengt Göransson Kortfat t a d beskrivning av den användarcentrer ade processen Software For Use (SFU) riktar sig som bok till utvecklare inom mjukvaruindustrin med ett koncept för att skapa den bästa utgångspunkten för att lyckas med sin användarcentrerade utveckling. Den röda tråden genom hela processen är att skapa modeller av verkligheten och föra dialog i samförstånd med användarna. Nedanstående bild visar SFUs bild av hur ett projekt löper över tiden. SFU poängterar att bilden inte ska misstas för att vara en beskrivning av vattenfallsmodellen eftersom iterationer under projektarbetet förekommer. De stjärnmarkerade punkterna ger de faser som enligt SFU ska involvera användare. Som synes enligt bilden ingår inte de verkliga användarna i alla steg vilket kan tyckas märkligt enligt en användarcentrerad utvecklingsfilosofi. Collaborative requirements dialogue Collaborative requirements dialogue står i detta sammanhang för kravdialog på svenska. Främst handlar SFU om att bygga systemet utifrån samförstånd från samtliga involverade parter. Det första steget i utvecklings processen görs genom möten och informella sammankomster. Där arbetar involverade parter fram en kravspecifika tion utifrån det gemensam ma synsättet av vad systemet ska åstad komma. 3/ 10

4 Domain modeling Domain modeling översätter vi till domänmodellering. Det handlar om att analysera hela systemet, dvs världen och verksamheten utanför datorn. Detta för att bilda en uppfattning om hur dator systemet ska bli en naturlig del av organisationen. Domänmodelleringen är enligt SFU inte en användarcentrerad process men involverar användarna för att skapa bilden av domänens gränser. Task modeling Task modeling eller uppgiftsmodellering behandlar slutanvändarnas beskrivningar och synpunkter. Beskrivningarna dokumenteras som scenarion som raffineras till use cases, användningsfall genom iterationer. Utvecklarna arbetar tillammans med användarna fram modeller och användar roller med de metoder som finns beskrivna i SFU. Genom att approximera verkligheten till en mer lätt implemen terad återspegling fås en översiktlig modell av systemets uppgifter. Då representativa slut använd are saknas kan expert paneler generera fiktiva användare som substitut. Interface conten t modeling Gränssnittsmodellering. Efter att användarscenarion skapats påbjuder SFU en modellering av vad som ska ingå i gränssnittet. Detta kan göras i samband med Task content modeling för att anpassa de olika utvecklingsstegen till varandra. Varje användnings fall får en egen gränssnitts modell. En navigationskarta skapas utifrån dessa gränssnittsmodeller för att se hur de olika användnings fallen interagerar med varandra. Detta för att utvärdera den kognitiva belastningen och finna likheter i modellerna. Likheter kan ge modellsammanslagningar för att ge snabbare arbets flöde. Implementation modeling Implementationsmodell för realisering av gränssnittsmodelleringen genom att specificera layouten av det grafiska gränssnittet och definiera interaktionen mellan användare och systemet. Modellen utvecklas genom att bestämma hur användningsfallen tekniskt ska implementeras, vad som passar bäst utifrån de olika situationerna. Implementationsmodellen resulterar i utkast för den faktiskt implementationen. Usability inspection Användbarhetsinspektion. Utvärdera systemets användbarhet och kvalitet där slutanvändarna in volveras i processen. Detta steg med utvärdering är en återkommande process för att upprätthålla en genomgående kvalitets kontroll.vid avsaknad av slutanvändare kan en heuristisk utvärdering utföras av en expertpanel. 4/ 10

5 Projektplan Projektbeskrivning Företaget "ebegravning" eller grävnerdig.nu har som ambition att bli Sveriges första internet begravnings byrå. ebegravning kommer att erbjuda en möjlighet för användaren att utforma sin begravning via internet portalen. Tänkta användare är personer som går mot livets slut och ingår i den växande generationen med kunskaper om IT-användning. ebegravningsbyrån skall vända sig dels till dessa användare som själva vill planera sin begravning, men även underlätta vid planeringen då nära anhörigas bortgång är nära. Med hjälp av portalen ebegravning skall det vara möjligt att planera olika typer av begravningar, portalen skall alltså inte vara religionsberoende. ebegravningsbyråns funktionalitet skall vara användarcentrerad och detta uppnås genom att tillämpa utvecklingspedagogiken som SFU beskriver. De första delarna i utvecklingen vi valt att använda är tre aktiviteter som är tänkta att skapa en grundförståelse för ebegravnings - systemet, kravdialog, domänmodellering och uppgifts modell ering. Vidare för senare implementering har vi tagit upp gränssnittsmodellering, visuell design, hjälp och dokumentation och användningsinspektion. Förutsättningar för portalen ebegravning är ett nystartat litet företag och har därmed begränsade resurser vilket leder till att portalen skall utvecklas inom ramen för sin ekonomi. Utvecklingen sker från grunden då det inte redan finns någon internet portal med liknande funktionalitet. Det finns heller ingen redan existerande mjukvara som kan inkluderas. Företaget ebegravning förväntas bistå med webbserver och en fungerande hårdvara, bakom - liggande administration etc. Kravdialog I kravdialogen för vi en diskussion och förhandling mellan användare, kunder och systemutvecklare. I dialogen byggs ett samförstånd upp mellan beställare, utvecklade och användare, som leder till systemets krav kartläggs och en kravspecifikation skapas. Det är denna del som bildar själva kärnan i ebegravningssystemets användbarhet. Eftersom ebegravning kommer att vara en webbportal har utvecklingsteamet inte en naturlig kontakt med kommande användare. Mycket sjuka eller anhöriga till nyligen avlidna personer bildar inte en bra användar grupp för intervjuer och stöd under en så lång process som en systemutvecklingsprocess. Detta tillsammans med att diskussioner kring döden och begravningar är känsliga så väljer vi vad SFU beskriver som user surrogates, användarsurrogat. Användarsurrogat innebär att i stället för verkliga slut - användare till ebegravningssystemet väljer vi en vad vi kallar användarpanel som får representera dessa användare. Slutanvändarna kan vara svåra att finna genom etiska regler och därför tillsätts en användar panel som användarsurrogat enligt SFU. Att utvärdera begravningar är etiskt problem atiskt och kan vara svårt att utföra bland personer som precis har förlorat en nära anhörig. En bedömning om kraven är uppfyllda måste också ske genom en anpassad testpanel. 5/ 10

6 För att sätta ihop en användarpanel behövs Designer Begravningsofficianter inom olika religioninriktningar samt borgerliga cermonier Begravningsbyrårepresent Kund Kravspecifikation Användarmodellering Användarroller är en abstraktion till användarnas verklighet och uppfattning av system - inter aktion en. SFU före språkar en dialog med representativa användare för att doku - mentera en samling ab straktioner av olika användarrollers behov, intressen, förut sätt - ningar, bete ende mönster och ansvar. Dessa abstraktioner förfinas av utvecklarna till olika an vändarroller genom ett antal itera tioner. Utveck larnas modell måste under varje iteration bekräftas av användar - panelen för att vara säkra på att modellen är korrekt enligt an vändarna. Viktigt att veta är att dessa roller inte är verkliga personer eller yrkestitlar från levande per soner, utan en abstrakt klass av dessa som inter agerar med systemet. Utvecklarna måste i samråd med användarpanelen arbeta fram användarroller genom samtal. Användarrollsmodelleringen måste ske så tidigt som möjligt under utvecklings - arbetet för att bilda korrekt uppfattning av användarnas verklighet innan implement - erings modelleringen. Om denna modellering på börjas för sent finns risk att hela projekt - ets tidsplan påverkas om utvecklings arbetet ska skötas användarcentrerat. Det är trots allt denna användarpanel som agerar systemanvändarna och därav måste dessa personer befinna sig i centrum under denna utvecklingsfas. Enligt SFU poängteras dock två extremismer av samarbetspartners vars agerande bör stävjas eller begränsas. Den ena att användarna ofta blir överkörda av ut vecklarna eftersom utvecklarna kan upplevas veta alltför väl vad som är bäst för an vändar na. Detta kan medföra att användarna förblir passiva utan in vändningar till vad utvecklarna modellerar. SFU:s andra extremism, näm ligen att användare kan vara alltför entusiastiska och dikterar villkoren för utvecklingen trots att de saknar tekniska kunskaper för att ett användar centrerat samarbete ska vara givande. Som alltid när det handlar om arbete med människor gäller att ha finger topps känsla för att hitta sam - arbets partners med fungerande gruppdynamik. Åter till SFU:s röda tråd, utvecklingen måste ske i samförstånd av alla berörda parter. SFU påpekar att alltför frekvent utnyttjande av användarna kan trötta ut dessa och generera ett ointresse för vidare förfrågningar. För att minska utmattningen av användarna måste dessa omedel bart eller snarast möjligt få uppskattning, bekräftelse och gensvar på sina uppoffringar. Detta p.g.a. människans psykologiska behov av att känna tillfredsställelse efter utförda sysslor. För att konkret komma framåt i vårt rollmodellerade behövs följande frågor ställas under diskussionen med användarna: 6/ 10

7 Vem kan tänkas använda systemet? Personer som redan tänker att på sin hänfärd och kanske saknar nära anhöriga diskutera saken med. Personer som känner ansvar att inte belasta sina nära och kära med sin bortgång. Vilken är den generella användarkategorin av systemet? Personer som finner sig i känslomässigt tillstånd att ta ansvar för sin egen begravning. Vad avgör hur de ska använda systemet? Tekniska resurser, uppfattning om hur en beställningshemsida fungerar. Vad behöver de från mjukvaran? Återkoppling av sina handlingar på internetportalen. Hur beter de sig i förhållande till mjukvaran? Sorgsna, bedrövade, frustrerade. Hur förväntar de sig att mjukvaran ska uppföra sig mot dem? Tillmötesgående som en traditionell begravningsfirma. När dessa punkter är utredda skapas en bild av systemanvändaren. Olika roller kan tänkas växa fram och snarlika sådana grupperas för att organisera doku men tationen för att minska risken för att duplicera data. Om rollerna är snar lika kan dessa slås samman för att minimera dokumentations bördan och under lätta rollhanteringen. De kvarvarande rollerna namnges med tydliga namn för att minimera risken att samma roll senare kan hamna under annat namn. Samtliga roller gås igenom och utvärderas till samtalets involverade parter är överens att dessa är systemets användarroller. När dessa roller är fastslagna fortsätter arbetet till att finna Focal roles. Centru m roller Användarroller Centrumroller eller SFU:s Focal Roles, innebär att finna de användarroller som har största nyttan för att driva gränssnittsdesigen framåt. Bara ett fåtal av användarroller har den digniteten att utmärka sig som speciellt återkommande, tekniskt- eller ur affärsperspektiv viktiga. Utifrån de utvalda rollerna dras gränssnittets riktlinjer. Centrala användarroller Använda rrollsdia gra m Då antalet användarroller kan bli stort underlättar ett användarrollsdiagram (User role map) över blicken av systemdesignen. Ett användarrollsdiagram använder en grafisk notation för att beskriva olika rollers beroenden till varandra. SFU nämner inte vilken notationsstandard som skall användas, bara att det är möjligt att grafiskt återge användarnas roller. Användardiagram 7/ 10

8 Uppgifts mod elle ring Utifrån användarrollerna påbörjas genereringen av användingsfall. En användare vet sällan svaret vid frågan om hur ett arbete utförs. Därför börjar också uppgifts modeller - ingen (task modeling) med att finna vad som ska utföras, inte hur. SFU pekar på olika lösningar beroende på projektets storlek. Flödes diagram är ett vanligt förekommande arbetssätt för att abstrahera arbetsuppgifter, men SFU höjer dock ett varningens finger eftersom flödesdiagram blir genom sin natur stela och sekventiella. På grund av sin sekventiella utformning är flödesdiagram bättre för maskiners handlande än människors. SFU förespråkar s.k. essential use case som också ibland kallas business use case. Dessa användnings fall utvecklas utifrån scenarion och är enligt SFU ett mer användar - centrerat arbetssätt efter som an vändaren ger ett scenario från sin arbetssituation. Scenarion komprimeras genom att irrelevant information tas bort och det centrala för användningen finns kvar. Ur dessa utvinns den viktiga abstrakta in formationen som blir till an vändnings fall. I vårt fall med ebegravning innebär detta att användarpanelen framlägger arbetsmönster och be skrivningar till systemutvecklarna vad som behöver utföras för att genomföra planering av en be gravning. De essentiella användarfallen beskriver interaktionen mellan en användarroll och systemet utan att binda utvecklingen till någon teknisk lösning p.g.a. sin abstraktion. Det essentiella användarfallet försöker beskriva användarrollens intentioner istället för att beskriva dess handlingar. Genom denna förenkling och kompakta format blir användningsfallen lätta att förstå för personer med olika bak grund och kompetens, vilket ger den positiva sidoeffekten att många fler än endast systemutvecklare och datorinteraktionsexperter kan tolka användningsfallen och har möjlighet att komma med utvecklings förslag. Eftersom företaget ebegravnings kunder är (fortfarande levande) människor och vår ambition är att driva utvecklingen användarcentrerat impliceras att essential use cases ska används enligt SFU:s förmaning för användarcentreringen. Innehållsmodellering Tydlig och övergripande beskrivning av systemets uppgifter När användarfallen är färdiga övergår systemutvecklaren till att börja modellera hur dessa ska representeras på skärmytan. Detta kallas gränssnittsmodellering. System - utvecklarna använder en enkel modell av papper och Post- It-lappar för att skapa den första övergripande systemdesignen. Post- It-lapparna är bra ur flera synvinklar. Det är lätt att ändra designen genom att flytta runt, lägga till och ta bort Post- It-lappar. Eftersom skissen ser så primitiv ut i förhållande till exempelvis en genomarbetad skärm - bild så har användarna enligt SFU en större benägenhet att föreslå ändringar av designen. Denna förändringsbenägenhet kommer i tron av att arbetet inte fortskridit speciellt långt och en ändring i tidigt projektskede är lättare att genom föra. (Vilket också är sant) Efter att gränssnittsmodellering är färdig arbetar systemutvecklarna vidare i projektet genom att skapa en grafisk navigationskarta av ebegravningsportalen. Då denna navigations karta fram ställs upptäcks lättare duplicerade gränssnittsmodeller än om 8/ 10

9 gränssnitts modellerna enbart är i textform. Om dupliceringar upptäcks kan dessa slås ihop till en gemensam webbsida på ebegravningsportalen. Vi kan även se till att navigations kedjorna inte blir för långa och därmed undvika lite kognitiv stress. Navigationskartor över systemets funktionalitet Innehållslista Pappersprototyper Visuell design När det visuella gränssnittet för ebegravning designas ska systemutvecklarna tänka på att alla kompo nenter ska komplettera varandra. Det vill säga, grafiken ska förstärka och klargöra texten och texten ska förstärka och klargöra grafiken. Om grafiken inte har något klart syfte så är den bara ett slöseri med skärmutrymme. För att text ska vara lättläst så ska det vara en klar kontrast från bakgrunden. Väldigt viktigt i vårt webbaserade system är att inte använda ett fixerat typsnitt utan ett typsnitt som kan varieras med webb - läsarens större- än funktioner (MSIE), så att äldre personer med dålig syn även kan använda systemet. Användbarhetsexperter Prototyper över systemet Användbarhetsinspektion ebegravning använder heuristisk utvärdering av systemet eftersom det är den typen SFU rekommen derar då representiva slutanvändare saknas. Den mesta valutan får utvecklingen om tre till fem testningsexperter utvärderar systemet oberoende av varandra och modell erna och prototyperna. Nielsen ger 10 regler, men dessa kan anpassas eller göras om för att passa det behov som vi har i vårt projekt. De experter som utvärderar programvaran är ackom panjerade av en obser verare. Det är en person ur utvecklings teamet som kan svara på frågor och för även anteckningar så att utvärderings experten slipper belastas med detta. Det är inte meningen att ut värderings - experten ska sitta och köra igenom alla innehållsmodeller, utan han/hon går igenom på det stora hela. SFU rekommenderar även en del andra metoder men de som inte är sämre än heuristisk utvärdering faller på att vi inte har några användare som vi kan tillgå. ebegravning kommer använda fokuserade inspektioner mot konsistensinspektioner. Dessa går ut på att en liten grupp utvecklare sätter sig och går igenom alla gräns snitts - element för att se att det finns en övergripande konsistens mellan dessa delar. Finner utvecklaren brister eller ingen konsistens får denne omarbeta för att finna en övergripande konsistens Testningsexperter Testningsprotokoll Testningsfeedback 9/ 10

10 Dokumentation och hjälp Dokumentationen av systemet ebegravning fortlöper kontinuerligt under hela projekttiden. Dokumentation och hjälp är till för att olika typer av uppgifter som understöd vid produktfrågor och användarhjälp. Dokumentationen består också av förklaringar av innehållet i själva programkoden för att underlätta framtida uppgraderingar och systemkorrigeringar. Tidsplan Manual Projektveckor Kravspecifikation Domänmodellering Uppgiftsmodellering Dokumentation och hjälp Kundbesök Interfaceskiss Utvekling underliggande funktionalitet Koppling mellan gränssnitt och funktionalitet Implementeringsmodellering Prototypkonstruktion Användbarhetsinspektion För och nackdelar i tillvägagångssätt e t Fördelar: Dokumentationsmängden Vid jämförelse med Rational Unified Process, (RUP) förespråkar inte SFU att alla steg i utvecklingsprocessen minutiöst måste dokumenteras. Uppfattnigen av SFU är att dokumentation inte är ett självändamål utan ska utföras med måtta. Systeminriktad utveckling Tyngdpunkten ligger mer på att utveckla ett användbart system än att involvera användarna i alla processer p.g.a. att det ligger i tiden. Förespråkar utveckling med papper och penna vilket ger en behaglig utvecklingsmiljö som är lätt för lekmän att förstå. SFU ger konkreta exempel SFU beskriver utförligt hur de beskrivna metoderna kan appliceras på exempel från verkligheten. (Mer än bankomater) Nackdelar: Användningsfall: Kan vara alltför abstrakta och svåra att förstå för lekmän (användarna) Svårt för utvecklarna finna de väsentliga användningsfallen Systemen blir inte mer användningsbara än användningsfallen, är användningsfallen inte bra blir systemet inte heller det 10/ 10