Examensarbete
Utveckling av fristående enkätmodul till ett
webbaserat hälsovårdsstödsystem
Julia Klingvall, Jonas Liljenfeldt
LiTH - IDA - EX - - 05 / 085 - - SEUtveckling av fristående enkätmodul till ett
webbaserat hälsovårdsstödsystem
Institutionen för datavetenskap, Linköpings universitet Julia Klingvall, Jonas Liljenfeldt
LiTH - IDA - EX - - 05 / 085 - - SE
Examensarbete: 20 p Nivå: D
Handledare: Hans Almvide
Lorensbergs Communication AB Examinator: Johan Åberg
Institutionen för datavetenskap, Linköpings universitet Linköping 30 november 2005
Institutionen för datavetenskap 581 83 LINKÖPING SWEDEN 30 november 2005 x x http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-4809 LiTH - IDA - EX - - 05 / 085 - - SE
Utveckling av fristående enkätmodul till ett webbaserat hälsovårds-stödsystem
Julia Klingvall, Jonas Liljenfeldt
Vi har utvecklat två fristående webbapplikationer till det webbaserade hälsovårdsstödsystemet Asynja. Den ena är en designapplikation för enkätundersökningar och den andra är en svarsapplikation där res-pondenterna kan besvara enkäterna.
Utvecklingsprocessen har bestått av planering, design, implementa-tion, testning och dokumentation. Mycket av arbetet har skett paral-lellt vilket vi har sett som en framgångsfaktor i examensarbetet. Projektet har präglats av att applikationerna ska vara användarvän-liga och funktionella samtidigt som designen och koden ska göra att applikationerna kan vidareutvecklas och underhållas effektivt.
Arbetet med att utvecklaJ2EE-applikationer och använda sig av
ram-verket Struts har gett goda erfarenheter och det har även visat sig att denna plattform är väl lämpad för denna typ av uppgifter.
mjukvaruutveckling, Java, servlets,JSP, Struts, enkät,
enkätundersök-ning Nyckelord Keyword Sammanfattning Abstract Författare Author Titel Title
URL för elektronisk version
Serietitel och serienummer
Title of series, numbering ISSN
ISRN ISBN Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport Avdelning, Institution Division, Department Datum Date
Sammanfattning
Vi har utvecklat två fristående webbapplikationer till det webbaserade hälsovårdsstödsystemet Asynja. Den ena är en designapplikation för en-kätundersökningar och den andra är en svarsapplikation där responden-terna kan besvara enkäresponden-terna.
Utvecklingsprocessen har bestått av planering, design, implementa-tion, testning och dokumentation. Mycket av arbetet har skett parallellt vilket vi har sett som en framgångsfaktor i examensarbetet.
Projektet har präglats av att applikationerna ska vara användarvänliga och funktionella samtidigt som designen och koden ska göra att applika-tionerna kan vidareutvecklas och underhållas effektivt.
Arbetet med att utveckla J2EE-applikationer och använda sig av
ram-verket Struts har gett goda erfarenheter och det har även visat sig att den-na plattform är väl lämpad för denden-na typ av uppgifter.
Nyckelord: mjukvaruutveckling, Java, servlets, JSP, Struts, enkät,
enkät-undersökning
Tack
Först och främst vill vi tacka Lorensbergs CommunicationABför att de
er-bjöd oss ett roligt och intressant examensarbete. Vi uppskattar att det var ett fristående programvaruutvecklingsprojekt som vi fick utveckla från början och som involverade många olika aspekter och moment.
Ett stort tack riktas även till våra testanvändare för viktiga synpunkter och förbättringsförslag.
Vi vill tacka vår examinator Johan Åberg för gott stöd och handledning. Vi är speciellt tacksamma för att kontakten har kunnat skötas via e-post, då vi har utfört arbetet i Göteborg.
Vi vill tacka vår handledare Hans Almvide för goda förslag och stort intresse för vårt examensarbete och resultatet. Vi vill även tacka övriga medarbetare i Asynja-gruppen på Lorensbergs Communication för att de varit hjälpsamma, svarat på våra frågor och varit gott sällskap.
Vi vill även tacka våra opponenter för värdefull återkoppling.
Innehåll
1 Introduktion 1
1.1 Bakgrund . . . 1
1.1.1 Företaget och produkten . . . 1
1.1.2 Uppgiften . . . 1
1.1.3 Författarna . . . 2
1.2 Syfte . . . 2
1.3 Begränsning . . . 2
1.4 Denna rapports målgrupp . . . 2
1.5 Läsguide . . . 3
1.6 Typografiska konventioner . . . 3
2 Metod 5 2.1 Programvaruutvecklingsmetod . . . 5
2.1.1 Rational Unified Process . . . 5
2.1.2 Extreme programming . . . 6
2.1.3 Jämförelse mellan metoderna . . . 8
2.1.4 Vår programvaruutvecklingsmetod . . . 8
2.2 Designmetod . . . 10
2.2.1 Vision . . . 10
2.2.2 Metoder för att generera en operativ bild . . . 10
2.2.3 Metoder för värdering . . . 11 2.2.4 Vår användbarhetsmetod . . . 13 2.3 Metodkritik . . . 14 3 Uppgift 15 3.1 Funktionella krav . . . 15 3.2 Icke-funktionella krav . . . 16 3.3 Beskrivning av kravspecifikationen . . . 17 3.3.1 Krav på designapplikationen . . . 17 3.3.2 Krav på svarsapplikationen . . . 17 Klingvall, Liljenfeldt, 2005. xi
4 Översikt av befintliga enkätsystem 19
4.1 Asynjas enkäthanterare . . . 19
4.2 Litium Enkät . . . 19
4.3 Datainstitutets Business Intelligence . . . 21
4.4 Relationwise . . . 21 4.5 Netigate . . . 22 4.6 E-enkät . . . 22 4.7 re:PDF . . . 22 4.8 Websurvey . . . 23 4.9 Tillvaratagna idéer . . . 23 5 Teoretisk bakgrund 25 5.1 Användbarhet . . . 25 5.1.1 Målgrupp . . . 26 5.1.2 Våra användbarhetskrav . . . 26 5.2 Enkätutformning . . . 28 5.3 Målgruppsutformning . . . 30 5.4 Personuppgifter . . . 30 5.5 Implementationsteori . . . 30
5.5.1 Givna tekniska förutsättningar . . . 30
5.5.2 Uppdelning av webbapplikationer . . . 31 5.5.3 Webbapplikationernas struktur . . . 31 5.5.4 Datalagring . . . 33 5.5.5 Inloggning . . . 35 5.5.6 Kryptering . . . 36 5.5.7 Inbjudningar . . . 37 5.5.8 Generering av enkätformuläret . . . 38 5.5.9 Validering av formulärdata . . . 39 6 Design av produkten 41 6.1 Vision . . . 41
6.2 Första versionen av den operativa bilden . . . 42
6.2.1 Design . . . 42
6.2.2 Interaktion . . . 43
6.2.3 Navigation . . . 43
6.2.4 Skisser och prototyper . . . 44
6.3 Värdering . . . 44
6.3.1 Val av testanvändare . . . 45
6.3.2 Värdering av dynamisk pappersprototyp . . . 45
6.3.3 Konstruktion av gränssnitt . . . 46
Innehåll xiii
6.3.5 Ändringar i andra versionen av programmet . . . 49
6.3.6 Värdering av andra versionen av programmen uti-från kravspecifikationen . . . 51
6.3.7 Värdering av andra versionen med testanvändare . . 54
6.3.8 Ändringar i tredje versionen av programmet . . . 57
6.3.9 Värdering av tredje versionen av programmen . . . . 59
6.3.10 Slutlig version av användargränssnittet . . . 59
7 Problem som har uppstått 61 7.1 Utvecklingsmiljön . . . 61 7.2 Teckenkodning . . . 61 7.3 Validering av formulärdata . . . 62 7.3.1 Validering av enkätsvar . . . 62 7.4 Begrepp i användargränssnitt . . . 63 8 Resulterande produkter 65 8.1 Användargränssnitt . . . 65
8.2 Gemensamt för båda applikationerna . . . 65
8.2.1 Struts . . . 66 8.2.2 Internationalisering . . . 66 8.2.3 Kodstandard . . . 66 8.3 Designapplikationens uppbyggnad . . . 66 8.3.1 Funktioner i designapplikationen . . . 66 8.3.2 Princip för kodstruktureringen . . . 67
8.3.3 Beskrivning av enkätundersökningsdelens lager . . . 68
8.3.4 Designapplikationens klasser . . . 70
8.3.5 DesignsdelensJSP . . . 71
8.3.6 Designapplikationens övriga filer och kataloger . . . 71
8.4 Svarsapplikationens uppbyggnad . . . 72
8.4.1 Funktioner i svarsapplikationen . . . 72
8.4.2 Beskrivning av svarsapplikationens lager . . . 73
8.4.3 Svarsapplikationen klasser . . . 74
8.4.4 SvarsapplikationensJSP . . . 75
8.4.5 Svarsapplikationens övriga filer och kataloger . . . . 76
8.5 Lagrade data . . . 76 8.5.1 Administratörer . . . 76 8.5.2 Enkätundersökningar . . . 76 8.5.3 Frågesamlingar . . . 77 8.5.4 Målgrupper . . . 79 8.5.5 Publicerade enkäter . . . 79 8.5.6 Enkätsvar . . . 81
8.6 Säkerhetsaspekter . . . 82
8.7 Prestanda . . . 82
8.8 Portabilitet . . . 83
8.9 Installation . . . 83
9 Diskussion och slutsatser 85 9.1 Återkoppling till syftet . . . 85
9.2 Återkoppling till kravspecifikationen . . . 85
9.2.1 Funktionella krav . . . 85
9.2.2 Icke-funktionella krav . . . 86
9.3 Återkoppling till programvaruutvecklingsmetodenXP . . . 88
9.4 Återkoppling till designmetoden . . . 89
9.5 Diskussion av lösningsval . . . 89
9.5.1 Struts . . . 89
9.5.2 Användbarhetsfrågor . . . 90
9.5.3 Jämförelse mellan servlets och andra tekniker . . . . 90
9.5.4 Uppdelning i lager . . . 90
9.5.5 Datalagring . . . 91
9.5.6 PUL . . . 91
9.5.7 Inbjudningar . . . 92
9.5.8 XSLT . . . 92
9.5.9 Flexibilitet kring frågetyper . . . 92
9.5.10 Utmaningar . . . 93
9.6 Förslag på ytterligare funktioner . . . 93
9.6.1 Utökade administratörsrättigheter . . . 93
9.6.2 Förhandsgranska en enkätundersökning . . . 93
9.6.3 Möjlighet att grafiskt hantera frågesamlings- och målgruppsbeskrivningar . . . 94
9.6.4 Historik för besvarade enkätundersökningar . . . 94
9.6.5 Alternativa inbjudningssätt . . . 94
9.6.6 Start- och slutdatum för en enkätundersökning . . . 94
9.6.7 Påminnelser . . . 94
9.6.8 Export tillPDF . . . 95
9.6.9 Import av svar till designapplikationen . . . 95
A Termer 101 A.1 Tekniska termer . . . 101
B Högnivåkravspecifikation från Lorensbergs Communication 103 B.1 Kravspecifikation Enkätmodul. . . 103
Innehåll xv
B.1.2 Vision . . . 103
B.1.3 Krav . . . 104
C Dynamisk pappersprototyp 105 D Första versionen av designapplikationen 107 E Första versionen av svarsapplikationen 111 F Andra versionen av designapplikationen 113 G Resulterande användargränssnitt 119 H DTD-filer 133 H.1 Administratörsfil . . . 133 H.2 Enkätundersökningsfiler . . . 133 H.3 Enkätfiler . . . 134 H.4 Målgruppsfiler . . . 134 H.5 Svarsfiler . . . 135 I En exempelenkät 137 J Bild av demonstrationsenkät 141
Figurer
4.1 Ett exempel på en enkät som är skapad i Asynja. . . 20 5.1 Flödet för en sidvisning med Modell 2. . . 32 5.2 Schematisk skiss över hurAES-krypteringen går till. . . 37
6.1 Schema över ursprungliga funktionerna i designapplikatio-nen. . . 41 6.2 Schema över ursprungliga funktionerna i
svarsapplikatio-nen. . . 42 8.1 Resulterande schema över funktionerna i
designapplikatio-nen. . . 67 8.2 Princip för kodstrukturen i designapplikationen. . . 68 8.3 Dataflödet samt paket- och kodstrukturen i
designapplika-tionen. . . 69 8.4 Schema över funktionerna i svarsapplikationen. . . 73 8.5 Dataflödet samt paket- och kodstrukturen i
svarsapplikatio-nen. . . 74 B.1 Schematisk beskrivning av enkätserver. . . 104 C.1 Skapa-vyn i den dynamiska pappersprototypen. . . 105 D.1 Inloggningsvyn. Rubriker är i en mörkröd nyans och färgen
runt innehållet är ljusbeige. . . 107 D.2 Skapa-undersökningsvyn med felaktig inmatning och
fel-meddelande i klarrött. . . 108 D.3 Bekräftelse på att en enkätundersökning har skapats. . . 108 D.4 Redigera-vyn med en enkätundersökning som är vald för
redigering. . . 109 D.5 Publiceringsvyn. . . 109 E.1 Inloggningsvyn. . . 111
E.2 Enkäten som ska besvaras. . . 112 E.3 Efter att svaret har lämnats visas denna vy. . . 112 F.1 Skapa-vyn. Nu har vi två menynivåer samt ett grå-svart
färgtema. . . 114 F.2 Skapa-vyn med ett felmeddelande. . . 114 F.3 Publicera-vyn som numera består av två steg. . . 115 F.4 Publicera-vyn. Här visas kort information om enkäten och
vilka som ska få e-postutskick. . . 115 F.5 Publicera-vyn med en bekräftelsedialog aktiv. . . 116 F.6 Vänta-vyn. . . 116 F.7 Som en bekräftelse på att publiceringen och inbjudan gick
bra visas denna vy. . . 117 G.1 Inloggningssidan. . . 120 G.2 Introduktionsfliken. . . 121 G.3 Frågefliken, vars funktionalitet inte är implementerad. . . . 122 G.4 Målgruppsfliken, vars funktionalitet inte är
implemente-rad. . . 123 G.5 Enkätfliken med underfliken Skapa ny enkät vald. . . 124 G.6 Enkätflikens underflik Redigera enkät är vald. Här visas
första steget. . . 125 G.7 Redigera-funktionens andra steg. . . 126 G.8 Förhandsgranskningsvyn, vars funktionalitet inte är
imple-menterad. . . 127 G.9 Vyn för att ta bort en enkät. Steg två och tre syns först efter
att användaren har valt en enkät i steg 1. . . 128 G.10 Publiceringens tre steg visas här. Liksom i ta bort- och
redi-gerafunktionera visas först steg 1 och sedan resterande steg. 129 G.11 Publiceringen föregås av en bekräftelsedialog som är
gene-rerad av ett JavaScript. . . 130 G.12 När publiceringen utförs och inbjudan skickas visas en
vänta-vy. . . 131 G.13 Den sista fliken är importera-fliken vars funktionalitet inte
är implementerad än. . . 132 J.1 Exempelenkäten i bilaga I. . . 142
Tabeller
1 Några förkortningar som vi använder . . . xxi
8.1 Klasser i designapplikationen . . . 71
8.2 Ett urval av deJSP som används i designapplikationen . . . 72
8.3 Klasser i svarsapplikationen . . . 75
8.4 JSPsom används i svarsapplikationen . . . 75
8.5 Frågetyper med svarsalternativ . . . 78
8.6 Frågetypernas underelement . . . 78
Förkortningsförteckning
Tabell 1: Några förkortningar som vi använder
Förkortning Betydelse
AES Advanced Encryption Algorithm CSS Cascading StyleSheets
DES Data Encryption Standard DIN Design Interaktion Navigation DTD Document Type Definition HTML HyperText Markup Language HTTP HyperText Transfer Protocol J2EE Java 2 Platform Enterprise Edition
JAAS Java Authentication and Authorization Service ISO International Organization for Standardization JRE Java Runtime Environment
JSP JavaServer Pages
MVC Model-View-Controller PDF Portable Document Format PUL Personuppgiftslagen
RUP Rational Unified Process SQL Structured Query Language UML Unified Modelling Language URL Uniform Resource Locator UTF Unicode Transformation Format XML Extensible Markup Language
XP Extreme Programming
XSL Extensible Stylesheet Language
XSLT Extensible Stylesheet Language Transformation
Kapitel 1
Introduktion
1.1 Bakgrund
1.1.1 Företaget och produkten
Företaget som vi har gjort examensarbetet på heter Lorensbergs Commu-nicationAB. Företaget utvecklar bland annat ett webbaserat system,
Asyn-ja, som används i företags- och skolhälsovården till journalföring, tidsbok-ning, ekonomisk administration med mera. Asynja används idag av cirka 70 kunder i Sverige.
Systemet är utvecklat i Java och Lorensbergs Communication eftersträ-var att endast skicka HyperText Markup Language, HTML, till klienterna
för att minimera kraven på dessa. Systemet använder sig även av Java-Script och databashanteraren MicrosoftSQLServer. Det är till detta system
som vi ska utveckla en ny fristående enkätmodul.
1.1.2 Uppgiften
I hälsovårdsstödsystemet Asynja finns det bland annat ett enkätverktyg. Enkätfrågorna matas in av personal från Lorensbergs Communication ef-ter förlaga från kunden. Det sker genom attSQL-satser skapas och därefter
körs mot databasen. De befintliga enkäterna kan nås i Asynjas gränssnitt där de presenteras iHTML-format. Därifrån kan enkäterna exporteras till
Portable Document Format1, PDF, för utskrift och distribution. I dagsläget finns det funktioner för att manuellt mata in enkätsvar, lagra dem samt utföra enkel bearbetning av enkätsvaren. Detta sker av administratörer i Asynjasystemet.
1URL:http://www.adobe.com/products/acrobat/adobepdf.html
I examensarbetet har vi skapat två webbapplikationer, en där admi-nistratörer kan logga in för att skapa och publicera enkätundersökningar och en där respondenter kan besvara desamma. Kraven på examensarbe-tet beskrivs mera detaljerat i kapitel 3.
1.1.3 Författarna
Vi som har utfört detta examensarbete studerade vid Linköpings tekniska högskola på civilingenjörsprogrammet i informationsteknologi. Examens-arbetet motsvarar 20 högskolepoäng var. Vi påbörjade Examens-arbetet den 12:e september 2005.
1.2 Syfte
Huvudsyftet med uppgiften var att skapa ett verktyg för digital hantering av enkätundersökningar och enkätsvar. I nuläget svarar man på enkäter-na via pappersutskrifter vilket gör att det tar mycket tid i anspråk att föra in svaren. Att skapa ett elektroniskt verktyg var motiverat eftersom det skulle förbättra arbetssituationen för de som idag arbetar med denna ena-handa uppgift. Lorensbergs Communication har även fått önskemål från sina kunder att ta fram ett sådant verktyg.
1.3 Begränsning
Eftersom detta examensarbete berörde stora områden, exempelvis an-vändbarhet, webbprogrammering och datasäkerhet, hade vi inte möjlig-het att i detalj sätta oss in i dessa områden utan till stor del grundade vi våra designbeslut på sedan tidigare inhämtad kunskap och erfarenhet.
Uppgiften var i stora drag given av Lorensbergs Communication i den kravspecifikation som vi fick. Därmed begränsades vi i vårt val av teknik och hur enkätundersökningarna var tänkta att fungera i stora drag.
1.4 Denna rapports målgrupp
Målgruppen för denna rapport är alla som studerar eller arbetar med ut-veckling av informationsteknik. Det är tänkbart att olika läsare kommer att finna olika delar av rapporten mer eller mindre intressanta men vi hoppas och tror att alla i målgruppen kommer att ha glädje av den.
1.5. Läsguide 3
1.5 Läsguide
Denna rapport beskriver vårt examensarbete. Följande kapitel ingår: Introduktion Detta kapitel introducerar läsaren till rapporten genom
kor-ta beskrivningar av förekor-taget, rapporten, dess förfatkor-tare samt uppgif-ten.
Metod Här redogör vi för våra metodval.
Uppgift I detta kapitel beskrivs kravspecifikationen.
Översikt av befintliga enkätsystem Här finns en redogörelse för några befintliga enkätsystem som studerades.
Teoretisk bakgrund I den teoretiska bakgrunden redogör vi för de alter-nativ som vi har valt mellan i utvecklingen samt hur vi motiverar valen.
Design av produkten En beskrivning av hur produktens användargräns-snitt och funktionalitet designades.
Problem som har uppstått Här beskriver vi några av de större problem som har uppstått under arbetets gång.
Resulterande produkter En beskrivning av de applikationer som vi har utvecklat.
Diskussion och slutsatser Avslutningsvis diskuterar vi hur våra resul-tat uppfyllde vår kravspecifikation, hur metoderna har använts och drar slutsatser utifrån detta. Vi har samlat idéer till förbättringar un-der arbetets gång som vi kortfattat presenterar i detta kapitel.
Några av de mest centrala termerna som används finns förklarade i bilaga A.
1.6 Typografiska konventioner
I rapporten använder vi oss av numrerade kapitel samt fyra rubriknivå-er där de två övrubriknivå-ersta är numrrubriknivå-erade. Den lägsta nivån särskiljs genom att efterföljande brödtext börjar på samma rad som rubriken.
Programkod, namn på klasser, filer, metoder och dylikt skrivs med ett teckensnitt medfast teckenbredd. Tekniska termer förkortas om
för-kortningen är den vanliga benämningen. Termen skrivs ut i sin helhet förs-ta gången den förekommer och förkorförs-tas därefter. De vanligast förekom-mande förkortningarna finns i tabell 1 på sidan xxi.
I de fall som vi anser det relevant anges hypertextlänkar i fotnoter. Des-sa referenser finns framför allt till för dem som vill läDes-sa mer om sådant som berörs ytligt i rapporten. Länkarna fungerade vid rapportens färdig-ställande och är valda med omsorg. Naturligtvis kan vi inte garantera att de alltid kommer att fungera.
Vid hänvisningar till figurer och tabeller som inte återfinns i bilagor anges sidnumret där figuren eller tabellen finns eftersom de ibland tende-rar att hamna en bit ifrån referensen.
När det är otydligt vad ett svenskt ord betyder och vi tror att den eng-elska termen är mer välkänd, skriver vi den engeng-elska termen inom paren-tes. Exempelvis skriver vi ”begäran (eng.request)” för att beskriva en
begä-ran från en klient till en server. I de fall det har funnits rekommendationer från Svenska Datatermgruppen2 har dessa följts, till exempel används or-det poppuppfönster istället för or-det engelska uttrycketpop-up.
Kapitel 2
Metod
Inom detta examensarbetes ramar var det viktigt att studera formen för hur programvaruutvecklingen bör bedrivas för att det ska ske på ett effek-tivt sätt. Nedan följer en utredning rörande vårt val av programutveck-lingsmetod.
Det är även viktigt att ha en metod för att uppnå och säkerställa god användbarhet hos systemet och detta diskuteras nedan.
2.1 Programvaruutvecklingsmetod
I detta kapitel diskuterar vi ett par olika programvaruutvecklingsmetoder. Vi valde att jämföra två vanligt förekommande lättviktsmetoder, Ratio-nal Unified Process (RUP) och Extreme Programming (XP). Detta eftersom
vi trodde att vi behövde en flexibel utvecklingsmetod då examensarbetet är ett litet projekt där förutsättningarna kunde komma att ändras. Dess-utom var vi inte så vana programvaruutvecklare, vilket innebar att vi kun-de ha svårt att bedöma hur lång tid olika moment skulle ta.
Som teoretisk grund valde vi två böcker om XP samt ett antal artiklar
om RUP och jämförelser mellan RUP och XP. Böckerna och artiklarna har
vi använt som kurslitteratur i kursen Användbarhetsorienterad systemut-veckling1, varför vi bedömer dem som relevanta.
2.1.1 Rational Unified Process
RUPär uppbyggt kring en mjukvara som är tänkt att underlätta och stödja
arbetet i projektet. Huvuddragen iRUPär följande [1, 2]:
1Vid Linköpings tekniska högskola, våren 2005.
Kurswebbplats:http://www.ida.liu.se/~HKGC10/
• Ha fokus på att leverera värde till kunden samt ha körbar program-vara.
• Hantera risker tidigt och kontinuerligt.
• Ha ett flexibelt förhållningssätt till förändrade krav. • Bygg upp systemet av fristående komponenter. • Jobba tillsammans som ett team.
• Utveckla programvaran iterativt.
• Ha kontinuerlig kontroll över kvaliteten. • Visualisera mjukvaran.
Man behöver inte haRUP-programvaran för att kunna följa dessa
hu-vuddrag, men den är tänkt att underlätta. Projektet ska bestå av fyra faser: Inception Förstå vad man ska göra.
Elaboration Fundera ut hur man ska göra det. Construction Göra en betaversion av produkten. Transition Göra den slutliga produkten.
Inom varje fas ska man iterera 6-9 gånger. Det innebär att processen är en blandning av vattenfallsmetoden och en iterativ process [1].
2.1.2 Extreme programming
XPär en programvaruutvecklingsmetod som skapades av Kent Beck och
Ward Cunningham för snart tio år sedan. Den präglas av ett flexibelt och kodcentrerat tänkande men inbegriper även arbetsmiljö och personalför-hållanden. Metoden lämpar sig för små projekt där deltagarna arbetar tätt ihop. För att båda ska vara lika insatta i all kod som skrivs samt hjälpa varandra under tidens gång används parprogrammering.
I terminologin för XP används återkommande termerna kund och
ut-vecklare. I beskrivningen nedan ser vi oss själva som utvecklare och
Lo-rensbergs Communication som kund och uppdragsgivare. Nedan återger vi kortfattat kärnvärdena hosXP[3].
2.1. Programvaruutvecklingsmetod 7 Kärnvärden
Konkret återkoppling Utvecklarna ska tidigt och kontinuerligt hålla kunden underrättad om hur arbetet fortskrider. Detta ska helst inte ske genom skriftliga rapporter utan hellre muntligen och via prak-tiska demonstrationer.
Successiv och flexibel planering Först görs en övergripande plan som se-dan bryts ner i iterationer. Detaljplaneringen görs successivt så att man bara planerar för den närmaste framtiden som man har över-blick över och kunskap om. Planeringen ska även ge utrymme för ändringar enligt kundens önskemål.
Testning Testverktyg ska användas för att underlätta kontinuerligt tes-tande och användandet av enkel och fungerande kod.
Muntlig kommunikation Utvecklarna ska kontinuerligt ha muntlig kon-takt. Detta underlättas genom att utvecklarna sitter i ett öppet kontor istället för i egna rum.
Successiv och flexibel design Det ska vara möjligt att ändra designen allt eftersom. Om möjligt ska man skjuta på designbeslut för att inte fatta dåligt underbyggda beslut.
XPi praktiken
De nedan uppräknade uppmaningarna är centrala iXP.
• Testa och integrera kodens olika delar ofta.
• Inspektera koden ofta för att säkerställa kvalitet och konsekvent an-vändande av kodstandard med mera.
• Sträva efter enkel kod. • Iterera med korta intervall. • Programmera i par.
• Jobba 40 timmar per arbetsvecka och ta rikligt med pauser. • Ha en nära relation till kunden, helst ska kunden finnas på plats. • Följ en kodstandard.
Under vissa förutsättningar ärXPmindre lämplig. Några faktorer som
gör att XP inte fungerar så bra är när arbetsgruppen är stor, när kunden
har låg tillit till utvecklarna eller använder teknik som inte medger tvära kast eller smidig testning [4].
2.1.3 Jämförelse mellan metoderna
RUP är till skillnad från XP en kommersiell produkt. RUP är tätt knuten
till en programvarusvit för systemutveckling frånIBM, och är ett stort och
flexibelt system. Bland annat detta gör attRUPäven passar större grupper
och grupper som inte befinner sig på samma plats. En annan skillnad är attRUPförsöker ta ett större helhetsgrepp medanXP i större grad
koncen-trerar sig på programmeringen [5].
RUP är förberett för stora projekt och kräver mycket anpassning för
att det ska passa ett examensarbete för två personer. RUPhar högre
inlär-ningströskel änXP. I en artikel i Computer Sweden [6] berättar erfarna
pro-jektledare om sina erfarenheter avRUPoch de tycker attRUPär bäst lämpat
för stora projekt med fler än 100 personer.XPpassar bäst vid
gruppstorle-kar på 2–10 personer [4].
2.1.4 Vår programvaruutvecklingsmetod
Vårt val föll påXP på grund av att det är lätt att komma igång, att vi har
använt metoden förut och att den är anpassad för små grupper. Dessutom trodde vi att den skulle passa vårt arbetssätt med parprogrammering, ett kontor med flera personer, fyrtiotimmarsveckor och tonvikt på muntlig kommunikation. XP är en bra grundstomme, men metoden anpassades
för våra behov, vilket förklaras nedan.
Parprogrammering
Vi utförde allt arbete tillsammans, vid en dator. Detta för att vi hela tiden skulle kunna komma med idéer till varandra, förklara för varandra och rätta varandras småfel i koden. Vi blev därför lika insatta i allt. Den som inte skrev på tangentbordet fick möjlighet att granska den kod som skrevs och fundera övergripande kring alternativa problemlösningsstrategier et-cetera. Vi varierade vem som skrev och vem som granskade.
XPhar även fördelen att vara flexibelt i planeringsfrågor och vid
ändra-de förutsättningar. Små iterationer gjorändra-de att vi snabbt och ofta såg resultat och kunde testa vårt program.
2.1. Programvaruutvecklingsmetod 9 Slutrapport
Under arbetets gång dokumenterade vi hur arbetet fortskred i denna rap-port. Vi skrev även i en dagbok där vi dagligen antecknade vad vi hade gjort, examensarbetets status samt eventuella insikter som vi ville komma ihåg. Dagboken gjorde det lätt att komma in i arbetet dagen eller veckan efter samt att vi kunde gå tillbaka och titta på vad som hade utförts och vilka tankar vi haft tidigare i projektet.
Kravspecifikation
Inledningsvis skapade vi en planeringsrapport med en detaljerad krav-specifikation, vilket innebar att vi satte oss in översiktligt i bland annat de problem som kan uppstå i samband med olika designval. Vi gjorde en kravspecifikation även om XPistället för en kravspecifikation förespråkar
kontinuerlig kontakt med uppdragsgivaren. Detta eftersom tydliga krav och målsättningar är en viktig del av ett examensarbete. Det kändes även mer tillfredsställande för oss som systemutvecklare att ha förstått uppgif-ten innan vi tog oss an den.
Parallell behandling
Enligt tidsplanen i planeringsrapporten skulle många aktiviteter ske se-kventiellt. I praktiken utfördes i princip alla aktiviteter parallellt vilket vi även fann stöd för i vår programvaruutvecklingsmetod XP. Detta
pa-rallella arbete resulterade automatiskt i små iterationer vilket har många fördelar.
Avvikelser frånXP
Behovet av dagboken, planeringsrapporten och slutrapporten innebar att vi var tvungna att rucka påXPs regler vad gäller till exempel
avståndsta-gandet mot dokumentation och den initiala planeringen. Projektet skulle enligt instruktionerna för examensarbetet inledas med en planeringsrap-port och avslutas med en slutrapplaneringsrap-port där arbetet och resultatet beskrevs.
Andra saker somXPförespråkar men som vi inte kunde anamma är att
en slutanvändare ska finnas på plats under utvecklingen samt att kunden ska skriva testprogrammen. Vi har i huvudsak testat våra webbapplikatio-ner genom att manuellt använda dem i webbläsaren men vi har även ut-värderat programmen med hjälp av testanvändare flera gånger. Vår kund, Lorensbergs Communication, har funnits på plats eftersom vi har arbetat
i deras lokaler. Vi har inte haft tillgång till de verkliga slutanvändarna, till exempel skolsjuksköterskor.
2.2 Designmetod
I stycke 5.1 finns en teoretisk genomgång av begreppet användbarhet. Ne-dan presenterar vi vårt val av metod för att uppnå god användbarhet.
Löwgren och Stolterman [7] delar upp designprocessen i tre delar: vi-sion, operativ bild och värdering. Eftersom visionen till stor del var färdig i den erhållna kravspecifikationen, se bilaga B, kommer vi att fokusera på den operativa bilden och värderingen. För dessa delar i processen kommer vi att välja en eller flera metoder.
2.2.1 Vision
Visionsarbetet innefattar att ta fram den vision som produkten ska sträva efter att uppfylla. I denna fas funderar man övergripande på hur proble-met kan lösas.
2.2.2 Metoder för att generera en operativ bild
Visionen omsätts i en operativ bild som är konkret, precis och detaljerad. Den operativa bilden ska gestaltas så att den kan utforskas av oss utveck-lare och så att vi kan kommunicera den till andra.
Ett vanligt sätt att åskådliggöra den operativa bilden är att använda gestaltningstekniker. Det är tekniker för att gestalta produkten, mer eller mindre detaljerat. Exempel på gestaltningstekniker är [7]:
Scenario En skriven berättelse som illustrerar ett användningsfall, med betoning på sammanhanget. Scenariot kan användas för att få en känsla för hur produkten ska användas och sätta in den i ett stör-re sammanhang.
Gränssnittsskiss En skiss av ett möjligt gränssnitt till produkten. Den blir mer detaljerad än scenariot och kan användas som förlaga för gräns-snittsimplementationen. Gränssnittsskissen kan användas för inle-dande användbarhetstest. Denna skiss är snabb, enkel och billig att ta fram.
Storyboard En tecknad serie där händelserna i produkten illusteras med bilder. Det blir en kombination av scenarion och gränssnittskisser.
2.2. Designmetod 11 Dynamisk pappersprototyp En utveckling av gränssnittskissen som kan hantera interaktion med användaren genom att till exempel använda klisterlappar för att fälla ut menyer. Vid ett användbarhetstest kan till exempel en utvecklare agera fönsterhanterare.
Dynamisk datorprototyp En digital prototyp med till synes samma funk-tionalitet som slutprodukten. Prototypen ska ge en uppfattning om hur det slutgiltiga systemet är att använda utan att implementera all den funktionalitet som slutprodukten ska innehålla.
När man tar fram den operativa bilden är det viktigt att inte låsa sig vid en modell i ett tidigt skede, utan att arbeta med flera parallellt, vara öppen för nya idéer och inte vara rädd för att bygga om hela bilden. Ett sätt att aktivt motverka låsningar kring ett visst lösningsförslag är att ar-beta med något som Löwgren och Stolterman kallar ”informella tekniker för att häva fixeringar” [7]. Som exempel på dylika tekniker ges att ställa sig själv oväntade frågor i stil med ”Vad skulle jag göra om projektbudge-ten var tio miljoner?”. Ytterligare ett exempel som går ut på att förändra problemlösningsstrategin är att välja en känd lösning som inte duger och be någon att kritisera den.
2.2.3 Metoder för värdering
Värderingen, eller användbarhetstestningen, är naturligtvis ett viktigt steg i designprocessen. Då kan man erhålla ett kvitto som visar hur användbar produkten upplevs. Enligt Löwgren och Stolterman [7] är användbarhets-testning ett mer eller mindre formellt experiment, där de blivande använ-darna försöker använda systemet eller en prototyp för att genomföra ett antal kortare testuppgifter. Under experimentet noteras användarnas in-teraktion med systemet med fokus på prestation, till exempel hur många fel som görs och hur lång tid olika operationer tar att utföra.
Nielsens heuristiska utvärderingsmetod
Ett exempel på en välanvänd användbarhetsmetod för webbgränssnitt är Nielsens heuristiska utvärderingsmetod [8]. Metoden utgår från ett tiotal punkter som Nielsen anser viktiga för användbarheten. Utvärderingen be-står av att cirka fem användare använder systemet och tillsammans med testledaren bedömer hur väl Nielsens punkter överensstämmer med pro-dukten.
Denna metod har kritiserats av användbarhetsexperten Tajakka [9] för att vara alltför godtycklig och diffus. Dessutom kritiseras metoden för att
vara onödigt resurskrävande då den kräver minst fem testanvändare för att ge bra resultat [8]. Istället föreslår Tajakka sin egenutvecklade metod, Design-Interaktion-Navigation-metoden (DIN-metoden) [10], som han
på-står löser dessa problem.
DIN-metoden
DIN-metoden utgår från vad som kännetecknar bra egenskaper i ett
an-vändargrässnitt, är konkret och innehåller handfasta rekommendationer på ett flertal punkter. Den är inte vetenskapligt utvecklad och tycks till stor del bestå av Tajakkas egna åsikter. Metoden utgår från en webbplats tre grundläggande kännetecken: design, interaktion och navigation. För varje kännetecken värderas ett antal egenskaper. Metoden innehåller även ett antal mycket konkreta råd i stil med att man alltid ska ha vänsterställ-da formulär. Det mesta i metoden kan vi själva utvärdera och testa men upplevelsen av navigationen och möjligheten till överblick av webbplat-sen kräver externa testanvändare.
Design Designen ska präglas av enkelhet och struktur. Enkelhet finns om det går fort och lätt att få en överblick över webbplatsens innehåll och de funktioner som erbjuds. Designstrukturen handlar om hur informatio-nen är strukturerad i form av till exempel rubrik- och länkhantering, bröd-text och bilder samt formulär. Det är viktigt att informationen grupperas så att viktig information framträder tydligt, att informationen även syns i mindre skärmupplösningar utan att bläddring i sidled krävs och så att balansen mellan information och tom yta är god.
Navigation Navigationen ska vara enkel i den meningen att användaren ska förstå var han eller hon befinner sig, har varit och kan navigera sig. Om det finns flera menyer är det nödvändigt att kopplingen mellan dem är tydlig. En meny får inte ta för stor plats på webbplatsen, maximalt en femtedel, och det ska gå att navigera utan hjälp av datormus. Vidare är det viktigt att namnen på menyelementen är väl överensstämmande med vad de innehåller samt att man kan ta sig tillbaka till startsidan.
Interaktion Interaktionen är uppdelad i tre delar: felhantering, instruk-tioner/information och användarkontroll. Felhanteringen ska uppmärk-samma, informera och ge förslag på hur användaren kan åtgärda felet. Instruktionerna och informationen ska underlätta för användaren att an-vända webbplatsen och i möjligaste mån förhindra fel. Anan-vändaren ska ha
2.2. Designmetod 13
kontroll över vad som sker i interaktionen och bör kunna ångra val samt avbryta och stanna upp processer.
2.2.4 Vår användbarhetsmetod
Vision
Vi utgick från Lorensbergs Communications vision för hur enkätunder-sökningar ska hanteras och formulerade en vision som är specifik för den del av enkätmodulen som examensarbetet innefattar.
Operativ bild
Eftersom visionen till stor del var given fokuserade vi inte på scenarion eller storyboards. Istället fokuserade vi på gränssnittsskisser och en dyna-misk pappersprototyp som vi även utvärderade. Därefter använde vi de riktiga programmen för utvärdering.
Värdering
Vi har tidigare i ett flertal projekt använt oss av Nielsens heuristiska ut-värderingsmetod och finner visst fog för Tajakkas kritik, se stycke 2.2.3. Nielsens metod är mer generell än Tajakkas som är strikt webbanpassad och konkret.
Eftersom vi användeXPoch påbörjade programmering och
gränssnitt-design i ett tidigt skede hade vi ett fungerande användargränssnitt till vå-ra applikationer som gick att testa. Vi använde oss av MVC-arkitekturen
vilket innebär att gränssnittslagret är åtskiljt från de övriga delarna och därför med lätthet kan modifieras. Detta gjorde att en datorprototyp inte var nödvändig.
Inledningsvis testade vi gränssnitten på en pappersprototyp för att an-vändaren skulle känna sig fri att komma med åsikter och kritik. Pappers-prototypen gick snabbt att utveckla och vi trodde att testanvändarna var mer benägna att kritisera och reflektera kring designen om den inte kän-des färdig och opåverkbar. Som utvecklare är det ofta lättare att ändra designen i en pappersprototyp jämfört med i produkten.
Vid utvärderingen skulle vi även säkerställa att de användbarhetskrav som vi ställde på vår produkt i kravspecifikationen var uppfyllda genom att först användaDIN-metoden och sedan intervjua och observera
testan-vändare. När vi använde DIN-metoden gick vi igenom punkterna i den
Till vår hjälp i värderingen hade vi definitionen av användbarhet, se stycke 5.1, för att se om vår produkt var användbar. Det är dock våra krav i kravspecifikationen som var viktigast att uppfylla.
2.3 Metodkritik
Vi har förstås inte haft möjlighet att ta del av all litteratur inom området men har försökt att välja vår litteratur med omsorg. Eftersom XPförordar
att man börjar programmera direkt vid projektuppstarten trodde vi att det fanns det en risk att vi skulle börja bygga systemet med bristfälliga kun-skaper och inte vidareutveckla det på bästa sätt. Så blev det dock inte utan vi byggde om systemet i takt med att vi tillägnade oss nya kunskaper.
Vad gäller användbarhetsmetoder finns en uppsjö designparadigmer att välja bland och vi hade svårt att på förhand veta om vi valde den som är bäst lämpad för detta projekt. Detta är något som vi fortfarande inte med säkerhet kan avgöra men det tycks som om metoden har fungerat bra.
Kapitel 3
Uppgift
Inledningsvis följer en beskrivning av uppgiften i form av en kravspecifi-kation, som grundar sig på den övergripande kravspecifikation som vi fick av Lorensbergs Communication, se bilaga B. Därefter beskriver vi krav-specifikationen kortfattat.
Enkätmodulen kommer att vara en fristående del av Asynja, både på grund av prestanda- och säkerhetskäl. I enkätmodulen ska det finnas möj-lighet att publicera och svara på enkäter samt ta emot och lagra svaren.
Utvecklingen av den fristående modulen ska ta hänsyn till att delar av modulen i framtiden kan komma att integreras i det befintliga Asynjasy-stemet. Det är dock inte troligt att den del där de svarande lämnar sina enkätsvar kommer att integreras i Asynja på grund av säkerhetsskäl.
Användbarhetskraven, krav fem till elva bland de icke-funktionella kraven, är formulerade med inspiration från Jakob Nielsens användbar-hetsheuristiker [8].
3.1 Funktionella krav
1. Inloggningsmöjlighet för administratörerna som ska skapa enkät-undersökningarna ska finnas men behöver inte valideras mot någon extern källa.
2. Administratörer som är inloggade i designapplikationen ska kunna publicera enkäter genom att överföra dem till svarsapplikationen. 3. En enkätundersökning består minst av en frågesamling samt
inlogg-ningsinformation för de som ska besvara enkäten. Denna informa-tion ska finnas i svarsapplikainforma-tionen.
4. Frågesamlingarna, målgruppernas inloggningsinformation samt en-kätsvaren ska lagras i ett format som gör att informationsutbyte med andra applikationer kan ske på ett enkelt sätt.
5. Varje person i målgruppen ska ha användarnamn och lösenord för att kunna logga in och svara på en publicerad enkät.
6. En inbjudan ska skickas till alla i målgruppen med lämplig informa-tion om enkätundersökningen.
7. Enkätsvaren ska lagras krypterat i svarsapplikationen.
3.2 Icke-funktionella krav
1. De webbapplikationer som skapas ska fungera oberoende av val bland de vanligt förekommande webbläsarna1.
2. Applikationerna ska vara skrivna i Java och köras under Tomcat på en webbserver.
3. Webbservern som kör applikationerna ska inte ha några beroenden till Asynjas databas eller andra databashanterare.
4. Applikationerna ska vara plattformsoberoende.
5. Användargränssnittet ska vara lätt att förstå och använda för perso-ner med grundläggande datorvana.
6. Systemets användare ska tydligt informeras om vad som har hänt och vad som pågår i systemet.
7. Val av begrepp, koncept och metaforer ska upplevas konsekvent med användarnas verklighet.
8. Användaren ska ha möjlighet att återställa misstag.
9. Applikationerna ska förhindra fel från användarens sida i möjligaste mån genom att tydliggöra när händelser aktiveras.
10. Användaren ska inte behöva ha onödigt mycket information i hu-vudet, utan all nödvändig information ska finnas lätt tillgänglig i systemet.
3.3. Beskrivning av kravspecifikationen 17
11. Antalet interaktioner mellan användare och system för att utföra en uppgift ska minimeras, men inte på bekostnad av något annat användbarhetskrav.
3.3 Beskrivning av kravspecifikationen
3.3.1 Krav på designapplikationen
Inloggning
Användarna ska kunna logga in för att administrera enkätundersökning-arna. Användaren är i detta fall till exempel en skolsköterska eller kurator. Dessa personers inloggningsuppgifter finns redan i Asynjas databas men autentiseringen görs istället lokalt i vår applikation. Detta eftersom det i dagsläget är oklart hur pass integrerad i Asynja som denna modul kom-mer att bli.
Publicera enkäter
När Asynjas administratörer ska publicera en enkätundersökning elektro-niskt måste de välja vilken frågesamling som ska användas i enkätunder-sökningen, och vilka som ska inbjudas till att svara på enkäten.
Datat som beskriver frågesamlingarna och målgrupperna ska sparas i ett format som möjliggör att de kan tillgodogöras från andra system, ex-empelvis Asynja.
De som ska svara på enkäten behöver ett användarnamn och ett lö-senord som de kan använda vid inloggningen till enkäten.
I samband med publiceringen skickas en inbjudan med inloggnings-uppgifter, enkätensURL samt eventuellt meddelande från den som
publi-cerat enkäten, ut via e-post till de som ska svara.
Vid publicering överförs enkäten och information om målgruppen till svarsapplikationen där respondenterna loggar in för att besvara enkäten.
3.3.2 Krav på svarsapplikationen
Inloggning för att svara på enkäter
Inloggningsuppgifterna ska finnas i svarsapplikationen eftersom inget be-roende till direkt kommunikation med designapplikationen får finnas för att kunna svara på enkäter.
Ta emot och lagra enkätsvar i svarsapplikationen
Enkätsvaren ska mellanlagras i svarsapplikationen för att vid annan tid-punkt överföras till designapplikationen. Vid lagring måste känsliga da-ta krypteras eller på annat sätt göras oåtkomliga för obehöriga. Vi måste även specificera hur detta görs för att underlätta framtida importering av enkätsvar till andra system.
Kapitel 4
Översikt av befintliga
enkätsystem
Vi har studerat några befintliga enkätsystem för att hämta inspiration. Med dem som underlag är det lättare för oss att bedöma vad som är rele-vant att ha med i vår enkätmodul. Vi har inget krav på att man ska kunna skapa själva enkäten i vårt program, men vi presenterar skapade enkäter och måste därför specificera vilka element som kan ingå i en enkät.
Det finns ett mycket stort antal befintliga enkätsystem och vi har en-dast valt ut en handfull. Vi börjar med att kort beskriva Asynjas befintliga enkätsystem.
4.1 Asynjas enkäthanterare
Asynja har en befintlig enkäthanteringsdel som kan visa upp enkäter för inloggade administratörer i Asynja, samt exportera dem till enPDF-fil för
utskrift. Ett exempel på en enkät från Asynja finns i figur 4.1 på sidan 20. De frågetyper som finns är antingen-eller-frågor, flervalsfrågor, fritextfrå-gor med en eller flera rader, fråfritextfrå-gor med numeriska svar samt matriser av både antingen-eller-frågor och flervalsfrågor.
4.2 Litium Enkät
Litium Enkät är ett verktyg för att skapa webbaserade enkätundersök-ningar [11]. Vi har inte kunnat testa det men det verkar vara flexibelt och enkelt. Följande information om Litium Enkät kommer från deras
4.3. Datainstitutets Business Intelligence 21
plats [12]. Enkäterna skapas i systemet, systemet skickar e-post till respon-denterna och resultatet sammanställs i en rapport.
Enkätgeneratorn har stor flexibilitet och man kan bland annat välja språk, hur många gånger en användare ska få besvara enkäten, om man ska ha separata webbsidor för varje fråga och tid för publicering. Påmin-nelser skickas ut till respondenterna. Man kan ha en inledning till frågorna med text och bild och Litium stödjer så kallade vägvalsfrågor1. Förutom de vanligaste frågetyperna (flervals-, antingen-eller-, textrads- och textrute-frågor) finns stöd för tid, datum, personnummer, en utfällningsbar meny för antingen-eller-svar, frågor i tabellform samt skalor och rangordning.
4.3 Datainstitutets Business Intelligence
Företaget Datainstitutet2 har en grafisk Microsoft Windows-programvara med möjlighet att skapa och publicera enkäter. Informationen om denna är hämtad från deras webbplats [13]. Systemet har även en webbmodul som möjliggör administration via Internet. Programmet är inte gratis, till exempel kostar webbmodulen extra.
Det finns 17 olika frågetyper att välja bland. Utöver de vanligaste finns kombination av flervalsfrågor och fritextfält, en tabell med numeriska svarsalternativ, olika skalor med bland annat siffrorna 2–5, en samtyc-keskala och en viktskala samt möjlighet att komplettera en text med ett ord på slutet samt att i ett fritextfält associera till ett eller flera ord.
4.4 Relationwise
RelationwiseA/Sär ettIT- och konsultföretag som bland annat
tillhanda-håller en webbtjänst för att skapa och publicera enkäter. Följande informa-tion är hämtad från deras webbplats [14]. Det finns möjlighet att prova de-ras system i webbläsaren Microsoft Internet Explorer, vilket vi gjorde. För-utom de vanligaste frågetyperna finns möjlighet att lägga till ett fritextfält vid flervalsfrågor, att kombinera flera olika textfält vid till exempel inmat-ning av adressuppgifter samt till en delad antingen-eller-tabell. Det går även bra att lägga till bilder.
Utseendet kan ändras på flera olika sätt, man kan lägga till logotyper på olika ställen på enkätsidorna samt välja färger. Vi hittade endast en version på danska. En av frågetyperna är en delad antingen-eller-tabell,
1Frågor där efterföljande frågor beror på tidigare svar.
där det går att välja ett av alternativen God, Middel och Dårlig samt ett av alternativen Vigtigt och Mindre vigtigt för varje underfråga.
4.5 Netigate
Företaget Netigate är ett undersökningsföretag som har ett enkätunder-sökningsverktyg med samma namn. Tjänsten är webbaserad och har ett trevligt gränssnitt. Man kan skapa enkäter och publicera dem. Netigate stödjer bland annat start- och stoppdatum för enkäternas publicering, oli-ka språk, designteman, en e-postadress till en kontaktperson för enkäten samt välkomst- och tacktext [15]. Frågorna kan enkelt förhandsgranskas samtidigt som de skapas [15].
4.6 E-enkät
Enkäthanteraren E-enkät är utvecklad av företaget Develosys systemut-veckling. All information om E-enkät är hämtad från deras webbplats [16]. I systemet kan man skapa frågor, publicera undersökningen samt skapa rapporter av resultatet, men enkätinbjudan skickas manuellt från inbju-darens e-postprogram. Detta enkätsystem är en enklare variant med alla frågor på samma webbsida samt ett fåtal frågetyper. Bland annat finns flervalsfrågor och antingen-eller-frågor där de senare visualiseras anting-en med radioknappar eller i anting-en utfällbar manting-eny.
4.7 re:
re:PDF har en lösning där enkäterna består av PDF-sidor. Informationen
om denna är hämtad från re:PDFs webbplats [17]. Enkätmakarna skapar
sina enkäter i valfritt program och exporterar dem sedan tillPDF. Därefter
används Adobe Acrobat för att skapa fält där respondenterna kan svara. Den färdiga filen laddas upp till re:PDFs webbplats och publiceras.
Förde-lar med detta är att enkätmakaren får stor kontroll över utseendet samti-digt som han eller hon får stora möjligheter att utforma enkäten efter tycke och smak. En nackdel är att den kommersiella programvaran Adobe Acro-bat krävs för att skapa enkäten. Den svarande måste även ha möjlighet att visaPDFer med formulär och lämna svar via en installerad programvara.
4.8. Websurvey 23
4.8 Websurvey
All information om Websurvey är hämtad från deras webbplats [18]. Fö-retaget Textalk har skapat enkätsystemet Websurvey och anger själva att det är det ledande enkätverktyget för Internet. Bland kunderna finns till exempel Regeringskansliet, Volvo, Svenska Spel och Hennes & Mauritz.
Detta enkätsystem har också många olika sorters frågor och kombina-tioner av dem. Till de numeriska svaren finns en ruta till varje siffra. Vid ta-beller går det att blanda fritextfält, utfällningsbara menyer samt antingen-eller-val ganska friskt. Det går att infoga bilder till frågorna och det finns även en rangordningsmatris. Den fungerar dock inte när vi provade den i webbläsaren Mozilla Firefox, eftersom det gick att säga att flera alterna-tiv skulle vara på första plats. Man kan bifoga information om frågan som visas genom att ett nytt litet webbläsarfönster öppnas.
Det finns också en skala där användaren kan förflytta en markör med musen för att svara. Skalan kan placeras både lodrätt och vågrätt. Detta svarssätt kräver musarbete men ett textfält finns där respondenten kan skriva in sitt svar manuellt med siffror.
4.9 Tillvaratagna idéer
Efter att ha studerat de olika frågetyper som lösningarna ovan använder kom vi fram till att de som redan fanns i Asynja verkade välanpassade och heltäckande. Vi behövde exempelvis inte fält för personnummer, adress eller liknande eftersom enkätsvaren ska kopplas till en journal där sådana uppgifter finns tillgängliga.
Flera av de undersökta systemen använde sig av utfällbara menyer för att välja ett av flera alternativ. Vi valde istället att endast ha radioknappar för detta behov eftersom vi anser att dessa är mer överskådliga.
Relationwise använde en delad antingen-eller-tabell vilket verkade svårt för våra användare att förstå. Våra enkätmakare måste istället gö-ra två sepagö-rata frågor.
Business Intelligence har flera olika typer av skalor, till exempel samtycke- och viktskala. Vi kan uppnå samma funktionalitet genom att använda vår skala eller radioknappar.
Vi har använt frågetyperna i Asynja med några modifieringar. Istället för en skala med ett skjutreglage använde vi radioknappar för att öka till-gängligheten för de användare som inte använder mus.
Förutom de frågetyper som vi har valt att implementera finns det möj-lighet att utöka systemet vid behov så att nya frågetyper kan hanteras.
Flera av de utvärderade systemen använder sig av uppdelning av en-käten i flera sidor, exempelvis en sida per fråga. Det har både för- och nackdelar men är nog viktigast om man har en väldigt omfattande enkät eller använder sig av villkorsstyrda frågor.
Vissa system har alternerande bakgrundsfärg för att kunna markera antingen att en ny fråga börjar eller att man växlar mellan fråga och svars-alternativ. Men vi ansåg att det inte behövdes för att kunna särskilja frå-gorna utan problem.
Systemet som använder sig avPDFär intressant men upplägget
Kapitel 5
Teoretisk bakgrund
Detta kapitel beskriver den teoretiska bakgrunden som ligger till grund för vårt resultat. Kapitlet inleds med ett stycke om användbarheten där vi diskuterar begreppet användbarhet, vår målgrupp samt hur våra använd-barhetskrav skulle uppfyllas. Därefter följer en utredning om hur våra in-data skulle utformas, det vill säga frågesamlingarna och målgrupperna. Sedan diskuterar vi översiktligt hur personuppgifter skulle behandlas i våra program och sist följer ett större stycke om hur programmen skulle implementeras.
5.1 Användbarhet
Begreppetanvändbarhet definierades 1998 av Internationella
Standardise-ringsorganisationen, ISO1, i standardenISO 9241-11 [19] som:
Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satis-faction in a specified context of use.
Vår översättning:
Den grad till vilken en produkt kan användas av specifika an-vändare i en given användningssituation för att uppnå specifi-ka mål på ett kraftfullt, effektivt och tillfredsställande sätt.
Enligt användbarhetsexperten Tajakka [20] kan begreppen kraftfullhet, effektivitet och tillfredsställelse i definitionen beskrivas på följande sätt:
1URL:http://www.iso.org
Kraftfullhet I vilken utsträckning ett mål eller en uppgift är uppnådd. Effektivitet Den grad av ansträngning som krävs för att slutföra och
upp-nå målet eller uppgiften. En mindre ansträngning ger högre effekti-vitet.
Tillfredsställelse Den grad av tillfredsställelse och positiva känslor som produkten frambringar då den används.
Vi avsåg att göra en produkt med god användbarhet enligt denna de-finition. Detta säkerställdes genom att produkten utvärderades enligt den metod som är beskriven i stycke 2.2.
5.1.1 Målgrupp
Användbarhetsdefinitionen kräver att det finns en specificerad målgrupp att anpassa sig till. Att veta vilka som ska använda systemet var viktigt både när vi utvecklade systemet och när vi utvärderade användbarheten.
Asynja har ingen uttalad målgrupp men är tänkt att kunna använ-das av all personal som kommer i kontakt med systemet inom företags-och skolhälsovården. Ofta är denna personal ovan att arbeta med dato-rer. Målgruppen för vår designapplikation liknar Asynjas målgrupp och är därmed även den tämligen bred. Vi kunde inte förutsätta någon större datorvana, men förmåga att utföra grundläggande operationer såsom att navigera med tangentbord och eventuellt mus eller liknande är en förut-sättning.
Eftersom vi inte kan veta något om de respondenter som kommer att använda svarsapplikationen har den mycket stora krav på användbarhet.
5.1.2 Våra användbarhetskrav
Våra krav på användbarhet var de icke-funktionella kraven nummer fem till elva, se stycke 3.2. Nedan diskuterar vi hur våra användbarhetskrav kan uppfyllas.
Alla kraven nedan samverkar för att göra produkten kraftfull, effek-tiv och tillfredsställande. Samtliga krav medför effekeffek-tivitet och framförallt krav fem, sex och nio ger tillfredsställelse.
5.1. Användbarhet 27 Krav 5: Användargränssnittet ska vara att lätt att förstå och använda för personer med grundläggande datorvana.
Arbetsflödet i designprogrammet måste vara intuitivt. Användarna måste till exempel kunna förstå att de måste sätta ihop en enkätundersökning innan den går att publicera. För detta krav krävs även att navigationssy-stemet är väl uttänkt för att främja arbetsprocessen. Det bör även finnas korta instruerande texter som berättar om den aktuella vyn eller funktio-nen.
För att alla ska kunna förstå webbplatsen snabbt och enkelt krävs ett tydligt teckensnitt samt färg och form som gör det enkelt att urskilja olika element såsom text, länkar, rubriker, formulärelement för indata, knappar att trycka på, bakgrund med mera. Vi utelämnar funktionalitet för att i våra applikationer kunna ändra teckenstorlek, eftersom detta enkelt går att göra i de webbläsare som vi avser att stödja.
Krav 6: Systemets användare ska tydligt informeras om vad som har hänt och vad som pågår i systemet.
Kravet borde öka tillfredsställelsen av produkten eftersom användaren måste få kunskap från systemet för att fatta kloka beslut. I annat fall upp-står lätt frustration.
Även för att uppnå detta krav krävs ett intuitivt arbetsflöde och ett tydligt navigationssystem så att det går att förstå var i flödet som man be-finner sig för tillfället och vart man är på väg. Textmeddelanden på webb-sidan bör underrätta användaren om systemets status.
Krav 7: Val av begrepp, koncept och metaforer ska upplevas konsekvent med användarnas verklighet.
Begrepp som enkät, målgrupp och respondenter är termer som används i enkätsammanhang medan termen enkätundersökning i vårt fall är ett samlingsord för en kombination av en enkät och en målgrupp. Detta måste kommuniceras konsekvent och tydligt genom hela applikationerna.
Om metaforer används på ett tydligt sätt kan de främja användbar-heten. Ett exempel är arkivflikmetaforen där de olika vyerna visas upp under flikar som delar i ett dokumentarkiv. Denna metafor gör det tydligt för användaren var han eller hon befinner sig i systemet.
Krav 8: Användaren ska ha möjlighet att återställa misstag.
I möjligaste mån ska man kunna redigera och ångra det man har gjort, men vissa saker är definitiva. Man kan till exempel inte ångra ett e-postutskick som redan har gått iväg. Däremot kan vi vara tydliga med att det kommer att hända, se krav nio.
Krav 9: Applikationerna ska förhindra fel från användarens sida i möj-ligaste mån genom att tydliggöra när händelser aktiveras.
Händelser som är extra viktiga och som är oåterkalleliga bör föregås av en bekräftelse så att användaren får en chans att hejda sig. Exempel på sådana tillfällen är innan enkätsvaren skickas iväg samt innan en enkät-undersökning publiceras.
Krav 10: Användaren ska inte behöva ha onödigt mycket information i huvudet, utan all nödvändig information ska finnas lätt tillgänglig i systemet.
I applikationerna ska användaren alltid kunna välja bland olika alternativ när sådana finns istället för att behöva kunna dessa utantill. När till exem-pel en enkätfil ska väljas bör användaren se vilka filer som finns att tillgå direkt i applikationen.
Krav 11: Antalet interaktioner mellan användare och systemet för att utföra en uppgift ska minimeras, men inte på bekostnad av något annat användbarhetskrav.
Webbsidorna bör upplevas snabba men det får inte gå ut över till exempel förståelsen av systemet. Vi försöker att ha funktionerna lättåtkomliga utan onödiga omvägar eller grupperingar.
5.2 Enkätutformning
Frågesamlingarna utformas inte i vår designapplikation. Enkäterna lagras i Extensible Markup Language-format (XML) vilket förenklar datautbyte
med andra system. I framtiden tänker vi oss att man i enkätmodulen även har möjlighet att skapa frågesamlingar.
Frågetyperna har utformats med tanke på hur de var uppbyggda tidi-gare i Asynja. I nuläget hanteras inte villkorsstyrda frågor, det vill säga att
5.2. Enkätutformning 29
man inte kan bestämma vilka frågor som ska besvaras beroende på tidiga-re svar. Om man till exempel svarade ja på en fråga, kanske enkätmakatidiga-ren vill ställa några följdfrågor som inte behövs vid ett nekande svar.
Dessa frågetyper förekommer:
Antingen-eller-frågor Frågor där enbart ett alternativ av flera kan väljas. Vi kallar denna frågetyp förradio.
Flervalsfrågor Frågor där flera alternativ kan väljas. Vi kallar denna frå-getyp förcheckbox.
Fritextfrågor med en rad Används för frågor där ett kort fritextsvar ska lämnas. Det går inte att byta rad och enkätmakaren bestämmer en övre gräns för hur många tecken som ska få plats. Denna typ kallar vi förtext.
Fritextfrågor med flera rader Används för frågor där ett längre fritextsvar ska lämnas. Enkätmakaren kan välja hur många ra-der som ska visas i textrutan men respondenten kan skriva flera rader. En rullist gör det möjligt att bläddra i texten. Denna typ kallar vi förtextarea.
Frågor med numeriska svar En textrad där respondenten enbart kan lämna ett heltal som svar. Enkätmakaren kan begränsa vilket inter-vall som svaret ska ligga i. Denna frågetyp kallar vinumerical.
Frågor med underfrågor Används då man vill ha flera frågor med samma svarsalternativ under samma fråga. Svarsalternativen kan antingen vara av antingen-eller- eller flervalstyp. Dessa frågetyper benämns inte med egna namn, utan benämns antingen radio eller check-box. Dessa är alltså specialfall av antingen-eller-frågor och
flervals-frågor.
Frågor med skala Används då en fråga ska besvaras med en bedömning på en skala. Enkätmakaren kan bestämma skalans numeriska värden samt etikett i början respektive slutet av skalan. Denna typ kallar vi för scale. Skalor är egentligen inte nödvändiga eftersom
radi-oknappar kan ge samma funktionalitet men vi ansåg att dessa var lämpliga eftersom de är vanliga i enkäter.
Rubrik Används för att avdela stycken i enkäten. Typen är egentligen ingen frågetyp, men är ändå en del av enkäten. Rubriker kallar vi förheading.
Alla frågor måste besvaras, förutom flervalsfrågor, eftersom man där ska få lämna valfritt antal svar.
5.3 Målgruppsutformning
Även målgruppen skapas utanför vårt program och importeras som en
XML-fil. Det designapplikationen vet om målgruppen är målgruppens
ti-tel, ett unikt namn samt varje respondents användarnamn, lösenord och e-postadress. Kopplingen mellan användarnamn och personens verkliga identitet ska inte finnas i designapplikationen. Information om vilka an-vändare som har besvarat enkäten finns i form av användarnamnet.
I en framtida version av applikationen bör man kunna konstruera mål-grupper i ett grafiskt gränssnitt.
5.4 Personuppgifter
Enligt Personuppgiftslagen (1998:204) [21] §18 får känsliga personuppgif-ter behandlas bland annat för hälso- och sjukvårdsändamål för förebyg-gande vård eller administration. Personuppgiftslagen stipulerar en rad be-stämmelser kring behandling av personuppgifter.
De personuppgifter som förekommer i våra applikationer är respon-denternas e-postadresser och det kan även tänkas att respondenterna som svar på enkäter lämnar personuppgifter i svaren. Kopplingen mellan iden-titeten och användarnamnet finns, förutom eventuellt i e-postadressen, endast där målgruppsfilen är skapad vilket inte är i någon av våra app-likationer.
Personuppgiftslagen [21] §31 säger att säkerhetsåtgärderna för be-handling av personuppgifter ska vara sådana att de står i paritet med till exempel de tekniska möjligheter som finns och hur känsliga personupp-gifterna är.
5.5 Implementationsteori
5.5.1 Givna tekniska förutsättningar
Eftersom Asynja är utvecklat som en webbapplikation i programmerings-språket Java skulle även våra applikationer skrivas i detta programme-ringsspråk (version 5.0) och vara anpassade för webben. Applikationerna
5.5. Implementationsteori 31
körs på en webbserver med Tomcat2 och användargränssnittet består av webbsidor. Vi valde därför att använda Java Servlets3 och JavaServer Pa-ges4, hädanefter benämnda servlets respektive JSP. Tomcat är gratis och har öppen källkod. Vi använder Tomcat version 5.5.9.
Utvecklarna av Asynja eftersträvar att endast skickaHTMLtill sina
kli-enter, vilket även vi gjorde. I Asynja förekommer JavaScript, bland annat för att kunna validera formulärdata på klientsidan. Därför tillät även vi oss att vid behov använda JavaScript men vi strävade efter att minimera dessa behov. Vi ville endast använda JavaScript för att tillföra funktionali-tet som man ändå kan klara sig utan om JavaScript inte används.
För utveckling av Asynja används utvecklingsmiljön Eclipse Platform. Vi använde oss av Eclipse-projektet Eclipse Web Tools Platform Project5 för att underlätta utvecklingen av våra webbapplikationer.
5.5.2 Uppdelning av webbapplikationer
Enkätmodulen består dels av en designdel och dels av en svarsdel. Dessa båda applikationer är fristående och kan köras på samma webbserver eller på två olika. Kommunikationen mellan dem sker via HyperText Transfer Protocol (HTTP) eller det säkrare så kallade HTTPS-protokollet.
5.5.3 Webbapplikationernas struktur
Det finns flera modeller för att strukturera webbapplikationer. När Sun utvecklade JSP definierade de två modeller6, Modell 1 och Modell 2, för
utveckling avJSP-baserade webbapplikationer.
Modell 1 är den enklare modellen som främst passar bra för mindre applikationer. Den innebär att logik- och presentationslagren inte är åt-skilda, utan att logiken finns i JSP-filer blandad med kod för
presentatio-nen i webbläsaren. Datalagringen är däremot fristående och använder sig avJavaBeans, så kallade bönor, för datatransport och viss lagring.
Modell 2 har samtliga lager åtskilda vilket gör att denna modell är mer flexibel och komplicerad, vilket i sin tur medför att den läm-par sig bättre för större projekt. Istället för att utföra logiska operatio-ner direkt på varje sida som visas, utförs detta i modellagret.
Koordina-2URL:http://jakarta.apache.org/tomcat/ 3URL:http://java.sun.com/products/servlet/ 4URL:http://java.sun.com/products/jsp/ 5URL:http://eclipse.org/webtools/index.html 6URL: http://java.sun.com/developer/onlineTraining/JSPIntro/ contents.html
