En processbeskrivning för och gränssnitt A process-description for development …1145354/... · 2017-09-28 · Keywords: HCI, evaluation method, Angular JS, Knockout JS, React,

INOM EXAMENSARBETE TEKNIK OCH EKONOMI,GRUNDNIVÅ, 15 HP

, STOCKHOLM SVERIGE 2017

En processbeskrivning för utveckling av webbaserade system och gränssnitt

A process-description for development of web-based systems and interface

En fallstudie av utvecklingsprocesser på GMP-Systems AB

A case study of development processes at GMP-Systems AB

GORAN IBRAHIM

LEONARD EK

KTHSKOLAN FÖR TEKNIK OCH HÄLSA

En processbeskrivning för utveckling av webbaserade system och gränssnitt A process-description for development of web-based systems and interface En fallstudie av utvecklingsprocesser på GMP-Systems AB A case study of development processes at GMP-Systems AB GORAN IBRAHIM LEONARD EK

Sammanfattning Affärssystem som inte har tydliga användargränssnitt tenderar att göra användarvänligheten sämre, vilket i sin tur kan leda till att delar av systemet inte nyttjas effektivt. Det kan därför vara lämpligt att ha en specifik och tydlig processbeskrivning för utveckling av system med hänsyn till användarvänlighet. I detta projekt undersöktes möjligheten att ta fram en processbeskrivning för IT-projekt vid framtagning av ett nytt gränssnitt i ett system. Mer konkret så är frågan som ska besvaras i denna rapport följande: ”Hur ska en utvecklingsmetod eller utvecklingsprocess för IT-system se ut för att tillvarata vetenskapliga, teoretiska och tekniska aspekter på Människa-Dator Interaktion (MDI)?” En fallstudie i detta projekt har utförts på företaget GMP-Systems AB.

För att komma fram till ett resultat, och för att få svar på frågeställningen, så har en litteraturstudie på aspekter inom MDI utförts. Dessutom har en analys huruvida teknisk implementation av detta kan åstadkommas med hjälp av ramverk. Vidare har intervjuer genomförts, samt tester där användaren har fått interagera med systemet. Resultatet av feedbacken har sedan analyserats. Detta för att senare kunna bygga prototyper till systemet.

I resultatdelen levereras en utvecklingsmetod och en processbeskrivning som är kopplad till den litteraturstudie och de erfarenheter som erhållits från projektets fallstudie. Till företaget GMP-Systems levereras en prototyp, en use-case model1 med user-stories2 samt ett sekvensdiagram3.

Nyckelord: MDI, Utvärderingsmetod, Angular JS, Knockout JS, React, Mockups, Processbeskrivning, Utvecklingsmetod.

1 Use-Case Model är en beskrivning på åtgärder och handlingar som en användare kan utföra, och definierar interaktionen mellan rollerna i ett system för att utföra ett mål. 2 User-stories är ett verktyg inom systemutveckling för att kunna ta fram en beskrivning av önskad funktionalitet som ofta utgår utifrån ett användarperspektiv. 3 Ett sekvensdiagram visar metodanrop mellan objekt i en tidsbegränsad situation och vilken ordning.

Abstract Business systems lacking a clear interface and subsequently a diminished usability, can lead to limited usage or no usage of parts of the system. It may therefore be critical to have a process outlined for the development of such system and its interface to ensure that all parts of the system are used. The objective of this case study was to investigate whether it is possible to develop a process description for IT projects at the initial stages of the development phase of a new interface in a system. More specifically, the question investigated in this report follows: “How should a development method or development process for IT systems look to seize scientific, theoretical and technical aspects of Human Computer Interaction (HCI)?” A case study of the project was carried out at the company GMP-Systems AB. A literature-study on aspects of Human-Computer Interaction (HCI) was carried out to arrive at a result and answer the question. Further, an analysis was conducted to consider whether the technical implementation of such process can be accomplished by adopting frameworks. In addition, interviews were conducted with users that have interacted with the system, and an analysis was carried out on the feedback provided to develop prototypes for the system. A development method and process description linked to the literature and the experience gained from the projects case study is outlined in the result section. To the client, GMP-Systems, a prototype, a use-case model4 with user-stories5 and a sequential diagram6 will be delivered. Keywords: HCI, evaluation method, Angular JS, Knockout JS, React, Moqups, process description, development method.

4 Use-Case model is a description of actions that a user can perform and defines the interaction between the roles of a system to accomplish a goal 5 User stories are a tool in system development to provide a description of the desired functionality, often from an end user perspective. 6 A sequential diagram shows how objects operate with one another and in what order.

Förord Denna rapport är resultatet av examensarbetet i Datateknik och ekonomi 15 högskolepoäng (10 veckor helfart). Kursen är en del av högskoleingenjörsutbildningen inom Teknik och ekonomi med inriktning datateknik på Kungliga Tekniska Högskolan. Vi vill rikta ett stort tack till GMP-Systems med anställda som har erbjudit oss möjligheten att utföra projektet på deras företag och som har ställt upp på intervjuer och med mentorskap. I synnerhet vill vi tacka: Niclas Söderström — utvecklare, GMP-Systems. Jan Edgren — utvecklare, GMP-Systems. Peter Sillén — universitetsadjunkt, Kungliga Tekniska högskolan.

Innehållsförteckning

1 Inledning ................................................................................................................................ 11.1 Bakgrund och problemformulering ........................................................................................... 11.2 Marknaden ................................................................................................................................... 2

1.2.1 Konkurrens ............................................................................................................................. 31.2.2 Värdet GMP erbjuder ............................................................................................................. 3

1.3 Mål ................................................................................................................................................ 41.3.1 Effektmål ................................................................................................................................ 41.3.2 Projektmål .............................................................................................................................. 51.3.3 Etik och jämställdhet .............................................................................................................. 5

1.4 Avgränsningar ............................................................................................................................. 6

2 Teori och bakgrund .............................................................................................................. 72.1 Projektteori .................................................................................................................................. 7

2.1.1 Fallstudie ................................................................................................................................ 72.2 Ramverk ....................................................................................................................................... 8

2.2.1 Angular JS .............................................................................................................................. 82.2.2 Knockout.js ............................................................................................................................ 92.2.3 React ..................................................................................................................................... 10

2.3 Människa-Dator Interaktion .................................................................................................... 102.3.1 Heuristisk utvärdering .......................................................................................................... 112.3.2 The Iterative Cycle of Human Centered Design - Hur upptäcks det riktiga problemet med systemet ......................................................................................................................................... 122.3.3 Uppgiftsanalys ...................................................................................................................... 132.3.4 Funktionell analys ................................................................................................................ 132.3.5 Root cause analysis .............................................................................................................. 142.3.6 Design for Error ................................................................................................................... 142.3.7 Användarvänlighet för personer med nedsatt syn ................................................................ 152.3.8 Färgsättning .......................................................................................................................... 162.3.9 Intervjuer .............................................................................................................................. 16

2.4 Bedömning av relevant data ..................................................................................................... 162.5 Utvecklingsprocess .................................................................................................................... 17

2.5.1 The Generic Product Development Process ......................................................................... 172.5.2 Stage-Gate Process ............................................................................................................... 172.5.3 Visualisering av processer .................................................................................................... 172.5.4 Kravanalys ............................................................................................................................ 18

3 Metod ................................................................................................................................... 193.1 Undersökningsmetod ................................................................................................................. 21

3.1.1 Värdering av undersökningsmetod ...................................................................................... 223.2 Projektmetodik .......................................................................................................................... 22

3.2.1 MosCow Matris och projekt-triangeln ................................................................................. 223.3 Teknikmetod .............................................................................................................................. 23

3.3.1 Verktyg ................................................................................................................................. 243.3.2 Ramverk analys .................................................................................................................... 24

4 Resultat ................................................................................................................................ 274.1 Utvecklingsmetod ...................................................................................................................... 274.2 Modellering ................................................................................................................................ 29

4.2.1 Use-case modell och sekvensdiagram .................................................................................. 294.2.2 Prototyp 1 och 2 ................................................................................................................... 304.2.3 Prototyp 3 ............................................................................................................................. 314.2.4 Evaluering ............................................................................................................................ 324.2.5 Undersökningsformulär ........................................................................................................ 334.2.6 MDI Modellering ................................................................................................................. 34

4.2.7 Implementation .................................................................................................................... 35

5 Analys och diskussion ......................................................................................................... 395.1 Diskussion metod ....................................................................................................................... 39

5.1.1 Projektmetodik ..................................................................................................................... 395.1.2 Teknikmetod ........................................................................................................................ 395.1.3 Metodkritik ........................................................................................................................... 40

5.2 Diskussion resultat ..................................................................................................................... 425.2.1 Utvecklingsmetod ................................................................................................................ 425.2.2 Modellering .......................................................................................................................... 43

5.3 Problemets relevans ................................................................................................................... 435.4 Ekonomi ...................................................................................................................................... 445.5 Etik och jämställdhet ................................................................................................................ 445.6 Hållbar utveckling ..................................................................................................................... 45

6 Slutsats ................................................................................................................................. 47

Källförteckning ...................................................................................................................... 49Bilagor ..................................................................................................................................... 53

Bilaga 1 ............................................................................................................................................. 53Bilaga 2 Arbetsplan och arbetsvolym per projektdeltagare ........................................................ 54Bilaga 3 User Stories ....................................................................................................................... 55Bilaga 4 MDI-Modellering .............................................................................................................. 61

sida 1

1 Inledning 1.1 Bakgrund och problemformulering Företaget GMP-Systems erbjuder en prenumerationstjänst till företag som lägger upp annonser i olika mediekanaler, t.ex. radio, tv och andra digitala medier såsom Youtube. Tjänsten innefattar att GMP sammanställer resultatet av annonser. Resultatet kan vara antal personer som har sett annonsen, huruvida annonsen nådde ut till rätt målgrupp och vilket värde företaget fick för det priset de betalade. Exempel på en annons kan vara en reklamfilm på tv eller en digitalskylt i tunnelbanan. GMP analyserar resultatet genom ovannämnda data och jämför resultatet med det mediebyråerna har utlovat vid försäljning av annonsplatser. Genom denna tjänst erbjuds kunderna en opartisk aktör, som enbart har intresse av att redovisa exakta data. Kunderna tar sedan del av detta genom en molnbaserad plattform, där de kan följa den detaljerade uppföljningen. För att ta del av denna tjänst betalar företag och andra aktörer som är med i processen en avgift. Aktörerna som använder systemet är auditörer, mediebyråer och annonsörer. Annonsörerna som brukar systemet är de företag som låter publicera en annons för en produkt eller tjänst som deras verksamhet erbjuder. Auditören hjälper till med att säkerhetsställa kampanjens träffsäkerhet och pris. Auditören är därmed den aktör som är mest beroende av systemet, samt är systemets primära användargrupp. Mediebyråerna som nyttjar tjänsten och systemet är den aktör som säljer en specifik annonsplats till en annonsör, samt sköter kommunikationen med mediekanalerna. Den utmaning GMP-Systems har är följande: Idag redovisar GMP processen för en kampanj, det vill säga viktiga milstolpar och aktörernas deadlines genom en specifik sida som företaget kallar för loggboken. Denna sida finns tillgänglig i systemet. Loggboken kan således liknas vid en backlog eller en planeringstavla innehållande essentiella uppgifter som ska genomföras för de olika aktörerna. Då det är olika parter och användargrupper med under denna process, så skiljer sig behovet och värdet åt för olika parter. Den nuvarande lösningen är därför inte optimal och visar delvis redundant data som saknar värde för vissa användare. Det är även svårt att få en överblick över vad respektive användare bör göra, vilket har bidragit till att parterna ej har använt denna del av systemet lika ofta som GMP-Systems önskar.

sida 2

1.2 Marknaden I detta delkapitel beskrivs den rådande marknaden som GMP-Systems verkar på samt interaktioner mellan de olika parterna som använder GMP:s plattform. Det beskrivs även vilka konkurrenterna är samt vilket värde GMP erbjuder sina kunder. Figuren nedan illustrerar hur de olika aktörerna interagerar med varandra.

Fig. 1.1: Beskrivning av processen för att publicera en annons och GMP-Systems roll i detta.

När en annonsör har en annons de vill publicera så kontaktar de en mediebyrå. Mediebyrån är den som sköter kontakten mellan annonsörerna och mediekanalen. Mediebyrån sätter ett pris för vad annonsplatsen kommer att kosta och ger ett löfte till annonsören om ett uppskattat resultat. Mediebyrån köper sedan annonsplatsen åt annonsören. Mediekanalerna föredrar att på detta sätt köpa annonsutrymme via byrå, då de slipper kontakt med flera annonsörer. Ofta säljs detta i ett stort paket då mediebyrån köper plats åt flera annonsörer samtidigt. Innan ”köpet” är avslutat hjälper auditören annonsören med att säkerhetsställa annonsens träffsäkerhet och pris. GMP fungerar som spindeln i nätet. GMP:s tjänst erbjuder analys av resultatet som mediebyrån utlovat, samt jämför det med det faktiska resultatet i efterhand. Med hjälp av dessa data kan annonsören förhandla sig till ett bättre pris än det mediebyrån initialt erbjudit.

sida 3

1.2.1 Konkurrens

I och med digitaliseringen av denna marknad, samt med GMP:s plattform, bryter företaget ny mark. Det finns därför begränsat med direkta konkurrenter som har liknande erbjudanden. De största konkurrenterna företaget har är redan etablerade auditörer med en stor kundbas och egna metoder, som dessutom inte nyttjar GMP:s system. Produkten GMP erbjuder har som konkurrensfördel att ersätta den manuella bearbetning som tidigare pågått i dialog mellan leverantör och kund, med en digital analys. Systemet gör istället alla beräkningar och utgår från rådata, där uppskattningar och tolkningar från användaren inte längre är aktuella. GMP bidrar även med att klassificera data och därmed standardisera detta för marknaden. Företaget använder samma klassifikationer mellan olika marknader så att samma variabler analyseras, och därmed får man korrekta beräkningar.

1.2.2 Värdet GMP erbjuder

Värdet som GMP har att erbjuda sina kunder är att vara en opartisk aktör. Det finns reklambyråer som erbjuder liknande tjänster, och det förekommer även att annonsörernas marknadsavdelningar gör egna beräkningar. Detta kan dock leda till att egna intressen tas in i beräkningarna. Det finns således en risk att dessa reklambyråer övervägande kommer att redovisa det positiva i ett utfört uppdrag. Detta kan medföra att trovärdigheten och tilliten till dessa byråer sjunker.

Det GMP erbjuder är alltså istället att vara en opartisk aktör som redovisar en uppsättning faktiska siffror. GMP tar inte hänsyn till vilka resultatet gynnar och försöker inte heller påverka detta.

sida 4

1.3 Mål I detta projekt definieras tre typer av mål: effektmål, projektmål och resultatmål. Med effektmål menas kundens mål med projektet. Projektmålen som det syftas på i detta fall innefattar projektgruppens interna målsättning. Resultatmålen är det bidrag som slutligen ska levereras till akademien och kunden.

Fig. 1.2: Figuren beskriver en förklaring till Sven Ekholms effektmål, resultatmål och projektmål.

1.3.1 Effektmål

Målet med detta arbete är att utveckla användandet av dagens loggbok. Uppdragsgivarens önskemål är att produkten, alltså loggboken, ska bli klar och få ett definierat innehåll. Detta för att förenkla för företaget, som då enbart behöver implementera resultatet i sin produktion. Inom tidsramarna för detta examensarbete är dock detta mål inte fullt realistiskt. Målet med arbetet är därför begränsat till att analysera nuläget, samt att beskriva ett förslag till en utveckling och en tydlig definition av ett nytt gränssnitt och funktionalitet för GMP-Systems produkt och tjänsteerbjudande (se kap: 1.1). Arbetet kommer att sträva efter att lösa företagets befintliga frågeställning (se kap: 1.1), samt att genomföra en överlämning som ger företaget en chans att ta vid där examensarbetet slutar.

sida 5

1.3.2 Projektmål

Många projektfel kan spåras tillbaka till oklara och inexakta mål. Man lägger ofta ner för lite arbete på att precisera varför man egentligen genomför projektet, vad det ska syfta till, och på vilket sätt man ska uppfylla kraven i kravspecifikationen. Projektmålen tydliggör alltså för projektgruppen vad egenintresset är, gruppens interna mål och resultat samt hur man prioriterar olika aspekter av genomförandet [1].

Vetenskaplighet Det vetenskapliga som kan lyftas ut ur detta arbete är ett tillvägagångssätt för och processbeskrivning av utvecklingsprojekt som kan användas av andra. Det initiala problemet grundar sig i att företaget har ett gränssnitt som har flera tillkortakommanden. Utifrån det ovan nämnda ska följande frågeställning besvaras:

• Hur ska en utvecklingsmetod eller utvecklingsprocess för IT-system se ut för att tillvarata vetenskapliga, teoretiska och tekniska aspekter på Människa-Dator Interaktion?

Med hjälp av denna frågeställning ska en utvecklingsmetod framställas som bryter ner processen för att ta fram och förbättra en del av ett system. Detta görs med hänsyn till användarnas beteenden samt till dagens teknologi. I detta arbete ges en möjlighet att göra detta för ett specifikt fall, och därmed göra en fallstudie. Det resultat som tas fram i detta projekt ska även grunda sig på vetenskapliga teorier. Undersökning N. Andersson & A. Ekholm tar bland annat upp nedanstående punkter för hur man går tillväga med en undersökning likt den som beskrivs i stycket ovan [2].

A. Se över vad som är egenintresse och vad som skulle ge generellt värde för branschen.

B. Tydlig avgränsning. C. Referensram (teori).

1.3.3 Etik och jämställdhet

Nedan listas frågor och parametrar som man bör reflektera kring inom ämnet etik och jämställdhet inom projektet.

• Kommer projektet att lyckas skapa ett användargränssnitt som tar hänsyn till likabehandling, jämställdhet och etik?

• Hänsyn till människor med olika funktionshinder och begränsningar. Alla ska kunna använda applikationen, och användargränssnittet ska vara brukbart för alla.

• Se över betydelsen för vissa färger inom vissa kulturer och religioner då systemet används i andra länder än Sverige.

sida 6

1.4 Avgränsningar Arbetet har begränsats till utförandet av en fallstudie på GMP-Systems, där en specifik del av företagets gränssnitt har analyserats. Utförda intervjuer har avgränsats till den specifika grupp användare som innehar en roll som auditör, alltså som nyttjar systemet. Till detta hör även att den litteraturstudie som har utförts är begränsad till ramverk som stödjer JavaScript, vilket är företagets befintliga utvecklingsspråk.

sida 7

2 Teori och bakgrund Detta kapitel förklarar olika ramverk och deras tekniska bakgrund, vilket gör det möjligt att analysera och utföra jämförelser. Kapitlet ger även en teoretisk bakgrund till definitionen projekt, samt ämnesområdet MDI. Dessutom ges bakgrund till benämningen av relevanta data och visualisering av processer för att besvara arbetets frågeställning.

2.1 Projektteori Människor kan ha olika uppfattningar om vad ordet projekt innebär. Därför kommer det här projektet förhållas till definitionen som Sven Eklund tar upp i boken ”Arbeta i projekt”. Utgångspunkten för denna definition är att ett projekt innebär att det finns en gemensam uppgift att utföra. Baserat på vad detta projekts uppgift handlar om, hamnar den inom kategorin utvecklingsprojekt [3]. Projektets egenskaper listas nedan. Projektet

• är av engångskaraktär • är avgränsat i tid och omfattning • har begränsade resurser • är målinriktat • är uppbyggt kring en tillfällig organisation.

2.1.1 Fallstudie

En fallstudie bör användas när man har begränsad kunskap om det man studerar och söker mer ingående djup, fakta, empirisk kunskap och analys om ett specifikt ämne [4]. En fallstudie presenterar originalforskning där specialisering sker i en viss enhet inom forskningsområdet. En stor fördel med en fallstudie är att det går att generalisera resultatet, vilket inte alltid är möjligt i andra sammanhang. En annan nytta med fallstudier är att flertalet metoder som exempelvis dokumentanalys, intervjuer, frågeformulär och observationer kan kombineras och användas parallellt. Detta medför att denna typ av forskning kan kombinera både kvalitativ och kvantitativa metoder under “datainsamlingen” för att uppnå resultatet [5].

sida 8

2.2 Ramverk Det primära syftet med användning av ramverk vid systemutveckling är att förenkla utvecklandeprocessen. Ramverk kan öka kvalitet, struktur och tillförlitlighet i ett system. Det kan även förhindra att utvecklaren spenderar tid på att utveckla systemets infrastruktur. Istället kan fokus läggas på utveckling av ny eller befintlig funktionalitet. Moderna verktyg möjliggör numera utveckling av avancerade webbaserade klienter, realtidservrar och även hybrida mobilapplikationer som är skapade med ett enda språk [6]. Användning utav ramverk innebär ofta att välbeprövad och färdig kod i form av funktioner, API:er och dokumentation för dessa, erbjuds till utvecklaren. Det kan även finnas tillfällen då de ramverk som finns tillgängliga inte möter de önskemål som utvecklaren har. Det kan då finnas en anledning till att skapa ett eget ramverk.

Fördjupningar har skett i följande ramverken: Angular JS, Knockout JS och React. Angular JS är ramverket GMP-Systems använder sig utav. Valet av Knockout och React togs för att de är relativt lika Angular.

2.2.1 Angular JS

AngularJS är ett open-source JavaScript-bibliotek som är skapat och underhålls av Google. Ramverket AngularJS bygger på mönstret Model-View-Controller, MVC. Fördelen med detta är att applikationerna som byggs ska vara skalbara. Detta möjliggör att ny funktionalitet med enkelhet kan läggas till i applikationen. Vyn kan ses som en komponent som kan bytas ut, då den inte är enskilt bunden till modellen [7]. Även underhåll förenklas genom detta.

Controllern inom AngularJS fungerar som en förbindelse mellan vyn och modellen, där controllern definieras som en JavaScript-constructor-funktion som tar emot argumentet $scope. $scope kan ses som ägare till applikationens variabler och funktioner [8]. AngularJS är även standardiserad, vilket innebär att standardiserade webbapplikationer som utnyttjar den senaste funktionaliteten som finns tillgänglig kan skapas [9]. Angular beskrivs även numera som ett ekosystem eller community där gemensamma problem och lösningar kan delas mellan utvecklare.

Directives är en del av de centrala koncepten inom Angular och är i huvudsak ett bekvämt sätt att anropa JavaScript-funktioner [10]. Mer ingående är directives ”markerare” på ett DOM-element såsom attribut, elementnamn, kommentarer eller en CSS-klass som uppger till AngularJS’s HTML-compiler att binda ett specifikt beteende till det specifika DOM-elementet.

Two-way binding är ett koncept inom AngularJS som innebär att varje datarelaterad ändring som sker på den underliggande modellen även uppdaterar vyn och vice versa.

Se figur 2.1 som förtydligar visuellt hur AngularJS använder sig ut av MVC modellen samt hur Angular interagerar med användare och server.

sida 9

Fig. 2.1: Bildbeskrivning av Angular JS arkitektur.

2.2.2 Knockout.js

Knockout är ett ramverk som bygger på ModelView-ViewModel (se fig: 2.2). Precis som AngularJS är det ett JavaScript-bibliotek som har som avsikt att hjälpa utvecklaren att skapa välfungerande och responsiva användargränssnitt-interaktioner. Ramverket uppdaterar automatiskt de korrekta delarna av användargränssnittet vid ändringar i datamodellen. Knockout ansluter med hjälp av deklarativa bindningar delar av användargränssnittet till en datamodell. En annan fördel med ramverket är att den kan läggas till ovanpå en befintlig webbapplikation utan att stora förändringar i arkitekturen krävs [11].

Fig. 2.2: Bildbeskrivning av Knockout.js arkitektur.

sida 10

2.2.3 React

React är ett JavaScript-ramverk som initialt skapades av Facebook. Syftet var att kunna möjliggöra en lösning på ett befintligt problem gällande skapandet av komplexa gränssnitt med datasets som förändras med tiden [12]. Reacts målsättning är att möjliggöra byggande av skalbara applikationer som även underhålls med enkelhet. React är implementerad med en algoritm som utför en full rendering av applikationen, varje gång något ändras. Utöver detta har React sitt eget JavaScript-språk, JSX, som tillhandahåller en förlängning av JavaScript genom att lägga till XML-liknande syntax [13].

2.3 Människa-Dator Interaktion Benämningen Människa-Dator Interaktion, MDI, innebär att samspelet mellan människan och systemet hamnar i allt större fokus, snarare än endast utformningen av gränssnittet. Detta innebär att ämnen såsom evaluering, design och implementation av interaktiva system måste beaktas. Målet med MDI är att skapa system som är funktionella, användarvänliga och säkra [14]. Enligt författarna T. Issa & P.I Saias som skrivit boken ”Sustainable Design: HCI, Usability and Environmental Concerns” så är system som har ett interface med hög kvalitet per automatik ett komplext sådant. Användarens interaktioner med systemet måste skötas på ett bra och användarvänligt sätt, det vill säga att systemet måste hantera: olika typer av input, avbrott av olika operationer, samt tillåta användaren att ångra olika val på ett lämpligt sätt. Till detta hör även att systemet ska fungera i realtid. I en studie som man kan finna i boken ”Software Engineering and Human-computer interaction”, beskrivs att efter undersökning av 74 olika utvecklingsprojekt så rapporterades det att i genomsnitt mer än 50 procent av koden för en bred uppsättning program ägnas åt användargränssnittet [15]. För att skapa ett system som uppnår de mål som tagits upp ovan är det viktigt att förstå organisatoriska, sociala, samt psykologiska faktorer som avgör hur människor fungerar och hur datateknik utnyttjas effektivt.

Psykologiska faktorer:

o Tillämpningen av teorier om kognitiva processer och analys av användarbeteende samt hur människor tänker.

Organisatoriska faktorer: o Innebär det samspel som finns mellan teknik, arbete, politik, träning och

organisation. Sociala faktorer:

o Faktorer som influerar användarens personlighet såsom attityd, tal, språk och kommunikation. Det innebär alltså att studera användarens beteende i sociala sammanhang.

Vidare bör dessa faktorer beaktas vid design av system. Så att man möter de olika krav som lämpar sig för användarens befintliga beteende. Användaren själv ska alltså inte behöva ändra sig för att kunna använda systemet [16].

sida 11

2.3.1 Heuristisk utvärdering

Heuristisk utvärdering är en metod som används för att hitta begränsningar, problem och fel ur ett användarperspektiv. För denna utvärdering krävs en grupp utvärderare som granskar gränssnittet och bedömer om det överensstämmer med erkända användbarhets principer kallad “heuristiken”.

Generellt ger det bättre resultat desto fler individer som är med för att göra en heuristisk utvärdering. Tidigare forskning visar att olika typer av utvärderare finner olika typer av problem vilket gör metoden avsevärt mycket bättre och effektivare.

Utförandet av heuristisk utvärdering görs genom att enskilda utvärderare inspekterar gränssnittet. Först när alla individuella utvärderingar har slutförts får utvärderarna träffas och kommunicera för att få sina förekomster aggregerade. Det är viktig denna process följs för att säkerhetsställa oberoende och objektiva utvärderingar från varje utvärderare. Den som utvärderar måste hänvisa till heuristiken när den finner något i gränssnittet hen inte tycker om. Det räcker inte att endast påpeka att man inte tycker om något.

Resultaten av utvärderingen kan registreras skriftligt i en rapport eller genom att utvärderarna verbalt delar med sig av sina kommentarer till en observatör medan man går igenom gränssnittet [17].

Nedan listas några punkter som räknas till heuristiken:

Synlighet av systemstatus

En webbapplikation bör alltid uppdatera användarna och hålla dem informerade om vad som händer, detta genom adekvat återkoppling. Responstid är också en viktig aspekt, återkoppling måste ske inom rimlig tid annars förlorar det sitt syfte och användare hinner eventuellt starta en annan dialog eller tro att något är “fel”.

Matchning mellan system och den verkliga världen

Systemet ska kommunicera med användaren med ord, fraser och begrepp som är bekanta, snarare än tekniska och systeminriktade termer.

Användarkontroll och frihet

När man tar fram ett system kan man inte garanteras att användare alltid kommer göra “rätt”, användare kommer vid tillfällen välja funktioner av misstag och därav måste möjligheten för att lämna ett oönskat tillstånd finnas. Denna “retur/ångra” funktion ska kunna göras utan att behöva gå igenom en utökad dialog.

Standarder

Ord och handlingar ska betyda samma sak över hela systemet, tydliga standarder ska alltså sättas.

sida 12

Felprevention

Denna heuristik handlar om att man hela tiden ska designa med målet att minimera förekomsten av vissa problem. Exempel på en metod är att visa användarna en bekräftelse innan de tillämpar åtgärden.

Erkännande snarare än återkallelse

Användarens minnesbelastning ska vara så minimal som möjlig. Detta går att uppnå genom att göra objekt, åtgärder och alternativ synliga samt att de hänger med från en del av dialogen till en annan om de behövs.

Estetisk och minimalistisk design

Information som är irrelevant skall inte visas. All information en användare tar in belastar dennas minne, detta kommer även i vägen för dialogens relevanta information.

Hjälp användare att identifiera, diagnostisera och återställa från fel

Felmeddelanden ska inte uttryckas i tekniska termer och kod, meddelandet ska uttryckas i vanligt språk och en konstruktiv lösning ska föreslås [18].

2.3.2 The Iterative Cycle of Human Centered Design - Hur upptäcks det riktiga problemet med systemet

För att hitta rätt lösning så gäller det att initialt hitta det problem som ligger till grund för att systemet inte fungerar som önskat, och även som uppfyller användarnas behov. Human-centred Design, HDC är en process som har fyra faser; Observation, Idea generation, Prototyping samt testing som genomförs iterativt för att uppnå detta. Observationsstadiet innebär att man på ett eller annat sätt träffar kunden eller

användaren och analyserar, samt förstår, vilka behov och intressen dessa personer har. En viktig del i att hitta dessa behov är att observera användarnas interaktion med systemet eller produkten för att förstå vad användaren försöker uppnå för mål. En annan fråga som bör tas i beaktning är huruvida produkten kommer att användas i andra länder än där design och utveckling sker [19].

Fig. 2.3: Beskrivning av Don Normans iterativa cykel av Human-Centered design.

sida 13

Idégeneratiosstadiet är det stadie där en möjlig lösning ska tas fram. Det är viktigt att man redan från början genererar flera olika idéer för att inte fastna tidigt i processen. En annan del i detta stadie är att inte kritisera någon annans idé, även om den initialt kan anses vara för radikal. Detta då en sådan idé senare kan komma att visa sig vara en del av den slutliga lösningen [20]. Prototypingstadiet är huvudsakligen det stadium där man försäkrar sig om att man har förstått användarens verkliga problem. Detta kan uppnås genom att göra pappersprototyper eller sketcher på programmet för varje typ av lösning från idégenerationsstadiet [21]. Testning av prototyperna bör ske av personer som motsvarar den användargrupp som slutligen kommer att använda systemet eller produkten. Det är även av vikt att dessa personer använder prototyperna på ett sådant sätt som även motsvarar normala användarflöden, det vill säga på samma sätt som om personerna hade använt systemet i verkligheten. Testarna bör under hela processen observeras, för att sedan se till att få mer detaljerad information. Det som har observerats kan sedan användas för att gå igenom testarens steg och händelseförlopp, för att sedan ifrågasätta dessa. Testerna av prototyperna ska inte göras på mer än fem personer [22].

2.3.3 Uppgiftsanalys

I ett tidigt stadie inom systemdesign bör en uppgiftsanalys/task analysis genomföras för att generera input. Användarens mål och approach till uppgiften är information som är viktig för att möjliggöra utvecklingen av ett användarvänligt system. Intervjuer med systemets användare ger även viktig insikt inom uppgiftsanalys/task analysis. Ett tillvägagångssätt är även att titta på “workarounds” där användaren tidigare har hittat en strategi för att snabbare lösa en uppgift. Dessa “workarounds” kan vara framtida förbättringar som det nya systemet stödjer. Vidare bör även befintliga svagheter med systemet där användaren inte lyckas uppnå sitt mål uppmärksammas. Dessa svagheter kan sedan ligga till grund för potentiella förbättringar i den nya produkten [23].

2.3.4 Funktionell analys

Anledningen till varför användaren utför en specifik uppgift och inte enbart hur denne utför uppgiften, är något som bör analyseras. Det gäller att hitta den underliggande funktionella anledningen till vad som ska uppnås när en användare utför en specifik handling, och på något sätt korrigera eller ändra detta [24].

sida 14

2.3.5 Root cause analysis

I ett system är det vanligt att användaren stöter på fel i systemet. Det är viktigt att betrakta dessa fel som om det vore designen av systemet som är problemet, och att det inte är användaren som har utfört en felaktig handling. För att förstå varför det går fel, är det viktigt att undersöka den felaktiga handlingen tills den underliggande orsaken har hittats. En svårighet med detta är dock att ofta är dessa fel resultatet av flera olika händelser som har utförts. När ett fel upptäcks, ska det analyseras för att man ska förstå varför felet uppstod, för att man sedan ska undersöka vad som kan göras för att förhindra det. Inom “Root cause analysis” finns en metod som kan tillämpas för att hitta orsaken till ett problem; “The Five Whys”. Metoden går ut på att söka efter orsaken till problemet. Om orsaken till ett problem hittas, så ställs frågan “varför” det uppstod, för att sedan repetera denna fråga tills det verkliga felet har upptäckts. Namnet (“The five whys”) är en riktlinje och behöver nödvändigtvis inte utföras 5 gånger [25].

2.3.6 Design for Error

Vid systemutveckling och design av olika system, är det vanligt att olika typer av fel uppstår för användaren när denne interagerar med systemet. Dessa fel kan vara små, men kan leda till stora konsekvenser beroende på vilken typ av system som det handlar om. Ett tillvägagångssätt för att lösa detta är metoden “Design for Error”, som går ut på att man i förväg, som en försiktighetsåtgärd, analyserar potentiella fel som skulle kunna uppstå i verklig miljö. Nedan följer viktiga punkter för att förhindra sådana fel:

• Hitta och förstå grundproblemet till felet, för att sedan designa systemet för att minimera att sådana orsaker uppstår.

• Göra det möjligt att ångra en handling, eller göra det svårare att utföra en handling som ej går att ångra.

• Göra det lätt för användare att upptäcka fel som uppstår, samt göra dessa enkla att korrigera.

• Behandla inte åtgärden som ett fel; försök snarare att hjälpa personen att utföra åtgärden korrekt [26].

Minimera “slips” Slips är något som uppstår när användaren vet vad och hur en handling ska utföras, men istället av misstag utför en annan. Slips kan bero på två fel; minnesfel och brist på uppmärksamhet. När användaren behöver placera information i korttidsminnet exempelvis när personen ofta repeterar en uppgift, är det lätt att det inträffar slips. För att minimera att dessa fel uppstår, handlar det ofta om att sätta restriktioner. Nedan listas några punkter för att förebygga slips:

• Placera ej kommandon nära varandra [27]. • Ta bort tillstånd där det krävs att användaren måste hålla information i sitt eget

minne, medan den går från ett steg eller stadium i en process till ett annat. • Tillåt användaren att bekräfta en operation, innan systemet går vidare till ett

destruktivt stadie [28].

sida 15

Minimera misstag Misstag inom MDI innebär att användaren har ett felaktigt mål eller plan, på någonting som inte stämmer överens med vad användaren bör göra. Det betyder alltså att oavsett om personen utför korrekta handlingar så kommer detta ändå leda till ett olämpligt och felaktigt resultat. Nedan följer ett par riktlinjer som man kan förhålla sig till för att minimera risken för att misstag uppstår:

• Gör inte misstaget att tro att användaren kommer att lära sig utvecklarens/designerns mentala modell.

• Då flera olika personer är involverade, är det viktigt att ansvarsområde tydligt statueras.

• Varningstexter är ineffektiva för att minimera misstag. Gör det föremål som påverkas mer framträdande istället.

• Tillåt operationer att vara korrigerbara [29].

2.3.7 Användarvänlighet för personer med nedsatt syn

Ett vanligt förekommande problem inom systemutveckling är svårigheten att möta användarvänlighet för personer som är blinda eller synskadade. Att enbart fokusera på funktionella krav kommer i slutändan att resultera i en högre kostnad och i mer utvecklingstid. Dåligt utformade lösningar tvingar användaren att anpassa sig, vilket i sin tur leder till undermålig användarvänlighet. Vid utformning av ett gränssnitt för en person med nedsatt syn, är det viktigt att analysera specifika fall, snarare än att behandla dessa som en homogen grupp. Alltså bör en särskild lösning föreslås, baserat på användarens nivå av synskada [30]. Nedan följer några viktiga riktlinjer som bör beaktas vid utveckling av gränssnitt för personer med nedsatt syn:

• Användning av standard-fonter såsom Helvetica och Arial. Texten bör kunna förstoras upp emot 200% utan tekniska hjälpmedel och ändå vara läsbar.

• Fontstorleken bör vara runt 12 och ej under 9. • Svart och vitt är att föredra vid visualisering av innehåll för personer med nedsatt

syn. • Navigeringslänkar bör vara i “headern” med en platt hierarki. Detta underlättar

för personer som använder skärmläsare, som snabbare kan komma till det riktiga innehållet.

• Använd lämpliga “alt” förklaringar till objekt i systemet och endast text-märkt grafik [31].

• Tillhandahåll en direkt länk till Access Keys, som visar vilka tillgängliga genvägar som finns på sidan [32].

sida 16

2.3.8 Färgsättning

Det har tidigare varit vanligt att färgsättning sker utifrån utvecklarens personliga intressen och preferenser. För att utveckla smart teknologi är det dock vitalt att färgsättningen uppmärksammas utifrån vetenskapliga stöd. En aspekt i detta är att designern bör begränsa antalet olika färger i färgsättningen så att det lämpar sig för systemets innehåll och för dess användare. Färgsättningen kan även hjälpa användaren att ta beslut och förstå innebörden av exempelvis ett specifikt element när de interagerar med systemet. Detta möjliggör att användaren kan uppfatta olikheter som kan hjälpa användaren att filtrera viktig och oviktig information, som systemet uppvisar. Vid systemutveckling och färgsättning finns det två allmänna riktlinjer som kan följas. En av dessa riktlinjer är att differentiera element och tillåta redundans på så sätt att både färg och former följs åt. En annan riktlinje är att tillåta användare att anpassa färger för att passa deras egna preferenser och deras kultur [33].

2.3.9 Intervjuer

Att intervjua användare av ett system kan vara till stor fördel då det resulterar till insyn för hur olika typer av användare faktiskt upplever systemet. För optimalt resultat ska frågorna alltid vara samma, på detta sätt blir analysen mindre komplicerad då enbart svaren varierar [34].

2.4 Bedömning av relevant data Relevant data ska ge nytta till den specifika användaren. Oftast vet användare själva vad relevant data är för dem. Det är i stort sett en representation av deras informationsbehov. För att bygga och testa effektiva applikationer med relevant data till olika användargrupper, måste vi översätta den intuitiva föreställningen om relevans i en strikt formalism. Detta visar sig vara något av en utmaning.

Det finns en relation mellan användarens begäran och ett objekt som returneras av systemet som svar på denna begäran. Systemet måste ta hänsyn till användarens uppgift och vad denne tidigare sett för objekt. För att förtydliga detta kan en samling av två identiska objekt föreställas. Om det ena objektet är relevant så, är även det andra objektet relevant. Det finns dock en risk att användaren inte blir nöjd med att även få se det andra alternativet, eftersom det är helt redundant [35].

Målet är att fånga upp relevant data utan att användaren vet om det. Detta görs baserat på tidigare användarbeteenden. Till en början är man beroende av att användaren tillhandahåller en uppsättning dokument eller data som denne anser sig behöva för sitt informationsbehov. Målet är sedan att använda de relevanta dokumenten för att bygga en bättre uppskattning av användarens relevanta modell. Relevanta feedback algoritmer har ett antal praktiska tillämpningar och kan tjäna ett gott syfte för att samla information, filtrering och anpassning för användaren [36].

sida 17

2.5 Utvecklingsprocess Vid utveckling av produkter är det vanligt förekommande att utvecklingen följer någon typ av utvecklingsprocess. Beroende på produkttyp, marknad och företagets strategi skiljer sig också utvecklingsprocessen. För att anpassa denna process ytterligare har vissa företag utvecklat en egen och/eller anammat fördelarna av en befintlig process [37]. .

2.5.1 The Generic Product Development Process

Denna utvecklingsprocess består av sex faser:

1. Planering och koncept 2. Utveckling 3. Arkitektur 4. Test 5. Detaljkonstruktion 6. Produktion

Var och en av dessa faser kan ses som en liten process, uppdelade i olika steg av aktiviteter. Till en början är processens innehåll bred. I konceptfasen finns det plats för många olika idéer och tankar. Ju längre man kommer, desto mer smalnar det av till den eventuella slutprodukten [38].

2.5.2 Stage-Gate Process

Stage-Gate process är en variant av den generiska utvecklingsprocessen. Skillnaden är att denna process har bättre definierade beslutspunkter (grindar) som fungerar som checkpoints mellan varje fas. Ett ökande antal organisationer använder denna modell för att minimera problem med produktprestanda, samt ökade utvecklingskostnader och utvecklingstid. Antalet steg i denna process skiljer sig mellan branscher och företag beroende på vilken typ av produkt man tar fram. Den huvudsakliga idéen med Stage-Gate processen är att man efter utförd uppgift utvärderar vid grindarna, i förhållande till användningen av resurser, tidsplaner och mål. Grindarna kan alltså ses som kontrollpunkter för kvalitetskontroll och för att planera nästa steg. Vid grindarna tas beslut av en “gatekeeper”. Beslutet som tas är huruvida projektet ska få en go, no go, eller om man ska avvakta [39].

2.5.3 Visualisering av processer

En visualiserad process kan användas för att ge alla i en projektgrupp eller ett team en gemensam överblick över ett projekt, samt vad som krävs av verksamheten för att uppnå de uppsatta målen. En noggrann visualiserad process visar inte enbart vilka aktiviteter som ska göras, utan den visar också vilka som är inblandade i aktiviteten samt ansvariga personer. Detta gör det enklare att veta vem man ska kontakta om man behöver mer information och vart man ska vända sig vid oklarheter [40].

sida 18

2.5.4 Kravanalys

Inom systemutveckling är framtagning av krav en viktig del. En svårighet kan däremot vara att upptäcka vad som behövs för att utveckla delar av systemet. Det kan därför vara bra att ha en process eller en fas för just detta. En riktlinje är att man ska sträva efter att samla så mycket information som möjligt. I detta fall handlar det om informationen om liknande system, och behovet som ska täckas upp i det nya systemet. Utöver de intressenter som finns, så kan det även inkomma krav från andra system som interagerar med systemet som ska specificeras. I processen för att ta fram krav, bör det genomföras intervjuer med intressenterna angående den befintliga systemlösning som används och systemet som ska utvecklas. På nästa sida beskrivs två tillvägagångssätt för att utföra dessa intervjuer:

• Öppen intervju; Innebär att frågorna för personerna som ska intervjuas redan är

föreskrivna. • Stängd intervju; innebär att intervjuaren diskuterar diverse problem relaterat till

systemet med intressenterna, utan att det finns några fördefinierade frågor. Genom detta ges en bättre förståelse av vilka behov som finns.

Kraven kan sedan konstrueras utifrån och med hänsyn till utförda intervjuer. Personer relaterar ofta enklare till verkliga scenarier. Ett tillvägagångssätt är därför att beskriva exempel på scenarier där användaren interagerar med systemet. Inom extrem programmering brukar ofta följande beskrivning innefattas av ett användarscenario:

• En beskrivning av vad användaren förväntar sig av systemet när scenariot startar.

• En beskrivning av det normala flödet av det specifika scenariot. • En beskrivning av vad som kan tänkas gå fel, samt hur det ska hanteras. • En beskrivning av vilket tillstånd systemet befinner sig i efter slutfört scenario

[41].

Inom systemutveckling är use-cases numera en grundläggande tillämpning som beskriver inblandade aktörer och interaktionen mellan dessa och systemet. Även andra system som är inblandade ska representeras av use-caset. Scenarier kan antingen ses som att vara ett enskilt use-case, eller att varje scenario är en enskild tråd i use-casen, där det normala flödet av interaktion samt alternativa flöden beskrivs. Utöver interaktionerna med aktörer och system ska även varje use-case dokumenteras med en detaljerad beskrivning [42].

sida 19

3 Metod I detta kapitel beskrivs de metoder som har använts under projektets gång för att göra det möjligt att besvara projektets frågeställning: “Hur ska en utvecklingsmetod eller utvecklingsprocess för IT-system se ut för att tillvarata vetenskapliga, teoretiska och tekniska aspekter på Människa-Dator Interaktion (MDI)?”. Undersökningsmetod, projektmetodik samt verktyg som används för att kunna uppfylla målen i sektion 1.2 demonstreras även här.

Den metod som har tillämpats för att utföra detta arbete är en kvalitativ undersökningsmetod. Ett specifikt företag vars nuvarande systemlösning undersöks, för att sedan se om teorier från arbetets litteraturstudie kan tillämpas ur ett praktiskt perspektiv:

• människa-dator interaktion • relevanta ramverk • kravanalytisk teori • bedömning av relevant data.

Det tillvägagångssättet som detta projekt har förhållit sig till, har varit att utföra en fallstudie inom ramen av det specifika företaget och dess problem. Vidare används en induktiv ansats. Detta innebär att alla aspekter som har undersökts inte var kända på förhand samt att observationer som gjordes i verkligheten generaliseras inom den teoretiska referensramen.

En litteraturstudie där tidigare studier kring områden såsom ramverk och visualisering av data/MDI samt arbetsprocesser skall utföras. Intervjuer kommer även att genomföras med företagets anställda, samt andra användare som nyttjar systemet.

När intervjuer har genomförts, och olika användargrupper har blivit kända, kommer mockups att konstrueras. Dessa redovisas för de olika grupperna och vid eventuell feedback görs de om enligt önskemål. Vidare kommer en analys att utföras om huruvida dessa prototyper är tekniskt möjliga att implementera. En funktionell prototyp kommer även att utvecklas i testmiljö. Det kommer även att utvecklas en kravspecifikation. Det som slutligen kommer att levereras till företaget är sekvensdiagram, klassdiagram, en kravspecifikation samt Mockups. När denna grund är lagd kan GMP ta vid för att vidareutveckla detta projekt. Valet av MDI metod kom dels efter att GMP-Systems hade ett problem som kunde angripas med detta tillvägagångssätt. Detta tillsammans med författarnas tidigare intresse och en djupare förståelse för detta ämne, som väckts i kursen Människa-Dator Interaktion.

Ramverk-analys utförs för att det fanns ett behov av att få en inblick i företagets befintliga ramverk, samt för att det kan finnas ett intresse för akademien att veta hur en sådan analys går till och fördelar och nackdelar med diverse ramverk.

sida 20

Undersökning och Utvecklingsmetod är två skilda metoder som kommer att användas under detta arbete. Undersökningsmetoden är den lösningsmetod som används för att besvara arbetets frågeställning. Utvecklingsmetoden är den metod som kommer arbetas fram under projektet och kommer slutligen bli det resultatet som levereras. Alltså är utvecklingsmetoden resultatet av undersökningsmetoden.

sida 21

3.1 Undersökningsmetod Inom projektet används Polyas metod för problemlösning, där följande fyra steg ligger i fokus:

I. Förstå problemet. II. Skapa en plan.

III. Utför planen. IV. Utvärdera resultatet [43].

För att lyckas inom IT-projekt är det viktigt att arbetslaget har en tydlig uppfattning om vad som ska göras, samt vilken prioritet dessa uppgifter har i förhållande till varandra. Initialt valdes det att skapa en projektdefinition för att få en tydlig bild av vad som förväntas och vad som ska göras. Utifrån ovanstående konstruerades en undersökningsmetod enligt följande: Undersökningsmetoden har tre faser som kommer att genomföras iterativt. Initialt kommer det att utföras en testfas där utvecklingsmetoden testas och huruvida den kommer att uppfylla de mål som är uppsatta. Detta följs av att synpunkter på utvecklingsmetodens om-formation samlas, för att sedan förbättra metoden ytterligare. Dessa faser repeteras tills en metod som uppfyller examensarbetet och kundens kriterier samt önskemål är framtagen. I den mån tid finnes, återupprepas detta för ytterligare förbättring. Det resultat som slutligen kan levereras är en utvecklingsmetod för att ta fram ett nytt gränssnitt till ett system. Undersökningsmetoden kommer att användas för att lösa företagets problem.

Fig. 3.1: Modellen beskriver framtagen undersökningsmetod som ska genomföras under arbetet.

sida 22

3.1.1 Värdering av undersökningsmetod

Vald undersökningsmetod följer A. Ekholm och N. Anderssons förhållningssätt kring vetenskaplighet enligt artikeln Vetenskaplighet - utvärdering av tre implementeringsprojekt inom IT bygg och fastighet. I artikeln diskuteras bland annat den generella vetenskapliga metoden om och huruvida den kan anpassas för teoretisk, experimentell och teknologisk forskning. Flera av momenten som tas upp i texten är en central del av vår angreppsmetod i detta projekt [44].

3.2 Projektmetodik Två viktiga principer har applicerats inom detta projekt: MosCow och projekt-triangeln. Projektet kommer att genomföras under en tidsram av 400 timmar som är uppdelad i olika iterationer. Det iteration innebär är att huvuduppgiften delas upp i mindre deluppgifter, som i sin tur är sina egna mindre projekt [45].

3.2.1 MosCow Matris och projekt-triangeln Alla krav är viktiga, däremot är tiden begränsad inom detta projekt. MosCow matrisen är en möjlig metod att använda sig utav vid prioritering av krav. Metoden lämpar sig bra vid mjukvaruutveckling på grund av att man tydligt kan visa intressenter vad de kan förvänta sig utav projektet. Därför ansågs det att denna metod var lämplig att använda med följande struktur som presenteras nedan. Must have requirements - Krav som är kritiska för projektet och behöver vara med i den aktuella leveransen för att projektet ska lyckas. Should have requirements - Krav som är viktiga för projektet, men som däremot inte är kritiska för den aktuella leveransens tidsram. Could have requirements - Krav som är bra att ha men däremot inte är kritiska. Won’t have requirements - Krav som ger lägst betalning tillbaka till projektet. Dessa krav planeras inte alltid med inom tidsramen av leveransen, utan tas med ifall budgeten eller tidsramen ändras.

Must Should Could Won’t

Tre prototyper Kravspecifikation Implementation utifrån prototyp

Slutförd rapport Intervju auditör Intervju annonsör

Use-case model Intervju byrå

Tabell. 3.1: MosCow matrisen med ifyllda krav.

sida 23

För att säkerställa att projektet blir lyckat, har projekt-triangelmetoden tillämpats, där tid, kostnad, funktion samt kvalitet ligger i fokus. Att förhålla sig till en balansgång mellan dessa faktorer är oundviklig och kritisk inom produktutveckling. Eftersom det ständigt kan uppstå ändringar i ett projekt är det viktigt att prioritera. Då tiden i detta projekt är fast, valdes det att specificera en flexibilitet för diverse funktionalitet som ska produceras [46].

Fig. 3.2: Figuren beskriver projekt-triangel-metoden [46].

3.3 Teknikmetod I detta projekt ska prototyper skapas med hänsyn till teorier inom MDI samt utifrån företagets gränssnitt och struktur. Utveckling av dessa ska ske genom att först och främst få en inblick i företagets ramverk och kodstruktur, för att sedan analysera den befintliga lösningen utifrån användarnas olika behov. I slutskedet kommer prototyper tas fram, testas och utvärderas.

Ramverk som kommer att användas inom detta projekt är AngularJS och Spring. En anledning till detta är att företagets befintliga lösning är uppbyggd med dessa ramverk.

Versionshantering sker via GitHub och SourceTree. Detta är även ett tillvägagångssätt som företaget har som nuvarande lösning.

Implementering sker via verktyget IntelliJ (IDE) och språken som kommer att användas är Java, JavaScript, HTML5 samt CSS3. MVC mönstret används i det befintliga systemet och kommer även tillämpas under detta projekt.

sida 24

3.3.1 Verktyg För att kunna utföra detta projekt bra, samt att ha en fungerande arbetsmiljö, har det funnits behov av tillgång till olika typer av utrustning och verktyg. Nedan beskrivs verktyg som har använts i projektet:

• IntelliJ (IDE), (Programvara, utvecklingsmiljön) • Moqups, (Online-baserat prototypverktyg) • Astah Community, (Programvara för klassdiagram) • SourceTree, (Programvara för versionshantering)

3.3.2 Ramverk analys

Det kan vara svårt att välja rätt ramverk. Det finns många ramverk och inget vetenskapligt belägg för huruvida val av ramverk bör gå till. Det finns dock några parametrar som man bör tänka på och gå igenom, innan utveckling med hjälp av ett ramverk påbörjas.

Nedanstående parametrar har tagits fram genom tidigare teori, intervju med Universitetsadjunkt på Kungliga Tekniska Högskolan, samt intervjuer med utvecklare på GMP-Systems.

Antalet användare - En bra indikation på att ett ramverk fungerar är antalet användare. Om ramverket har många användare vet man att ramverket håller någon form av kvalitet och är möjligt att arbeta med. Är det istället för få användare av ett ramverk, kan detta innebära att ramverket är för avancerat och krångligt, eller möjligtvis enbart passar en viss typ av applikation.

Dokumentation - Man behöver undersöka om tillförlitlig dokumentation om ramverket och dess funktionalitet finns tillgänglig. Ett bra ramverk har tydlig dokumentation som ska vara till nytta för användaren vid inlärning, även om användaren inte har möjlighet att komma vidare med sin utveckling.

Komplexitet - Storleken på applikationen bör även tas i beaktande vid val av ramverk. Arbetar man med ett mindre utvecklingsprojekt, är det onödigt att ha allt för komplex kod. I dessa fall blir ramverket mer till en börda än en hjälp.

Ovanstående parametrar tillhör det första urskiljandet av ramverk. Man bör samla ett par ramverk som uppfyller kriterierna ovan. Sedan börjar jämförelsen mellan dessa. Parametrar för den andra urskiljandefasen beskrivs på nästa sida.

sida 25

Avklarade fall - Om ett ramverk har många användare blir det också intressant att se hur många av fallen som blev lösta. Man kan få en uppskattning av detta genom utvecklarforum, t.ex. Stackoverflow. I dessa forum lägger användare upp olika fall och delar med sig av sina kunskaper samt hjälper varandra. Man kan enkelt se avklarade fall för specifika ramverk genom dessa forum. Detta ger en grov uppskattning om huruvida ramverket är praktiskt och tekniskt möjlig för hela applikationer.

Releaser - Senast utförd uppdatering av ramverket, samt antalet resurser som utför arbete på det, är viktiga aspekter att tas i beaktande innan man börjar utveckla. Gör man det i tid minskar man risken för att råka på ett föråldrat ramverk som inte fungerar med nya versioner av webbläsare osv.

Support - Stöter man på problem är det viktigt att ramverken tillhandahåller någon form av support. Därför är det väsentligt att undersöka om det tillhandahålls adekvat support för det specifika ramverket.

Testkod - För att se hur ramverken beter sig kan man skriva testkod. Denna kod bör göra exakt samma sak i respektive ramverk. Genom detta kan man jämföra exekveringstid och se om något av ramverken beter sig på ett oönskat sätt.

sida 26

sida 27

4 Resultat I detta kapitel presenteras det resultat som erhållits i detta projekt efter genomförd litteraturstudie samt fallstudie.

4.1 Utvecklingsmetod I metodkapitlet presenteras undersökningsmetoden som skulle utföras i detta projekt. På nästa sida visas den resulterande utvecklingsmetoden som tagits fram med hjälp av examensarbetets frågeställning och tillhörande undersökningsmetod.

Den föreslagna utvecklingsmetoden har sedan prövats i ett konkret fall hos företaget GMP-Systems där en del av applikationen har fått ett nytt gränssnitt med hjälp av metoden.

I arbetet användes en kombination av tekniken öppen intervju och stängd intervju för att få fram potentiella användarproblem. Dessa typer av intervjuer genomfördes vid flera tillfällen och gav en tillförlitlig grund på vad som förväntas av systemet samt vilka nuvarande problem som fanns. För att inte begränsa modellen till enbart intervjuer valdes det även att lägga till ytterligare en parameter genom att utföra workshops. User stories bör tidigt skapas så att intressenter kan få reda på vad som förväntas av systemet samt även för att möjliggöra konstruktion av prototyper och huruvida en teknisk implementation är möjlig. Detta testades i arbetet och utfördes i samband med att problemformuleringen var definierad, vilket slutligen gav ett lyckat resultat (se undersökningsformulär, kap: 4.2.5). Om ett projekt saknar en tydlig problemformulering är det svårt att veta vad det verkliga problemet är och projektet kommer därmed troligtvis inte leverera en önskvärd lösning. Eftersom problemformuleringen bygger på användarnas nuvarande problem blir intervjuerna vitala. I arbetet utfördes som tidigare nämnts intervjuer såväl som en workshop. Dessa tillvägagångssätt gav projektet en grund på huruvida relevant teoretisk undersökning, prototyper (se kap: 4) samt hur teknisk implementation (se kap: 4.2) torde genomföras. Modellering av den slutliga prototypen var ett resultat av att flera prototyper framställdes och testades. Valet av att tre prototyper skapades beror dels på projektets omfattning och resurser såväl som målet var att tidigt få produkten testad (detta tillvägagångssätt diskuteras i kap: 5.4). Slutligen bör även prototyperna testas med hjälp av en modelleringsteknik såsom heuristisk evaluering (se kap: 4.2 samt 5.4) för att kunna slutföra en teknisk implementation som levererar ett adekvat resultat.

De två första utvecklingsmetoderna innehöll iterationer (se bilaga 1), dessa bidrog mestadels till planeringen men avspeglade inte arbetets verklighet. Iterationerna användes främst för att visualisera vad som skulle göras innan nästa iteration påbörjades. Då en arbetsplan (se bilaga 2) redan hade utformats var iterationerna inte nödvändiga. När den tredje utvecklingsmetoden togs fram hade författarna mer empirisk kännedom om hur arbetet bör angripas samt mer teoretisk bakgrund. Därför implementerades Stage-Gate processen (se kap: 2.5.2) i den slutgiltiga utvecklingsmetoden. Iterationerna plockades bort och ersattes av tre ”Gates”. Detta effektiviserade arbetet då det bidrog till en tydlig plats för reflektion och utvärdering.

sida 28

Fig 4.1: Resultat av framtagen utvecklingsmetod

Metodbeskrivning av lösning till uppdragsgivare

Förstudie: I förstudien ska problemet formuleras ur kundens och akademiens perspektiv. En omvärldsanalys kring relevanta ämnen, där forskning och dokumentation ska visa på ̊vad som tidigare gjorts i liknande fall och inom liknande ämnesområde skall utföras. Fastställd frågeställning, litteraturstudie samt förväntat resultat skall även tas fram i detta stadie.

Förstå kundens problem: I detta stadie undersöks kundens/uppdragsgivarens befintliga problem. Genom att se över systemlösningen och de hinder som finns.

Ta fram en processbeskrivning för uppdragsgivaren: I detta skede tas en beskrivning fram om huruvida uppdragsgivarens problem ska lösas. Genomförandet ska bestå utav intervjuer, modellering av förslag på hur processen kommer att se ut, följt utav kontroll med uppdragsgivaren. Detta genomförs iterativt och denna process kommer att modifieras och kommer att omarbetas tills en metod som uppfyller de krav som ställs från kunden och akademien.

Gate: En “Gate” är en beslutspunkt som fungerar som en “checkpoint” mellan större delmoment. Här skapar man utrymme för reflektion kring det man har åstadkommit och beslutar ifall man är redo för go, no go eller om man behöver förbättra något.

-------------------------- Gate 1 ----------------------------------

Problemformulering: En problemformulering bör tas fram, där den initiala orsaken till felet med systemet framtas. Att utföra en “root cause analysis” är ett möjligt tillvägagångssätt för att uppnå detta.

Teknisk möjlig: I det detta skede av utvecklingsprocessen behandlas frågan om problemet har en teknisk lösning som är möjlig att implementera. Hur detta ska gå till, samt vilka ramverk som tillhandahåller en enkel lösning till detta bör även analyseras.

-------------------------- Gate 2 ----------------------------------

MDI modellering: I modellerings-stadiet ska faktiska prototyper tas fram med hänsyn till litteraturstudien och den teori som lästs in. Användarobservationer bör initialt göras, följt av en fas för idé-generering. Minst tre olika prototyper bör sedan konstrueras utifrån detta. Detta kan sedan analyseras med användartester och feedback där en slutgiltig modell framtas.

-------------------------- Gate 3 ----------------------------------

Implementation: I det slutliga metod-steget implementeras sedan konstruerad prototyp i systemet.

sida 29

4.2 Modellering Användarintervjuer har genomförts individuellt samt i form av en gemensam workshop där det befintliga problemet samt systemets uppbyggnad (se kap: 1.1) diskuterades i detalj. Vid dessa möten redogjordes och konkretiserades problematiken med det befintliga systemet. Senare gav detta upphov till konstruktion av use-case model, sekvensdiagram (se fig: 4.1) samt innehåll till modellering av prototyper. Efter att användarens grundproblem och behov formulerats påbörjades konstruktion av prototyper. När prototyperna var färdigställda initierades en evalueringsprocess där användaren fick utvärdera och testa framtagna prototyper.

4.2.1 Use-case modell och sekvensdiagram

Use-case modell (se fig: 4.2, vänster figur) visar loggbokens olika roller samt vilka möjliga handlingar som användare kan utföra. Vilka handlingar en specifik roll kan utföra representeras av pilarna kopplade till respektive handling. Exempelvis kan en auditör skapa ett event som inkluderar en titel, roll, och märke. En användare med rollen agent eller annonsör kan ej skapa ett sådant event, däremot kan de båda se dessa event i loggboken.

Sekvensdiagram (se fig: 4.2, höger figur) visar hur objekten i loggboken förhåller till varandra samt i vilken tidsordning integration med systemet görs. En annonsör eller agent kan exempelvis markera en task till slutförd först när ett event är skapat.

Fig 4.2: Resultat av framtagen Use-case modell och sekvensdiagram

sida 30

4.2.2 Prototyp 1 och 2

För att möjliggöra konstruktion av prototyper togs det fram user stories (se bilaga 3). Dessa userstories bygger på de användarfall som målats upp från intervju och workshop. Följande punkter var de som användarna ansåg vara de mest viktiga vid utformningen av loggboken.

1. En användare ska kunna skapa event. 2. En användare ska kunna skapa tillhörande uppgifter. 3. En användare ska kunna tilldela dessa uppgifter till systemets olika

användargrupper.

Med hjälp av ovannämnda sekvensdiagram, use case model samt user stories, kunde den första prototypen färdigställas (se prototyp 1, fig: 4.2). Däremot ansåg användarna att prototyp 1 medgav en viss problematik då överblicken samt uppföljning blev sämre när flera event skapades. Detta resulterade i att en ny prototyp med kalender-vy skapades för loggboken (se prototyp 2, fig: 4.2).

Fig. 4.3: Resultatet av Loggbok prototyp 1 och 2 från vänster till höger

sida 31

4.2.3 Prototyp 3

Efter genomförd evalueringsprocess kunde nedanstående prototyp tas fram. Denna baseras på både på feedback från användarnas interaktion med systemet såväl som den data som insamlats från intervjuer samt från den litteraturstudie som genomförts inom MDI. Det som skiljer prototyp 3 (se fig: 4.3) från föregående prototyp (se fig: 4.2) är en tillagd sorteringslista kopplat till land och märke dit respektive event tillhör. Anledningen till denna konstruktion är att det ska vara lätt att hitta till ett specifikt event och inte förväxla event med varandra. Användarna ansåg även att en kalender-vy som visar en hel månad gav en bättre överblick och var lättare att följa än den föregående prototypen som presenterar loggboken veckovis. En funktionalitet som lades till var att när en uppgift sattes som slutförd stod datum och namn på användaren som slutfört uppgiften, vilket var ett önskemål som hade poängterats av flera användare under utförd heuristisk evaluering (se kap: 4.2.4).

Fig. 4.4: Slutgiltig loggboks prototyp

sida 32

4.2.4 Evaluering

Vikten av att involvera användaren i hela utvecklingscykeln har tidigare poängterats i arbetets litteraturstudie. Detta tillvägagångssätt applicerades således i detta projekt. Totalt intervjuades sex användare med olika bakgrund, där alla på något sätt nyttjade GMP-Systems tjänst i arbetet. Inför intervjuerna tilldelades användarna ett evalueringsformulär (se fig: 4.4) att besvara. Detta skulle besvaras såväl innan modelleringen påbörjades, samt efter den var genomförd. Genom att tillämpa tekniken “Heuristisk utvärdering” kunde direkt feedback på hur systemet torde fungera för verkliga användare ges. Denna evaluering gav även information om huruvida det fanns rum för ytterligare förbättringsmöjligheter för prototyp under test. På nästa sida presenteras ett par punkter av det resultat som kunde tas fram efter utförd evaluering:

• Lättare att särskilja element - Samtliga användare ansåg att det tydligt framgick vilka uppgifter som tillhörde specifika events eftersom färgerna var sammankopplade per event.

• Tillåt inte användarna att hålla saker i minnet - Användarna tyckte det var enklare att skapa ett event på grund av den avskalade “skapa event” modulen.

• Estetisk och minimalistisk design - Användarna ansåg även att de fick en bra översikt över relevanta event och sådant som inte längre var aktuellt.

• Felförebyggande - Det fanns tidigare utrymme att skapa ett felaktigt event i föregående loggbok och eftersom det inte heller gick att ta bort ett event kunde detta medföra viss frustration. Den nya modellen innehöll vissa restriktioner som såg till att användaren mer sällan försattes i detta läge. Exempelvis var “skapa event” knappen ej klickbar innan alla obligatoriska fält var ifyllda. Detta var även något som 60% av användarna instämde i.

Denna evalueringsprocess utgick från J. Nielsens samt D. Norman’s “tio heuristiker” som även togs upp under arbetets litteraturstudie. Nedan visas ett urval på hur dessa heuristiker har tillämpats och ställts till olika användare.

Fig. 4.5: Urklipp på evalueringsformulär från genomförd heuristisk evaluering.

sida 33

4.2.5 Undersökningsformulär

Nedan presenteras det undersökningsformulär som gavs ut till användarna före respektive, efter modelleringen slutförts. Antal användare som deltog i undersökningen var nio stycken. Värt att nämna är att den framtagna prototypen resulterade i att samtliga användare upplevde en förbättrad användarupplevelse på frågorna ett, två, tre och fem. Mer specifikt ansåg 67% av användarna att uppföljning av ett event tidigare varit en svårighet. Detta baseras på användare som valt en siffra lägre än 5 (se fig: 4.6). Undersökningsformuläret (se fig: 4.5) baseras på användarnas grundproblem (se kap: 1.1) och framställdes i samband med den workshop som genomförts med användarna. Följande fem frågor belyser det problem som användarna främst upplevde med nuvarande loggbok: skapa event, skapa en uppgift, växla mellan byråer, markera en uppgift till att vara slutförd såväl som uppföljning av event. Data från det frågeformulär som gavs ut efter att den slutgiltiga prototypen var färdigställt analyserades. Det som kunde utläsas från denna analys var att användarna sammantaget upplevde en förbättring gällande uppföljning av event. Den nya lösningen ledde till att endast 33% fortfarande upplevde problematik med uppföljning av event till skillnad från tidigare 67% (se fråga 5, fig: 4.5).

Fig. 4.6: Urklipp på från undersökningsformuläret som gavs ut till användare

sida 34

I arbetet ställdes frågan om det var möjligt att ta fram en modell för systemutveckling som tar hänsyn till personer med nedsatt syn. För att åstadkomma detta utfördes ytterligare en utvärderingsprocess i slutet av projektet. De tillfrågade var personer som hade någon typ av synfel. I intervjuerna deltog fem personer och de genomfördes vid olika tillfällen. Tillvägagångssättet kan liknas vid en blandning av både en öppen och stängd intervju (se kap: 2.5.4) där personen både ställdes fördefinierade frågor samt att användarens befintliga problem diskuterades. Det som ansågs vara av vikt för användaren redogörs i modellen nedan (se fig: 4.6).

4.2.6 MDI Modellering

Nedan presenteras resultatet av framtagen MDI modellering. Modellen baseras på arbetets litteraturstudie inom MDI (se kap: 2.3), intervjuer samt utförd heuristisk evaluering med användarnas synpunkter samt den data som analyserats från frågeformulären (se kap: 4.2.5).

Fig. 4.7: Framtagen MDI-modell

sida 35

4.2.7 Implementation

Nedan visas kodstycken som baserats på den slutgiltiga prototypen. Programmeringsspråken som använts är HTML, JavaScript och Java, ramverken som har använts är Spring och Angular JS, dessa två ramverk används också av GMP.

Fig. 4.8 & 4.9: Utdrag ur html-klassen

Ng-click är ett Angular JS direktiv som ordnar så att applikationen får ett anpassat beteende när ett specifikt element klickas på. Ovanstående kodstycke visar hur direktivet används för att filtrerare events till/på olika användarroller.

Ng-repeat är ett annat Angular JS direktiv som upprepar en uppsättning HTML ett specifikt antal gånger, direktivet fungerar med andra ord som en loop. När ovanstående kodstycke används kommer html-satsen upprepas en gång per varje event som finns i objektet uiConfig.

sida 36

Fig 4.10: Utdrag ur JavaScript controllern.

För att hämta loggböcker som tillhör den inloggade användaren anropas metoden getLogBookByUserId som finns i JavaScript servicelagret. När loggböckerna returneras läggs dessa på $scope.logBooks så att de kan hämtas och visas i html-skalet.

För att lägga till nya event i en loggbok använts addEvent som ligger på $scope.addEvent. När en användare trycker på en knapp kan Angular direktivet ng-click användas för att anropa $scope.addEvent. Denna funktion kommer i sin tur pusha in det nya eventet till eventlistan.

sida 37

Fig. 4.11: JavaScript servicelager

Servicelagret används som en tunnel mellan JavaScript och Java. Restangular är en Angular JS-tjänst som förenklar bland annat GET och POST förfrågningar. Denna tjänst använder GMP och var även lämplig i loggbokens implantation då det ser till att förfrågningar kan göras med minsta möjliga klientkod.

sida 38

Fig 4.12: Utdrag från Java Controllern.

Ovanstående kodstycke innehåller två metoder. Metoden findById tar emot ett användar-id och returnerar loggböckerna som är kopplade till detta id. Metoden addEvent tar emot en specifik loggbok och lägger sedan till ett event i den loggboken för att sedan returnera hela uppdaterade loggboken. Klasserna LogBookService och AuthenticationService som anropas är GMP-Systems egna klasser och är därav inte med i resultatet.

sida 39

5 Analys och diskussion I detta kapitel analyseras, diskuteras och utvärderas examensarbetets resultat i relation till målsättningen och den modell samt de lösningsmetoder som har använts.

5.1 Diskussion metod

5.1.1 Projektmetodik

I det här arbetet har det utförts en studie på huruvida en generell utvecklingsmetod och MDI-modell kan tas fram för ett IT-projekt. Tidigt i detta projekt togs det fram en ansats på en process som sedan utvärderades och förbättrades. Det slutgiltiga resultatet grundar sig på den litteraturstudie som har genomförts och utifrån arbetets fallstudie. För att ett utvecklingsprojekt ska lyckas krävs det först och främst planering, tidsestimering, samt prioritering, vilket även behandlas i kapitlet projektmetodik (se kap: 3.2). Tillämpningen av MosCow matrisen samt projekttriangeln fungerade väl i detta avseende. Däremot erhölls redan en direkt överblick på vilka krav som var väsentliga på grund av projektets omfattning. Behovet torde korrelera väl mellan ett projekts storlek och användandet av MosCow matrisen. Efter slutförd studie kan det dock konstateras att oavsett storlek så är MosCow matrisen även lämplig för projekt av mindre karaktär. Detta då den ger intressenter en uppfattning om vad de kan förvänta sig utav ett projekt i ett tidigt skede.

5.1.2 Teknikmetod

Under arbetet valde vi samma verktyg som GMP-Systems använder för versionshantering samt utveckling (se kap: 3.3). För att ytterligare underlätta överlämningen samt att koppla den del av applikationen som vi utvecklade med resterande applikation använde vi också de befintliga ramverken. Detta visade sig vara effektivt då vi kunde använda oss av förekommande kod samt ha genomgångar och diskussion med utvecklarna på GMP. Dock var detta inte alltigenom optimalt då GMP använder sig ut av den första versionen av Angular JS (se kap: 2.2). I kapitel 3.3.2 Ramverks analys tar vi upp olika parametrar som ska underlätta valet av ramverk, en av dessa är Releaser. Då arbetet har anpassats för att uppnå akademins mål och GMP-Systems krav följde vi inte denna parameter i valet av ramverk. Detta hade förmodligen gjorts annorlunda om stora delar av applikationen inte redan var uppbyggd med den äldre versionen av Angular.

sida 40

5.1.3 Metodkritik

I denna del presenteras kritik mot metoderna som har använts under detta arbete.

Generellt Eftersom detta är ett akademiskt projekt har hänsyn till kursmålen tagits under projektets gång. En stor del av arbetet har även gått ut på att leverera något till akademien. Om projektet utförts utanför akademien, hade vissa problem tacklats annorlunda med enbart det aktuella företagets intressen i fokus. Vald metod innehåller vissa brister och kan vara svår att applicera inom en del projekt. Det kan finnas svårigheter med att hitta användare som är villiga att spendera tid på att genomföra intervjuer och tester på framtaget resultat. Metoden är uppbyggd på ett sätt som sätter tiden i centrum. Det finns ingen begränsning på när arbetet ska vara färdigt eller hur lång en iteration är. Detta kan innebära en svårighet då disponeringen av tid för respektive uppgift kan bli obalanserad. Därför bör varje iteration vara satt till en bestämd längd på exempelvis 1 vecka. Varje uppgift bör även ha en definierad tidsram. Metoden levererar ett resultat på en utvecklingsstrategi (se kap: 4. Resultat) där de olika stadierna som tagits fram utgår från ett perspektiv på ett optimalt utvecklingsscenario. Om ett projekt har resurser för detta beror ofta på budget och projektets omfattning. Detta är aspekter som ej togs med i utformandet av metod eller resultat.

Synpunkter på framtagen utvecklingsmetod Den utvecklingsmetod som slutligen levererades bygger på vald undersökningsmetod samt litteraturstudie. Det som kan kritiseras i den framtagna utvecklingsmetoden är att det inte tas någon hänsyn till organisationers befintliga utvecklingsprocess. Detta kan innebära att det kan finnas vissa svårigheter med att applicera framtaget resultatet för andra projekt, beroende på vilka befintliga utvecklingsmetoder som används.

Intervjuer och användartester Från de intervjuerna som utfördes på respektive användare och gav upphov till det slutliga resultatet i produktväg, (se kap: 6 bilagor) finns det en del brister. Detta då det endast tillhandahölls tillgång till en roll av systemanvändare: Auditör, att genomföra användartester samt intervjuer på. Eftersom rollerna kan ha olika krav och önskemål har det med stor sannolikhet påverkat vår bedömning av vad som kan vara relevant och användbart för alla roller. Det kan därmed även ha påverkat det som slutligen levererades till uppdragsgivaren. En förutsättning för att utföra en heuristisk utvärdering är att personen som utför evalueringen innehar en hög förståelse av de specifika heuristikerna. Detta lägger stor vikt på att de systemanvändare som utförde evalueringen förstår innebörden av de frågor som besvarades och bör därmed även tas i beaktande. Kritik bör även riktas mot omfattningen av undersökningen som gjordes av personer med nedsatt syn då det inte tas någon hänsyn till huruvida olika typer av synfel kan ha påverkat resultatets generaliserbarhet. Möjligtvis hade ett mer optimalt tillvägagångssätt för att utföra denna undersökning varit att jämföra det antal

sida 41

musklick som krävdes för att en uppgift ska utföras. Fördelen med ett sådant test är att det kan förse projekt med data på sådant som personer inte kan beskriva verbalt. Fallstudie Nackdelen med en fallstudie är att det kan vara svårt att få tillgång till lämpliga källor av information och empiriska data, då metoder som intervju och test mestadels består av människors personliga åsikter och uppfattningar.

Litteraturstudie De källor som har använts kommer till stor del från andra akademiska arbeten där vissa studier som utförts varit av mindre slag. Även en del böcker som har lästs har varit äldre (se källförteckning: 15, 35, 41 och 45), vilket innebär att det kan finnas modernare studier utförda som har varit av mer relevans som kan ha missats. Detta främst då det ständigt skapas nya tillämpningar inom området användbarhet för IT.

sida 42

5.2 Diskussion resultat

5.2.1 Utvecklingsmetod

Det resultat som levereras är först och främst en lösning på problemet för huruvida en del av ett system kan utvecklas. Vi anser att det även kan tillämpas när man bygger ett system från grunden.

Resultatet har tagits fram genom en fallstudie som gjorts på ett relativt litet företag. Resultatet skulle även kunna implementeras på medelstora företag. Vid större företag med många olika avdelningar kan det däremot vara en större utmaning. På företag där de flesta uppgifterna är uppdelade mellan olika avdelningar och i vissa fall olika kontor, krävs det antagligen fler Gate’s och fler iterations uppföljningar. I större företag blir visualiseringen av processer som tagits upp ännu viktigare då bristande kommunikation mellan olika instanser kan förekomma. Arbetet har bidragit till en viktig insikt, vilken är vikten av att tidigt utföra intervjuer i ett utvecklingsprojekt. Detta för att förstå det ursprungliga problemet. Denna information kan sedan ligga till grund för att angripa problemet och kunna arbeta fram en slutlig lösning. Efter genomförda intervjuer observerades skillnader mellan intressenternas önskemål, i detta fall användarna, och beställarna av systemet. Detta är inte något som är unikt för detta specifika fall och det kan därför vara viktigt att man hittar en balansgång mellan dessa. Resultaten från användar-intervjuerna visade på en del problem gällande användbarheten av den första prototypen, där vi initialt trodde att vi funnit en lösning på problemet. Detta var dock inte fallet och det resulterade istället i andra problem för en viss aktör.

Det som kan konstateras efter det resultat som slutligen kunde tas fram, är vikten av att involvera användaren så mycket som möjligt genom hela utvecklingscykeln. Att ta tillvara på användarens vanor, kunskaper och dess sätt att arbeta, förenklar utvecklande-processen för att åstadkomma ett användarvänligt system och gränssnitt.

Arbetet visar att det finns fördelar med att ha ett användarvänligt system. Fallstudiens ursprungliga problem härstammar från att de haft ett för komplext användargränssnitt för en specifik del av system, vilket har lett till låg användning. Författaren Steve Krug nämner följande i boken “Don’t Make Me Think”:

“When I look at a web-page, it should be self-evident. Obvious. Self-explanatory. I Should be able to “get it” - What it is and what it is and how to use it - without expending any effort thinking about it” [47].

Efter den evalueringsprocess och litteraturstudie som genomförts i detta arbete är ovanstående citat något som även vi anser vara vitalt för både webbsidor såväl som affärssystem.

sida 43

5.2.2 Modellering Enligt det MDI-modelleringsresultat som togs fram, bör flera av dessa aspekter tillämpas i ett utvecklingsprojekt. Däremot kan det innebära en svårighet att ta hänsyn till alla aspekter som exempelvis etik och jämställdhet vid en implementation. Det bör därför alltid utföras en analys för vilka som kommer att använda systemet. Det bör även analyseras till vilken grad tidigare nämnda MDI aspekter ska och kan tillämpas.

Utifrån det resultat som togs fram i MDI-modellen, så uppstod det svårigheter att tillämpa alla aspekter i våra prototyper, vilket till viss del kan bero på projektets tidsbegränsningar.

Implementation I kapitlet metod och resultat nämns det att man i ett projekt bör analysera vilka tekniska möjligheter som finns, innan en eventuell implementation genomförs. Det finns flera olika sätt att angripa detta. Eftersom det fanns begränsat med tid, samt ett redan fördefinierat ramverk, bestämdes det att enbart titta på vilka färdiga lösningar och metoder som tillhandahölls från Angular. Detta är dock inte optimalt, då andra ramverk möjligtvis skulle kunna tillhandahålla en bättre lösning. Vi kom däremot fram till att AngularUI-fullcalendar skulle underlätta utvecklingen av våra prototyper, vilket det påbörjades en implementation av [48].

5.3 Problemets relevans Antagandet om att vårt resultat och vår problemformulering är av hög relevans för andra ingenjörer grundar sig på följande:

• Problematiken torde inte vara sällsynt då aktuellt företag som fallstudien grundar sig på, hade ett stort behov av ett förbättrat gränssnitt.

• Ur ett etiskt perspektiv, så är det viktigt att system är användarvänligt och tillämpbart oavsett funktionsnedsättning. Vår MDI-modellering är därför relevant för att den syftar till att minimera svårigheter som ett funktionshinder som nedsatt syn medför. Ett system som personer inte nyttjar eller har svårigheter att använda, kan innebära produktionsbortfall för ett företag.

• Icke användarvänliga gränssnitt vars komplexitet och otydlighet försvårar interaktionen med systemet, är ett generellt och befintligt problem för företag och är därav även av relevans.

sida 44

5.4 Ekonomi I detta arbete har vi tagit hänsyn till den ekonomiska aspekten, dvs förbrukning av resurser och skapandet av värden. Planering och implementation har en påverkan på ekonomin. Med en arbetsplan (se bilaga 2) fick vi en tydlig översikt över hur många timmar som projektet kräver. Gör man en grovplanering i början av ett projekt kan man tidigt förebåda om projektets slutresultat kommer att skapa värde gentemot kostnaderna för att utföra det. Då vi har haft en bestämd tidsram inom examensarbetet var det enkelt att skapa en arbetsplan. I andra projekt kan det vara svårare att göra en uppskattning då olika faktorer påverkar innan och under projektet samt att prioriteringar kan förändras. Den nya loggboken som togs fram under projektet kan vara till stort ekonomiskt värde då den förtydligar vem och vilka parter som ska utföra olika arbetsuppgifter i ett projekt. Detta sparar anställda tid och förhindrar eventuella missar i kommunikationen. Loggboken loggar även användarnas handlingar, t.ex. när någon har gjort klart en uppgift och loggar det så har vi valt att skriva ut datum och vilken användare som utfört handlingen (se bilaga 3). Detta bidrar till bättre tidseffektivitet när man behöver backa tillbaka och se över handlingar som redan utförts. Om detta behöver göras ofta så sparar man tid och kostnader på att handlingarna redan finns loggade och är lätta att hitta. GMP-Systems är ett ungt företag och loggboken är en relativ oprövad del av deras system. Med detta i åtanke var det optimalt att begränsa funktionaliteten i loggboken så att tidiga användare kan nyttja tjänsten samt ge feedback för framtida utveckling. Lin Chou Cheng nämner följande i sin artikel ”The Mobile App Usability Inspection (MAUi) Framework as a Guide for Minimal Viable Product (MVP) Testing in Lean Development Cycle”: “In contrast to the past software development practices, where extensive user testing happened only after the completion of a potentially shippable product, in the lean development cycle the user acceptance test will be deployed once a proto minimal viable product (MVP) is made available” [49].

5.5 Etik och jämställdhet I detta arbete har hänsyn tagits till människors olika förutsättningar och behov. Strategin var att ta fram en utvecklingsmetod samt en potentiell användbar MDI-modellering som även lämpar sig för personer med funktionsnedsättning. Avgränsningar som gjorts inom denna undersökning var att utforma modelleringen med hänsyn till personer med nedsatt syn.

sida 45

5.6 Hållbar utveckling Arbetet var en fallstudie på ett företag vilket avspeglar sig i resultatet då det anpassats till andra akademiker, ingenjörer och företag med liknande problem (se kap: 1.1). Trots att detta gör det svårare har vi under arbetets gång tänkt på möjligheterna och begränsningarna detta arbete kan ha ur en social synvinkel. Genom en visualiserad processbeskrivning av projekt som utvecklingsmetoden är (se kap: 4.1) kan en bättre arbetsmiljö uppstå. Detta genom att medarbetare får en tydlig bild på vad som ska göras och hur långt man har kommit i projektet. Den viktigaste delen av utvecklingsmetoden som kan kopplas till hållbar utveckling är Gaterna (se kap: 4.1). Gaterna skapar tid och utrymme för reflektion där saker som behöver förbättras eller göras annorlunda tas upp vilket i längden kan skapa en mer hållbar arbetsplats och arbetsmiljö. Genom digitalisering av branscher och produkter kan pappersproduktion minska vilket bidrar positivt till miljön. Loggboken är ett bra exempel på detta, istället för att ha fysiska kalendrar, listor eller ”post it” lappar med deadlines samlas allt i applikationen. Detta ökar dock mängden data som i sin tur kan ha en negativ påverkan på miljön. Eftersom mer data måste hanteras och lagras behövs större databaser vilken i sin tur ökar energikonsumtion.

sida 46

sida 47

6 Slutsats

Avslutningsvis är vi stolta över att vi har lyckats lösa problemen från vår problemformulering (se kap: 1.1) och därmed så har vi även lyckats ta fram ett resultat (se kap: 4) som andra ingenjörer kan använda sig av. De prototyper som slutligen kunde levereras till företaget grundar sig på den litteraturstudie och det resultat som har tagits fram. Vi kan även med tidigare nämnda motiveringar till vald modell påstå att vi lyckats ta fram en applicerbar MDI-modellering, som även är anpassad för personer med nedsatt syn. Aspekter som personer utan funktionshinder vanligtvis inte tänker på eller möjligtvis inte förstår. Med detta i åtanke är vi väldigt nöjda att vi nått målen vi satte upp i början av arbetet samt att vi lyckats leverera värde till akademin, andra ingenjörer och GMP-Systems. Rekommendationen är att GMP-Systems samlar in mer feedback när fler användare börjar nyttja loggboken. Detta för att kunna vidareutveckla gränssnittet med hänsyn till olika användarbeteende samt lägga till mer önskvärd funktionalitet. Nya problemställningar som identifierats är val av ramverk vid utveckling av ett delsystem när resterande system redan är beroende av ett ramverk. Är det alltid lämpligt att fortsätta med det befintliga ramverket eller ska man se det som en möjlighet att förnya och bryta loss?

sida 48

sida 49

Källförteckning [1] S. Eklund, ”Arbeta i Projekt - individen, gruppen, ledaren”, upplaga 4, år 2011, Utgivare: Lund: Studentlitteratur, ISBN: 978-91-44-07275-3, s. 139-142.

[2] N. Andersson & A. Ekholm, ”Vetenskaplighet - Utvärdering av tre implementateringsprojekt inom IT Bygg & Fasithet”, Lunds Tekniska Högskola, år 2002.

[3] S. Eklund, ”Arbeta i Projekt - individen, gruppen, ledaren”, upplaga 4, år 2011, Utgivare: Lund: Studentlitteratur, ISBN: 978-91-44-07275-3, s. 20.

[4] AL, Alert, “Att mäta Lean utveckling - En sammanställning av metoder för att utveckling inom lean och en fallstudie på ett företag” år 2010, s.xxx. Tillgänglig: http://kth.diva-portal.org/smash/get/diva2:453621/FULLTEXT01.pdf. [5] J, Andren, “Leadership for Organizational Change - A case study of how insurance companies can develop their leadership in order to better manage orginzational change” år 2015, s.23. Tillgänglig: http://kth.diva-portal.org/smash/get/diva2:1060297/FULLTEXT01.pdf. [6] V. Karpov & D. Netto, “Professional AngularJS”, 1st edition, Published by John Wiley & Sons, Inc. Indiana, år 2015, DOI: 10.1002/9781119209546, ISBN: 1-118-83209-4, s.XXV. [7] A. Grant, “Beginning Angular JS”, 1st Edition, Published by Apress, år 2014, ISBN: 9781484201619, DOI: 10.1007/978-1-4842-0160-2_2, s.52. [8] E. Elrom, “Pro MEAN Stack Development”, 1st edition, Published by Apress, New York, år 2016, DOI:10.1007/978-1-4842-2044-3, ISBN: 1-4842-2043-9, s.109. [9] A. Freeman, “Pro Angular 2”, 2nd edition, Published by Apress, New York, ISBN: 978-1-4842-2306-2, DOI: 10.1007/978-1-4842-2307-9, år 2017, s.1. [10] A. Grant, “Beginning Angular JS”, 1st Edition, Published by Apress, år 2014, ISBN: 9781484201619, DOI: 10.1007/978-1-4842-0160-2_2, s.36. [11] Knockout officiella hemsida, “Introduction”, Tillgänglig: http://knockoutjs.com/documentation/introduction.html, 2017-04-03. [12] C. Gackenheimer, “Introducktion to React”, Publicerad av Apress: Berkeley, CA, New York, år 2015, ISBN: 978-1-4842-1246-2, DOI: 10.1007/978-1-4842-1245-5, s.1. [13] E. Molin, “Comparison of Single-Page Application Frameworks”, år 2016, s.26. Tillgänglig: http://kth.diva-portal.org/smash/get/diva2:1037481/FULLTEXT01.pdf

sida 50

[14] T. Issa & P. Isaias, “Sustainable Design: HCI, Usability and Environmental Concerns”, Publicerad av Springer London, London år 2015, ISBN: 978-1-4471-6752-5, s.22-24.

[15] R.N. Taylor & J. Coutaz, “Software Engineering and Human-Computer Interaction”, år 1994, s.77.

[16] T. Issa & P. Isaias, “Sustainable Design: HCI, Usability and Environmental Concerns”, Publicerad av Springer London, London år 2015, ISBN: 978-1-4471-6752-5, s.24.

[17] Nielsen Norman Group, ”Evidence-Based User Experience Research, Training and Consulting”, Tillgänglig: https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/, 2017-07-22.

[18] Nielsen Norman Group, ”Evidence-Based User Experience Research, Training and Consulting”, Tillgänglig: https://www.nngroup.com/articles/ten-usability-heuristics/, 2017-07-22.

[19] D. Norman, “The Design of Everyday Things”, Publicerad av Basic Books, New York, år 2013, ISBN: 978-0-465-05065-9, s.222-223.

[20] D. Norman, “The Design of Everyday Things”, Publicerad av Basic Books, New York, år 2013, ISBN: 978-0-465-05065-9, s.226.

[21] D. Norman, “The Design of Everyday Things”, Publicerad av Basic Books, New York, år 2013, ISBN: 978-0-465-05065-9, s.227-228.

[22] D. Norman, “The Design of Everyday Things”, Publicerad av Basic Books, New York, år 2013, ISBN: 978-0-465-05065-9, s.228-229.

[23] J. Nielsen, “Usability Engineering”, Publicerad av Burlington: Elsevier Science, September 1994, ISBN: 0-12-518406-9, s.75.

[24] J. Nielsen, “Usability Engineering”, Publicerad av Burlington: Elsevier Science, September 1994, ISBN: 0-12-518406-9, s.77.

[25] D. Norman, “The Design of Everyday Things”, Publicerad av Basic Books, New York, år 2013, ISBN: 978-0-465-05065-9, s.162-165.

[26] D. Norman, “The Design of Everyday Things”, Publicerad av Basic Books, New York, år 2013, ISBN: 978-0-465-05065-9, s.198-199.

[27] D. Norman, “The Design of Everyday Things”, Publicerad av Basic Books, New York, år 2013, ISBN: 978-0-465-05065-9, s.171-207.

[28] Nielsen Norman Group, “Preventing User Errors: Avoiding Conscious Mistakes”, https://www.nngroup.com/articles/user-mistakes/, Uppladdad: 2015-09-07.

sida 51

[29] D. Norman, “The Design of Everyday Things”, Publicerad av Basic Books, New York, år 2013, ISBN: 978-0-465-05065-9, s.171-205.

[30] A. Kurti, B. Vogel, M. Ferati, B. Raufi, “Accessibility Requirements for Blind and Visually Impaired in a Regional Context: An Exploratory Study”, år 2014, s.13-15.

[31] A.M. Michalska, C.X. You, A.M. Niccoloni, V.J. Ippolito, W. Fink, “Accessible Web Page Design for the Visually Impaired: A Case Study”, år 2014, s.996-997.

[32] A.M. Michalska, C.X. You, A.M. Niccoloni, V.J. Ippolito, W. Fink, “Accessible Web Page Design for the Visually Impaired: A Case Study”, år 2014, s.1000.

[33] T. Issa & P. Isaias, “Sustainable Design: HCI, Usability and Environmental Concerns”, Publicerad av Springer London, London år 2015, ISBN: 978-1-4471-6752-5, s.71-72.

[34] A. Martin, “Evaluating and improving the user-interface of existing GIS-applications by the use of HCI evaluation techniques, år 2015, s. 5, Tillgänglig: http://kth.diva-portal.org/smash/get/diva2:824772/FULLTEXT01.pdf

[35] V. Lavrenko, “A Generative Theory of Relevance”, The information Retrieval Series, Vol.26, Publicerad av Springer, Berlin, ISBN: 978-3-540-89363-9, år 2008, s.7-8.

[36] V. Lavrenko, “A Generative Theory of Relevance”, The information Retrieval Series, Vol.26, Publicerad av Springer, Berlin, ISBN: 978-3-540-89363-9, år 2008, s.116.

[37] K. Kemi & E. Törnqvist, “The Product Development Process within a Multinational Company - A Case Study of the Work Procedures and Interactions at an Indian Subsidiary” år 2009, s.13. Tillgänglig: http://kth.diva-portal.org/smash/get/diva2:542501/FULLTEXT01.pdf

[38] K. Kemi & E. Törnqvist, “The Product Development Process within a Multinational Company - A Case Study of the Work Procedures and Interactions at an Indian Subsidiary” år 2009, s.14. Tillgänglig: http://kth.diva-portal.org/smash/get/diva2:542501/FULLTEXT01.pdf

[39] K. Kemi & E. Törnqvist, “The Product Development Process within a Multinational Company - A Case Study of the Work Procedures and Interactions at an Indian Subsidiary” år 2009, s.14. Tillgänglig: http://kth.diva-portal.org/smash/get/diva2:542501/FULLTEXT01.pdf

[40] K. Kemi & E. Törnqvist, “The Product Development Process within a Multinational Company - A Case Study of the Work Procedures and Interactions at an Indian Subsidiary” år 2009, s.38. Tillgänglig: http://kth.diva-portal.org/smash/get/diva2:542501/FULLTEXT01.pdf

sida 52

[41] I. Sommerville, “Software Engineering”, International ed of 9th revised ed, Publicerad av Pearson Education, år 2009, ISBN: 0-13-705346-0, s.103-105.

[42] I. Sommerville, “Software Engineering”, International ed of 9th revised ed, Publicerad av Pearson Education, år 2009, ISBN: 0-13-705346-0, s.106-107.

[43] S. Eklund, ”Arbeta i Projekt - individen, gruppen, ledaren”, upplaga 4, år 2011, Utgivare: Lund: Studentlitteratur, ISBN: 978-91-44-07275-3, s. 120.

[44] N. Andersson & A. Ekholm, ”Vetenskaplighet - Utvärdering av tre implementateringsprojekt inom IT Bygg & Fasithet”, Lunds Tekniska Högskola, år 2002, s.16–17.

[45] C. Larman, “Agile and iterative development: a manager’s guide”, 1st edition, Publicerad av Addison-Wesley Professional, Boston, år 2004, ISBN: 0-13-111155-8, s.8.

[46] S. Eklund, ”Arbeta i Projekt - individen, gruppen, ledaren”, upplaga 4, år 2011, Utgivare: Lund: Studentlitteratur, ISBN: 978-91-44-07275-3, s. 128–129.

[47] Steve Krug, “Don't Make Me Think! A Common-Sense Approach to Web Usability”, New Riders Publishing, Indiana, Publiserad 2000, ISBN: 0-7897-2310-7, Sida 11.

[48] FullCalendar LLC, “FullCaldendar” https://fullcalendar.io, Tillgänglig: 2017-04-01.

[49] Lin Chou Cheng, ”The Mobile App Usability Inspection (MAUi) Framework as a Guide for Minimal Viable Product (MVP) Testing in Lean Development Cycle” School of Informatics & IT, Singapore. Publiserad 2016, Sida 1.

sida 53

Bilagor Bilaga 1

Utvecklingsmetod 1

Utvecklingsmetod 2

sida 54

Bilaga 2 Arbetsplan och arbetsvolym per projektdeltagare Följande diagram och beräkning är skapat med verktyget Google Kalkylark och visar planerade arbetstimmar för en av projektdeltagarna.

Integralen av funktionen i diagrammet nedan och över de visade veckorna ger den totala planerade arbetsvolymen som skall bli cirka 400 timmar per student.

sida 55

Bilaga 3 User Stories

Loggbok - Länk: https://app.moqups.com/Goran1992/GcPnF5cbBo/view/page/ ad64222d5

1. Användarfall - Skapa ett event

Det ska vara möjligt att skapa ett event i loggboken. Eventet ska innehålla olika uppgifter där även roller specificeras.

Normalt flöde

1. Användaren loggar in på GMP-System. 2. Användaren trycker på Loggbok. 3. Användaren trycker på skapa event (via plussymbolen) 4. Användaren skriver in ett namn väljer land på det specifika eventet 5. Användaren väljer ett datum för varje task 6. Användaren trycker på spara för att skapa ett event.

Det specifika eventet är nu skapat och visas i kalendern.

sida 56

Alternativt flöde 1

I steg 4 väljer användaren att skapa ett event bakåt i tiden. - Ska ej fungera.

Alternativt flöde 2

I steg 4 väljer användaren att skapa ett event som har ett namn som redan existerar. - Ska ej fungera.

2. Användarfall - Set to Done

För att göra det möjligt för användare att markera att en uppgift är klar har varje task i loggboken en “checkbox” som kan klickas i. Endast den roll som har fått uppgiften tilldelad sig har den funktionen synlig.

sida 57

Förvillkor

Ett event är skapat och har lagts till för en annan aktör för ett specifikt datum Normalt flöde

1. Användaren loggar in på GMP-Systems. 2. Användaren trycker på Loggbok. 3. Användaren får upp ett event som aktören har skapat

Rätt datum visas och endast det event som aktören ska se visas

4. Användaren klickar in att den specifika uppgiften är utförd.

Uppgiften är nu markerad som grön och utförd. Datum och användare som utfört handlingen skrivs ut och detta syns även för personen som skapat eventet.

Alternativt flöde - Utdaterat datum

1. Användaren loggar in på GMP-Systems. 2. Användaren trycker på Loggbok. 3. Användaren får upp ett event som aktören

har skapat 4. Användaren trycker på done på ett event

med datum som skulle vara klart bakåt i tiden. a. Eventet är placerad på samma datum

som tidigare dvs det datum uppgiften initialt skulle vara slutförd.

b. Det datum som uppgiften sedan slutfördes visas i uppgiften och är markerad i röd text.

c. “Checkboxen” är även markerad i röd färg.

sida 58

3. Användarfall - sök efter event

Förvillkor

Ett flertal event är skapade.

Normalt flöde

1. Användaren loggar in på GMP-Systems. 2. Användaren trycker på Loggbok. 3. Användaren söker på ett specifikt event

Eventet listas i menyn till vänster och objekten som hör till, visas i kalendern.

4. Användarfall - Ta bort event

Det ska finnas en möjlighet att ta bort ett specifikt event. Det kan hända att en användare har skapat ett felaktigt event eller skapat ett event av misstag. Endast den rollen som har skapat eventet kan ta bort det.

Förvillkor

Event är skapade med den specifika användaren Event är skapade med en annan typ av användare.

Normalt flöde

1. Användaren loggar in på GMP-Systems. 2. Användaren trycker på Loggbok.

Event som användaren eller någon med samma roll inte har skapat ska inte ha en editera knapp.

3. Användaren trycker på ett specifikt event som denna har skapat. 4. Användaren trycker på editera. 5. Användaren trycker på delete. 6. Eventet ska nu vara borttaget och inte längre visas för någon av

användaren.

sida 59

5. Användarfall – ändra datum på task Det ska finnas en möjlighet att korrigera ett specifikt event. Endast den rollen som har

skapat eventet kan ändra det.

Förvillkor

Minst ett event är skapat med den specifika rollen

Normalt flöde

1. Användaren loggar in på GMP-Systems. 2. Användaren trycker på Loggbok. 3. Användaren väljer att dra en task till ett annat datum.

En popup ruta visas och frågar användaren om den är säker på att flytta uppgiften till det specifika datumet.

4. Användaren trycker på ja.

- Eventet ska nu vara ändrat med den nya uppgiften.- Ett datum ska vara synligt där det står: (Uppgift flyttad från datum: xx/xx).

sida 60

6. Användarfall – Editera event

Det ska finnas en möjlighet att editera ett event. Endast den rollen som har skapat

eventet kan ändra det.

Förvillkor

Minst ett event är skapat med den specifika rollen.

Normalt flöde

1. Användaren loggar in på GMP-Systems.

2. Användaren trycker på Loggbok.

3. Användaren trycker på editera knappen intill ett skapat event.

4. Användaren editerar om önskade fält som namn, land, titel och datum.

5. Användaren trycker på spara.

Eventet ska nu ha anpassat sig efter de nya parametrarna.

7. Användarfall - Visa specifik aktör

Det ska finnas en möjlighet att sortera på att endast visa en specifik rolls uppgifter i loggboken för att underlätta det för användaren att få en bättre översikt.

Förvillkor

Event är skapade med flera olika uppgifter.

Normalt flöde

1. Användaren loggar in på GMP-Systems. 2. Användaren trycker på Loggbok. 3. Användaren väljer att “trycka” på en av aktörerna som listas.

Endast de uppgifter som är tilldelade användarens roll visas i loggboken.

sida 61

Bilaga 4 MDI-Modellering

Minimera slips

• Vi har tagit hänsyn till att användare inte ska behöva hålla information i minnet och därav valt att se till att valda roller alltid är synliga.

• Vi valde även att all information visas och lagras på en sida när man skapar ett nytt event, så att man får en tydlig överblick.

• Man skapar uppgifter vid ett tillfälle istället för att göra detta i en flerstegsprocess.

Färgsättning

• Färgsättning till objekt har tagits hänsyn till genom att vi begränsat antalet färger samt kopplat färgerna till specifika roller och använt dessa konsekvent.

• Man kan tydligt se vilken uppgift som tillhör respektive roll genom att vi har definierat elementen via få och tydliga färgsättningar.

Minimera misstag

• När en uppgift markeras som klar kan en användare alltid ”ångra” sig genom att bocka ur rutan igen. Här tillåter vi operationer att vara ändringsbara.

Design av system som tar hänsyn till nedsatt syn

• Vi har tagit hänsyn till personer med nedsatt syn genom att använda standardfonter.

Upptäck grundproblemet

Ett grundproblem som vi upptäckte var att användarna hade svårt att få en överblick över loggboken. Utifrån detta:

• har strukturen ändrats och vi har istället delat upp länder och brands på vänster sida, vilket har gjort det tydligare för användaren att få en överblick över fler länder och brands

• användaren har även möjlighet att scrolla/söka i det fältet utan att den befintliga vyn påverkas.

TRITA STH 2017:121

www.kth.se