SimAnalyzer: Implementation av ett verktyg för analys av registrerad data från flygsimulator

Kandidatuppsats

SimAnalyzer: Implementation av ett verktyg f¨

or analys av

registrerad data fr˚

an flygsimulator

av

Caroline Karlsson

LIU-IDA/KOGVET-G--15/011--SE 2015-06-09

Kandidatuppsats

SimAnalyzer: Implementation av ett verktyg f¨

or analys av

registrerad data fr˚

an flygsimulator

av

Caroline Karlsson

Uppdragsgivare: Saab Aeronautics LIU-IDA/KOGVET-G--15/011--SE Handledare : Carine Signoret

Institutionen f¨or beteendevetenskap och l¨arande vid Link¨opings universitet

Sammanfattning

Detta arbete har som utg˚angspunkt att specificera, implementera och ut-v¨ardera ett verktyg som har som syfte att ta fram resultat fr˚an fr˚agest¨ all-ningar mot registrerade data fr˚an flygplanssimulator. Detta g¨ors genom framtagning av kravspecifikation och en iterativ programutvecklingsme-tod. Ett utv¨arderingstest i simulator utf¨ordes f¨or att samla data som sedan analyserades med verktyget. Detta f¨or att unders¨oka om det g˚ar att hitta tillf¨allen d¨ar h¨og kognitiv belastning upplevdes.

Nyckelord : flygsimulator, analysprogram, cockpit design, kognitiv be-lastning, SQL

Tack

Jag vill tacka min handledare Carine Signoret f¨or allt st¨od och r˚ad hon bidragit med genom arbetet. Ett stort tack till Johan Holmberg p˚a Saab f¨or all expertis och v¨agledning. Jag vill ¨aven tacka Rita Kovordanyi f¨or v¨ardefull feedback.

Tack pappa f¨or att du alltid varit min stora inspiration. Jag hoppas du kan l¨asa det h¨ar fr˚an himlen.

Inneh˚

all

Tabeller ix Figurer x 1 Inledning 1 1.1 Syfte . . . 2 1.2 Fr˚agest¨allningar . . . 2 1.3 Avgr¨ansningar . . . 2 2 Bakgrund 3 2.1 Projektbakgrund . . . 3 2.1.1 Saab Aeronautics . . . 3 2.1.2 Hj¨arnbudget . . . 3 3 Teori 5 3.1 Kognitiv belastning . . . 5 3.1.1 Situation awareness . . . 6

3.1.2 Delad uppm¨arksamhet . . . 6

Wickens multiple resource model . . . 7

3.2 Anv¨andbarhetsutv¨ardering . . . 7

3.3 Implementation . . . 8

3.3.1 Agil systemutveckling . . . 8

Scrum f¨or ett enmansprojekt . . . 9

viii INNEH˚ALL

SQLite . . . 10

4 Metod 11 4.1 Programutvecklingsmetod . . . 11

4.2 Specifikation . . . 12

4.2.1 T¨ankbara ansatser f¨or att unders¨oka registrerad data fr˚an simulator . . . 12

F¨or¨andringar och niv˚aer p˚a loggade data . . . 13

Utfall i f¨orh˚allande till f¨orv¨antat beteende . . . 13

Studera reaktionstider . . . 14 Entropier . . . 14 4.3 Implementation . . . 15 4.3.1 Val av programspr˚ak . . . 15 4.3.2 Datalagring . . . 15 SQLite . . . 15

4.4 Utv¨ardering och datainsamling . . . 16

4.4.1 Loggfiler . . . 16

5 Resultat 17 5.1 Funktionella krav . . . 17

5.1.1 Krav f¨or framtida utveckling . . . 18

5.2 Implementation . . . 18 5.2.1 ButtonEvents . . . 18 5.2.2 ContinuousLog . . . 19 5.2.3 LayoutEvent . . . 20 5.3 Utv¨ardering . . . 21 6 Diskussion 25 6.1 Resultatdiskussion . . . 25 6.2 Metoddiskussion . . . 27 6.3 Vidareutveckling . . . 28 7 Slutsats 29 Litteraturf¨orteckning 30

Figurer

5.1 GUI f¨or att ladda loggfil. ButtonEventlog ¨ar laddad . . . . 19 5.2 Funktioner i GUI f¨or filtrering av data ur ButtonEvent . . . 19 5.3 Exempel p˚a en av verktyget genererad SQL-query . . . 20 5.4 Funktioner i GUI f¨or filtrering av data ur ContinuousLog . 20 5.5 Funktioner i GUI f¨or filtrering av data ur LayoutEvent . . . 21 5.6 Tidpunkter d¨ar Bar Alt (h¨ojd) > 500 mellan tidpunkterna

15:09 och 15:17 . . . 22 5.7 Alla knappinteraktioner mellan 10:45 och 10:46 . . . 23 5.8 Displayinneh˚all mellan 10:45 och 10:46 . . . 24

Kapitel 1

Inledning

Bakgrunden till detta arbete ¨ar utvecklingen av ett nytt stridsflygplan. Vid anv¨andbarhetsutv¨ardering av en cockpits gr¨anssnittsdesign genomf¨ors tes-ter med flygsimulator. En simulator kan representes-tera komplexiteten i en verklig situation utan att beh¨ova inneb¨ara livshotande risker. Under tes-terna registreras data (blickregistrering, systemtillst˚and/h¨andelser i gr¨ ans-snittet, systemtillst˚and/h¨andelser f¨or flygplanet, video). Vid utv¨ardering av ett aktuellt gr¨anssnitts anv¨andbarhet formuleras fr˚agest¨allningar som ”¨ar detta tillr¨ackligt bra?”, ”¨ar l¨osning A mer anv¨andbar ¨an l¨osning B?” och ”finns det n˚agot i l¨osningen som kan f¨orb¨attras?”. De registrerade data kan analyseras utifr˚an algoritmer f¨or de m˚att som antas vara begr¨ ansan-de. P˚a s˚a vis kan ett verktyg hj¨alpa till att hitta intressanta tidpunkter i den registrerade datan, exempelvis tidpunkter d¨ar h¨og kognitiv belastning antas genereras, och anv¨andas som komplement till subjektiv utv¨ardering.

2 1.1. Syfte

1.1

Syfte

F¨or att inte beh¨ova leta upp intressanta h¨andelser i registrerad data manu-ellt ska ett verktyg designas och implementeras d¨ar en anv¨andare kan ange en fr˚agest¨allning och f˚a resultatet presenterat.

1.2

Fr˚

agest¨

allningar

• Hur kan ett verktyg implementeras f¨or att underl¨atta tolkning av registrerad data?

• Hur kan ett verktyg, genom att unders¨oka data, anv¨andas som kom-plement till konventionell anv¨andbarhetstestning?

• Hur n˚as systemets krav p˚a funktionalitet utifr˚an projektets syfte? • Hur kan man omvandla informationen fr˚an en loggfil till ett format

som l¨att kan tolkas av anv¨andare?

1.3

Avgr¨

ansningar

Detta arbetes syfte ¨ar att ta fram en f¨orsta version av verktyget. Funk-tionerna som verktyget skall ha kommer att utg˚a fr˚an ett begr¨ansat antal m¨ojliga fr˚agest¨allningar. Verktyget ska utformas p˚a ett s¨att att det l¨att kan byggas p˚a med mer funktionalitet f¨or att st¨odja nya analysmetoder. Funktionaliteten f¨or att tolka indatan ska enkelt kunna modifieras f¨or att st¨odja fler element. I detta arbete kommer ett fungerande gr¨anssnitt som kommunicerar resultat fr˚an analyserad data till anv¨andare att f¨ardigst¨allas.

Kapitel 2

Bakgrund

2.1

Projektbakgrund

2.1.1

Saab Aeronautics

Saab har ungef¨ar 14 700 anst¨allda och ¨ar uppdelad i sex aff¨arsomr˚aden. Om-r˚adet Aeronautics, d¨ar detta projekt utf¨orts, ligger ansvarsomr˚aden bland annat p˚a avancerade luftburna system, relaterade delsystem och obeman-nade flygande farkoster. Saab Aeronautics har ansvar f¨or utveckling, pro-duktion och f¨ors¨aljning av flygplanet Gripen. Vid utveckling av Gripens HMI (human-machine interface) implementeras gr¨anssnittet i en avance-rad simulator d¨ar tester sedan genomf¨ors och anv¨andbarheten utv¨arderas.

2.1.2

Hj¨

arnbudget

Projektet Hj¨arnbudget ¨ar ett samarbete mellan Saab Aeronautics, Total-f¨orsvarets Forskningsinstitut (FOI) och Stockholms universitet. Syftet ¨ar att ta fram kvantitativa och kvalitativa HMI-m˚att och metoder f¨or att

ut-4 2.1. Projektbakgrund

v¨ardera interaktionen mellan m¨anniska och maskin i en cockpit, samt att ta fram algoritmer som m¨ater och skattar mental workload och situation awareness i en utv¨ardering av ett gr¨anssnitt (Jander et al., 2011). Begrep-pet hj¨arnbudget kommer av att hj¨arnan antas ha en begr¨ansad kapacitet f¨or informationsbearbetning (Wickens, 1984).

Kapitel 3

Teori

Detta avsnitt ger en ¨oversikt av den teoretiska bakgrunden till de forsk-ningsf¨alt som ¨ar relevanta f¨or detta arbete. Konventionell anv¨ andbarhets-utv¨ardering beskrivs, samt faktorer som p˚averkar en m¨anniskas f¨orm˚aga att fatta beslut och utf¨ora uppgifter p˚a ett bra s¨att. Teoretisk bakgrund till faktorer n¨ar det g¨aller implementation beskrivs ¨aven, som programut-vecklingsmetod och databashantering.

3.1

Kognitiv belastning

Med begreppet kognitiv belastning menas att en m¨anniska har en begr¨ an-sad arbetsminneskapacitet, och den kognitiva belastningen ¨ar den totala m¨angd mentala resurser som anv¨ands i arbetsminnet i en viss situation. (Sweller, 1988; Wickens, 1984) N¨ar ett system designas ¨ar m˚alet att minska den kognitiva belastningen och frig¨ora mental kapacitet f¨or att anv¨ anda-ren ska kunna hantera ov¨antade h¨andelser (Jander et al., 2011). D¨arf¨or ¨ar det viktigt att unders¨oka vilken information som ¨ar viktig f¨or anv¨andaren i scenarier med h¨og kognitiv belastning d˚a h¨og kognitiv belastning medf¨or sv˚arigheter att rikta uppm¨arksamheten mot nya h¨andelser. D¨armed ¨okar

6 3.1. Kognitiv belastning

risken f¨or fel, vilket kan medf¨ora stora risker. D˚a en flygplanscockpit r¨aknas som en riskfylld milj¨o ¨ar det viktigt att unders¨oka den kognitiva belastning en pilot uts¨atts f¨or. (Wickens et al., 2013)

En studie av Benthem et al. (2015) har visat att h¨og kognitiv belastning leder till en ¨okad risk att g¨ora fel i en cockpitmilj¨o. Studien gick huvudsak-ligen ut p˚a att piloter fl¨og en Cessna 172-simulator och skulle uppeh˚alla kommunikation med trafik och uppm¨arksamma olika flygparametrar. Pi-loterna beh¨ovde rapportera muntligt vid flera olika tillf¨allen och n¨ar den kognitiva belastningen ¨okade (i form av flera saker som h¨ander samtidigt) s˚a missade piloter att rapportera i h¨ogre utstr¨ackning ¨an om belastningen var mindre. N¨ar minnet sviktar p˚a grund av h¨og kognitiv belastning, finns risk f¨or olyckor. Att exempelvis gl¨omma bort att informera andra flygplan om sin plats eller att gl¨omma ett steg i rutinen vid start kan resultera i allvarliga olyckor.(Benthem et al., 2015)

3.1.1

Situation awareness

Endsley (1988) definierar situation awareness som perceptionen av kritiska element i omgivningen, f¨orst˚aelsen av deras mening, och projektionen av deras status f¨or framtiden. Situation awareness ¨ar viktigt n¨ar det g¨aller att utf¨ora uppgifter effektivt i kritiska milj¨oer. Det handlar om att f¨orst˚a vad som h¨ander i omgivningen och hur ens handlingar kommer att p˚averka ens m˚al och uppgifter. H¨og kognitiv belastning p˚averkar situation awareness negativt, och brist p˚a situation awareness ¨ar en stor faktor i olyckor som beror p˚a den m¨anskliga faktorn (Wickens et al., 2013).

3.1.2

Delad uppm¨

arksamhet

N¨ar en m¨anniska beh¨over g¨ora flera saker samtidigt s˚a m˚aste uppm¨ arksam-heten delas mellan de olika uppgifterna. Problemet med delad uppm¨ ark-samhet eng. divided attention ¨ar att n¨ar en m¨anniska beh¨over utf¨ora flera uppgifter samtidigt s˚a tenderar denne att g¨ora misstag eller utf¨ora uppgif-ten l˚angsammare. Kahneman (1973) menar att det finns en mental pool av

Teori 7

resurser f¨or uppm¨arksamhet som kan f¨ordelas mellan flera olika uppgifter. Beroende p˚a vilka modaliteter som anv¨ands i uppgifterna kan de interferera med varandra och det blir sv˚art att utf¨ora dem samtidigt.

Wickens multiple resource model

Wickens (1984) tog fram en modell ¨over hur mentala resurser kan f¨ordelas beroende p˚a vilka modaliteter som anv¨ands. Multiple resource model visar hur exempelvis visuella och verbala aktiviteter h¨amtar resurser fr˚an olika k¨allor och kan d¨arf¨or utf¨oras parallellt utan att st¨ora varandra. Modellen f¨or multipla resurser kan anv¨andas som ett verktyg i design och f¨or att f¨orutse kognitiv belastning under multitasking (Wickens, 2008). Genom att utg˚a fr˚an denna modell kan gr¨anssnitt s˚asom en flygplanscockpit designas f¨or att anv¨anda de olika modaliteterna och d¨armed minska den mentala belastningen, exempelvis genom att ha auditiva upplysningar f¨or varningar eller till och med anv¨anda taktila egenskaper.

3.2

Anv¨

andbarhetsutv¨

ardering

Anv¨andbarhet definieras som f¨oljande enligt ISO-standarden 9241-11: ”Den grad i vilken anv¨andare i ett givet sammanhang kan bruka en produkt f¨or att uppn˚a specifika m˚al p˚a ett ¨andam˚alsenligt, effektivt och f¨or anv¨andaren till-fredsst¨allande s¨att.” (ISO, 1993) I utvecklingen av en cockpitdesign anv¨ands flygsimulator f¨or att utv¨ardera anv¨andbarhet. Anv¨andbarhetsutv¨ardering kan g¨oras med konventionella metoder, som den verbala metoden t¨anka h¨ogt-protokoll och subjektiv utv¨ardering med SUS-m¨atning. Anv¨ andbar-hetsutv¨ardering genomf¨ors bland annat f¨or att uppt¨acka om en uppgift ger en anv¨andare h¨og kognitiv belastning, d˚a kognitiv belastning ¨ar en faktor som p˚averkar hur m¨anniskor fattar beslut i probleml¨osning (Wickens et al., 2013).

I ett t¨anka h¨ogt-protokoll f˚ar en anv¨andare kontinuerligt dela med sig av sina tankar muntligt medan denne l¨oser ett problem. T¨anka h¨ogt-metoden kan anv¨andas f¨or att unders¨oka individuella skillnader i probleml¨osning,

8 3.3. Implementation

skillnader i sv˚arighetsgrader mellan uppgifter och andra faktorer som kan p˚averka probleml¨osning (Barnard et al., 1994).

En m¨atning med SUS (System Usability Scale) g˚ar ut p˚a att snabbt utv¨ ar-dera en produkt genom att ta fram ett numeriskt resultat som indikerar produktens anv¨andbarhet. Anv¨andaren f˚ar skatta sina upplevelser utifr˚an tio p˚ast˚aenden som var och en besvaras i en likertskala med fem steg (0-4), d¨ar anv¨andaren anger hur mycket denne h˚aller med om p˚ast˚aendet i fr˚aga. Anv¨andarens svar konverteras genom att ta h¨ansyn till att vartannat p˚ a-st˚aende ¨ar positivt respektive negativt laddat. D¨armed ber¨aknas resultatet genom att de p˚ast˚aenden med j¨amna nummer (negativt laddade p˚ast˚ aen-den) ges v¨ardet 5 - deltagarens angivna v¨arde. De p˚ast˚aenden p˚a udda nummer (positivt laddade p˚ast˚aenden) ber¨aknas med deltagarens angivna v¨arde - 1. Resultaten f¨or respektive p˚ast˚aende adderas och summan multi-pliceras med 2.5 och resulterar i ett v¨arde mellan 0 och 100, d¨ar en h¨ogre siffra indikerar b¨attre anv¨andbarhet. (Brooke, 1996)

3.3

Implementation

3.3.1

Agil systemutveckling

Det agila manifestet enligt Beck et al. (2001) representerar vad som ¨ar viktigt i agil systemutveckling:

• Individer och interaktioner framf¨or processer och verktyg. • Fungerande programvara framf¨or omfattande dokumentation. • Kundsamarbete framf¨or kontraktsf¨orhandling.

• Anpassning till f¨or¨andring framf¨or att f¨olja en plan.

Den agila systemutvecklingsmetodiken ses som en reaktion mot den tradi-tionella planbaserade metoden. Tanken bakom agil utveckling ¨ar att ha ett n¨ara samarbete med anv¨andaren under hela utvecklingen. Systemutveck-lingen sker inkrementellt, vilket inneb¨ar flera mindre leveranser och l¨opande utv¨ardering. En styrka i agila systemutvecklingsmetoder ¨ar att de hanterar

Teori 9

f¨or¨andringar bra, d˚a krav kan tillkomma eller tas bort under processens g˚ang. (Dalcher and Brodie, 2007)

Det finns flera olika agila systemutvecklingsmetoder, en av dessa ¨ar Scrum.

Scrum f¨or ett enmansprojekt

Utvecklingsmetoden Scrum ¨ar knuten till att arbeta i ett utvecklingsteam och omfattar ett antal olika roller. D˚a metoden skall anv¨andas i ett en-mansprojekt s˚a kommer den personen anta alla roller inom teamet, utom produkt¨agaren, som skall representera kunden och hantera ¨onskem˚al om ¨

andringar och till¨agg f¨or produkten. Produkt¨agaren skriver user stories, vil-ka ¨ar korta beskrivningar av vad en anv¨andare beh¨over anv¨anda systemet till. Att anv¨anda Scrum i ett enmansprojekt kr¨aver allts˚a en anpassning av metoden, d˚a det saknas gruppmedlemmar att diskutera, arbeta, och ha m¨oten tillsammans med. (Schwaber and Sutherland, 2011)

Scrummetoden anv¨ander sig av artefakter som skall underl¨atta arbetspro-cessen, som produktbacklogg och sprintbacklogg (Beedle et al., 1999). Per-sonal Scrum ¨ar ett begrepp som tagits fram av anv¨andare som manipulerat metoden f¨or att anv¨andas av en ensam utvecklare (Pruitt, 2011). Element som kan anv¨andas effektivt i ett enmansprojekt ¨ar exempelvis principen att dela upp arbetet i sprintar, anv¨andning av en produktbacklogg f¨or att strukturera arbetet och hantera krav, samt sprintbackloggar f¨or att ha koll p˚a det som skall implementeras under den kommande sprinten. Scrumme-toden innefattar ¨aven dagliga scrumm¨oten d¨ar utvecklingsteamet granskar processen och g˚ar igenom vad som gjorts och vad som skall g¨oras till mor-gondagen (Schwaber and Sutherland, 2011). Att arbeta mot v¨aldefinierade, kortsiktiga m˚al ¨ar allts˚a n˚agot som g˚ar att anv¨anda sig av ¨aven som en en-sam utvecklare.

10 3.3. Implementation

3.3.2

Databashantering

Structured Query Language (SQL) ¨ar ett programspr˚ak som anv¨ands f¨or att hantera data i en databas, som att h¨amta och modifiera data. Program-spr˚akets syntax delas in i olika element, varav ett ¨ar queries, som utf¨ors med ett ”SELECT”-statement. Queries l˚ater en anv¨andare beskriva ¨onskad da-ta, och l˚ater en databashanterare utf¨ora optimering och de handlingar som beh¨ovs f¨or att producera det ¨onskade resultatet. Det finns ett stort antal databashanterare p˚a marknaden och n˚agra av de mest anv¨anda ¨ar Oracle Database, MySQL och Microsoft SQL Server enligt DB-Engines ranking i juni 2015 (DB-Engines, 2015). M˚anga databashanterare ¨ar klient/server-baserade, som ¨ar vanliga d˚a program skall kommunicera ¨over n¨atverk och d¨ar en anv¨andare skall kunna komma ˚at data fr˚an olika datorer.

SQLite

SQLite ¨ar en databashanterare som inte ¨ar klient/serverbaserad utan finns inb¨addad i programmet och beh¨over inte kommunicera med andra processer utanf¨or programmet. SQLite ¨ar gratis att anv¨anda och g˚ar att b¨adda in i ett stort antal programspr˚ak, bland annat C#, C++ och Java. (SQLite, 2015)

Kapitel 4

Metod

Detta avsnitt beskriver metoden som anv¨andes f¨or att ta fram verktyget. Arbetsg˚angen bestod huvudsakligen av f¨oljande steg:

• Bakgrundsanalys, unders¨okning av metoder och liknande system. • Framtagning av kravspecifikation med funktionella krav och designkrav. • Programutveckling i iterationer (”sprintar”).

• Utv¨ardering av verktygets funktion. Ett simulatortest utf¨ordes och de insamlade data analyserades med verktyget.

4.1

Programutvecklingsmetod

En modifierad variant av den agila programutvecklingsmetoden Scrum an-v¨andes. Metoden anpassades f¨or ett utvecklingsteam p˚a en person. Varje sprint var en vecka l˚ang och implementationen bestod av totalt sju sprintar. Fokus l˚ag inledningsvis inte p˚a gr¨anssnittsdesign utan p˚a den bakomliggan-de funktionaliteten. De funktionella kraven bakomliggan-delabakomliggan-des upp i mindre best˚ ands-delar och specificerades i en produktbacklogg f¨or att ha en bra ¨oversikt ¨over

12 4.2. Specifikation

vad som beh¨ovde g¨oras. I slutet av varje sprint levererades ett inkrement och ett m¨ote h¨olls med produkt¨agaren f¨or att utv¨ardera inkrementet samt planera och ta fram en sprintbacklogg f¨or n¨asta sprint.

4.2

Specifikation

En kravspecifikation togs inledningsvis fram tillsammans med produkt¨ a-garen, en representant f¨or Saab, genom generering av user stories ur vilka funktionella krav utvanns.

Systemet ska anv¨andas av utvecklare, prototypare och testare p˚a HMI-avdelningen som komplement till konventionell anv¨andbarhetsutv¨ardering. Syftet med systemet ¨ar att l¨asa in och presentera registrerade data fr˚an simulatortester. En anv¨andare ska kunna ange en fr˚agest¨allning, utifr˚an denna g¨ors en analys av loggdatan och analysen presenteras p˚a sk¨armen. Diskussionen ledde ¨aven fram till exempelfr˚agest¨allningarna som verktyget skall svara p˚a. Dessa analysmetoder har genererats i projektet Hj¨arnbudget.

4.2.1

T¨

ankbara ansatser f¨

or att unders¨

oka registrerad

data fr˚

an simulator

Som komplement till konventionella metoder, som de tidigare n¨amnda, kan registrerad loggdata analyseras f¨or att hitta tidpunkter d¨ar det enligt datan kan ha genererats h¨og kognitiv belastning. Tidigare beskrevs begrepp som p˚averkar anv¨andbarhet och mental belastning, utifr˚an dessa faktorer har dessa fyra ansatser till analysmetoder har tagits fram. De beskriver f¨ or-slag p˚a hur registrerad data skulle kunna angripas f¨or att finna intressanta punkter i de data som finns. Det finns ett extremt stort antal intressanta punkter som potentiellt skulle kunna unders¨okas och definitionerna f¨or des-sa kan vara komplexa, d¨arf¨or valdes dessa fyra ansatser som utg˚angspunkt.

Metod 13

F¨or¨andringar och niv˚aer p˚a loggade data

Ett s¨att att finna intressanta punkter ¨ar att s¨oka i loggdatan efter ov¨antade f¨or¨andringar, exempelvis n¨ar det g¨aller dessa faktorer:

• Flygplansdata – h¨ojd, fart, kurs

• Interaktionsdata – Knappar, menyer, spakhantering • Annat - till exempel antal displayytor som anv¨ands Exempelfr˚agest¨allningar:

• Jag vill hitta tidsomr˚aden d˚a f¨oraren hade mycket interaktioner (knapp-tryckningar, spakr¨orelser) med systemet.

• Jag vill hitta tidsomr˚aden d˚a f¨oraren hade interaktioner (knapptryck-ningar) med systemet samtidigt som flygplanet man¨ovrerade (roll, tipp, kurs f¨or¨andras).

Utfall i f¨orh˚allande till f¨orv¨antat beteende

I denna ansats anv¨ands experters tankar som ing˚angsv¨arde, till exempel ”om X intr¨affar, ta fram meny Y, klicka p˚a Z...”. Sekvenser av h¨andelser unders¨oks f¨or att se om piloten anv¨ant sig av en f¨orv¨antad sekvens av inter-aktioner med systemet. Om inte, kan det vara ett tecken p˚a h¨og kognitiv belastning, d˚a detta tidigare visat sig leda till missade kommandon och interaktioner (Benthem et al., 2015).

Exempelfr˚agest¨allningar:

• N¨ar f¨oraren fick ett nytt m˚all¨age, anv¨ande han d˚a UCP enbart, inmat-ningssida+UCP eller mark¨orklick i kartan f¨or att mata in m˚all¨aget? Jag f¨orv¨antar mig att han anv¨ander UCP enbart under flygning och inmatningssida+UCP om flygplanet ¨ar p˚a marken.

14 4.2. Specifikation

Studera reaktionstider

Ett s¨att att unders¨oka kognitiv belastning ¨ar att m¨ata tiden mellan en h¨ an-delse och tills den ¨ar ˚atg¨ardad. M˚aste veta n¨ar n˚agot intr¨affar och n¨ar den anses ˚atg¨ardad. Vad som ¨ar en acceptabel reaktionstid beror p˚a uppgiftens karakt¨ar. ¨Ar reaktionstiden inte acceptabel kan ytterligare analyser g¨oras f¨or att ta reda p˚a om andra faktorer inverkat p˚a reaktionstiden.

Exempelfr˚agest¨allningar:

• Hur l˚ang tid tog det fr˚an att f¨oraren fick varning om att han blivit beskjuten tills han gjorde n˚agot av f¨oljande: sv¨angde bort, d¨ok ned, f¨allde motmedel, bytte till automatmod?

• Hur l˚ang tid tog det fr˚an att f¨oraren b¨orjar knappa p˚a UCP (knapp=UCP ∗) tills han ¨ar klar (knapp = UCP ENT)?

Entropier

Denna ansats g˚ar ut p˚a att unders¨oka hur m˚anga displayer/informationsk¨allor som anv¨ands och hur en anv¨andare arbetar med olika ytor.

Exempelfr˚agest¨allningar:

• N¨ar har f¨oraren som mest arbetsbelastning (viktat v¨arde av olika systeminteraktioner, st¨orre presentations¨andringar, kanske ¨aven i fram-tiden informationsdensitet p˚a de vyer han har framme)?

• Finns det kombinationer av systeminteraktioner som ger h¨og arbets-belastning (knapptryckningar t¨att i tiden men p˚a olika platser i ka-binen) som intr¨affar ofta? Vilka ¨ar det och n¨ar intr¨affade de?

Metod 15

4.3

Implementation

4.3.1

Val av programspr˚

ak

Implementationen gjordes i programspr˚aket C# i utvecklingsmilj¨on Visual Studio. C# ¨ar ett objektorienterat programspr˚ak, utvecklat av Microsoft. Valet av programspr˚aket C# grundades huvudsakligen i att st¨odja vidare-utveckling. Utvecklingsmilj¨on Visual Studio anv¨andes d˚a det ¨ar anv¨andbart n¨ar det g¨aller att snabbt och smidigt utveckla samt modifiera ett anv¨ an-dargr¨anssnitt. En viktig aspekt av det h¨ar arbetet ¨ar att g¨ora koden enkel att l¨asa f¨or att underl¨atta framtida utveckling. Kommentering av kod gjor-des grundligt och l¨opande under implementationen f¨or att det senare skall vara l¨att att f˚a en ¨overblick av vad enskilda klasser och funktioner har f¨or syfte. F¨or att p˚a ett effektivt s¨att s¨atta samman ett anv¨andargr¨anssnitt till verktyget anv¨andes ramverket Windows Presentation Foundation (WPF ) som ¨ar en del av Microsoft .NET Framework 4.

4.3.2

Datalagring

F¨orst skapades funktioner f¨or att g˚a igenom loggfilerna och plocka ut varje kolumn, rad f¨or rad, f¨or att l¨agga in dem i en databas. Att lagra data i en databas ¨ar smidigt d˚a det ¨ar enkelt att h¨amta data ur databasen med queries. Det passade bra ihop med projektets syfte med tanke p˚a att det ska g˚a att ange fr˚agest¨allningar och presentera resultat.

SQLite

Programmet ska g˚a att k¨ora lokalt p˚a en dator, d¨arf¨or gjordes valet att anv¨anda databashanteraren SQLite, d¨ar databasen lagras lokalt som en fil (SQLite, 2015). D¨armed beh¨over det inte finnas en extern server att lagra databasen p˚a. SQLite laddas ner som ett bibliotek till C# och blir d¨armed integrerat i programmet.

16 4.4. Utv¨ardering och datainsamling

4.4

Utv¨

ardering och datainsamling

Ett test togs fram f¨or att anv¨andas i flygsimulatorn. En rad av uppgif-ter togs fram som antas generera h¨og kognitiv belastning. Anv¨andaren fick m˚al (i koordinatform) och andra instruktioner auditivt och beh¨ovde d¨arefter manuellt knappa in koordinater i systemet. Anv¨andaren var ej stridspilot men hade stora kunskaper om Gripens cockpitdesign och hur systemet anv¨ands. Vissa krav fanns under hela testet f¨or att ¨oka den f¨ or-v¨antade arbetsbelastningen, exempelvis fanns det en h¨ojdbegr¨ansning som skulle h˚allas d˚a flygplanet var ¨over vatten och vid ett tillf¨alle i simuleringen t¨omdes br¨anslet s˚a att en n¨odlandning beh¨ovde ske.

4.4.1

Loggfiler

Aktivitet registrerades i tre separata loggfiler, ButtonEvents, ContinuousLog samt LayoutEvents. ButtonEvents inneh˚aller information om alla aktivite-ter med knappar under testet. ContinuousLog inneh˚aller kontinuerlig data som h¨ojd, hastighet och liknande. LayoutEvents inneh˚aller vad som visas p˚a sk¨armarna. Loggfilernas tidsst¨amplar ¨ar inte synkroniserade och tidsinter-vallet mellan m¨atningar skiljer sig mellan de olika filerna. I ButtonEvents-filen registreras en m¨atning n¨ar en aktivitet sker med en knapp, I Conti-nuousLog registreras en m¨atning varje sekund, med en differens p˚a n˚agra hundradels sekunder mellan varje m¨atning. LayoutEvents-h¨andelser regi-streras n¨ar inneh˚allet p˚a sk¨armarna ¨andras.

Kapitel 5

Resultat

Detta avsnitt beskriver funktionella krav, hur gr¨anssnittet ser ut och vilka funktioner som finns i verktyget. Sist beskrivs hur verktyget kan anv¨andas f¨or att unders¨oka loggdatan som registrerades i simulatortestet.

5.1

Funktionella krav

Nedan f¨oljer de framtagna funktionella kraven som ska uppfyllas i denna ut-vecklingsfas, utifr˚an user stories och de framtagna fr˚agest¨allningarna. Vissa ¨

onskem˚al filtrerades bort f¨or att projektet skulle h˚alla sig inom tidsramen. Se Krav f¨or framtida utveckling.

• Det skall g˚a att definiera vilka loggfiler som ska anv¨andas. • Det skall g˚a att v¨alja ett tidsintervall i loggfiler.

• Programmet ska klara av att hantera ok¨anda v¨arden, exempelvis om till¨agg av nya varningar eller nya bildmoder sker.

• Det skall g˚a att s¨atta upp matematiska/logiska s¨okvillkor som utg˚ar fr˚an registrerade data och f˚a ut tider f¨or n¨ar villkoren ¨ar uppfyllda.

18 5.2. Implementation

• Skall kunna v¨alja bland registrerade data i ett GUI utan att beh¨ova veta exakt vad variablerna och deras uppr¨akningsbara v¨arden heter. • Det skall g˚a att s¨oka efter sekvenser av h¨andelser.

• Det skall vara enkelt att l¨agga till hantering av fler variabler fr˚an loggfil.

• Det skall g˚a att s¨atta ett startvillkor och ett stoppvillkor och f˚a ut tider.

5.1.1

Krav f¨

or framtida utveckling

• Kunna plotta resultatet av en s¨okfr˚aga grafiskt alternativt exportera data s˚a att det g˚ar att plotta med ett externt program.

5.2

Implementation

Inneh˚allet i loggfilerna samt gr¨anssnittet och funktionaliteten f¨or respektive flik beskrivs nedan.

Anv¨andaren beh¨over ladda upp de olika loggfilerna separat. Tre knappar med funktioner har implementerats f¨or att hantera respektive loggfil (se figur 6.1).

5.2.1

ButtonEvents

I ButtonEvents-loggen lagras alla knappinteraktioner. Data fr˚an Button-Eventstabellen i databasen h¨amtas och representeras i gr¨anssnittet i re-spektive kolumn. I dessa kolumner kan en anv¨andare markera de element som skall unders¨okas och sedan klicka p˚a en knapp f¨or att generera en SQL-query vars resultat presenteras i en tabell i den nedre delen av gr¨anssnittet. En funktion f¨or att unders¨oka aktivitet i ButtonEvent-loggen implemente-rades, f¨or att en anv¨andare ska kunna ange ett antal aktiviteter per angiven

Resultat 19

Figur 5.1: GUI f¨or att ladda loggfil. ButtonEventlog ¨ar laddad

tidsenhet och filtrera s¨okresultatet utifr˚an aktivitetsfiltret. D¨armed kan en anv¨andare sj¨alv best¨amma vad som ¨ar ”mycket aktivitet” i olika scenarier. Det g˚ar ¨aven att ange en start- och en sluttid och se vilka aktiviteter som finns d¨ar, utifr˚an vilka val som definierats tidigare.

Figur 5.2: Funktioner i GUI f¨or filtrering av data ur ButtonEvent

5.2.2

ContinuousLog

I ContinuousLog lagras kontinuerlig data, som flygh¨ojd och hastighet. I gr¨anssnittet g˚ar det att ange intervall f¨or respektive data, anges ingenting

20 5.2. Implementation

Figur 5.3: Exempel p˚a en av verktyget genererad SQL-query

visas samtliga poster. Det g˚ar ¨aven att ange ett tidsintervall f¨or att filtrera resultatet.

Figur 5.4: Funktioner i GUI f¨or filtrering av data ur ContinuousLog

5.2.3

LayoutEvent

LayoutEvent-loggen lagrar vad som visas p˚a de olika delarna av sk¨armarna. Gr¨anssnittet ¨ar uppbyggt som tre sk¨armar med en ¨ovre och en nedre del d¨ar all data fr˚an loggfilen visas. Anv¨andaren kan markera vilka sk¨armar denne ¨ar intresserad av att se aktivitet p˚a och generera en tabell som visar detta. ¨Aven h¨ar g˚ar det att ange ett tidsintervall f¨or att filtrera resultatet.

Resultat 21

Figur 5.5: Funktioner i GUI f¨or filtrering av data ur LayoutEvent

5.3

Utv¨

ardering

Under testet som utf¨ordes i simulator uppt¨acktes flera misstag som antas bero p˚a h¨og kognitiv belastning. Det var sv˚art att h˚alla h¨ojden under 500 fot under multitasking. D¨arf¨or kan man s¨oka i programmet efter alla tillf¨ al-len d¨ar h¨ojden ¨an den godk¨anda h¨ojden och unders¨oka vilka interaktioner som gjordes under dessa tidpunkter, vilka eventuellt kan antas ha en bi-dragande faktor till att h¨ojdkravet inte h¨olls. Vid en s˚adan s¨okning visas flera tillf¨allen d¨ar h¨ojden ¨ar h¨ogre ¨an 500 fot (se figur 5.6), utifr˚an dessa tidsst¨amplar kan antingen mer s¨okning g¨oras f¨or att se vilka sk¨armar som visades vid tillf¨allena eller se vilka interaktioner som gjordes med gr¨ anssnit-tet, alternativt kan dessa tidpunkter anv¨andas f¨or att enklare g˚a igenom videomaterial. Om vi vet att h¨ojdkravet beh¨ovde h˚allas mellan klockan 15:09 och 15:17 kan en s¨okning g¨oras, d¨ar resultatet i tabellen ¨ar samtliga loggade tidpunkter mellan 15:09 och 15:17 d¨ar h¨ojden ¨overstiger 500 fot.

22 5.3. Utv¨ardering

Figur 5.6: Tidpunkter d¨ar Bar Alt (h¨ojd) > 500 mellan tidpunkterna 15:09 och 15:17

Resultat 23

24 5.3. Utv¨ardering

Kapitel 6

Diskussion

Det h¨ar avsnittet best˚ar av resultatdiskussion, d¨ar resultatet diskuteras och kopplas till fr˚agest¨allningar, samt en metoddiskussion d¨ar metodvalet diskuteras.

6.1

Resultatdiskussion

Det h¨ar arbetet har resulterat i ett verktyg som skall anv¨andas som kom-plement till anv¨andbarhetsutv¨ardering. Fr˚agest¨allningarna var:

• Hur kan ett verktyg implementeras f¨or att underl¨atta tolkning av registrerad data?

• Hur kan ett verktyg, genom att unders¨oka data, anv¨andas som kom-plement till konventionell anv¨andbarhetstestning?

• Hur n˚as systemets krav p˚a funktionalitet utifr˚an projektets syfte? • Hur kan man omvandla informationen fr˚an en loggfil till ett format

26 6.1. Resultatdiskussion

D˚a loggfilerna f¨or nuvarande ¨ar tre till antalet, och kan komma att ut¨okas med fler typer av loggfiler, gjordes valet att implementera en flik f¨or varje typ av loggfil i gr¨anssnittet. Funktionaliteten f¨or att ladda och lagra da-ta fr˚an filen i databas ¨ar konsekvent f¨or alla loggfiler. D¨armed beh¨over en utvecklare endast skapa en ny flik f¨or en ny loggfil och utg˚a fr˚an kodstruk-turen n¨ar den nya filen skall l¨asas in och lagras i databasen. D˚a programmet skall kunna hantera ok¨anda v¨arden s˚a skapades en funktion som l¨aser varje kolumn och l¨agger in den str¨ang som finns d¨ar i databasen. D¨armed kan flera typer av exempelvis knappar registreras i loggfilen och programmet kan hantera det. D˚a informationen ¨ar av olika typer i respektive loggfiler beh¨ovde ett unikt gr¨anssnitt tas fram f¨or varje typ av loggfil, vilket ocks˚a motiverar valet av implementationen av flikar.

Verktyget ¨ar t¨ankt att anv¨andas f¨or att unders¨oka data i efterhand som komplement till den anv¨andbarhetsutv¨ardering som idag utf¨ors. Eftersom ett test i en simulator kan ta l˚ang tid och inneh˚alla m˚anga olika aktiviteter kan loggfilerna bli stora, vilket g¨or att det ¨ar tids¨odande att manuellt g˚a igenom dessa f¨or att finna intressanta punkter. D˚a det finns flera separata filer ¨ar det osmidigt att manuellt korrelera funnen data i en fil med data i en annan, speciellt om flera punkter skall unders¨okas samtidigt.

En anv¨andare kan exempelvis anv¨anda verktyget f¨or att se vilka sk¨armar och knappar som anv¨andes under ett test. P˚a det s¨attet g˚ar det att f˚a reda p˚a om det finns tillf¨allen d˚a vissa knappar eller sk¨armar aldrig anv¨ands eller hur ofta vissa knappar eller sk¨armar anv¨ands. Det kan vara sv˚art f¨or en anv¨andare att efter ett simulatortest sj¨alv svara p˚a hur m˚anga g˚anger denne tryckte p˚a en viss knapp eller bytte bild p˚a en sk¨arm och d¨arf¨or ¨ar detta verktyg bra f¨or att ta reda p˚a svaret p˚a fr˚agor som denna.

Om aktiviteter som missas p˚a grund av h¨og kognitiv belastning skall un-ders¨okas kan man se p˚a en tidpunkt f¨or en varning, och sedan s¨oka efter samtliga eller relevanta knapptryckningar inom en viss tid efter att h¨ an-delsen intr¨affat och se om det st¨ammer ¨overens med den f¨orv¨antade serien av interaktioner. Eftersom knapptryckningarna visas kronologiskt i en lista blir det enkelt att se i vilken ordning och med vilket tidsspann knapp-tryckningar g¨ors. (se figur 5.6 och 5.7). D˚a det f¨or nuvarande inte loggas h¨andelser i GUI, f¨orutom vilka sk¨armar som visas, ¨ar det sv˚art att unders¨

o-Diskussion 27

ka relevanta reaktionstider (exempelvis d˚a en varning visas tills varningen ¨

ar ˚atg¨ardad). N˚agot som framkom under utv¨arderingstestet var att an-v¨andaren inte uppt¨ackte att br¨ansletanken var tom. Detta skulle kunna analyseras med verktyget genom att s¨oka efter den tidpunkten och se vilka interaktioner som gjordes, om det kan ha varit en bidragande faktor till att varningen missades.

6.2

Metoddiskussion

Valet att anv¨anda SQLite som databashanterare medf¨orde en integrerad databasmotor som l¨aser och skriver till filer p˚a h˚arddisken. M˚anga andra databashanterare ¨ar klient/serverbaserade och f¨ors¨oker implementera ett delat lagringsutrymme. N¨ar det g¨aller detta verktyg s˚a ¨ar inte data separe-rat fr˚an applikationen ¨over ett n¨atverk, d¨arf¨or beh¨ovs inte en databashante-rare som ¨ar klient/serverbaserad. En anv¨andare skall inte heller beh¨ova vara uppkopplad mot internet vilket ocks˚a motiverar valet av SQLite. SQLite har en annan f¨ordel i att det ¨ar gratis att anv¨anda samt g˚ar att integrera i flera olika programmeringsspr˚ak. I C# g¨ors detta enkelt genom att ladda ned och inkludera ett bibliotek. Databasen som skapas med SQLite be-st˚ar av en enda fil som kan mailas eller flyttas med ett USB-minne. Andra f¨ordelar med att v¨alja SQLite ¨ar bland annat att filformatet p˚a databasen g˚ar att flytta mellan 32-bit och 64-bit operativsystem (SQLite, 2015) vilket g¨or det smidigt att kopiera programmet till olika datorer utan att ett nytt bibliotek beh¨over inkluderas. Det finns vissa begr¨ansningar med SQLite, till exempel att den inte hanterar lika avancerade queries som andra da-tabashanterare. Detta har inte varit n˚agot problem i det h¨ar arbetet men kan komma att bli det d˚a queries beh¨over vara mer avancerade.

N¨ar det g¨aller anv¨andningen av Scrummetodik i ett enmansprojekt s˚a var det optimalt ha en sprintl¨angd p˚a en vecka. En sprintl¨angd skall vara maxi-malt en m˚anad l˚ang (Schwaber and Sutherland, 2011). Sprintl¨angden sattes till en vecka p˚a grund av projektets korta tidsram, detta f¨or att kontinu-erligt tr¨affa produkt¨agaren tillr¨ackligt m˚anga g˚anger under implementa-tionsprocessen. Att ta fram funktionella krav utifr˚an user stories samt att

28 6.3. Vidareutveckling

sortera dem i en produktbacklogg fungerade bra f¨or att f˚a en struktur p˚a projektet. Andra programmeringsspr˚ak, som Java eller C++ hade f¨ ormod-ligen g˚att att anv¨anda i implementationen med goda resultat. SQLite, som fungerade v¨aldigt bra f¨or programmets syfte, g˚ar som n¨amnt att integrera i ett flertal olika spr˚ak.

6.3

Vidareutveckling

Ett s¨att att utveckla programmet vidare ¨ar att implementera en ytterligare flik d¨ar alla resultat fr˚an de genererade queries produceras i en tabell. Detta kan g¨oras med en SQL-join som anv¨ands f¨or att kombinera rader fr˚an flera tabeller, utifr˚an ett gemensamt f¨alt, som i detta fall ¨ar tidsst¨ampel som finns i samtliga tabeller. Detta g¨ors f¨or att analysera loggfilerna tillsammans och d¨armed g¨ora det enklare att se h¨andelser i de olika loggarna vid samma tidpunkt, utan att beh¨ova byta mellan olika flikar.

D˚a programmet kan ut¨okas till att hantera fler olika loggvariabler och filer s˚a finns det stora m¨ojligheter att g¨ora mer avancerade analyser av kognitiv belastning. Om algoritmer tas fram f¨or olika m˚att av mental belastning kan dessa funktioner implementeras och anv¨andas p˚a de data som registrerats i en simulering. Ytterligare funktionalitet f¨or att kunna avg¨ora det fysiska avst˚andet mellan olika knappar i buttonEvent-loggen kan g¨ora det m¨ oj-ligt att vikta arbetsbelastning p˚a olika s¨att beroende p˚a var knappar ¨ar placerade i cockpit. Wickens multiple resource model (Wickens, 1984) kan anv¨andas n¨ar fler typer av loggdata finns, d˚a kan datan delas upp i visuellt, auditivt och manuellt och d¨armed ge ¨annu b¨attre analyser.

N¨ar det g¨aller gr¨anssnittet s˚a finns det f¨orb¨attringar som kan g¨oras d˚a fokus inte legat p˚a att ta fram det perfekta gr¨anssnittet f¨or syftet. Det skulle exempelvis beh¨ovas input fr˚an anv¨andartester, som t¨anka h¨ogt-metoden eller SUS-m¨atning. Att g¨ora dessa tester skulle ge en bild av hur anv¨andbart verktyget ¨ar f¨or anv¨andare och f¨orb¨attringar kan d˚a g¨oras utifr˚an resultatet.

Kapitel 7

Slutsats

Syftet med detta arbete var: F¨or att inte beh¨ova leta upp intressanta h¨ an-delser i registrerad data manuellt ska ett verktyg designas och implemen-teras d¨ar en anv¨andare kan ange en fr˚agest¨allning och f˚a resultatet presen-terat.

Ett verktyg har tagits fram som kan sortera och filtrera data utifr˚an en anv¨andares preferenser. Verktyget har ¨oppnat upp f¨or nya m¨ojligheter att anv¨anda registrerad data fr˚an loggfiler i anv¨andbarhetsutv¨ardering. Det blir speciellt anv¨andbart d˚a filerna blir st¨orre och inneh˚aller mer data d˚a det minskar den kognitiva belastningen hos den som skall utv¨ardera de registrerade data som finns. En anv¨andare kan ange en fr˚agest¨allning genom att v¨alja ut och filtrera de intressanta elementen i gr¨anssnittet. Programmet genererar en SQL-query utifr˚an anv¨andarens val och presenterar resultatet i en tabell. Som programmet ser ut i detta f¨orsta stadie s˚a ¨ar en m¨ojlig till¨ampning att anv¨anda det f¨or att finna intressanta punkter att granska n¨armare i videomaterial. D˚a fler typer av data registreras i loggfiler kan programmet ut¨okas f¨or utf¨orligare analyser.

Litteraturf¨

orteckning

Barnard, Y. F., Sandberg, J. a. C., and van Someren, M. W. (1994). THE THINK ALOUD METHOD A practical guide to modelling cognitive pro-cesses. Academic Press, London.

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Grenning, M. F. J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Martin, B. M. R. C., Mellor, S., Schwaber, K., Sutherland, J., and Dave, T. (2001). Manifesto for Agile Software Development.

Beedle, M., Devos, M., Sharon, Y., Schwaber, K., and Sutherland, J. (1999). SCRUM : An extension pattern language for hyperproductive software development. Pattern Languages of Program Design, 4:1–18.

Benthem, K. D. V., Herdman, C. M., Tolton, R. G., and Lefevre, J.-a. (2015). Prospective Memory Failures in Aviation : Effects of Cue Sa-lience, Workload, and Individual Differences. Aerospace Medicine and Human Performance, 86(4):366–373.

Brooke, J. (1996). SUS-A quick and dirty usability scale. Usability evalu-ation in industry.

Dalcher, D. and Brodie, L. (2007). Successful IT Projects. Middlesex Uni-versity Press, London.

DB-Engines (2015). DB-Engines Ranking - popularity ranking of relational DBMS.

Endsley, M. R. (1988). Design and Evaluation for Situation Awareness En-hancement. Proceedings of the Human Factors and Ergonomics Society Annual Meeting, 32(2):97–101.

ISO (1993). ISO 9241-11: Guidelines for specifying and measuring usability. Jander, H., Borgvall, J., and Castor, M. (2011). Brain Budget Evaluation of Human Machine Interaction in System Development for High Risk and Task Critical Environments Information Systems. (September). Kahneman, D. (1973). Attention and effort. Prentice-Hall, Englewood

Cliffs, New Jersey.

Pruitt, J. (2011). Personal Scrum | John Pruitt on WordPress.com. http://blog.jgpruitt.com/2011/04/10/personal-scrum/.

Schwaber, K. and Sutherland, J. (2011). The scrum guide. Scrum. org, October, 2(July):17.

SQLite (2015). About SQLite. https://www.sqlite.org/about.html.

Sweller, J. (1988). Cognitive load during problem solving: Effects on lear-ning. Cognitive Science, 12(2):257–285.

Wickens, C. D. (1984). Processing resources in attention, dual task perfor-mance, and workload assessment. Academic Press, New York.

Wickens, C. D. (2008). Multiple resources and mental workload. Human factors, 50(3):449–455.

Wickens, C. D., Hollands, J. G., Banbury, S., and Parasuraman, R. (2013). Engineering Psychology and Human Performance. Pearson, New Jersey, 4th edition.

Copyright

Svenska

Detta dokument h˚alls tillg¨angligt p˚a Internet - eller dess framtida ers¨attare - under 25 ˚ar fr˚an publiceringsdatum under f¨oruts¨attning att inga extraordin¨ara omst¨andigheter uppst˚ar. Tillg˚ang till dokumentet inneb¨ar tillst˚and f¨or var och en att l¨asa, ladda ner, skriva ut enstaka kopior f¨or enskilt bruk och att anv¨anda det of¨or¨andrat f¨or ickekommersiell forskning och f¨or undervisning. ¨Overf¨oring av upphovsr¨atten vid en senare tidpunkt kan inte upph¨ava detta tillst˚and. All annan anv¨andning av dokumentet kr¨aver upphovsmannens medgivande. F¨or att garantera ¨aktheten, s¨akerheten och tillg¨angligheten finns det l¨osningar av teknisk och administrativ art.

Upphovsmannens ideella r¨att innefattar r¨att att bli n¨amnd som upphovsman i den omfattning som god sed kr¨aver vid anv¨andning av dokumentet p˚a ovan beskrivna s¨att samt skydd mot att dokumentet ¨andras eller presenteras i s˚adan form eller i s˚adant sammanhang som ¨ar kr¨ankande f¨or upphovsmannens litter¨ara eller konstn¨arliga anseende eller egenart.

F¨or ytterligare information om Link¨oping University Electronic Press se f¨orlagets hemsida http://www.ep.liu.se/

English

The publishers will keep this document online on the Internet or its possible replacement -for a period of 25 years from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Link¨oping University Electronic Press and its proce-dures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/

c

Caroline Karlsson Link¨oping, 15 juni 2015