Projektuppgift ACSD ht 2004 E-dagis enligt Constantine & Lockwood (Software for Use)

Projektuppgift ACSD ht 2004 E-dagis enligt Constantine & Lockwood (Software for Use) Grupp 4: Henrik Kriisa, Henrik Andersson, Erik Andersson 13 december 2004 E-post: henrik.kriisa.2165@student.uu.se, henrik.andersson.1861@student.uu.se, erik.andersson.6345@student.uu.se 1

Innehåll 1 Inledning 3 2 Förutsättningar 3 3 Grundläggande frågeställningar 4 4 Modellering 4 5 Användargrupper 5 6 Tidsplan 6 7 Det praktiska genomförandet 6 8 Aktivitetsöversikt 7 9 Kravdialogen 7 10 Uppgiftsmodellering 8 11 Domänmodellering 9 12 Design av objektstrukturen 10 13 Standarder och riktlinjer 10 14 Hjälpsystem och dokumentation 11 15 Situations- och miljöanalys 11 16 Gränssnittsmodellering 11 17 Implementationsmodellering 13 18 Den första användbarhetsutvärderingen 13 19 Användningsfallsbaserad konstruktion 15 20 Iterativ utveckling 15 21 Den andra användbarhetsutvärderingen 15 22 Slutresultat 16 23 För- och nackdelar 17 2

1 Inledning Användningscentrerad design består av fem huvuddelar som tillsammans kan förbättra användbarheten hos mjukvara. Dessa fem delar är: pragmatiska designriktlinjer, en modelldriven process, organiserade utvecklingsaktiviteter, iterativa förbättringar samt mått på kvalitét. (På engelska: Pragmatic design guidelines, Model-driven design process, Organized development activities, Iterative improvement och Measures of quality). Pragmatiska designriktlinjer är till för att hjälpa designers att fatta förnuftiga beslut när det gäller utveckling av användbara system, att det färdiga systemet ska vara lätt att lära, lätt att komma ihåg, eektivt, pålitligt samt tillfredställande att använda. Med en modelldriven designprocess menas att utvecklarna ska använda modeller för att lättare förstå användarna och på så vis göra mer användbara system. Den del som kallas organiserade utvecklingsaktiviteter behandlar vilka steg själva utvecklingen ska följa och i vilken ordning. Figuren nedan ger en visuell presentation av processen.! User involvement Systemutveckling leder sällan direkt fram till den produkt man hade tänkt sig och därför är iterativa förbättringar viktigt. Dessa innebär att systemutvecklingen görs i era steg för att användbara system ska bli resultatet i slutändan. Kvalitétsmåtten innebär att det nns stöd för utvärdering av användargränssnittens kvalité som utvecklarna kan använda sig av. 2 Förutsättningar Då projektets möjlighet att bli lyckosamt bygger på att användarna verkligen upplever systemet som användarcentrerat ser vi det som mycket viktigt att användarna kan vara med och delta i utvecklingsprocessen fullt ut genom hela projektet. Därför är Krylbodas löfte om att ställa upp med ett testdagis av väsentlig betydelse för hela projektet. Mertid som krävs av användarna är svårt att förutsäga varför kostnadskalkylen bygger på att kommunen fullt ut står för dessa kostnader. Vårt företag antas bestå av cirka tiotalet anställda, varav för detta projekt 3

avsatts fyra systemutvecklare där samtliga har en god kompetens och erfarenhet av användarcentrerad utveckling. På detta sätt undviker vi behovet att behöva ta in externa konsulter för att få in denna för detta projekt så nödvändiga kompetens. 3 Grundläggande frågeställningar För att lösa uppgiften med att ta fram ett e-dagis på ett användarcentrerat sätt måste vi besvara ett antal grundläggande och viktiga frågeställningar: Vilka är användarna och hur kommer de relatera till systemet? Vilka uppgifter ska användarna lösa i systemet som utvecklas? Vad behöver de från systemet för att fullfölja deras uppgifter och hur ska de organiseras? Hur är de rådande förhållandena under vilket systemet ska användas? Hur ska användargränssnittet se ut som och hur ska det bete sig? 4 Modellering Grundelementet i vår användningscentrerade systemutvecklingsprocess är modeller. Genom modeller kan vi eektivt och kortfattat sammanfatta svaren till dessa frågor. I utvecklingsprocessen använder vi oss av en kärna med tre enkla modeller som addresserar frågorna kring användare, användning och arkitektur: Användningsmodell (Role-model) -Relationerna mellan användarna och systemet Uppgiftsmodell (Task-model) - Strukturen av uppgifterna som användarna behöver för att lösa uppgiften. Innehållsmodell (Content-model) - Består av verktyg och innehåll som ska tillhandahållas användaren genom användargränssnittet. Modellen ska organiseras i användbara samlingar som i sin tur relaterar till varandra. Kärnmodellerna utökas sedan med två ytterligare modeller, den operationella (operational model) samt implementationsmodellen (implementation model) som används för specikation kring design av användargränssnittet. 4

! " # $ % & ' ( ) ( * + ( * $ # (, Rollmodellerande För att förstå vilka användare som ska använda systemet skapar vi en aktörsmodell där vi samlar de aktörer som ska interagera med systemet och skapar en översiktskarta där relationerna mellan dessa aktörer framgår. Uppgiftsmodellerande I uppgiftsmodellen tar vi fram grundläggande användningsfall och en karta över hur användingsfallen relaterar till varandra. Innehållsmodellerande Innehållsmodellerandet löser vi genom att nyttja en användningskontextmodell (interface context model) tillsammans med en navigeringskarta som denierar relationerna mellan de olika interaktionsutrymmena av användingsgränssnittets arkitektur. Situationsmodellering samt implementationsmodellerande Dessa modeller syftar till att ta fram själva gränssnittet och är därför mycket viktiga men ändå inte kärnan i den användningscentrerade systemutvecklingsprocessen. 5 Användargrupper För att lyckas med detta projekt kräver det att användarna verkligen tar till sig systemet och upplever att de kan arbeta med detsamma och få ut ett tydligt mervärde samt att den nedlagda arbetsinsatsen ska vara minimal. Ett dagis huvudsyfte är trots allt att ta hand om barnen och denna uppgift får inte försvåras avsevärt av detta dokumentationssystem. De användargrupper som är aktuella att ta med under utvecklingsprocessen är: Dagispersonalen, som antas vara de som slutligen kommer fylla på systemet med data om barnens utveckling. De bör också kunna ta del av tidigare inlagd data. 5

Barnen, som eventuellt också kommer interagera med systemet. Barnens speciella behov behöver specialstuderas om systemet också utvecklas för dem. Barn i denna ålder har troligtvis inte särskilt stor datorvana. Föräldrarna, vars mål är att kunna ta del av barnens utveckling är huvudsyftet med systemet. Administrationspersonal, som ska administrera systemet, lägga upp nya system för andra dagis, lägga till och ta bort konton med mera. 6 Tidsplan Att uppskatta en tidplan för detta projekt är svårt, men i grova drag har vi skissat på följande tidsplan: 1. Förstudie, ta reda på vad uppgiften egentligen består i, samt se om det överhuvudtaget går att lösa uppgiften med tilldelade resurser och tidsram, 1 månad. 2. Kalkylering och oert, kalkylering av projektet med riskanalyser och offertskrivande, 2 veckor. 3. Iterativ systemutveckling, själva utvecklingsprocessen, i halvfart under 12 månader. Syftet med att arbeta under halvfart är att öka möjligheterna till en användarcentrerad utveckling och hinna ta del av användarnas erfarenheter och synpunkter. 4. Reservtid, 1 månad. 5. Leverans, 1 månad. 7 Det praktiska genomförandet Ett av grundelementen i den användarcentrerade utvecklingen är den parallella utvecklingen (eller i varje fall möjligheten till parallell utveckling). Genom att arbeta med era områden parallellt undviker vi askhalsar men vi följer ändå i stora drag en huvudsaklig linje som enkelt kan beskrivas på detta sätt: 1. Modellera användarrollerna 2. Modellera de grundläggande användningsfallen 3. Ta fram en innehållsmodell med en navigeringskarta 4. Ta fram en pappersprototyp 5. Genomför en användbarhetsinspektion tillsammans med övriga inblandade i projektet 6. Förändra den graska designen och ta fram en fungerande prototyp genom att nyttja ett graskt utvecklingsverktyg. 6

8 Aktivitetsöversikt Den process vi följer består av tretton större delar: 1. Kravdialogen (Collaborative Requirements Dialog) En första dialog med alla inblandade om systemets syfte och tillhörande krav. 2. Uppgiftsmodellering (Task Modeling) Konstruktion av grundläggande användningsfall. 3. Domänmodellering (Domain Modeling) Konstruktion av UML-diagram. 4. Design av objektstrukturen (Object Structure Design) En av de tidiga programmeringsfaserna. 5. Standarder och riktlinjer (Standards and Style Denition) Huvudsakligen skapandet av standarder för gränssnittet. 6. Hjälpsystem och dokumentation (Help System and Documentation) 7. Situations- och miljöanalys (Operational Contextualization) 8. Gränssnittsmodellering (Interface Content Modeling) 9. Implementationsmodellering (Implementation Modeling) 10. Den första användbarhetsutvärderingen (Usability Inspection 1) 11. Användningsfallsbaserad konstruktion (Concentric Construction) 12. Iterativ utveckling (Architectural Iteration) 13. Den andra användbarhetsutvärderingen (Usability Inspection 2) I varje del går vi igenom vad aktiveteten går ut på i detalj samt hur det skulle bli för vårt dagis. 9 Kravdialogen Efter att ha fört de inledande diskussionerna och gått igenom förutsättningar och preliminära krav och tankar kring projektet går vi över till att börja jobba med kravdialogen. I denna fas samverkar alla inblandade parter för att tillsammans ta fram en kravspecikation som ska vara så hjälpsam och korrekt som möjligt. Vi tar med oss de inledande diusa idéerna kring projektet och försöker omsätta dessa idéer till informella krav som vi presenterar för de inblandade för att få värdefull feedback. Själva dialogen har givetvis också den en iterativ del, krav diskuteras, förkastas och förnas ända tills till någon form av konsensus uppnås eller det inte längre går att motivera att tillbringa mer tid i denna fas. I denna process jobbar vi antagligen med väldigt enkla pappersskisser och motsvarande, och vi tar själva hand om organiseringen av arbetet utifrån de resurser vi har blivit tilldelade. 7

Användarna är givetvis en viktig del av gruppen som ingår i dialogen, deras medverkan redan i detta tidiga skede kan underlätta avsevärt för utvecklandet av användarcentrerade system. Resultatet av fasen är förhoppningsvis en samling dokument av vilka merparten tillhör någon form av kravspecikation. För vårt projekt blir det huvudsakligen en diskussion med kommunen, personalen samt föräldrarna på pilotdagiset. Om barnen skall använda systemet bör nog även de vara med på något sätt, men att det kan antingen kräva en expert eller erfaren personal att kommunicera med dem på ett givande sätt. Även om man givetvis skulle önska att man kunde lägga ner hur mycket tid och arbete på denna fas som helst anser vi nog att den inte bör ta mer än två veckor. 10 Uppgiftsmodellering Uppgiftsmodellering kan ses som själva kärnan i den användningscentrerade processen. Syftet med detta modellerande är att få fram en tydlig och komplett bild av de funktioner som systemet ska stödja användarna med. Uppgiftsmodellering kommer logiskt efter användarmodelleringen men är också tätt sammanbunden med den och övriga delar i systemutvecklingsprocessen. Det går helt enkelt inte att lösa denna uppgift utan att samtidigt utveckla och förändra de närliggande andra processtegen. Uppgiftsmodellerandet i e-dagisprojeketet kan börja med att vi tar reda på vad användarna av systemet egentligen ska göra. Här räcker det inte med att enbart fråga användarna om hur de agerar idag när de dokumenterar barnens uppväxt, främst eftersom det nya systemet syftar till att dokumentera avsevärt mer än vad som sker idag - användarna har helt enkelt inte möjlighet att direkt svara på vilka uppgifter de ska utföra med det nya systemet. Det nns många olika sätt att modellera arbetet. Ett traditionellt tillvägagångsätt är att använda sig av någon form av ödesschema som beskriver uppgifterna i termer av logiska sekvenser av händelser eller processer. Detta förfaringssätt är detaljerat och konkret, men det är dock inte bra sätt att modellera uppgifter ur användarens perspektiv. Istället avser vi att ta fram uppgifterna genom scenarier och de nära angränsade användningsfallen. Scenarier kan ses som ett sätt att representera strukturen på uppgifterna och de framförs i formen av en historia, ett händelseförlopp, som utspelar sig i ett givet sammanhang. Att skriva scenarier påminner en hel del om historieberättande. Tätt ihopkopplade med scenarierna är användningsfallen, som kan beskrivas som: Beskrivningar av systemets funktionalitet Ett externt perspektiv, "black box" Berättande beskrivningar Interaktioner mellan användaren och systemet Delmängder av systemet som är kompletta och meningsfulla för användaren. Det är dock viktigt att våra användningsfall inte blir för detaljerade då syftet med användningsfall i uppgiftsmodellerandet är att få fram de grundläggande användningsfallen. 8

Constantine och Lockwood ger oss följande denition: An essential use case is a structured narrative, expressed in a language of the application domain and of users, comprising a simplied, generalized, abstract, technology-free and implementation-indedependent description of one task or interaction that is complete, meaningful, and well-dened from the point of view of users in some role or roles in the relation to a system and that embodies the purpose or intentions underlying the interaction. Ett grundläggande användningsfall är således baserat på det bakomliggande syftet eller intentionerna en användare har med sin interaktion. Den handlar alltså inte om de konkreta stegen eller mekanismerna. Detta är mycket viktigt för att inte låsa fast användningsfallen i begränsande designlösningar (ex: användaren loggar in i systemet genom att dra sitt magnetkort i en läsare och slår in sin fyrsiriga kod). Den logiska starten för att starta ett användningsfall är att utgå från användningsmodellen. Genom att undersöka användarrollerna kan vi ställa en mängd specicerade frågor angående respektive roll: Vad är det användarna i denna roll ska utföra? För att fullfölja denna roll, vad är det användarna behöver kunna göra? Vad är det för funktioner som behövs för att stödja användarna i denna roll för att de ska kunna utföra uppgiften? Det nns många olika vägar för att få fram en komplett bild över de grundläggande användningsfallen. Ett ofta använt sätt är helt enkelt att "brainstorma" vilka olika fall som nns och sedan utröna vilka av förslagen som ska anses som grundläggande. Först när detta är gjort är det dags att gå vidar och fylla rubrikerna med text. När användningsfallen beskrivs är det viktigt att hela tiden ställa sig kritisk till beskrivningarna. Vad är det användarna egentligen gör? Vad är det som de egentligen ska utföra? Varför? En viktig källa under uppgiftsmodellerandet är naturligtvis de tilltänkta användarna. De kan vara med och beskriva hur de gör idag för att lösa uppgifterna så att föräldrarna kan ta del av barnets uppväxt (i den mån det är relevant). Samtidigt är det som också påpekats också viktigt att inse att användarna troligen inte sitter på hela den kompletta bilden utan vi måste hela tiden själva vara kritiska och fundera på alternativa lösningar för att lösa de uppgifter som systemet ska göra på ett bra användarcentrerat sätt. I denna fas kommer vi troligtvis att jobba mycket med personal och föräldrar för att gå igenom de fall de tycker är viktigast och mest meningsfulla. Exempel på grundläggande användningsfall kan vara att personalen matar in teckningar som barnen har gjort eller att föräldrarna går in för att titta på sina barns teckningar. Vi förväntar oss inte att få alltför många grundläggande användningsfall att jobba med så vi tar oss tid och går igenom de vi har väldigt ordentligt. Denna fas beräknar vi ta omkring två veckor. 11 Domänmodellering Domänmodellering syftar till att få en bild av hur systemet ska se ut i form av objekt och relationer. Modellen ska deniera ett språk som ska kunna beskriva systemet och systemets funktion. Det kan åstadkommas med hjälp av en Entity Relationship Model(ERM) eller en Domain Class Model(DCM). 9

Här tänker vi bygga upp en bild av hur e-dagiset ska se ut med hjälp av en DCM som vi gör i UML och med utgångspunkt från kravspecikationen. Eftersom vi har erfarenheter av UML anser vi att vi inte behöver ta in någon till hjälp med detta utan vi räknar med att kunna hantera det själva. Modellen kommer först att skissas upp på papper för att sedan göras digitalt. Nu kommer vi även att behöva ta hjälp av användarna. Det är användarna som kan ge oss viktig information om hur de vill att systemet ska se ut, och vilket språk som kan vara lämpligt. Här har vi tänkt samla representanter ur användargruppen som vi använde i kravdialogen, dock inte nödvändigtvis samma personer som förut. Vi tänker föra en diskussion med användarna och bolla idéer, både från oss själva och från användarna, för att kunna skissa ner ett UML-diagram ger en bra representation av e-dagiset. Här räknar vi med att det tar omkring fem arbetsdagar att få ner en skiss som vi är överens om och sedan tar det en dag att föra över den till digitalt format. Som resultat kommer vi att få ett UML-diagram som vi kan använda senare i systemutvecklingsdelen av processen. 12 Design av objektstrukturen Designen av objektstrukturen är inte fullt så användningscentrerat i sig, men det använder sig i varje fall av de UML-diagram som vi tog fram i samråd med användare och andra intressenter. Vi bygger i denna fas upp en objektstruktur med en terminologi och med klassdiagram som hämtas från de UML-diagram vi utvecklade. Objektstrukturen är i sig ingenting som användare ska behöva bry sig om eller komma i kontakt med, men de kan i varje fall i någon mening hjälpa till att utforma en naturlig struktur. I likhet med de andra mer programmeringsnära faserna sköter vi det utan yttre inblandning. Det som produceras är alltså prototyp- eller pseudokod för att beskriva objektstrukturen för kommande faser, och vi beräknar att det ska ta omkring två veckor. 13 Standarder och riktlinjer För vår användningscentrerade process är det viktigt att de standarder (huvudsakligen för gränssnittet) vi följer är exibla. Att låsa sig vid en viss standard kan vara en begränsning som försämrar användbarheten genom att den förbjuder lösningar som skulle uppskattas av användare. Att standarderna är exibla innebär förstås inte att de skall ändras hela tiden, bara att användare och experter skall kunna komma med synpunkter som kan leda till att standarder förkastas eller förändras. Denna aktivitet löper parallellt med de esta huvudpunkterna i projektet även om det inte nödvändigtvis behöver innebära att vi konstant arbetar med våra standarder utan bara att vi alltid är beredda att göra det. Det som produceras är standarder och riktlinjer för hur systemet skall bete sig, och tidsplanen är beroende av de andra faserna. I vårt fall är det svårt att säga hur standarderna kommer att se ut eftersom det inte är klart hur systemet i slutändan kommer att vara utformat. På något sätt vill vi i varje fall utveckla ett ganska homogent system som ter sig naturligt både för personal, föräldrar och även barnen om det går. 10

14 Hjälpsystem och dokumentation En intressant sak med Constantine och Lockwoods användbarhetscentrerade aktivitetsmodell är att användarna inte är en del av utvecklandet av hjälpsystem och dokumentation. Klart är i varje fall att dokumentation är något som sker parallellt med i princip alla andra faser, och att vi knappast kan förvänta oss att användarna ska hjälpa till särskilt mycket med den saken. Arbetet med den dokumentation som ska användas av användarna (manualer och liknande) är någonting som vi vid behov anlitar professionell hjälp för. Det huvudsakliga manualarbetet påbörjas först mot slutet av projektet, och då nns förhoppningsvis tillräckligt mycket bakgrundsmaterial, skisser och liknande för att den eller de som utvecklar manualen ska kunna slutföra arbetet inom rimlig tid (kanske två-tre månader). Till skillnad från Constantine och Lockwood skulle vilja ha användarnas hjälp i utvecklandet av hjälpsystem, både till deras utformning och deras innehåll. (Det är förstås tänkbart att författarna betraktar detta som del av andra faser där användarna är inblandade). Det som produceras i denna fas är alltså huvudsakligen mängder av dokumentation som förhoppningsvis kommer till användning i alla andra faser under projektets gång. Till detta kommer en eventuell pappersmanual samt ett väl fungerande integrerat hjälpsystem. Någon särskild tidsplan nns alltså inte, denna fas pågår i princip från projektets början till dess slut. I vårt dagisfall behöver vi nog inte överdriva med dokumentationen, och i bästa fall behöver vi kanske inte ens någon manual. Eftersom vårt system inte behöver bli alltför komplicerat i termer av mängden funktionalitet tror vi att vi skall kunna utveckla ett system som i princip skall vara så enkelt att det inte behöver mer än en kort genomgång med svar på några vanliga frågor. 15 Situations- och miljöanalys Denna något diust namngivna aktivitet är ändå ganska viktig för processen och rör analys av användningssituationen och de begränsningar och möjligheter den medger. Användarna är inte avsedda att medverka direkt i denna analys, i stället är det vi som tar fram proler som täcker upp olika faktorer som påverkar användningen. De proler som tas fram används sedan som underlag för olika beslut i många andra faser. Denna fas löper också den parallellt med era andra och har därför inget fast schema. I vårt fall får vi förstås titta närmare på hur dagismiljön ser ut och ännu viktigare är kanske att ta upp barnens speciella förutsättningar om de är tänkta att använda systemet. 16 Gränssnittsmodellering I detta steg av processen ska vi göra en modell av det tänkta gränssnittet utifrån användningsfallen producerade vid uppgiftsmodelleringen. För varje användningsfall producerar vi en abstrakt representation i form av en modell som visar hur det kan se ut där användningsfallet utspelar sig Vi kommer att använda oss av pappersmodeller och post-it lappar eftersom det har visat sig vara det bästa. Visserligen kan det ligga nära till hands att 11

använda någon digital representation eftersom vi är ett IT-företag, och gärna använder oss av datorer, men vi kommer inte att använda det i interface modelleringen. I gränssnittsmodelleringen kommer vi inte att ta hjälp av användarna eftersom de har varit med i uppgiftsmodelleringen och utformat användningsfallen och vi nu bara gör en abstrakt representation av just dessa. Först går vi igenom varje användningsfall för att bilda oss en uppfattning av vilka verktyg och material som kan nnas för användarna i användningsfallen. Varje användningsfall får sedan ett separat papper som vi modellerar användningsfallet på. Vi sätter ett passande namn på modellen som återspeglar den funktion som användningsfallet beskriver. Detta namn behöver inte vara precis vad funktionen gör utan kan vara ett namn som användarna använder i vanliga fall. På pappret klistrar vi post-it lappar som representerar de verktyg och material som vi ck fram under den första genomgången av användningsfallen. Ett exempel skulle kunna vara att vi har en post-it lapp som representerar en ruta där det valda dagisbarnet har sitt foto. En fördel med att använda sig av post-it lappar är att vi enkelt kan ytta dessa för att ändra upplägget på interfacet. En annan är att det verkligen blir en abstrakt representation vilket vi vill åstadkomma här. Om modellen blir för lik en verklig implementation kan det vara lätt att vi låser oss vid ett visst upplägg. Å andra sidan blir det svårare för användarna att förlika sig med prototypen om den bara är gjord av pappersark och post-it lappar. I gränssnittsmodelleringen är det inte tänkt att vi ska ha med alla små detaljer utan vi ska skapa en abstrakt modell. Detaljerna kommer med i implementationsmodelleringen. Till den abstrakta pappersmodellen kommer vi att behöva ha en mer formell modell i form av text. Den passar sig bättre när vi ska kommunicera med andra om modellen som våra kunder och även om vi vill ha dokumentation. I textmodellen skriver vi ner namnen på de verktyg och material som post-it lapparna ska representera. Som rubrik använder vi namnet på pappersarket som vi bestämde tidigare. En viktig del som vi också kommer att behöva är en karta för att navigera mellan distinkta delar av systemet (på engelska: Context Navigation Map) som ska skapa en helhetsbild av alla modeller. Om vi gör många små och enkla modeller från användningsfallen blir det lättare för användarna att förstå varje modell men det blir svårare att representera mer komplexa uppgifter som användaren har. Kartan ska alltså representera relationerna mellan de olika modellerna, i vårt fall pappersmodeller. Som resultat av detta steg i processen får vi era pappersmodeller som representerar miljön där användningsfallen utspelar sig, dvs systemet. Vi får även en textrepresentation av detsamma och sist men inte minst en karta som ger helhetsbilden av modellerna och relationerna mellan modellerna. Det är svårt att se hur vi skulle behöva anpassa denna punkt till vårt projekt utan att designa något, men vi anser i varje fall att vi kan klara av att göra jobbet själva. Vi räknar med att detta steg i processen tar cirka två veckor. 12

17 Implementationsmodellering Nu är det dags att göra en prototyp med hjälp av de modeller och dokumentation som vi har från de tidigare stegen i processen. Det är möjligt att skippa detta steg med prototyper och gå direkt på konstruktionen av det verkliga systemet, förutsatt att vi har utvecklare som varit med i hela processen och som är erfarna. För vår del så har vi inte gjort några liknande projekt tidigare i vårt företag och vi anser då att vi måste göra detta steg. När vi ska göra vår prototyp skulle vi kunna jobba vidare med pappersmodeller och göra en prototyp med papper och penna (passiv prototyp). Vi känner att vi kan vara mer produktiva och förhoppningsvis skapa en bättre prototyp om vi jobbar interaktivt och tänker därför göra en webbaserad prototyp (aktiv prototyp). Här har vi egentligen era alternativ till prototyp. Vi skulle kunna göra en enklare prototyp i form av en mock-up i t.ex. PowerPoint. Vi skulle även kunna göra en enkel simulering med hjälp av Visual Basic eller Delphi men vi tycker att en direkt (begränsad) implementation är att föredra. Bakgrunden till detta är att vi har goda kunskaper i webbprogrammering och tycker att det blir lättare att göra en prototyp direkt i form av en begränsad implementation och lättare för användarna att se hur det verkliga systemet kommer att se ut. I implementationsmodelleringen kommer vi inte att ta hjälp av användarna. Här räknar vi med att kunna överföra de modeller och beskrivningar som vi har gjort tidigare till en prototyp. Vi tror även att vi kommer att kunna hantera detta steg i processen på egen hand. Fördelen med att vi gör en begränsad implementation är att vi inte lägger ner lika mycket arbete som med en verklig implementation och det är då lättare att ändra om något inte är bra vi kommande utvärdering. Är det en färdig implementation som ska utvärderas för första gången kan det vara mycket som inte är bra och eftersom mycket arbete är nerlagt kan det vara svårt att få igenom de ändringar som föreslagits. Ändringsförslag kan komma både från utvecklare och användare och i viss mån även speciella utvärderare. Viktigt att komma ihåg i detta steg är att det är här vi verkligen börjar se om vi har gjort ett grundligt och genomtänkt arbete vid de tidigare delarna i processen. Har vi inte det kommer det att bli svårt att översätta modellerna till en prototyp. Det kommer även att visa sig vid kommande utvärdering när prototypen presenteras för användarna. När det här steget är klart räknar vi med att ha en prototyp som ska kunna ge en bra bild av hur det färdiga systemet skulle kunna se ut i webbaserad form. Prototypen är nu klar och kan skickas vidare för utvärdering. Troligen kommer detta steg i processen att ta cirka två veckor. 18 Den första användbarhetsutvärderingen I användningscentrerad systemdesign nns det två stora utvärderingssteg i utvecklingsprocessen. Det första är det här steget som görs efter implementationsmodellering. Här ska prototypen som utvecklades i implementationsmodelleringen utvärderas. Utvärdering är ett viktigt steg i användningscentrerad systemdesign eftersom det är nästan omöjligt att få det rätt från början. Om vi inte har någon 13

utvärdering kommer troligen inte det färdiga systemet att vara användningscentrerat. Nu är det självklart att vi tänker ta användarna till hjälp. Vi tänker även ta en expert på användningscentrering till vår hjälp. Att få in en expert som inte har varit med i projektet från början kan ge värdefull information. Även om användarna inte tycker att en viss sak i prototypen är dålig kan en expert säga vad som eventuellt kan bli ett problem senare. Naturligtvis kommer vi även att utvärdera varandras arbete inom företaget och på så vis se designlösningarna utifrån era perspektiv. Vi kommer alltså att använda oss av expert(er), kollegor och användare vid vår utvärdering av prototypen. Utvärderingen med användarna kommer vi att göra med hjälp av scenarier som användarna ska utföra. Vi kommer under dessa scenarier (tester) att iaktta användarna och ställa frågor hur de upplever systemet. Vi kommer även att ställa frågor efter själva testerna där användarna kan i lugn och ro svara på frågor angående systemet. Scenarierna kommer vi att utforma utifrån de olika arbetsuppgifter som användarna vill kunna genomföra med hjälp av systemet. I vårt fall blir det då bland annat scenarier som handlar om att föräldrar ska kunna plocka fram viss information om sitt barn. Under vår användbarhetsutvärdering kommer vi att följa Jakob Nielsens heuristiska regler för användningscentrerad systemdesign. Det är fem huvudregler (se nedan) för användbarhet som vi tänker titta på när vi gör utvärderingen. Nielsens heuristiska regler är er än dessa fem men vi anser att de tillsammans med användarnas och expertens kommentarer kommer att ge oss en god bild av hur den verkliga implementationen bör se ut. Själva utvärderingen uppskattar vi att den kommer att ta cirka 14 arbetsdagar. Om vi märker att något steg inte blivit korrekt utfört får vi ta och gå tillbaka och xa till det för att sedan göra en ny utvärdering. När vår prototyp fått godkänt av oss själva, experten och användarna kan vi gå vidare med den verkliga implementationen. Efter detta steg har vi alltså en godkänd prototyp. Nielsens fem huvudregler: Tillgänglighet (Access) Ett system ska vara användbart, utan någon hjälp eller instruktioner, av en användare som har kunskap och erfarenhet av arbetsdomänen men ingen tidigare erfarenhet av systemet. Eektivt (Ecacy) Systemet ska inte störa eller hindra eektiviteten hos en erfaren användare som har god erfarenhet av systemet. Utveckling (Progression) Systemet bör underlätta kunskapsutveckling och ökad skicklighet, och underlätta och anpassa användningen av systemet när användaren får mer erfarenhet av systemet. Stöd (Support) Systemet bör stödja det verkliga arbetet som användarna försöker att göra genom att göra det lättare, enklare, snabbare eller roligare eller att göra nya saker möjliga. 14

Sammanhang (Context) Systemet bör vara anpassat till de verkliga förutsättningarna som nns i arbetsdomänen där systemet ska användas. 19 Användningsfallsbaserad konstruktion Grundtanken bakom denna utvecklingsfas är att utgå från de grundläggande användningsfallen. Denna fas står för att vi börjar med de viktigaste av dessa användningsfall och sedan bygger upp systemet användningsfall för användningsfall i stället för att betrakta systemet som en uppsättning med diust relaterade funktioner. Versioner av programmet kommer sedan i huvudsak att basera sig på vilka användningsfall som programmet stöder, och vi kan på detta sätt också enklare skilja programmet i basversion eller lyxversion genom att kapa av de användningsfall som vi betraktar som lyx utan att få ett sämre gränssnitt eller att riskera att programmet blir oanvändbart för dess huvudsakliga användning. I vår utveckling använder vi oss givetvis av de UML-diagram och objektstrukturer vi redan har utvecklat och lägger sedan alltså stegvis på de funktioner som krävs för att våra användningsfall ska gå att genomföra. Användarna har ingen särskild roll i denna sektion, denna form av utveckling sköter vi själva. Denna fas kan i någon mening pågå väldigt länge, men för den första versionen med stöd för de viktigaste användningsfallen avsätter vi omkring sex månader. 20 Iterativ utveckling Denna aktivitet är den som förhoppningsvis leder fram till den slutgiltiga koden. Vi utvecklar enligt ovan funktionaliteten enligt de behov som det viktigaste användningsfallet har, och vi gör detta givetvis på ett iterativt sätt. Även om iterativ utveckling inte nödvändigtvis behöver ha någonting med användningscentrering att göra, utan snarare är att betrakta som en sund princip för systemutveckling, så är det ändå något som förknippas med användingcentrering. Orsaken är att det i princip är nödvändigt att jobba med iterationer och utvärderingar för att försäkra sig om att det system som faktiskt produceras är relaterat till de prototyper, proler och analyser vi tagit fram under utvecklingens gång. Vi återkommer i någon mening till denna punkt för att utveckla den nya funktionalitet som krävs för alla viktiga användningsfall vi anser nödvändiga för att systemet ska kunna anses färdigt. Denna fas är denitivt programmerarnas huvudansvar, och vi sköter den givetvis själva. Användarna är inte direkt inblandade i denna fas även om deras synpunkter från utvärderingarna givetvis förs tillbaka in i utvecklandet för att kunna göra de rätta förändringarna. Då denna fas är en sorts delfas av den föregående kommer den också att ta omkring sex månader. 21 Den andra användbarhetsutvärderingen I användningscentrerad systemdesign nns det som sagt två större utvärderingssteg i utvecklingsprocessen. Det här är det andra steget och det görs efter själva implementationen. Nu ska det verkliga systemet utvärderas och vi får se om vi lyckats samla alla synpunkter från den första utvärderingen och om vi 15

har omsatt dessa i den verkliga implementationen. Om vi förutsätter att alla synpunkter och all kritik kommit fram vid den första utvärderingen och att vi har en godkänd prototyp att jobba med vid själva implementationen så borde denna utvärdering inte ge upphov till allt för stora överraskningar. Teoretiskt sett borde de synpunkter och kritik som nu kommer fram vid denna utvärdering gå att spåra till själva implementationen. I praktiken är det kanske inte alltid fullt så enkelt, men det är också därför denna utvärdering behövs. Även i denna utvärdering kommer vi att ta användarna till hjälp. Det är nu som användarna får se det slutgiltiga systemet, e-dagiset. Även under denna utvärdering kommer vi att låta användarna genomföra några scenarier för att se om vårt e-dagis verkligen blev som det var tänkt. Vi kommer under dessa scenarier (tester) att iaktta användarna och ställa frågor hur de upplever systemet. Vi kommer även att ställa frågor efter själva testerna där användarna i lugn och ro kan svara på frågor angående systemet. Om systemet inte blev som det var tänkt går vi tillbaka i processen och förbättrar det. Förhoppningsvis är det bara själva implementationsfasen som inte har blivit som det var tänkt eftersom vår tidigare utvärdering gick bra (annars hade vi ju inte kommit till detta steg). I den här andra utvärderingen kommer vi också att använda oss av en expert på användningscentrering. Det blir lika som vid den första utvärderingen att det är vi, användarna och experten som utvärderar systemet tillsammans. Även i denna utvärdering kan vi använda oss av Jakob Nielsens heuristiska regler. När detta steg är färdigt, och vi har gått tillbaka till implementationsfasen och xat till de saker som dök upp under utvärderingen, kommer vi att ha ett tillräckligt bra system för leverans. Vi räknar med att denna sista utvärdering kommer att ta cirka en vecka. Vårt e-dagis är nu äntligen färdigt efter en lång men lyckad utvecklingsprocess. 22 Slutresultat Den slutliga produkten, vårt e-dagis, kommer troligtvis principiellt att se ut som guren nedan, som egentligen beskriver en klassisk databasstruktur. Systemet kommer matas med information om vad som händer på dagiset, där information troligtvis kommer att läggas in både halvautomatiskt och manuellt. Det kan handla om inscanning av barnens teckningar eller lmsnuttar från ut- ykter med mera. Huvudansvariga för att mata in information i systemet blir naturligt den existerande dagispersonalen men det kan även bli möjligt att barnen själva kan mata in data i systemet, t ex teckningar och liknande som de gör direkt i en dator. Ansvariga för e-dagisets administration kommer också ha tillgång till systemet för att lägga upp nya användare, ta bort gamla, få ut statistik med mera. Denna administration kommer troligtvis att ske centralt i kommunen och de ansvariga kan i längden bli ansvariga för ertalet e-dagissystem. Föräldrarna slutligen, kommer troligtvis att få tillgång till systemet genom en säker fjärranslutning (genom Internet eller motsvarande). Där ska de kunna ta del av den data som rör deras barn och generell data som rör samtliga barn. 16

23 För- och nackdelar Det tillvägagångssätt som beskrivs i vår bok kallas Usage-centered design dvs användningscentrerad design. Redan titeln säger att det är användning och inte användare som är det viktigaste. Det är också där vi har hittat både för- och nackdelar med processen. Enligt boken ska användarna inte involveras i alla steg i processen vilken vi kan hålla med om. I vissa steg där processen inte tycker att användarna ska involveras tycker vi istället att de borde vara med för att få ett bättre resultat. Vi tycker framför allt att användarna borde involveras i all modellering. I Task Modeling nns användarna med men inte i Interface Content Modeling eller i Implementation Modeling. Här beror det mycket på vilken typ av modellering vi använder. Är det papper och post-it lappar som ligger till grund för modelleringen kan användarna vara med. Är det istället, som i t.ex. Implementation Modeling, att vi gör en begränsad implementation så blir det programmering och då är det inte lämpligt att ha med användarna. Vår uppfattning av processen är att den är stor och i vissa fall klumpig, och att den kan bli dyr att följa. Den känns mer lämpad för stora projekt. Vi är medvetna om att många säger just så, den här processen passar inte vårat projekt, och att det är nog ofta det som är problemet med mindre projekt. I stora projekt kan man ofta vara tvungen att använda en i förväg bestämd process men i mindre projekt slarvar man kanske med den saken. Det som känns bra med den här processen är att den är utvecklad efter erfarenheter av många verkliga projekt. Man få ofta uppfattningen av andra processer att de bara är teoretiska produkter. Det innebär att stegen i processen överlappar vilket känns rimligt. Man kan inte köra ett steg i processen fullt ut och sedan köra nästa osv. Vi tror att det bli överlapp i verkligheten och det återspeglar processen också. En liten detalj som vi gillar skarpt med processen är något som kallas feedforward/work-back. Det innebär att alla goda idéer som kommer upp under processens gång, och som inte kan omsättas direkt för att vi är i fel steg i processen, sparas för att senare kunna användas. Det gör att processen känns 17

exibel. Processen känns också robust eftersom vi har en bra uppdelning i era steg vilket gör att inte hela projektet står och faller med en del. Vi gillar den här processen och tycker att den är bra men om vi skulle jobba användarcentrerat så skulle vi vilja ta in användarna i er steg. 18