Timestamp ett användarvänligt tidsrapporteringssystem

ett användarvänligt tidsrapporteringssystem Ayaz Shukat TRITA-NA-E05090

Numerisk analys och datalogi Department of Numerical Analysis KTH and Computer Science 100 44 Stockholm Royal Institute of Technology SE-100 44 Stockholm, Sweden Timestamp ett användarvänligt tidsrapporteringssystem Ayaz Shukat TRITA-NA-E05090 Examensarbete om 20 poäng inom fristående kurs i datalogi Stockholms universitet år 2005 Handledare på Nada var Åke Walldius Examinator var Yngve Sundblad

Sammanfattning Målet med projektet Timestamp var att utveckla ett tidsrapporteringssystem med fokus på användbarhet. Samtidigt ville intressenterna se konsekvenserna av användarcentrerad systemutveckling, dvs. utveckling av mjukvara som är väl anpassad till slutanvändarens behov. Under arbetets gång analyserades slutanvändarna och deras krav. Slutanvändarna kom också med tips och kommentarer för att utöka användandet av systemet. Undersökningarna låg till grund för utvecklingen av produkten. Utvecklingsmodellen valdes ut noggrant utifrån en grupp av systemutvecklingsmodeller. Utvecklingsmodellen Usability Engineering Lifecycle är en användaranpassad systemutvecklingsmodell och har legat till grund för utvecklingsarbetet. Modellen är resultatinriktad och har krävt flera undersökningar. Dessa undersökningar har visat på positiva resultat och uppskattning av Timestamp. Projektet avslutades med en sista återkopplingsenkät. Denna enkät gav information om produktens slutgiltiga form. Det innebar konkret att fördelar och nackdelar med systemet framhävdes. Under diskussionen av arbetet framställs en överblicksbild som förklarar användarcentrerad systemutveckling. Bilden är uppdelad i flera olika verksamhetsområden för att göra den så generell som möjligt och för att den ska kunna utnyttjas av många olika typer av utvecklingsprojekt.

Abstract Timestamp - A User-friendly Time Reporting System The purpose of this thesis is to manage usability within the framework of a software development project. The aim is to develop a time-reporting system, called Timestamp, with a focus on usability. Another aim is to analyse the effects of usability work in a software development project and to observe its effectiveness and efficiency. During the project, users where given the opportunity to provide the development team with concrete ideas and viewpoints. All data were then used to develop the system in a way that would fit the vision of the end users. The system development model used is called The Usability Engineering Lifecycle. This model was chosen because its main focus is on the end-users and their satisfaction. The project ended with a final feedback in the form of a user-satisfaction questionnaire. This questionnaire informed the development team about the positive and negative aspects of the system. The goal was to collect data for the development of the next version of Timestamp. In the discussion-part of the thesis an overview of the user-centred systems engineering process is presented. This overview shows relationships between different important factors inside and outside of a software project. The purpose is to show what needs to be addressed during a software project which focuses on usability. It also shows difficulties that can appear during the process.

Förord Under slutet av 2003 funderade jag länge på ett intressant ämne för mitt examensarbete. Då jag alltid varit intresserad av systemutvecklingsteori, speciellt analys och design, lutade det åt just systemutveckling inom något avancerat språk såsom C# eller JAVA. Samtidigt ville jag binda utvecklingsprocessen med en utförlig systemarkitektur som skulle bli systemets stomme. Läsaren kanske redan börjar undra över vad C# och systemarkitektur innebär? Denna komplexa bild av systemutveckling fick mig att tänka över hur system fungerar idag och hur användare brukar dem. Duktiga programmerare och experter gäspar när de använder datorer, de behärskar datorer och kan nyttja dem till fullo. Samtidigt har nybörjare ansenliga problem för att kunna använda de mest triviala funktioner, exempelvis hanteringen av utskrifter eller informationssökning på Internet. Denna kunskapsklyfta har alltid intresserat mig och är en av flera bakomliggande orsaker till att detta examensarbete har sett dagens ljus. Mitt tillvägagångssätt är att kartlägga systemutvecklingens metoder för att se om den beskrivna kunskapsklyftan verkligen existerar. Samtidigt så vill jag hitta en lösning som ska överbrygga denna klyfta och bli en plattform som täcker kraven från majoriteten av användare. Under årens lopp har teknologin utvecklats i en allt snabbare takt. Det nya IT-samhället idag ser väsentligt annorlunda ut än för 50 år sedan. Samtidigt så kan man med en hög sannolikhet säga att samhället om 50 år kommer att vara än mer annorlunda än idag. För att möta denna snabba utveckling krävs det en ständig inlärningsprocess av alla individer för att hålla sig à jour med det dagliga arbetet. Ansvaret att lära sig systemet läggs mestadels på individen. Man ställer konstigt nog inte samma krav på systemet att lära sig mer om individen. Det kan ses som banalt att försöka få ett system att förstå människan och integrera sig med den. Dock är det i verkligheten ett sätt att skapa balans mellan användaren och systemet. Om systemet skapas med hänsyn tagen till slutanvändaren så kommer användaren känna sig tillfredsställd när han eller hon använder systemet och kommer inte uppfatta systemet som komplicerat. På samma sätt kommer systemet att kunna fungera med en högre precision då det har evaluerats utifrån en målgrupp av slutanvändare. Denna interaktion kan sammanfattas med begreppet användbarhet som är ett mått på användarens uppskattning av systemet som ligger till grund för utvecklingen av otaliga system samt som är fokus i detta examensarbete. Examensarbetet har inneburit mycket arbete inom flera verksamhetsgrenar samt flera skolor inom systemutveckling. I detta spektrum av modeller presenteras en rad olika men överlappande perspektiv på hur användbara system kan utvecklas.

Avslutningsvis vill jag tacka alla som på något sätt har assisterat mig under mitt arbete och har givit mig motivationen att fullfölja projektet och avsluta det. Däribland kan nämnas Tippu Mahmood (min handledare på Consoul), Alexander Alghazaly (systemutvecklare) och Åke Walldius (min handledare på Nada) som genom hela projektet har kommit med idéer och synpunkter som har varit viktiga för projektets framgång.

Innehåll 1 INLEDNING 1 1.1 Bakgrund 1 1.2 Begränsningar 1 1.3 Syfte 1 1.4 Mål 1 2 TEORI 2 2.1 Hur utvecklas ett system? 2 2.1.1 Anpassning 3 2.1.2 Användarvänlighet 3 2.1.3 Acceptans 4 2.1.4 Kompetens 4 2.2 Vad finns det för standarder idag? 4 2.2.1 Standarder som hanterar produktanvändningen 5 2.2.2 Standarder för undersökning av gränssnitt 5 2.2.3 Standarder för utvecklingsprocesser 5 2.3 Vad är interaktionsdesign? 7 2.3.1 Arbetsprocessen vid interaktionsdesign 7 2.3.2 Målet för interaktionsdesign 8 2.4 Systemutveckling (Software Engineering) 8 2.4.1 Objektorienterad utveckling 9 3 SYSTEMUTVECKLINGSMETODIK 11 3.1 Val av systemutvecklingsmodell 11 3.2 Systemutvecklingsmodeller 11 3.2.1 Spiralmodellen 12 3.2.2 Rational Unified Process (RUP) 13 3.2.3 The Usability Engineering Lifecycle 15 4 PROTOTYPUTVECKLING 17 4.1 Val av modell (Usability Engineering Lifecycle, UEL) 17 4.1.1 Deltagande av Användare 17 4.2 Steg 1 UEL Kravanalys (Requirements Analysis) 19 4.2.1 Användarprofil (User profile) 19 4.2.2 Analys av systemets omgivning (Contextual Task Analysis) 20 4.2.3 Plattformskrav (Platform Capabilities/Constraints) 23 4.2.4 Designprinciper (General Design Principles) 23 4.2.5 Användbarhetsmål (Usability Goals) 23 4.2.6 Designguide (Style Guide) 24 4.3 Steg 2 UEL Design/Testning/Utveckling (Design/Testing/Development) 24 4.3.1 Utveckling av rutiner och processer (Work Reengineering) 24

4.3.2 Visionsmodell (Conceptual Design) 25 4.3.3 Skisser (Mock-up) 26 4.3.4 Evaluering (Iterative CM Evaluation) 27 4.3.5 Skärmstandardisering (Screen Design standards SDS) 28 4.3.6 Prototypframställning (SDS Prototyping) 28 4.3.7 Evaluering (Iterativ SDS Evaluation) 28 4.3.8 Stilguide (Style Guide) 29 4.4 Steg 3 UEL Installation 29 4.4.1 Användaråterkoppling (User Feedback) 29 4.5 Utvärdering av UEL utifrån dess stöd för systemutveckling med användbarhet i fokus 31 5 DISKUSSION 32 5.1 Överblicksbildens beståndsdelar 33 5.1.1 Management 33 5.1.2 CMM Capability Maturity Model 33 5.1.3 Användbarhet 34 5.1.4 Systemutveckling 35 5.1.5 ISO-Standarder 35 5.1.6 OOSE Object Oriented Software Engineering 35 5.1.7 System 35 5.2 Varför beskrivs denna överblicksmodell? 36 6 SLUTSATSER 37 LITTERATURFÖRTECKNING 39 KÄLLFÖRTECKNING 40 BILAGOR 41 I. Spiralmodellen 41 II. RUP Inception phase 42 III. RUP Elaboration phase 43 IV. RUP Construction phase 44 V. RUP Transition phase 45 VI Förundersökningsenkät 46 VII Feedbackenkät 53

1 Inledning 1 Inledning Detta kapitel beskriver bakgrunden till projektet samt svarar på frågor som när, var, hur och varför projektet blivit till. 1.1 Bakgrund Gignos och Consoul är två företag som sysslar med konsulttjänster inom IT, samt utvecklar flexibla och webbaserade applikationer. Gignos är ITleverantörer som hjälper kunder med allt inom hårdvara, från support till datordrift. Consoul sysslar med mjukvaruutveckling inom webbsystem såsom enklare webbportaler och mer avancerade webbsystem. Gemensamt för de båda företagen är deras kundkrets som består av små till medelstora företag, antalet anställda varierar mellan 10-50 anställda. Branschtillhörighet hos kunderna sträcker sig från mindre industriföretag till medelstora konsultbolag. Tillsammans har företagen utvecklat detta projekt för att möta framtidens krav på liknande system. Krav på systemet är att det skall vara snabbt, effektivt och enkelt att använda. Med andra ord sätts användbarheten i fokus. 1.2 Begränsningar Detta examensarbete begränsas till att utveckla en prototyp av ett tidsrapporteringssystem. Externa system diskuteras vid vissa tillfällen i rapporten men ingår dock inte i utvecklingen av Timestamp. Fokus under projektet och i denna rapport är på användbarhet och på vilket sätt systemet kan optimeras utifrån det. Utvecklingsmiljön har inte analyserats utan har valts utifrån utvecklarens kunskaper. 1.3 Syfte Syftet med projektet är att se hur systemutveckling med fokus på användbarhet får för konsekvenser för IT-system vad gäller produktivitet och användaracceptans. Ökar produktiviteten hos användarna om de använder detta systemet? Kommer deras acceptans verkligen öka av produkter utvecklade med användbarhet som fokus? Spelar användbarhet en tillräckligt stor roll för att den skall användas framöver inom utvecklingsprojekt? Svaret på dessa frågor lägger grunden till syftet med examensarbetet. Dock ska man ha i åtanke att de största förändringarna tar längre tid och kommer förmodligen inte att kunna utläsas utifrån kortsiktiga utvärderingar. 1.4 Mål Målet med projektet är att utveckla en prototyp av ett tidsrapporteringssystem som uppfyller krav som ställs av Consoul och Gignos kundgrupp. Utvecklingen ska ske utefter en väl specificerad utvecklingsmodell med användbarhet i fokus. Slutligen utvärderas systemet utifrån användbarheten och undersöks för att se ifall de ursprungliga kraven samt användarnas individuella förväntningar och önskemål går i uppfyllelse. -1-

2 Teori 2 Teori Detta kapitel beskriver modeller som är viktiga för att förstå projektet och dess uppbyggnad. Modellerna ger en djupare förståelse av de viktiga besluten, kring användbarhet, som tas under projektets gång samt varför det är viktigt att integrera användbarhet inom systemutveckling. Samtidigt så blir det enklare att förstå de modeller för utveckling som kommer att beskrivas i senare kapitel. 2.1 Hur utvecklas ett system? Ett datasystem har vissa aspekter som påverkar dess produktivitet. Om dessa aspekter optimeras leder det till en ökad produktivitet. Denna ökning i kvalité kan ha flera fördelar som ökad användning samt mindre felsteg under användandet. Produktivitet Funktionalitet (funktioner i programmet klarar av relevanta uppgifter) Informationsbehov (användaren har tillgång till lämplig information för att kunna lösa sina arbetsuppgifter) Användbarhet Anpassning Användarvänlighet Acceptans Kompetens Åtkomlighet Förenlighet med och Individualisering Hjälpresurser stöd för människans Mentala funktionssätt. Figur 1. En modell som visar produktivitet kartlagt i relation med användbarhet och användarvänlighet 1. Modellen ser på användbarhet utifrån IT-stödets relation till omgivningen. Utifrån Allwoods modell beskriven i figur 1 kan man se att det essentiella med IT-stöd är att de ska öka produktiviteten. Alla förbättringar av system är till för just att öka produktiviteten. För att detta ska kunna ske måste 3 områden belysas: Funktionalitet, informationsbehov samt användbarhet. 1 Carl Martin Allwood (1998), Människa-datorinteraktion, Studentlitteratur -2-

2 Teori Funktionalitet har varit det första området där förbättringar och utökning av antalet funktioner har lett till ökat produktivitet. Det är oftast inom funktionalitet man hittar konkreta exempel på faktorer som behöver förbättras. Informationsbehov är svårare att kartlägga då det krävs en omfattande verksamhetsanalys för att hitta sådana behov. Verksamhetsanalysen undersöker hur information flödar i organisationen samt vilka informationskanaler som finns. Detta underlag används sedan för att förbättra informationsflödet mellan systemet, organisationen samt slutanvändaren. Det i sin tur ökar produktiviteten. Användbarhet är enligt Allwood i grunden ett verktyg för att på ett högre plan bedöma ett IT-stöd ur en användares ögon. Måttet användbarhet bedömer hur enkelt det är att använda IT-stödet samt hur enkelt det är att lära sig hur stödet fungerar. Denna bedömning är oftast väldigt individuell då den har många aspekter. Kognitiva, perceptionella (sinnesintryck) samt fysiska egenskaper hos användaren spelar stor roll vid bedömningen av objektet. Det är därför väldigt komplext att göra en allmängiltig bedömning av ett objekt då användbarhet är starkt kopplat dels till den egna organisationens struktur och dels till individuella uppfattningar av verkligheten. Användbarheten är indelad i flera delmoment, se figur 1. Dessa delmoment är viktiga att förstå för att få en enhetlig bild av användbarhet. 2.1.1 Anpassning Anpassning är ett mått på hur konsekvent utvecklat ett system är samt hur optimalt alla beståndsdelar, i systemet, samverkar för att uppnå syftet med systemet i den miljö som omger systemet. 2.1.2 Användarvänlighet Begreppet användarvänlighet är enligt Allwood svårdefinierat och kan enklast förstås av dess mindre beståndsdelar. Beståndsdelarna ger en helhetsbild som täcker det breda spektrum av aspekter som är relevanta för samspelet mellan människan och datorn. Användarvänlighet kan delas in i tillgänglighet, användaranpassning, individualisering samt hjälpresurser. Tillgänglighet är ytterst relevant ur ett praktiskt perspektiv för användarvänligheten. Om ett system i något avseende sätts ur funktion påverkar det användaren direkt. Om delar av systemet blir svåråtkomliga sätts också användarens tillgång till dess funktioner på spel och påverkar honom negativt. Förenlighet mellan system och användare är viktigt inom systemutveckling. Detta kan ses som att man tar i beaktande användarens synsätt på systemet. Det i sin tur underlättar utvecklandet av ett system som får användaren att känna sig delaktig. Användaren behöver då inte ändra sin mentala inställning till systemet. -3-

2 Teori Varje användare har en individuell uppfattning av ett system. Ett incitament för att utöka användandet av systemet blir då att individualisera systemet som användaren själv ansvarar för. Det kan t.ex. vara att användaren själv får välja färg på element i gränssnittet, välja text och sätta in en bild på sig eller sitt företag. Dessa incitament ökar acceptansen för systemet hos användaren. Hjälpresurser är vitala för nya användare. De behöver oftast lättbegripliga riktlinjer för hur systemet kan användas samt snabb assistans när problem uppstår. Vana användare kan också behöva hjälp ibland, exempelvis då man behöver slå upp något som man har glömt. Formen på hjälpresurser kan och bör variera för att motsvara användarens krav. 2.1.3 Acceptans Acceptans är ett viktigt begrepp för att fastställa graden av användbarhet. Allwoods definition av termen är användarens vilja att nyttja systemet. Om acceptansen är låg så kommer systemet att antingen användas sällan eller på ett fel sätt. Orsaken är att användaren inte känner sig komfortabel med systemet och då påverkar sin omgivning negativt vid användandet av systemet. Detta leder oftast till sämre produktivitet och försämring av arbetsmiljön. Därför är det viktigt med att kartlägga acceptansen för ett system samt att kontinuerligt arbeta för att den ska öka. 2.1.4 Kompetens Kompetens kan både direkt och indirekt påverka användbarhet. Användarens kunskaper och insikt i systemet påverkar direkt användbarhet. Uppfattning av andra system, social kompetens m.m. kan påverka användarens tillfredställelse indirekt. 2.2 Vad finns det för standarder idag? I dagsläget finns det en mängd olika teorier och utvecklingsmodeller för användbarhet. För att kunna navigera enkelt bland dem så finns det vissa standarder man kan följa. Dessa standarder definieras av en schweizisk organisation vid namn ISO, som står för International Organization for Standardization. Denna väldigt stora organisation har målet att skapa standarder för industrier, statsmakter samt för det civila samhället 2. När det kommer till användbarhet så existerar det flertal standarder inom ISO. Dessa kan delas in i tre kategorier: Karaktären av produktanvändning. Produktens gränssnittsattribut. Utvecklingsprocesser. 2 http://www.iso.org -4-

2 Teori 2.2.1 Standarder som hanterar produktanvändningen Denna kategori innehåller standarder för produktens effektivitet utifrån slutanvändarens perspektiv samt hur uppskattad produkten är av slutanvändaren. Exempel på en standard inom denna kategori: ISO 9241-11 Riktlinjer för användbarhet Denna standard systematiserar metodiken runt datainsamling för både specifikationen samt utvärderingen av ett system. Denna metod innehåller flera användbarhetstester för att kunna utvärdera slutanvändarens uppfattning av ett system. 2.2.2 Standarder för undersökning av gränssnitt Denna kategori innefattar standarder för gränssnittsdesign samt interaktionen mellan användaren och systemet. ISO 9241-10 Dialogprinciper För att förbättra samspelet mellan slutanvändare och system så behövs sju element från ergonomin implementeras. Dessa är: Anpassa samspelet till uppgiften av systemet. Samspelet ska vara självinstruerande. Dialogen ska kunna styras. Användaren ska enkelt kunna hantera dialogen. Samspelet bör kunna hantera användarens felsteg. Dialogen bör kunna anpassas på ett individuellt plan. Dialogen bör ha stöd för inlärning. ISO 9241-13 Användarvägledning Denna standard beskriver ett gränssnitt som har en effektiv interaktion med användaren och guidar honom igenom gränssnittet med hjälp av ett flertal hjälpmedel (så som hjälptexter, informativa felsvar, återkoppling, statusinformation m.m.). 2.2.3 Standarder för utvecklingsprocesser Här finner man utvecklingsmodeller som innefattar användbarhet. Exempel på en sådan standard: ISO 13407 Användarcentrerade utvecklingsprocesser för interaktiva system Denna standard utfärdar riktlinjer för att utveckla interaktiva system så att de blir mer användarorienterade. Standarden kräver att processer och aktiviteter inom den valda utvecklingsprocessens hela livscykel förbättras och blir mer ändamålsenliga samt mer effektiva. Utvecklingsprocessen måste innehålla fyra viktiga aspekter för att uppfylla användbarhetskraven: -5-

2 Teori Användningen av systemet måste vara klart och tydligt. Organisationens samt slutanvändarens krav måste specificeras noggrant. En design och prototyp måste framställas. Man måste göra kontinuerliga användbarhetsundersökningar. Alla dessa aktiviteter måste göras iterativt (se figur 2) ända tills kraven på användbarhet är uppfyllda. Modellen ska också specificera en plan för hur alla aktiviteter interagerar med varandra samt vilka ansvarsområden som existerar. Planering av användarcentrerat arbetssätt Möter kraven Specificering av användningssammanhang Utvärdering jämfört med kravspecifikation Specificering av krav ställda av organisationer & användare Produktion av designlösningar Figur 2. En iterativ utvecklingsmodell som följer ISO 13407. ISO 18529 Ergonomics ergonomics of human-system interaction - Human-centred life cycle process descriptions Denna standard skrevs 2000 som en överbyggnad till ISO 13407 och beskriver generellt hur en organisation ska bygga upp användarcentrerade designprocesser (Human Centred Design Processes, HCD) för att uppnå höga krav på användbarhet. Modellen är uppdelad i sju element som utgör en riktlinje för att uppnå målet. HCD 1. Säkerställ att utvecklingsstrategin innefattar HCD. HCD 2. Planera och övervaka HCD processen. HCD 3. Specificera användarkraven. HCD 4. Skapa en förståelse av användarna samt deras miljö. HCD 5. Utveckla prototyp. HCD 6. Evaluera prototypen utifrån kravspecifikationen. HCD 7. Introducera och sedan styra det nyutvecklade systemet. -6-

2 Teori 2.3 Vad är interaktionsdesign? Interaktionsdesign innebär en brygga mellan allmän användbarhet och systemutveckling (se figur 3). Bryggan skapar en förståelse för de båda separata verksamhetsområdena. Med åren har design börjat värdesättas mer och mer då användarna får mer att säga till om. Dagens system är mycket enklare att använda jämfört med för 20 år sedan. Idag finns det många interaktiva hjälpmedel som förmedlar till användaren hur systemet ska hanteras, det är en beskrivning av bra interaktiv design. Akademiska discipliner Ergonomi Psykologi/ Kognitiv vetenskap Information Ingenjörskonst Systemvetenskap/ Mjukvaruutveckling Humaniora/ Sociologi, Antropologi Interaktionsdesign Design Grafisk design Produktdesign Industriell design Filmindustrin Artistisk design Informationssystem Mänskliga faktorer (MF) Kognitiv systemutveckling Människa-datorinteraktion (MDI) Mellanliggande fält Kognitiv ergonomi System för att stödja mänskligt samarbete Figur 3. Här visas relationerna mellan interaktionsdesign och andra näraliggande discipliner 3. Syftet är både att visa de olika disciplinernas samverkan med interaktionsdesign samt att visa hur de står i relation med varandra. 2.3.1 Arbetsprocessen vid interaktionsdesign För att sammanfatta utvecklingsprocessen av interaktionsdesign enligt Preece et al. kan man nämna fyra fundamentala aktiviteter: 1. Identifiera behov och skapa en kravspecifikation 2. Skapa olika prototyper utifrån kravspecifikationen. 3. Skapa interaktivitet hos prototyperna för att enklare komma åt den samt att förbättra kommunikationen mellan prototypen och slutanvändarna. 4. Utföra regelbundna utvärderingar av systemet. 3 Preece, Rogers, Sharp (2002), Interaction Design, John Wiley & Sons. -7-

2 Teori 2.3.2 Målet för interaktionsdesign Målet med interaktiv design är att ett system ska ha så hög effektivitet som möjligt samt en optimal interaktion med slutanvändaren. Detta mål är indelat i användbarhetsmål samt användarens mål utifrån erfarenhet. Användbarhetsmålen enligt Preece et al. motsvaras av de kategorier som är definierade innan i 2.1 som handlar om användbarhetsteori och kan sammanfattas på följande sätt: Ändamålsenligt (effectiveness) Effektivt att använda (efficiency) Säkert att använda (safety) Har god allmännytta, användbarhet (utility) Enkelt att lära sig (learnability) Enkelt att lära sig utantill (memorability) Målet med användarens erfarenhet (User experience goals) utgår ifrån att användaren redan besitter en viss nivå av erfarenhet. Denna erfarenhet kan vara av liknande system eller av användning av datorer i allmänhet. Beskrivningen av systemet utifrån användarens erfarenhet är olik den för användbarhetsmålen. Istället för att beskriva systemets egenskaper så beskriver användaren istället hur han själv upplever systemet. Dessa kategorier är: Användartillfredsställelse (satisfying) Njutbar (enjoyable) Roligt (fun) Underhållande (entertaining) Hjälpsam (helpful) Motiverande (motivating) Estetiskt tilltalande (aesthetically pleasing) Ger stöd till nyskapande (supportive of creativity) Lönande (rewarding) Känslomässigt uppfyllande (emotional fulfilling) 2.4 Systemutveckling (Software Engineering) När man har bestämt sig för vad man vill utveckla är nästa steg att välja vilken typ av systemutvecklingsmodell man vill använda. Det finns åtskilliga modeller att välja mellan och man ser det ofta som en smaksak vilken man väljer. I detta arbete har den objektorienterade systemutvecklingsmodellen valts då den förenklar synsättet på systemets delar och skapar en konsekvent design. Samtidigt är modellen väl anpassad till de livscykelmodeller som undersöks i nästa kapitel. -8-

2 Teori 2.4.1 Objektorienterad utveckling Objektorienterad utveckling kan beskrivas som en extrahering av objekt utifrån en utsaga och sedan utveckla en modell som tar tillvara på dessa objekt och deras egenskaper 4. Generellt brukar man beskriva systemet och dess miljö som ett scenario. Detta scenario har olika aktörer (Actors). Aktörerna kan motsvaras av användare, olika system samt andra delaktiga parter som påverkar systemet på olika sätt. Systemet har olika relationer med aktörerna och aktörerna kan även ha relationer sinsemellan också. Relationer mellan systemets delar definierar interaktionen mellan dem. När man är klar med att beskriva scenariot analyseras det och omvandlas till en teknisk specifikation. Aktörerna blir objekt och relationerna blir funktioner mellan objekten. Varje aktör har attribut som beskriver hur aktören ser ut. Aktören har också kunskaper som aktören kan utföra, dessa kallas för operationer (se figur 4). Den objektorienterade metodiken brukar delas upp i fyra generella delar: analys, systemdesign, design av objekt samt implementation. Objekt: Cykel Klass: Cykel Attribut: Färg Hjul Växlar Bromsar Etc. Operationer: Växla Åka Tvätta Reparera Figur 4. Denna figur visar ett föremål beskrivet som ett objekt. Varje objekt har ett eller flera attribut och operationer. Dessa egenskaper ger objektet dess form och betydelse. Analys Utifrån en problembeskrivning utvecklas en modell av verkligheten. Den är inte kopplad till utvecklingsmiljön eller på annat sätt begränsad av andra system. Det kan konkret innebära att man beskriver väldigt generellt hur det framtida systemet ska se ut och sedan gör en uppräkning på alla krav som ställs. 4 James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen (1991), Object-Oriented Modeling And Design, Prentice Hall International Editions. -9-

2 Teori Systemdesign I denna fas byggs arkitekturen upp utifrån specifikationen som utvecklats i den tidigare fasen. Här beslutas hur övergripande strukturer skall definieras. Samtidigt måste en strategi tas fram för att övervinna begränsningar och problem för att garantera systemets prestanda. Objektdesign Objektdesign handlar om att utifrån en modell av systemet extrahera en objektmodell. Denna modell skall i detalj beskriva alla relevanta relationer mellan de olika objekten. Implementering I denna fas översätts objektmodellen till programkod som kommer att ligga för grund för systemets tekniska struktur. Om objektdesignen täcker de viktigaste aspekterna av systemet så kommer nya beslut inte behöva tas i någon större utsträckning. -10-

3 Systemutvecklingsmetodik 3 Systemutvecklingsmetodik Systemutvecklingsmetodik beskriver tillvägagångssättet för att specificera hur ett system ska utvecklas. Detta innebär att man utifrån analysen av ett problem specificerar en beskrivning av en lösning samt diskuterar runt de verktyg som behövs för att implementera lösningen, för att slutligen utforma ett tillvägagångssätt för att utveckla ett program. 3.1 Val av systemutvecklingsmodell Val av metod är alltid en svår balansgång mellan både vad som är praktiskt tillämpbart och vad som innehåller en teoretisk vetenskaplighet. Metoder brukar oftast vara ganska handfasta och teorin brukar oftast utelämnas. Inom systemutveckling finns det otaliga modeller för att ge utvecklarna riktlinjer för sitt arbete. Valet brukar i ofta bero på projektledarens omdöme. Han eller hon sätter upp riktlinjer och tidsgränser samt bestämmer roller för projektets deltagare. Detta blir sedan styrande för projektet från start till mål. Problemet blir att projektledaren sällan ger övriga projektdeltagare möjlighet att uttrycka önskemål om vad de anser är en bra modell. Deltagarna får heller inte diskutera fram en modell som motsvarar deltagarnas kunskaper samt speglar verkligheten i form av existerande verktyg och tidsram. Tidsaspekten är tyvärr oftast den bestämmande faktorn vid valet och kan därför sätta käppar i hjulet för projektet. Det kan konkret innebära att projektledaren inte har full kontroll på projektet utan skyndas på av att framställa konkreta resultat inom en knapp tidsram. Det som speglar valet av metod i detta examensarbete är dess fokus på användbarhet. Konkret betyder det att modeller, där kommunikation mellan användare och utvecklare värdesätts, är av intresse. För att uppnå detta krav finns det flera omfattande modeller som kan användas. Modellerna kommer att beskrivas utifrån deras teori, struktur och inriktning på användbarhet. Utifrån dessa krav har tre modeller valts: Spiralmodellen, Rational Unified Process (RUP) och The Usability Engineering Lifecycle. 3.2 Systemutvecklingsmodeller Nedan beskrivs tre systemutvecklingsmodeller som valts ut. Modellerna är i sin struktur väldigt olika varandra men ganska lika på ett teoretiskt plan. Alla modellerna består av konsekvent och rutinmässigt utvecklade steg som projektets utvecklingsgrupp följer. -11-

3 Systemutvecklingsmetodik 3.2.1 Spiralmodellen Spiralmodellen 5 utvecklades av Barry Boehm. Definitionen lyder: The spiral development model is a risk-driven process model generator that is used to guide multi-stakeholder concurrent engineering of software-intensive systems. It has two main distinguishing features. One is a cyclic approach for incrementally growing a system's degree of definition and implementation while decreasing its degree of risk. The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions 6 Modellen utgår ifrån att man ska kartlägga alla risker för projektet. I varje fas av utvecklingen gör man en riskutvärdering samtidigt som man skapar en beredskapsplan för att säkerställa riskerna. Utformningen av modellen som en spiral förstås i ljuset av en iterativ modell som under varje iteration växer och utvecklas till dess att systemet är färdigutvecklat. De övergripande faserna motsvaras av 3 steg: Plan för kravspecifikation Denna fas börjar med att kartlägga risker och skapa en beredskapsplan för att minimera riskerna. Man skapar en tidig prototyp samt en kravspecifikation. Därefter skapas en ny prototyp som följer specifikationen. Plan för utveckling Plan för utveckling börjar med en ny kartläggning av risker samt en beredskapsplan. När detta är klart är projektet redo för utveckling av systemet. Det är inte specificerat vilken utvecklingsmodell man bör använda utan det är upp till projektgruppen att ta ett beslut om det. Samtidigt måste projektet utformas och gruppen måste komma överens om en modell som passar systemet. Det innefattar i första hand programspråk och dokumentationsstandarder. Plan för testning och integration Denna fas innehåller olika typer av tester såsom modultestning 7, blackbox-testning 8 m.m. Dessa tester godkänner systemet och gör det redo för nästa steg. Den slutliga processen är integration av systemet i den miljö som existerar hos slutanvändarna. Det kan också innebära att man arbetar för att skapa en acceptans hos slutanvändarna så att de ökar integrationen av systemet i deras unika miljöer samt använder systemet på rätt sätt. 5 Se bilaga I. 6 http://www.stsc.hill.af.mil/crosstalk/2001/05/boehm.html 7 Modultestning är ett test av delar av systemet s.k. moduler. 8 Blackbox-testning innebär att man skickar in information i systemet och sedan jämför svaret med det förväntade svaret. -12-